tt may be that GHC 7.8 optimizes the program better.
Compile with -O0 and see if it runs out of memory, too.
If so, you can just optimize the program by hand.
I'd suggest making a heap profilie with -O0 or in GHC 7.6
and finding out where the memory goes.
Of course, it's possible you've hit a
Hi David,
I don't think this is a ghc issue.
I suspect you have too many unevaluated function calls lying around
(this would cause the runtime to run out of *stack* as opposed to
*heap*). Different versions of ghc perform different optimizations on
your code, and 7.8 knows a way to fix it that
Ok, I backed it out for all but the compound cases and the performance test
once more passes, and I can round-trip compound RdrNames.
On Fri, Dec 12, 2014 at 11:30 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
On reflection, I can try to make it work with annotations just for those
fairly
Hi,
Am Freitag, den 12.12.2014, 21:51 -0500 schrieb Richard Eisenberg:
Phab has shown up some performance regressions in my recent commits.
See https://phabricator.haskell.org/harbormaster/build/2607/. The
failures except for haddock.base are new, and evidently my fault. They
didn't show
I think I've fixed this. I've pushed the fix to wip/rae, and waiting for
validation results before pushing to master.
My hunch below was right -- it was the change to matchFam, which essentially
evaluated type-level functions more strictly. I've now made it lazier again.
I'd like to better
On Wed, 03 Dec 2014 11:59:42 +
Simon Marlow marlo...@gmail.com wrote:
In unrelated work, I saw this scroll across when happy'ing the parser:
shift/reduce conflicts: 60
reduce/reduce conflicts: 16
These numbers seem quite a bit higher than what I last remember (which
is
Fixed, hopefully!
On Dec 13, 2014, at 10:03 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
I think I've fixed this. I've pushed the fix to wip/rae, and waiting for
validation results before pushing to master.
My hunch below was right -- it was the change to matchFam, which essentially
Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
tracking those down,
Those fixes should get into 7.8.4 and 7.10 both. Currently HPC on OSX is
broken in pretty fundamental ways, and thats not ok!
-Carter
On Wed, Dec 3, 2014 at 5:53 PM, George Colpitts
Ben Gamari b...@smart-cactus.org writes:
Johan Tibell johan.tib...@gmail.com writes:
Ben,
Is this something that worked in cabal-install 1.18.0.5 and that stopped
working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you
expected to be fixed in 1.18.0.6? These 1.18 and
I tried all optimization levels of 7.6.3 and it runs out of memory
I tried all optimization levels of 7.8.3 and it doesn't
So it must be something the compiler does even without any optimization.
On Sat, Dec 13, 2014 at 3:05 AM, Mikolaj Konarski miko...@well-typed.com
wrote:
tt may be that GHC
I think there's some confusion about makeCounts's behavior. makeCount
never traverses the same thing twice. Essentially, the worst-case size of
the unevaluated thunks doesn't exceed the total size of the array of lists
that was used to create them (and that array itself was created with
I tried adding strictness to everything, forcing each line with evaluate .
force
It still runs out of memory and now running with -hc blames the extra
memory on trace elements which seems somewhat unhelpful.
On Sat, Dec 13, 2014 at 2:10 PM, David Spies dnsp...@gmail.com wrote:
I think there's
On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski
miko...@well-typed.com wrote:
On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
tracking those down,
You mean these are regressions?
OK. In that case, let's remember to get *that* version of cabal into 7.8.4.
/me conditions himself with chocolate to help the remembering
On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel ttue...@gmail.com wrote:
On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski
miko...@well-typed.com wrote:
Andreas Voellmy wrote:
Hi GHCers,
I just fixed a bug (#9423) and went through the Phab workflow. Then I did a
fresh checkout from git and ran:
$ git checkout master
$ arc patch --nobranch D129
$ git push origin master
as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator,
15 matches
Mail list logo
