Master recently broke on OS X

[Ben Gamari]

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] https://phabricator.haskell.org/harbormaster/build/14220/?l=100


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving GHC GC for latency-sensitive networked services

[Niklas Hambüchen]

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
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving GHC GC for latency-sensitive networked services

[Simon Marlow]

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 average pause time is <50ms with 100MB
live data on large multicore machines.  There's probably still scope to
reduce that some more.

- Thread-local heaps don't fix the pause-time issue.  They reduce the pause
time for a local collection but have no impact on the global collection,
which is still unbounded in size.

- I absolutely agree we should have incremental or concurrent collection.
It's a big project though.  Most of the technology is fairly well
understood (just read
https://www.amazon.co.uk/gp/product/1420082795/ref=pd_bxgy_14_img_2?ie=UTF8=1=P08F0WS4W6Q6Q6K8CSCF)
and I have some vague plans for what direction to take.

- The issue is not so much maintaining multiple GCs.  We already have 3 GCs
(one of which is experimental and unsupported).  The issue is more that a
new kind of GC has non-local implications because it affects read- and
write-barriers, and making a bad tradeoff can penalize the performance of
all code.  Perhaps you're willing to give up 10% of performance to get
guaranteed 10ms pause times, but can we impose that 10% on everyone?  If
not, are you willing to recompile GHC and all your libraries?

Cheers
Simon


On 17 October 2016 at 18:08, Christopher Allen  wrote:

> It'd be unfortunate if more companies trying out Haskell came to the
> same result: https://blog.pusher.com/latency-working-set-ghc-gc-
> pick-two/#comment-2866985345
> (They gave up and rewrote the service in Golang)
>
> Most of the state of the art I'm aware of (such as from Azul Systems)
> is from when I was using a JVM language, which isn't necessarily
> applicable for GHC.
>
> 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.
>
> Does anyone know what could be done in GHC itself to improve this
> situation? Stop-the-world is pretty painful when the otherwise
> excellent concurrency primitives are much of why you're using Haskell.
>
> --- Chris Allen
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving GHC GC for latency-sensitive networked services

[Boespflug, Mathieu]

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 most
non-trivial problems, it's a combination of multiple solutions that'll help
us reduce or eliminate these long pauses.

The first line of work involves hacks to the GC. Making the GC incremental
would certainly be nice. Local heaps might help for some workloads, but
it's no silver bullet, as Simon PJ writes below. I think it would be very
illuminating if Simon M or whoever else worked on early experiments
regarding local heaps could post a detailed writeup as to what made the
"complexity of the implementation extremely daunting" and the tradeoffs
involved. Or a link there already is one. :)

As Ben alluded to earlier and as Reddit discovered some weeks ago, as part
of another line of work, we are donating some ongoing effort to help with
the problem by simply taking out some objects from the GC managed heap.
Objects that the GC just doesn't have to deal with at all (either because
allocated elsewhere or not at all, thanks to fusion) can relieve the
pressure on the GC. But quite apart from our effort here, which does
involve an extension to the type system to enable the programmer to make
more of her/his intent clear to the compiler, I think the compact regions
work that will be part of 8.2 is already a great step forward. It requires
some programmer assistance, but if it's GC pause times you're wrestling
with, chances are you have a very hard use case indeed so providing that
assistance is likely easier than most other things you'll have to deal with.

Best,

--
Mathieu Boespflug
Founder at http://tweag.io.

On 17 October 2016 at 19:08, Christopher Allen  wrote:

> It'd be unfortunate if more companies trying out Haskell came to the
> same result: https://blog.pusher.com/latency-working-set-ghc-gc-
> pick-two/#comment-2866985345
> (They gave up and rewrote the service in Golang)
>
> Most of the state of the art I'm aware of (such as from Azul Systems)
> is from when I was using a JVM language, which isn't necessarily
> applicable for GHC.
>
> 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.
>
> Does anyone know what could be done in GHC itself to improve this
> situation? Stop-the-world is pretty painful when the otherwise
> excellent concurrency primitives are much of why you're using Haskell.
>
> --- Chris Allen
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving GHC GC for latency-sensitive networked services

[Harendra Kumar]

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 understand what's going on. Then I learnt to always strive to keep
the retained heap to the minimum possible. But sometimes the minimum
possible could be a lot. This blog article was sort of a deja vu for me. It
seems this is not a rare problem.

I guess, the compact regions technique as suggested by Ben can be used to
workaround the problem but it sounds like it is application aware and users
will have to discover the possibility of that solution, I might be mistaken
though. If we want GHC to work smoothly for performance critical
applications then we should perhaps find a cost effective way to solve this
in an application transparent manner.

-harendra

On 18 October 2016 at 18:33, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> |  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 thread-local heaps, but while perf did improve a
> bit, the complexity of the implementation was extremely daunting.   So we
> decided that the pain didn't justify the gain.
>
> I'm not sure it'd help much here, since the data is long-lived and might
> migrate into the global heap anyway.
>
> Most GCs rely on traversing live data. Here the live data is big. So
> really the only solution is to traverse it incrementally.  You can still
> stop-the-world, but you have to be able to resume normal execution before
> GC is complete, thus smearing GC out into a series of slices, interleaved
> with (but not necessarily in parallel with) the main application.
>
> I believe the that the OCaml runtime now has such a GC.  It'd be lovely to
> have one for GHC.
>
> But I defer to Simon M
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Christopher Allen
> |  Sent: 17 October 2016 18:08
> |  To: ghc-devs@haskell.org
> |  Subject: Improving GHC GC for latency-sensitive networked services
> |
> |  It'd be unfortunate if more companies trying out Haskell came to the
> |  same result:
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.
> |  pusher.com%2Flatency-working-set-ghc-gc-pick-two%2F%23comment-
> |  2866985345=01%7C01%7Csimonpj%40microsoft.com%7C04c1bc69e00c47d382
> |  2908d3f6b028d0%7C72f988bf86f141af91ab2d7cd011db47%7C1=dE1VP0u3kQ
> |  L9R7CaGTAOGswRY6SyKH72c0xG%2FOggEK0%3D=0
> |  (They gave up and rewrote the service in Golang)
> |
> |  Most of the state of the art I'm aware of (such as from Azul Systems)
> |  is from when I was using a JVM language, which isn't necessarily
> |  applicable for GHC.
> |
> |  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.
> |
> |  Does anyone know what could be done in GHC itself to improve this
> |  situation? Stop-the-world is pretty painful when the otherwise
> |  excellent concurrency primitives are much of why you're using Haskell.
> |
> |  --- Chris Allen
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs=01%7C01%7Csimonpj%40microsoft.com%7C04c1bc69e00c47d3822908d3
> |  f6b028d0%7C72f988bf86f141af91ab2d7cd011db47%7C1=XwvaAPx%2BGqugD4
> |  Kx%2FkXiYticgBCUMkboqH9QE315EhQ%3D=0
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Improving GHC GC for latency-sensitive networked services

[Simon Peyton Jones via ghc-devs]

|  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 thread-local heaps, but while perf did improve a bit, 
the complexity of the implementation was extremely daunting.   So we decided 
that the pain didn't justify the gain.

I'm not sure it'd help much here, since the data is long-lived and might 
migrate into the global heap anyway.

Most GCs rely on traversing live data. Here the live data is big. So really the 
only solution is to traverse it incrementally.  You can still stop-the-world, 
but you have to be able to resume normal execution before GC is complete, thus 
smearing GC out into a series of slices, interleaved with (but not necessarily 
in parallel with) the main application.

I believe the that the OCaml runtime now has such a GC.  It'd be lovely to have 
one for GHC.  

But I defer to Simon M

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Christopher Allen
|  Sent: 17 October 2016 18:08
|  To: ghc-devs@haskell.org
|  Subject: Improving GHC GC for latency-sensitive networked services
|  
|  It'd be unfortunate if more companies trying out Haskell came to the
|  same result:
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.
|  pusher.com%2Flatency-working-set-ghc-gc-pick-two%2F%23comment-
|  2866985345=01%7C01%7Csimonpj%40microsoft.com%7C04c1bc69e00c47d382
|  2908d3f6b028d0%7C72f988bf86f141af91ab2d7cd011db47%7C1=dE1VP0u3kQ
|  L9R7CaGTAOGswRY6SyKH72c0xG%2FOggEK0%3D=0
|  (They gave up and rewrote the service in Golang)
|  
|  Most of the state of the art I'm aware of (such as from Azul Systems)
|  is from when I was using a JVM language, which isn't necessarily
|  applicable for GHC.
|  
|  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.
|  
|  Does anyone know what could be done in GHC itself to improve this
|  situation? Stop-the-world is pretty painful when the otherwise
|  excellent concurrency primitives are much of why you're using Haskell.
|  
|  --- Chris Allen
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=01%7C01%7Csimonpj%40microsoft.com%7C04c1bc69e00c47d3822908d3
|  f6b028d0%7C72f988bf86f141af91ab2d7cd011db47%7C1=XwvaAPx%2BGqugD4
|  Kx%2FkXiYticgBCUMkboqH9QE315EhQ%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows build

[Simon Peyton Jones via ghc-devs]

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 ; ghc-devs@haskell.org
Subject: 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 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

.../typecheck/should_fail$ python3 --version

Python 3.4.3

.../typecheck/should_fail$

From: Phyx [mailto:loneti...@gmail.com]
Sent: 18 October 2016 11:07
To: Simon Peyton Jones >; 
ghc-devs@haskell.org
Subject: 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 
> wrote:
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 exit code] (ghci)

   plugins/plugins07.run plugins07 [bad exit code] (normal)



Unexpected stat failures:

   perf/haddock/haddock.compiler.run  haddock.compiler [stat not good enough] 
(normal)



Framework failures:

   ./cabal/T5442b.run   T5442b [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./codeGen/should_run/cgrun040.runcgrun040 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./concurrent/should_run/conc027.run  conc027 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./deSugar/should_run/dsrun010.rundsrun010 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./dph/sumnats/dph-sumnats-vseg.run   dph-sumnats-vseg 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./dph/words/dph-words-copy-fast.run  dph-words-copy-fast 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./driver/T9963.run   T9963 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/scripts/ghci044a.run  ghci044a [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/scripts/T4127.run T4127 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/should_run/ghcirun001.run ghcirun001 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./overloadedlists/should_fail/overloadedlistsfail02.run  
overloadedlistsfail02 [runTest] (Unhandled exception: global name 
'WindowsError' is not defined)

   ./package/package07e.run package07e 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./parser/should_fail/ParserNoForallUnicode.run   
ParserNoForallUnicode [runTest] (Unhandled exception: global name 
'WindowsError' is not defined)

   ./parser/should_fail/T12051.run  T12051 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./perf/should_run/T4830.run  T4830 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

  ./plugins/plugins07.run  plugins07 [normal] 
(pre_cmd failed: 2)

   ./rts/stack003.run   stack003 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./rts/ffishutdown.runffishutdown 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./simplCore/should_compile/T3234.run T3234 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_compile/tc217.run tc217 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/tcfail013.runtcfail013 [runTest] 

Re: Windows build

[Phyx]

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 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
>
> .../typecheck/should_fail$ python3 --version
>
> Python 3.4.3
>
> .../typecheck/should_fail$
>
>
>
> *From:* Phyx [mailto:loneti...@gmail.com]
> *Sent:* 18 October 2016 11:07
> *To:* Simon Peyton Jones ; ghc-devs@haskell.org
> *Subject:* 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 run individually; e.g.
>
> make TEST=AssocTyDef09
>
> Simon
>
>
>
>
>
> Unexpected passes:
>
>rts/T7037.run  T7037 [unexpected] (normal)
>
>
>
> Unexpected failures:
>
>ghci/prog003/prog003.run  prog003 [bad exit code] (ghci)
>
>plugins/plugins07.run plugins07 [bad exit code] (normal)
>
>
>
> Unexpected stat failures:
>
>perf/haddock/haddock.compiler.run  haddock.compiler [stat not good
> enough] (normal)
>
>
>
> Framework failures:
>
>./cabal/T5442b.run   T5442b
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./codeGen/should_run/cgrun040.runcgrun040
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./concurrent/should_run/conc027.run  conc027
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./deSugar/should_run/dsrun010.rundsrun010
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./dph/sumnats/dph-sumnats-vseg.run
> dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError'
> is not defined)
>
>./dph/words/dph-words-copy-fast.run
> dph-words-copy-fast [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
>
>./driver/T9963.run   T9963
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./ghci/scripts/ghci044a.run  ghci044a
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./ghci/scripts/T4127.run T4127
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./ghci/should_run/ghcirun001.run ghcirun001
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./overloadedlists/should_fail/overloadedlistsfail02.run
> overloadedlistsfail02 [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
>
>./package/package07e.run package07e
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./parser/should_fail/ParserNoForallUnicode.run
> ParserNoForallUnicode [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
>
>./parser/should_fail/T12051.run  T12051
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./perf/should_run/T4830.run  T4830
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>   ./plugins/plugins07.run  plugins07
> [normal] (pre_cmd failed: 2)
>
>./rts/stack003.run   stack003
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./rts/ffishutdown.runffishutdown
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./simplCore/should_compile/T3234.run T3234
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_compile/tc217.run tc217
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_fail/tcfail013.runtcfail013
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_fail/tcfail110.runtcfail110
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_fail/AssocTyDef09.run AssocTyDef09
> [runTest] (Unhandled 

RE: Windows build

[Simon Peyton Jones via ghc-devs]

.../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

.../typecheck/should_fail$ python3 --version

Python 3.4.3

.../typecheck/should_fail$

From: Phyx [mailto:loneti...@gmail.com]
Sent: 18 October 2016 11:07
To: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: 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 
> wrote:
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 exit code] (ghci)

   plugins/plugins07.run plugins07 [bad exit code] (normal)



Unexpected stat failures:

   perf/haddock/haddock.compiler.run  haddock.compiler [stat not good enough] 
(normal)



Framework failures:

   ./cabal/T5442b.run   T5442b [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./codeGen/should_run/cgrun040.runcgrun040 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./concurrent/should_run/conc027.run  conc027 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./deSugar/should_run/dsrun010.rundsrun010 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./dph/sumnats/dph-sumnats-vseg.run   dph-sumnats-vseg 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./dph/words/dph-words-copy-fast.run  dph-words-copy-fast 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./driver/T9963.run   T9963 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/scripts/ghci044a.run  ghci044a [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/scripts/T4127.run T4127 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/should_run/ghcirun001.run ghcirun001 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./overloadedlists/should_fail/overloadedlistsfail02.run  
overloadedlistsfail02 [runTest] (Unhandled exception: global name 
'WindowsError' is not defined)

   ./package/package07e.run package07e 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./parser/should_fail/ParserNoForallUnicode.run   
ParserNoForallUnicode [runTest] (Unhandled exception: global name 
'WindowsError' is not defined)

   ./parser/should_fail/T12051.run  T12051 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./perf/should_run/T4830.run  T4830 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

  ./plugins/plugins07.run  plugins07 [normal] 
(pre_cmd failed: 2)

   ./rts/stack003.run   stack003 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./rts/ffishutdown.runffishutdown 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./simplCore/should_compile/T3234.run T3234 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_compile/tc217.run tc217 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/tcfail013.runtcfail013 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/tcfail110.runtcfail110 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/AssocTyDef09.run AssocTyDef09 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ../../libraries/base/tests/stableptr003.run  stableptr003 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ../../libraries/base/tests/IO/ioeGetErrorString001.run   
ioeGetErrorString001 [runTest] (Unhandled exception: global name 'WindowsError' 
is not defined)
___

Re: Windows build

[Phyx]

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 run individually; e.g.
>
> make TEST=AssocTyDef09
>
> Simon
>
>
>
>
>
> Unexpected passes:
>
>rts/T7037.run  T7037 [unexpected] (normal)
>
>
>
> Unexpected failures:
>
>ghci/prog003/prog003.run  prog003 [bad exit code] (ghci)
>
>plugins/plugins07.run plugins07 [bad exit code] (normal)
>
>
>
> Unexpected stat failures:
>
>perf/haddock/haddock.compiler.run  haddock.compiler [stat not good
> enough] (normal)
>
>
>
> Framework failures:
>
>./cabal/T5442b.run   T5442b
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./codeGen/should_run/cgrun040.runcgrun040
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./concurrent/should_run/conc027.run  conc027
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./deSugar/should_run/dsrun010.rundsrun010
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./dph/sumnats/dph-sumnats-vseg.run
> dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError'
> is not defined)
>
>./dph/words/dph-words-copy-fast.run
> dph-words-copy-fast [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
>
>./driver/T9963.run   T9963
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./ghci/scripts/ghci044a.run  ghci044a
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./ghci/scripts/T4127.run T4127
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./ghci/should_run/ghcirun001.run ghcirun001
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./overloadedlists/should_fail/overloadedlistsfail02.run
> overloadedlistsfail02 [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
>
>./package/package07e.run package07e
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./parser/should_fail/ParserNoForallUnicode.run
> ParserNoForallUnicode [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
>
>./parser/should_fail/T12051.run  T12051
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./perf/should_run/T4830.run  T4830
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>   ./plugins/plugins07.run  plugins07
> [normal] (pre_cmd failed: 2)
>
>./rts/stack003.run   stack003
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./rts/ffishutdown.runffishutdown
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./simplCore/should_compile/T3234.run T3234
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_compile/tc217.run tc217
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_fail/tcfail013.runtcfail013
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_fail/tcfail110.runtcfail110
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>./typecheck/should_fail/AssocTyDef09.run AssocTyDef09
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>../../libraries/base/tests/stableptr003.run  stableptr003
> [runTest] (Unhandled exception: global name 'WindowsError' is not defined)
>
>../../libraries/base/tests/IO/ioeGetErrorString001.run
> ioeGetErrorString001 [runTest] (Unhandled exception: global name
> 'WindowsError' is not defined)
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Windows build

[Simon Peyton Jones via ghc-devs]

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 exit code] (ghci)

   plugins/plugins07.run plugins07 [bad exit code] (normal)



Unexpected stat failures:

   perf/haddock/haddock.compiler.run  haddock.compiler [stat not good enough] 
(normal)



Framework failures:

   ./cabal/T5442b.run   T5442b [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./codeGen/should_run/cgrun040.runcgrun040 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./concurrent/should_run/conc027.run  conc027 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./deSugar/should_run/dsrun010.rundsrun010 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./dph/sumnats/dph-sumnats-vseg.run   dph-sumnats-vseg 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./dph/words/dph-words-copy-fast.run  dph-words-copy-fast 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./driver/T9963.run   T9963 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/scripts/ghci044a.run  ghci044a [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/scripts/T4127.run T4127 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./ghci/should_run/ghcirun001.run ghcirun001 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./overloadedlists/should_fail/overloadedlistsfail02.run  
overloadedlistsfail02 [runTest] (Unhandled exception: global name 
'WindowsError' is not defined)

   ./package/package07e.run package07e 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./parser/should_fail/ParserNoForallUnicode.run   
ParserNoForallUnicode [runTest] (Unhandled exception: global name 
'WindowsError' is not defined)

   ./parser/should_fail/T12051.run  T12051 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./perf/should_run/T4830.run  T4830 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

  ./plugins/plugins07.run  plugins07 [normal] 
(pre_cmd failed: 2)

   ./rts/stack003.run   stack003 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./rts/ffishutdown.runffishutdown 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ./simplCore/should_compile/T3234.run T3234 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_compile/tc217.run tc217 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/tcfail013.runtcfail013 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/tcfail110.runtcfail110 [runTest] 
(Unhandled exception: global name 'WindowsError' is not defined)

   ./typecheck/should_fail/AssocTyDef09.run AssocTyDef09 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ../../libraries/base/tests/stableptr003.run  stableptr003 
[runTest] (Unhandled exception: global name 'WindowsError' is not defined)

   ../../libraries/base/tests/IO/ioeGetErrorString001.run   
ioeGetErrorString001 [runTest] (Unhandled exception: global name 'WindowsError' 
is not defined)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Dataflow analysis for Cmm

[Jan Stolarek]

> (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 think this should be visible in your final patch. In a perfect world 
each repositrory 
commit shouyld provide exactly one functionality - not more and not less. So 
your final patch 
should not reflect intermediate steps you took to implement some functionality 
because they are 
not really relevant. For the purpose of development and review it is fine to 
have a branch with 
lots of small commits but before merging you should just squash them into one.

Janek
 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs