Many new validate failures, "Synonym in TyConAppCo"-related

Hi, I suddenly get Unexpected failures: gadt T7294 [exit code non-0] (normal) indexed-types/should_compile GADT1 [exit code non-0] (normal) indexed-types/should_compile GADT11 [exit code non-0] (normal) indexed-types/s

Re: Validate failures

Hi, a small reminder to the masteres of the stable branch: The ghc-7.8 branch currently still does not validate on Travis: Am Samstag, den 03.05.2014, 22:08 +0200 schrieb Joachim Breitner: > ghc-7.8: > > Unexpected failures: >annotations/should_compile/th annth_compunits [b

Re: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow

Hi, Am Freitag, den 30.05.2014, 09:28 + schrieb Simon Peyton Jones: > I've improved Note [Order of Coercible Instances] in TcInteract > > Generally, it's much better to give an actual, concrete example in the > Note, and refer to the ticket for additional background. It took me a > few minut

Re: Validate failures

Dear Release branch managers, may I remind you of this small merge request? It would help cut down noise from Travis, and help me catch real errors more easily: Am Sonntag, den 18.05.2014, 20:54 +0200 schrieb Joachim Breitner: > a small reminder to the masteres of the stable branch: The ghc-

Re: GHC/cabal release procedures, and Stackage

Hi, Am Freitag, den 06.06.2014, 12:37 + schrieb Simon Peyton Jones: > I think that would be great. Absolutely: the earlier we can catch > regressions the better. > > Couldn’t we make it part of the continuous-integration builds > (Travis?) that various folk are running, eg. Joachim? Travis h

Re: Offering GHC builder build slaves

Hi, Am Samstag, den 07.06.2014, 12:21 +0200 schrieb Páli Gábor János: > 2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk : > > It'd be a shame to have > > various test results from multiple machines but not use them. > > I see what you mean. But I would also feel strange to mark the test > results fa

Re: GHC/cabal release procedures, and Stackage

Hi Michael, Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: > If there was a daily snapshot build, I would be happy to set up some > kind of regular process to download that snapshot and do a Stackage > run on it. I'm currently blocked on this kind of activity, since I > can't ge

Re: GHC/cabal release procedures, and Stackage

Hi, Am Sonntag, den 08.06.2014, 07:55 +0300 schrieb Michael Snoyman: > > Actually, GHC HEAD isn't the problem I'm running into right now. I'm > already testing that[1] using Herbert's Ubuntu PPA[2] Ah, cool! > I'm specifically looking for builds off of the 7.8 branch so I can > start testing p

Failed to load interface for GHC.Integer.Type

Hi, since http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd6501abd98 travis is complaining: HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o HC [stage 1] libraries/ghc-prim/dist-install/b

Re: Failed to load interface for GHC.Integer.Type

Hi, Am Montag, den 09.06.2014, 23:56 +0300 schrieb Sergei Trofimovich: > I guess real fault is: > http://ghc.haskell.org/trac/ghc/changeset/f31b042c25b9c51efdbe84c1cb6f65f49534c14d/ghc I don’t think so, reverting my patch fixed it again. Given that I as able to build with the patch from an uncle

Re: Failed to load interface for GHC.Integer.Type

Hi, Am Montag, den 09.06.2014, 22:16 + schrieb Simon Peyton Jones: > I'm guessing that it may be the fact that the type-class defaulting > rules involve Integer. You added NoImplicitPrelude, which removed a > dependency on Prelude. Maybe defaulting is looking for the type > Integer, but the

Re: GHC/cabal release procedures, and Stackage

Hi, Am Sonntag, den 08.06.2014, 21:25 +0300 schrieb Michael Snoyman: > That's great news, thanks! I'll try to get a test going with that. Another benefit of this would be that it is more likely that $ cabal install criterion --with-compiler=.../ghc/inplace/bin/ghc-stage2 works, which would be v

Re: Make -fno-write-interface to all modes of GHC, not just -fno-code.

Hi, it seems that commit 05120ecd95b2ebf9b096a95304793cd78be9506e Author: Edward Z. Yang Date: Fri Jun 27 13:48:19 2014 +0100 Make -fno-write-interface to all modes of GHC, not just -fno-code. Signed-off-by: Edward Z. Y

Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding

Hi, Am Donnerstag, den 03.07.2014, 10:44 +0200 schrieb Jan Stolarek: > Now, I understand people who don't want such change because of merge > conflicts. But the truth is there will never be a good moment to > implement such changes because there is always some ongoing > work and outstanding branc

Re: 7.8.3 source tarball imminent

[Resending this from an address allowed to post on ghc-devs] Hi, Am Donnerstag, den 10.07.2014, 01:50 -0500 schrieb Austin Seipp: > Hi all, > > After all the paranoia and double-checking, the source tarballs are online: > > https://www.haskell.org/ghc/dist/7.8.3/ Debian package on its way to t

Put GHC on travis for real

Hi, with all packages as submodules, ghc-complete (which is basically a git repository tracking the „fingerprint“ of the main repository) is obsolete. So we could move the travis-checking of the main line to run on the ghc repository directly. This would require * adding a .travis.yaml based on

Re: Put GHC on travis for real

Hi, Am Freitag, den 11.07.2014, 13:39 +0200 schrieb Herbert Valerio Riedel: > Travis-CI is enabled for ghc/ghc with "Build only if .travis.yml is present" > > I'd suggest you create a self-contained .travis.yml in a wip/ branch ( > as that should trigger travis-builds) and tweak it there until it

Re: Put GHC on travis for real

Hi, Am Freitag, den 11.07.2014, 14:48 +0200 schrieb Herbert Valerio Riedel: > So travis does a recursive clone by default? So that we can't even > easily inject > > > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#AlternativeGitHubrewriterules > > ? > > If I get the

Travis now tests ghc directly

Hi, I just added a .travis.yml file to GHC master. This means that every push will be validated automatic and for free by travis; you can check the build status at https://travis-ci.org/ghc/ghc/builds It is not a full validation. In particular, * it skips DPH * it does not build dynamic librari

Re: Trac spam

Hi, Am Montag, den 14.07.2014, 09:43 +0200 schrieb Herbert Valerio Riedel: > On 2014-07-14 at 09:34:07 +0200, Simon Peyton Jones wrote: > > Is it possible to stop spam on GHC's Trac? > > A few days ago, bots/users registering via @yahoo.com addresses managed > to break the (rather simple) text-ba

Re: [commit: ghc] master: Update various performance benchmarks (194107e)

Hi, Am Montag, den 14.07.2014, 11:13 + schrieb Simon Peyton Jones: > I'ts important to monitor the actual bump, rather than the first time > the limit is broken. (They aren't the same, of course.) Quite right. I am in the process of setting up per-commit monitoring of _nofib_ results, and I

Re: T9203

continue on) https://ghc.haskell.org/trac/ghc/ticket/9315 for a discussion of that problem. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digital

Re: Travis now tests ghc directly

Hi, Am Dienstag, den 15.07.2014, 08:38 + schrieb Simon Peyton Jones: > This is all fantastic, thank you Joachim. But how would a new GHC dev > find out this information? Could it please be documented on the wiki? Yes, I plan to do it once it settles, there are still a view things to observe

GhcLibHcOpts: -O or -O2?

://ghc.haskell.org/trac/ghc/ticket/9315#comment:5 but I wanted to the wider audience of the mailing list for such a design decision.) Thanks, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc

Building GHC under Wine?

Hi, I feel sorry for Simon always repeatedly stuck with an unbuildable tree, and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it likely to catch the kind of problems that Simon is getting? If so, maybe it runs fast enough to be also tested by travis on every commit? (This mail

Beta Performance dashboard

tup could manages this, with a dedicated builder doing the benchmark runs and the builder server scheduling a build for each commit. That’s it for now. Enjoy clicking around! Greetings, Joachim ¹ I guess that could be considered beta-reduction :-) -- Joachim Breitner e-Mail: m...@joac

Re: Travis now tests ghc directly

Hi, Am Dienstag, den 15.07.2014, 23:34 +0200 schrieb Joachim Breitner: > Am Dienstag, den 15.07.2014, 08:38 + schrieb Simon Peyton Jones: > > This is all fantastic, thank you Joachim. But how would a new GHC dev > > find out this information? Could it please be documen

Re: Building GHC under Wine?

Hi, Am Freitag, den 18.07.2014, 08:38 +0100 schrieb Simon Marlow: > I might be misremembering, but I believe someone (Ross Paterson?) used > to do this a while ago. > > I can't think of any good reasons it *shouldn't* work. Then, next question: Is it likely to find windows building failures, ar

Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW?

Hi, Am Freitag, den 18.07.2014, 07:25 + schrieb Simon Peyton Jones: > | 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 > | H

Re: Update Cabal submodule to HEAD (1.21)

Hi Edward, your commit makes the builders fail: [28 of 79] Compiling Distribution.Simple.Utils ( libraries/Cabal/Cabal/Distribution/Simple/Utils.hs, bootstrapping/Distribution/Simple/Utils.o ) libraries/Cabal/Cabal/Distribution/Simple/Utils.hs:382:46: `Process.delegate_ctlc' is not a (visi

Re: Update Cabal submodule to HEAD (1.21)

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 w

Re: Update Cabal submodule to HEAD (1.21)

Hi, Am Samstag, den 19.07.2014, 16:48 +0200 schrieb Joachim Breitner: > 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. >

Re: Update Cabal submodule to HEAD (1.21)

Hi, Am Sonntag, den 20.07.2014, 16:58 +0200 schrieb Joachim Breitner: > > > I suppose if you /really/ wanted to we could add a > > > macro to disable ctl-c support and pass it on the zeroboot. > > > I tried that (there is already a macro BOOTSTRAPPING), and then it d

Re: Update Cabal submodule to HEAD (1.21)

But anyways... > Excerpts from Joachim Breitner's message of 2014-07-20 16:55:20 +0100: > > Am Sonntag, den 20.07.2014, 16:58 +0200 schrieb Joachim Breitner: > > So I got a working configuration. The following patch needs to be > > applied to Cabal: > > > &g

Re: Update Cabal submodule to HEAD (1.21)

Hi, Am Sonntag, den 20.07.2014, 22:57 +0100 schrieb Edward Z.Yang: > Since this patch causes GHC HEAD to not bootstrap out of the box > from GHC 7.6, I've reverted it for now. We'll have to cross > this bridge sometime though. thanks. Cabal already has applied the patch to make the initial ghc

Re: Multi-instance packages status report

Hi, Am Montag, den 21.07.2014, 18:43 +0100 schrieb Edward Z.Yang: > In my copy of GHC and Cabal [1,2], you can now install multiple copies of a > package with differing dependencies to the package database, i.e. q-1.0 > compiled against p-1.0, and against p-2.0. The packages in the database > ar

Re: Beta Performance dashboard

hem with changed build settings. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___

Re: Multi-instance packages status report

[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

Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW?

Hi Rob, Am Montag, den 21.07.2014, 22:55 +0100 schrieb Rob Stewart: > On 18 July 2014 09:01, Joachim Breitner wrote: > > Am Freitag, den 18.07.2014, 07:25 + schrieb Simon Peyton Jones: > >> | On Saturday 6th September is the Haskell Implementers Workshop. There > &g

Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW?

ing off at 19:10) and might not be able to attend the last session. Who is able to fill in for me if the infrastructure talk is scheduled here? Maybe Simon M, or Austin, or Herbert? Of some coalition thereof Thanks, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http:

Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW?

Hi, Am Dienstag, den 22.07.2014, 17:12 +0200 schrieb Joachim Breitner: > Am Dienstag, den 22.07.2014, 12:12 +0200 schrieb Jost Berthold: > > (Sorry for joining this late... I figured we would be in dialogue off > > the list eventually) > > > > Joachim wrote and pos

Re: Removing GHC's dependency on Cabal

Hi, Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang: > We were wondering if there was any reason to prefer the former > situation over the latter. One way to decide that is to ask “What is the more stable interface”? I.e. under what circumstances will upgrading Cabal require up

Re: Dashboard

Dear Alexander, Am Dienstag, den 29.07.2014, 03:27 +0400 schrieb Alexander Pakhomov: > I think automatic regression notification at least to the author is a good > idea. > Probably I can do it in a nearest time. Unfortunately, right now I fail to > get your code up. > Also I believe it is a good

Build broken: Forall'd constraint ‘Ix i’ is not bound in RULE lhs

Hi SPJ, it seems as if your latest commit “Improve the desugaring of RULES, esp those from SPECIALISE pragmas” broke the build (when building with -Werror and -dcore-lint): libraries/array/Data/Array/Base.hs:476:1: Warning: Forall'd constraint ‘Ix i’ is not bound in RULE lhs showsIArray

Re: Build broken: Forall'd constraint ‘Ix i’ is not bound in RULE lhs

Hi, Am Freitag, den 01.08.2014, 20:27 + schrieb Simon Peyton Jones: > OK fixed I think. Apologies. looks good, all green on https://travis-ci.org/ghc/ghc/builds/31457663 Thanks, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner

Re: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)

Hi, Am Freitag, den 01.08.2014, 20:28 + schrieb Simon Peyton Jones: > Urk. It's quite surprising that this particular change would increase > allocation significantly. > I wonder whether it just pushed it over the threshold. I’m confident it was not just that: ~/logs $ fgrep 'Deviation

Re: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)

Hi, Am Freitag, den 01.08.2014, 23:27 +0200 schrieb Joachim Breitner: > Am Freitag, den 01.08.2014, 20:28 + schrieb Simon Peyton Jones: > > Urk. It's quite surprising that this particular change would increase > > allocation significantly. > > I wonder whether

Re: Question about BangPatterns semantics/documentation

Hi Herbert, Am Sonntag, den 03.08.2014, 11:31 +0200 schrieb Herbert Valerio Riedel: > However, the following two functions are not equivalent after > compilation to Core: > > g, h :: (Int -> Int) -> Int -> () > g f x = let !y = f x in () > h f x = case f x of y -> () > > In fact, compilati

Re: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)

Hi, Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang: > Yes, on my box, this test is now failing (because the stat is too good): > > Expectedhaddock.base(normal) max_bytes_used: 127954488 +/-10% > Lower bound haddock.base(normal) max_bytes_used: 115159039 > Upper boun

Re: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)

Hi, Am Montag, den 04.08.2014, 13:08 +0200 schrieb Joachim Breitner: > Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang: > > Yes, on my box, this test is now failing (because the stat is too good): > > > > Expectedhaddock.base(normal) max_bytes_

Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)

Hi, the attached commit seems to have regressed the scs nofib benchmark by ~3%: http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?exe=2&base=2+68&ben=nofib/time/scs&env=1&revs=50&equid=on The graph unfortunately is in the wrong order, as the tool gets confused by timezones

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)

Hi Sergei, Am Mittwoch, den 06.08.2014, 22:15 +0300 schrieb Sergei Trofimovich: > On Wed, 06 Aug 2014 09:30:45 +0200 Joachim Breitner > wrote: > > the attached commit seems to have regressed the scs nofib benchmark by > > ~3%: > > http://ghcspeed-nomeata.rhcloud.com/time

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)

Hi, Am Mittwoch, den 06.08.2014, 23:40 +0300 schrieb Sergei Trofimovich: > I think I know what happens. According to perf the benchmark spends 34%+ > of time in garbage collection ('perf record -- $args'/'perf report'): > > 27,91% test test [.] evacuate

Re: Status updates

Hi, Am Dienstag, den 19.08.2014, 08:39 -0500 schrieb Austin Seipp: > - Phabricator now has significantly better build integration, as I'm > sure many of you have seen. It is less noisy (and doesn't email you as > much), has better logging support (that actually works), and it now > builds commit

Re: Proposal: run GHC API tests on fast

Hi Edward, Am Freitag, den 22.08.2014, 18:01 +0100 schrieb Edward Z.Yang: > OK, I've gone ahead and done this. I’m seeing errors like this on travis, with DEBUG_STAGE2=YES, but with varying test cases from ghc-api: Compile failed (status 256) errors were: [1 of 1] Compiling Main ( g

Re: Proposal: run GHC API tests on fast

Hi, Am Samstag, den 23.08.2014, 18:57 +0100 schrieb Edward Z.Yang: > I couldn't reproduce this error on x86_64 with BuildFlavour = devel2. > Is perhaps parallelism involved? likely. Did you try validating with "CPUS=2"? (But then, I believe that is actually the default). Greetings, Joachim --

Re: nofib external dependencies

Hi, Am Montag, den 25.08.2014, 18:35 +0400 schrieb Alexander Pakhomov: > I've noticed nofib depends on external packages, such as vector. > So when vector is updated we have a benchmark result change even without > compiler changes. > I guess we need to use fixed version. When some package has m

Contributing To Haskell talk

Hi list, you might know that was I talked into^W^Wvolunteered to holding the “Contributing to GHC”¹ talk at HIW in 9 days. I’ll do it, but for some of the intended topics, I don’t feel like the best person to do it on my own. In particular, I was wondering if any of the active Phabricator propone

Re: build fixes

Hi, Am Freitag, den 29.08.2014, 10:04 + schrieb Simon Peyton Jones: > I’ve pushed patches that should finally fix the build. (including > improved performance in the compiler itself!) oh wow, what a huge number of patches. It’ll take a few days for http://ghcspeed-nomeata.rhcloud.com/ to ca

Re: build fixes

Sorry, Am Freitag, den 29.08.2014, 09:53 -0700 schrieb Joachim Breitner: > ¹ https://github.com/tobami/codespeed should have been https://github.com/tobami/codespeed/issues/173 Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner

Re: cons/build and making rules look boring

Dear Sven, glad to you are making progress! Am Samstag, den 30.08.2014, 18:05 -0400 schrieb David Feuer: > I think I may have figured out at least part of the reason that > cons/build gives bad results. I actually ran into a clue when working > on scanl. It seems at least part of the problem is t

Re: Proposal: run GHC API tests on fast

Hi, Am Dienstag, den 02.09.2014, 09:08 +0200 schrieb Edward Z.Yang: > I pushed a fix for the tests in ghc-api. thanks! Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F De

Re: Extending fold/build fusion

Dear Akio, Am Mittwoch, den 12.03.2014, 19:36 +0100 schrieb Joachim Breitner: > Dear Akio, > > Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano: > > I modified the base library to use foldrW/buildW, with no changes to > > foldl yet. nofib showed a very big regre

Re: slow Trac

Hi, Am Freitag, den 05.09.2014, 03:21 -0500 schrieb Austin Seipp: > Update: Trac should be much more responsive now (and Hackage too), but > Hackage still needs more investigation. Still ongoing for the > moment... I’m still observing bad response times, and errors like "database locked". If the

Re: Trying to fix an efficiency issue noted in a TODO in SAT.hs

Hi David, Am Samstag, den 06.09.2014, 23:05 -0400 schrieb David Feuer: > compiler/simplCore/SAT.hs has a TODO comment about the fact that it > does a fair bit of appending onto the ends of lists, and that should > be done differently. I made an attempt to fix it. Great! We need people to work on

Re: Status updates

Hi, Am Dienstag, den 09.09.2014, 08:34 -0500 schrieb Austin Seipp: > - I've merged the Applicative Monad patchset! Yay! Many thanks to > Nathan Howell for helping me out in the end there. Please let me know > if anything explodes horribly (I hope not). Not horrible, but still, it breaks: "inpl

The list fusion lab

Hi, especially David and Dan, I wanted to announce this only when I had time to polish more corners, but since you are busy hacking on list fusion, experimenting with foldrW etc., maybe it’s better to release early (and you might enjoy polishing the corners yourself). Together with John Wiegly at

AMP performance effect

Hi, nothing overly exciting, but since I am running this ghcspeed thing, I guess I should inform you about changes, just to get some practice doing that :-) Due to various build failures, the AMP landing patch was not measured in isolation, so these numbers reflect the effect of these patches: $

Re: AMP performance effect

Hi, Am Freitag, den 12.09.2014, 10:00 -0400 schrieb Edward Z. Yang: > You are probably seeing the effects of this bug for cryptarithm1: > > https://ghc.haskell.org/trac/ghc/ticket/9570#ticket possibly. But you report runtime differences without changes in allocation numbers, whereas I obser

Re: AMP performance effect

Hi, Am Freitag, den 12.09.2014, 16:10 +0200 schrieb Johan Tibell: > Once we think pagespeed is stable enough, I would be for sending > automated emails on regressions. it is quite noisy, which is mostly due to the fact that I track the „number of failing testcases“ as a performance value, whic

Re: FoldrW/buildW issues

Hi, Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: > On Sep 12, 2014 2:35 PM, "Joachim Breitner" > wrote: > > Interesting. I assumed that some wrap.unwrap=id law would hold, or > at > > least some moral approximation (e.g. disregarding bottoms in an

Re: The list fusion lab

Hi, Am Donnerstag, den 11.09.2014, 09:46 -0400 schrieb David Feuer: > Joachim Breitner wrote: > > Together with John Wiegly at ICFP, I started to create a list > > performance laboratory. You can find it at: > > https://github.com/nomeata/list-fusion-lab > &

Re: FoldrW/buildW issues

Hi, Am Sonntag, den 14.09.2014, 14:47 -0400 schrieb David Feuer: > Your scanl wrapper might be right for scanl, but it does not satisfy > the condition Joachim proposed. In particular, if we define > > (!!) :: [a] -> Int -> a > xs !! n > | n < 0 = error "Negative index." > | otherwise = fold

Re: The list fusion lab

Hi, Am Sonntag, den 14.09.2014, 16:26 -0400 schrieb Carter Schonwald: > what fails to build with head? (current head + cabal have that fix > that still need merging in, so its hard to try criterion with current > todays head, which is all i have handy at present) > some weeks ago, I had problem

Re: Random infrastructure requests, questions and suggestions

Hi, Am Montag, den 15.09.2014, 08:22 -0500 schrieb Austin Seipp: > 5. Long term, I think Phabricator has some goals to try and do this > with its Charting/Facts application, but there isn't really anything > today I'm afraid that would be easy. We could have Phabricator submit > information to Jo

Re: Remove special casing of singleton strings, split all strings, Re: Implement `decodeDouble_Int64#` primop

the improvement of binary-trees’s runtime (4.6% regression), but no other notable changes. Again, I leave it to the respective commiters to decide if any of this is worth investigating. See http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2Ftime%2Fbinary-trees&env=

Re: FoldrW/buildW issues

Hi, Am Mittwoch, den 24.09.2014, 16:37 -0400 schrieb David Feuer: > On Sep 12, 2014 2:35 PM, "Joachim Breitner" > wrote: > > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > > function, semantically the identity, but tell th

Re: [commit: ghc] master: Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` (f636faa)

Hi, Am Samstag, den 27.09.2014, 21:07 + schrieb g...@git.haskell.org: > commit f636faa7b2b7fc1d0663f994ad08f365d39a746d > Author: Herbert Valerio Riedel > Date: Sat Sep 27 22:55:19 2014 +0200 > > Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` > > This

Re: [commit: ghc] master: Extend `Foldable` class with `length` and `null` methods (e5cca4a)

Hi, Am Sonntag, den 28.09.2014, 13:07 + schrieb g...@git.haskell.org: > commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa > Author: Herbert Valerio Riedel > Date: Sun Sep 28 13:02:53 2014 +0200 > > Extend `Foldable` class with `length` and `null` methods > > This completes the

Build time regressions

Hi, the attached graph shows a noticable increase in build time caused by Update Cabal submodule & ghc-pkg to use new module re-export types author Edward Z. Yang https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae and only halfway mitigated by Update `binary` subm

Re: GitHub pull requests

Hi, we already have the problem with some people submitting diffs on trac, other submitting git patches on trac or linking to their private fork somewhere to pull from, and others using Phabricator. And, at least as far as I can tell from here, it doesn’t seem to be a big deal. So (warning: surpr

Re: GitHub pull requests

But they will be much more motivated to do so when they have already successfully contributed something. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is

Re: Again: Uniques in GHC

Hi, Am Montag, den 06.10.2014, 09:58 + schrieb p.k.f.holzensp...@utwente.nl: > - The implementation is based on FastInts, which, on most machines > nowadays, is a 64-bit thing. The serialisation in BinIface is > explicitly based on Word32s. Aside from the obvious potential (albeit > with a lo

Re: GitHub pull requests

Hi, Am Montag, den 06.10.2014, 17:54 +0200 schrieb Tuncer Ayaz: > By the way, while the Github team has no public ticket system, they > are very responsive when you send them feature requests or, say, > explain where the review system is incomplete/broken. They never > promise anything and do not

Re: Again: Uniques in GHC

Hi, Am Montag, den 06.10.2014, 19:55 + schrieb p.k.f.holzensp...@utwente.nl: > Although I can't quite get what you're saying from the posts on that > link, I'm not immediately sure what you're saying should extend to > hi-files. These files are very much specific to the compiler version > you'

Re: oneShot (was Re: FoldrW/buildW issues)

Hi, Am Dienstag, den 07.10.2014, 03:05 -0400 schrieb David Feuer: > Just for the heck of it, I tried out an implementation of scanl using > Joachim Breitner's magical oneShot primitive. Using the test > > [..] > > with -O2 (NOT disabling Call Arity) the Core from barB is really, > really beautifu

Re: GitHub pull requests

Hi, Am Montag, den 06.10.2014, 19:32 +0200 schrieb Joachim Breitner: > Am Montag, den 06.10.2014, 17:54 +0200 schrieb Tuncer Ayaz: > > By the way, while the Github team has no public ticket system, they > > are very responsive when you send them feature requests or, say, > &

Re: [commit: ghc] master: Make Data.List.takeWhile fuse: fix #9132 (d14d3f9)

Hi, Am Mittwoch, den 08.10.2014, 06:53 + schrieb g...@git.haskell.org: > commit d14d3f92d55a352db7faf62939127060716c4694 > Author: Joachim Breitner > Date: Wed Oct 8 08:53:26 2014 +0200 > > Make Data.List.takeWhile fuse: fix #9132 > > Summary: >

Re: Request: Phab Differentials should include road maps

Hi, Am Dienstag, den 14.10.2014, 09:33 -0400 schrieb Richard Eisenberg: > What do we think? Is this a behavior we wish to adopt? sounds sensible. I only worry that if people put such comments in the DR description, they will end up in the commit pushed to the tree, if done using "arc land". Mayb

Re: Wiki: special namespace for proposals?

Hi, Am Mittwoch, den 15.10.2014, 01:12 +0300 schrieb Yuras Shumovich: > Would it be better to organize proposals under one namespace? Right now > they belongs to root namespace, so title index > ( https://ghc.haskell.org/trac/ghc/wiki/TitleIndex ) is hard to use. > > I was going to start new page

Re: Wiki: special namespace for proposals?

it fits that format). The discussion about the Proposal would still be there for those who need to do some historical digging, i.e. when someone suggest a new implementation and we need to check if that variant was considered in the original implementation. Greetings, Joachm -- Joachim Breitne

Re: Wiki: special namespace for proposals?

Hi, Am Mittwoch, den 15.10.2014, 18:48 +0200 schrieb Jan Stolarek: > Joachim >> yes, you are right that proposals and designs are different > things. > > > And we already have a namespace for that: Commentary! > Good point. > > > So when a Proposal gets implemented, this should be clearly not

Re: Merging a branch

Hi, Am Donnerstag, den 16.10.2014, 08:08 + schrieb Simon Peyton Jones: > I’d like to completely re-organise the patches before committing to > HEAD. How do I do that? Some kind of rebase? Clearly I want to > start from current HEAD, rather than having weird merge patches > involved. > >

Re: T3064 failures

haskell.org/harbormaster/ only builds of DRs are failing, the builds of recent commits to master succeed. Are these built with slightly different settings, or is that just by accident? Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.

Re: [commit: ghc] master: Reify data family instances correctly. (e319d6d)

Hi Richard, Travis is complaining about your commit: Actual stderr output differs from expected: --- ./th/T9692.stderr 2014-10-21 13:22:53.783212762 + +++ ./th/T9692.comp.stderr 2014-10-21 13:52:36.314083513 + @@ -1,2 +0,0 @@ -data family T9692.F (a_0 :: k_1) (b_2 :: k_3) :: * -dat

Re: [commit: ghc] master: Implementation of hsig (module signatures), per #9252 (aa47995)

Hi Edwardd, Am Freitag, den 24.10.2014, 23:47 + schrieb g...@git.haskell.org: > >--- > > commit aa4799534225e3fc6bbde0d5e5eeab8868cc3111 > Author: Edward Z. Yang > Date: Thu Aug 7 18:32:12 2014 +0100 > > Implementation of hs

Call Arity, oneShot or both

Hi, some months ago I tried to make foldl a good consumer in the common case. The starting point is always to write foldl k a xs = foldr (\v f a -> f (v `k` a)) id xs a and then somehow make GHC produce good code with this. I came up with two solutions: A more sophisticated compiler ana

Re: Call Arity, oneShot, or both

Hi, Am Sonntag, den 26.10.2014, 10:56 -0400 schrieb David Feuer: > > There is also the option of combining both. Then we do not get the > > regression, but still the improvement for fft2: > > I *definitely* think we should leave Call Arity in place by default > unless and until something strictl

Re: [commit: ghc] wip/oneShot: Avoid inlining oneShot in unfoldings (16066a1)

Hi, Am Sonntag, den 26.10.2014, 21:04 + schrieb Simon Peyton Jones: > | Avoid inlining oneShot in unfoldings > > I'm sure there's a reason for this but, again, please say what is, lest I > accidentally reverse it in 3 years time. don’t worry, this is a very experimental branch, barely

Re: Call Arity, oneShot, or both

Hi, Am Montag, den 27.10.2014, 03:39 -0400 schrieb David Feuer: > Joachim Breitner כתב > > That would be great! But do we have evidence of this > user-written code > that benefits? So far I have only seen relevant improvement > due to >

  1   2   3   4   5   6   7   >