New home for the perf.haskell.org builder wanted

[Joachim Breitner]

Hi,

although I have moved away from Karlsruhe three months ago, so far it
is still my office PC driving
https://perf.haskell.org/ghc/

But a new person is now using my desk and wants to use this machine, so
I should really really move this away from there now.

Sebastian Graf has been working on turning gipeda, the Frontend
perf.haskell.org, into a more general service open to open source
Haskell projects, and this is close, but not close enough to simply
stop running the performance tests until he is good to go.

He currently has a machine given from haskell.org to run this on, but
it is a virtual machine and the measurements are too flaky for real
use.

So basically, I need a decent non-virtualized (or virtualized, but
exclusive) machine to move my performance build runner to, as quickly
as possible. The current specs are
 * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz 
 * 16 GB RAM
but it does not matter too much, a slightly weaker machine would be
able to keep up as well. I also do not necessarily need root access
(but it would be beyond the point if the machine would do other stuff
that incurs a heavy load).

The same machine could then be used by Sebastian for his more general
setup, once that is ready to go.

Does anyone have something handy?

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long-term storage of abandoned branches

[Joachim Breitner]

Hi,

Am Montag, den 24.10.2016, 11:13 -0700 schrieb John Wiegley:
> JB> Maybe I should move the branch to archive/foobar, to make it clear that
> JB> this is not something actively worked on?
> 
> As a side note: you could move them into a different ref spec entirely, which
> is not pulled by default when someone clone's or pull's.

I know about the possibility, but I think that would simply be too
undiscoverable then.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long-term storage of abandoned branches

[John Wiegley]

> "JB" == Joachim Breitner  writes:

JB> Maybe I should move the branch to archive/foobar, to make it clear that
JB> this is not something actively worked on?

As a side note: you could move them into a different ref spec entirely, which
is not pulled by default when someone clone's or pull's. For example, you
could store them under:

refs/archives/foobar

Which would require a pullspec to be added before someone can gain access to
these archives:

git config remote.origin.fetch 
'+refs/archives/*:refs/remotes/origin/archives/*'

GitHub does something very similar with its pull requests, which are stored
under a "pull" ref spec, and are not cloned by default, but can be accessed by
adding the appropriate fetch attribute:

+refs/pull/*:refs/remotes/origin/pr/*

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Dataflow analysis for Cmm

[Michal Terepeta]

On Fri, Oct 21, 2016 at 4:04 PM Simon Marlow  wrote:

> On 16 October 2016 at 14:03, Michal Terepeta 
> wrote:
>
> Hi,
>
> I was looking at cleaning up a bit the situation with dataflow analysis
> for Cmm.
> In particular, I was experimenting with rewriting the current
> `cmm.Hoopl.Dataflow` module:
> - To only include the functionality to do analysis (since GHC doesn’t seem
> to use
>   the rewriting part).
>   Benefits:
>   - Code simplification (we could remove a lot of unused code).
>   - Makes it clear what we’re actually using from Hoopl.
> - To have an interface that works with transfer functions operating on a
> whole
>   basic block (`Block CmmNode C C`).
>   This means that it would be up to the user of the algorithm to traverse
> the
>   whole block.
>
>
> Ah! This is actually something I wanted to do but didn't get around to.
> When I was working on the code generator I found that using Hoopl for
> rewriting was prohibitively slow, which is why we're not using it for
> anything right now, but I think that pulling out the basic block
> transformation is possibly a way forwards that would let us use Hoopl.
>

Right, I've also seen:
https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance
but it seems that there weren't any follow-ups/conclusions on that.
Also, I haven't started writing anything for the rewriting yet (only
analysis for
now).

Btw. I'm currently experimenting with the GHC's fork of Dataflow module -
and for now I'm not planning on pushing the changes to the upstream Hoopl.
There are already projects that depend on the current interface of Hoopl
(it's
on Hackage after all) and it's going to be hard to make certain changes
there.
Hope that's ok with everyone!
(also, we can always revisit this question later)

A lot of the code you're removing is my attempt at "optimising" the Hoopl
> dataflow algorithm to make it usable in GHC.  (I don't mind removing this,
> it was a failed experiment really)
>

Thanks for saying that!


>   Benefits:
>   - Further simplifications.
>   - We could remove `analyzeFwdBlocks` hack, which AFAICS is just a
> copy
> of `analyzeFwd` but ignores the middle nodes (probably for efficiency
> of
> analyses that only look at the blocks).
>
>
> Aren't we using this in dataflowAnalFwdBlocks, that's used by
> procpointAnalysis?
>

Yes, sorry for confusion! What I meant is that
analyzeFwdBlocks/dataflowAnalFwdBlocks is currently a special case of
analyzeFwd/dataflowAnalFwd that only looks at first and last nodes. So if we
move to block-oriented interface, it simply stops being a special case and
fits
the new interface (since it's the analysis that decides whether to look at
the
whole block or only parts of it). So it's removed in the sense of "removing
a
special case".

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

Long-term storage of abandoned branches

[Joachim Breitner]

Hi,

in https://ghc.haskell.org/trac/ghc/ticket/12618#comment:37
Simon raises a question that I was wondering about as well:

Where do we want to store feature branches that contain useful work
that might be picked up some time later (maybe much later¹)?


So far, I have left them as wip/foobar branches. Which works ok, but it
clutters up the branch namespace, and “wip” is a lie.

Maybe I should move the branch to archive/foobar, to make it clear that
this is not something actively worked on?


An alternative is having it in Phab only, where it is “more out of the
way”, and there is commentary attached to it. Linked from the
appropriate ticket, the code is as accessible as  a git branch.

But are we committed to keeping the Differential Revisions around for
years?

Also, if the branch contains many small commits, which presumably makes
it more useful to whoever revives the project one day, it is easy to
recover that from Phab? (I wonder because arc land squashes commits.)

Greetings,
Joachim

¹ this does happen, see 
  https://ghc.haskell.org/trac/ghc/ticket/1600#comment:52

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Semantics of MVars and IORefs?

[Peter Trommler]

Hi Iavor and Ryan,

One ticket on memory model issues is #12469.

At openSUSE we see several build failures only now because we recently switched 
to parallel Cabal builds.
A compiled Cabal Setup that is called with -j sometimes segfaults on 
PowerPC. Actually, if I
try building package OpenGL locally on my PowerMac Setup -j almost always 
fails with a segfault if n is
the number of cores or higher. See also #12537.

When building on Open(SUSE) Build Service the build fails only sometimes. We 
build all of LTS Haskell and a
random selection of around 40 packages fail, most of them with segfaults in 
Setup but some with GHC panics.
#12469 has examples.

Peter

> On 21.10.2016, at 19:56, Ryan Yates  wrote:
> 
> Hi Iavor,
> 
> You might be interested in what Edward has written about this:
> 
> http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/
> 
> I would say when we do have a memory model for GHC the program you gave will 
> almost certainly be correct.  MVar operations should be full synchronization 
> operations.  There are some bugs on relaxed systems with initialization that 
> I think are being addressed.  I can't find the tickets at the moment.
> 
> Ryan

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

RE: Aarrgh! Windows build broken again

[Simon Peyton Jones via ghc-devs]

Thanks for such a prompt reply -- I'll try that.

Simon

|  -Original Message-
|  From: Matthew Pickering [mailto:matthewtpicker...@gmail.com]
|  Sent: 23 October 2016 00:13
|  To: Simon Peyton Jones 
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Aarrgh! Windows build broken again
|  
|  Erik has a patch which fixes this. I will merge it now.
|  
|  Matt
|  
|  On Sun, Oct 23, 2016 at 12:11 AM, Simon Peyton Jones via ghc-devs
|   wrote:
|  > On Windows with HEAD I get
|  >
|  > C:/code/HEAD/inplace/mingw/bin/ld.exe: cannot find -lnuma
|  >
|  > Sigh.   This didn’t happen a day or two ago
|  >
|  > Simon
|  >
|  >
|  > ___
|  > 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=02%7C01%7Csimonpj%40microsoft.com%7Ca7ec55f6a94d429104a008d3
|  fad1098b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6361277481201917
|  06=IswaW41WhOlEA2tHdxqjLfjaay3Eob%2B1RSo%2F3u4hqlI%3D=0
|  >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs