Re: Dataflow analysis for Cmm

> (did you intend to send two identical links?) No :-) The branches should be js-hoopl-cleanup-v1 and js-hoopl-cleanup-v2 > Yes, the end result would be the same - I'm merely asking what would be > preferred by GHC devs (i.e., I don't know how fine grained patches to GHC > usually are). I don't

RE: Windows build

.../typecheck/should_fail$ which python /usr/bin/python .../typecheck/should_fail$ which python2 /usr/bin/python2 .../typecheck/should_fail$ which python3 /usr/bin/python3 .../typecheck/should_fail$ python --version Python 3.4.3 .../typecheck/should_fail$ python2 --version Python 2.7.11

Windows build

On Windows I now get a lot of framework failures, below. I have not tried them all, but some work fine when run individually; e.g. make TEST=AssocTyDef09 Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad

Re: Windows build

Hi Simon, What does which python 2 and which python 3 return? Along with uname -a? Tamar On Tue, Oct 18, 2016, 10:58 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > On Windows I now get a lot of framework failures, below. > > I have not tried them all, but some work fine when

Re: Windows build

And uname -a? If you're on anything higher than 2.5.1 the runtime has a regression per Ben's email. If you're not. Try using python3 for testing. Make test PYTHON=/usr/bin/python3 On Tue, Oct 18, 2016, 11:30 Simon Peyton Jones wrote: > .../typecheck/should_fail$ which

Re: Improving GHC GC for latency-sensitive networked services

It will be awesome if we can spread the GC work instead of stopping the world for too long. I am a new entrant to the Haskell world but something similar to this was the first real problem (other than lazy IO) that I faced with GHC. While I was debugging I had to learn how the GC works to really

RE: Improving GHC GC for latency-sensitive networked services

| I understand Marlow's thread-local heaps experiment circa 7.2/7.4 was | abandoned because it penalized performance too much. Does the | impression that there isn't the labor to maintain two GCs still hold? | It seems like thread-local heaps would be pervasive. I was optimistic about

RE: Windows build

Sorry I forgot .../typecheck/should_fail$ uname -a MSYS_NT-10.0 MSRC-4079181 2.5.1(0.297/5/3) 2016-05-16 10:51 x86_64 Msys I’ll try Make test PYTHON=/usr/bin/python3 Simon From: Phyx [mailto:loneti...@gmail.com] Sent: 18 October 2016 11:39 To: Simon Peyton Jones ;

Re: Improving GHC GC for latency-sensitive networked services

Chris, There are a few things here. - There are different levels of latency-sensitivity. The system I work on at Facebook is latency sensitive and we have no problem with the GC (after we implemented a few optimisations and did some tuning). But we're ok with pauses up to 100ms or so, and our

Re: Improving GHC GC for latency-sensitive networked services

I'll be lazy and answer the simplest question in this thread :) On 18/10/16 16:32, Simon Marlow wrote: > If not, are you willing to recompile GHC and all your libraries? Yes. ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Improving GHC GC for latency-sensitive networked services

Hi Chris, the GC pauses when using GHC have seldom been a serious issue in most of our projects at Tweag I/O. We do also have some projects with special requirements, however (strong synchrony between many machines that block frequently). For those the GC pauses are indeed a problem. And like

Master recently broke on OS X

Hello Simon, It looks like one of the patches that you pushed to master today may have broken the build on OS X. According to Harbormaster something in the range of f148513ccd93..7129861397f8 caused T5611 to fail on the OS X build bot [1]. Could you have a look? Cheers, - Ben [1]