Re: Telemetry (WAS: Attempt at a real world benchmark)

> Simon Peyton Jones via ghc-devs : > > Just to say: > > · Telemetry is a good topic > · It is clearly a delicate one as we’ve already seen from two widely > differing reactions. That’s why I have never seriously contemplated doing > anything about it. >

Re: More windows woe

Ben Gamari writes: > Simon Peyton Jones via ghc-devs writes: > >> I see that anything involving ghci fails: >> >> /c/code/HEAD/inplace/bin/ghc-stage2 --interactive >> >> GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help >> >>

Re: Windows build again

Simon Peyton Jones via ghc-devs writes: > Windows build is broken in a new way. > When I run validate I end up with sh.exe processes that consume a full CPU > forever. See the process log below. > > Note that these are not GHC processes: they are shells! I have no

Re: More windows woe

Edward Yang pointed out a truncated sentence in this message. See below. Thank you Edward! Cheers, - Ben Ben Gamari writes: > Simon Peyton Jones via ghc-devs writes: > ... > > To hack around this, mingw-w64 ships a static library, msvcrt.a, which

Re: More windows woe

Simon Peyton Jones via ghc-devs writes: > I see that anything involving ghci fails: > > /c/code/HEAD/inplace/bin/ghc-stage2 --interactive > > GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `base-4.9.0.0' > >

More windows woe

I see that anything involving ghci fails: /c/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a:

Re: Attempt at a real world benchmark

I'd imagine that "opt-in" could even mean you have to install a separate program/package to send data that's been collected. If it were very separate from the compiler itself, would these security concerns still be a problem? I for one would go through the effort of opting in since I want the

Re: Attempt at a real world benchmark

I would opt-in. I also agree with Simon that privacy is no longer a big deal although I do believe that most companies do telemetry with an opt in policy. If it's opt-in why would anyone have a problem with telemetry? On Fri, Dec 9, 2016 at 1:46 PM Tom Murphy wrote: > On Fri,

Re: Attempt at a real world benchmark

> It could tell us which language features are most used. A lot could be gleaned just by analyzing the packages on Hackage though. For example: https://www.reddit.com/r/haskell/comments/31t2y9/distribution_of_ghc_extensions_on_hackage/ ___ ghc-devs

Re: Telemetry (WAS: Attempt at a real world benchmark)

On Fri, Dec 9, 2016 at 3:53 PM, Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > > Just to say: > > > > > > · Telemetry is a good topic > > > > · It is clearly a delicate one as we’ve already seen from two widely > > differing

Re: Please don’t break travis

On Fri, Dec 9, 2016 at 3:56 PM, Ben Gamari wrote: > I seem to recall that this isn't the first time that this has happened. > Given that our testsuite is only growing, what is the long-term plan for > managing this? > Consider running the test suite as a separate job? --

Re: Attempt at a real world benchmark

On Fri, Dec 9, 2016 at 9:50 AM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > The big issue is (a) design and implementation effort, and (b) dealing > with the privacy issues. And (c) not everyone is going to upgrade their ghc, even if you backport the telemetry to older

Re: Attempt at a real world benchmark

On Fri, Dec 9, 2016 at 4:50 AM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > I have wanted telemetry for years. ("Telemetry" is the term Microsoft, > and I think others, use for the phone-home feature.) > > It would tell us how many people are using GHC; currently I have

Re: Telemetry

I certainly see the value of telemetry in being able to produce a higher quality product through understanding user behavior. However, I am not sure it is realistic. My clients are very conscious of intellectual property and data privacy concerns, and for some of them, even discussing the

Re: Telemetry

Pretty random idea: What if ghc exposed measurement points for performance and telemetry, but a separate tool would handle the read-out, configuration, upload etc. That would keep the telemetry from being built-in, while still being a way to get *some* information. Such a support tool might

Re: Please don’t break travis

Hi, I was not aware of that discussion. Great! If the twitter message does not do the job already, I will write a polite mail to Mathias Meyer. Greetings, Joachim Am Freitag, den 09.12.2016, 17:57 +0100 schrieb Boespflug, Mathieu: > Or this route: 

Re: Please don’t break travis

Or this route: https://mail.haskell.org/pipermail/ghc-devs/2015-June/009234.html. -- Mathieu Boespflug Founder at http://tweag.io. On 9 December 2016 at 17:06, Joachim Breitner wrote: > Am Freitag, den 09.12.2016, 10:56 -0500 schrieb Ben Gamari: > > > Joachim Breitner

Differential builds with on Darwin now enabled

Hello everyone, Note that the Mac Mini builder will now build submitted Differentials as well as commits to master. Originally I was hesitant to take this step since unreviewed differentials are essentially untrusted code; however it has become clear that to keep regressions from entering the

Re: Please don’t break travis

Am Freitag, den 09.12.2016, 10:56 -0500 schrieb Ben Gamari: > > Joachim Breitner writes: > > > Hi, > > > > again, Travis is failing to build master since a while. Unfortunately, > > only the author of commits get mailed by Travis, so I did not notice it > > so far. But

Re: Please don’t break travis

Joachim Breitner writes: > Hi, > > again, Travis is failing to build master since a while. Unfortunately, > only the author of commits get mailed by Travis, so I did not notice it > so far. But usually, when Travis reports a build failure, this is > something

RE: Telemetry (WAS: Attempt at a real world benchmark)

Simon Peyton Jones via ghc-devs writes: > Just to say: > > > · Telemetry is a good topic > > · It is clearly a delicate one as we’ve already seen from two widely > differing reactions. That’s why I have never seriously contemplated > doing anything about it. > > · I’m love

RE: GHC 8.2 status

I added join-points, which Luke is engaged in https://ghc.haskell.org/trac/ghc/wiki/SequentCore Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 09 December 2016 13:25 | To: GHC developers |

RE: Telemetry (WAS: Attempt at a real world benchmark)

Just to say: · Telemetry is a good topic · It is clearly a delicate one as we’ve already seen from two widely differing reactions. That’s why I have never seriously contemplated doing anything about it. · I’m love a consensus to emerge on this, but I don’t have the

Re: Telemetry (WAS: Attempt at a real world benchmark)

It could tell us which language features are most used. Language features are hard if they are not available in separate libs. If in libs, then IIRC debian is packaging those in separate packages, again you can use their package contest. What in particular makes them hard? Sorry if this

Re: Attempt at a real world benchmark

Hi, Am Freitag, den 09.12.2016, 13:54 +0800 schrieb Moritz Angermann: > > I am not sure what you are saying. Are you proposing the maintain a > > benchmark set outside GHC, or did you get the impression that I am > > proposing it? > > Yes, that’s what *I* am proposing for the reasons I

GHC 8.2 status

Hello everyone, While we are still trying to get 8.0.2 out the door, 8.2.1 is quickly approaching. If you have a feature that you would like to see in 8.2, please add it to the 8.2 status page [1] as soon as possible and let us know; we would like to cut the ghc-8.2 branch in late December for a

Re: Attempt at a real world benchmark

Sorry for hijacking the thread, but On 12/ 9/16 10:50 AM, Simon Peyton Jones via ghc-devs wrote: I have wanted telemetry for years. ("Telemetry" is the term Microsoft, and I think others, use for the phone-home feature.) telemetry or better "call-home", this is very dangerous idea to even

RE: Attempt at a real world benchmark

I have wanted telemetry for years. ("Telemetry" is the term Microsoft, and I think others, use for the phone-home feature.) It would tell us how many people are using GHC; currently I have literally no idea. It could tell us which language features are most used. Perhaps it could tell us

Re: Attempt at a real world benchmark

>> Actually, now that I think about it: What about if this were integrated >> into the Cabal infrastructure? If I specify "upload-perf-numbers: True" >> in my .cabal file, any project on (e.g.) GitHub that wanted to opt-in >> could do so, they could build using Travis, and voila! >> > >