-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21/10/14 09:18, Alexander Berntsen wrote:
On 20/10/14 21:13, Ben Gamari wrote:
1. Do nothing, ignore pull requests as we do now
2. Monitor Github for new pull requests and close with a message
requesting that the user opens a
Hi all,
Is there a way to put `arc` into a read-only mode?
Frequently while working on a patch, I make several commits, preferring to
separate out testing commits from productive work commits and non-productive
(whitespace, comments) commits. Sometimes each of these categories are
themselves
On Tue, 2014-10-21 at 09:34 -0400, Richard Eisenberg wrote:
Hi all,
Is there a way to put `arc` into a read-only mode?
Not sure it is relevant, please ignore me if it is not.
Does arc diff --preview work for you? It will create a diff without
creating revision and changing anything locally.
This is probably the biggest shortcoming of Phab. If you don't want this
merging behavior you need to make a separate Phab review *per commit*.
When I use arc I usually use git to rewrite the message after the review to
something less messy.
On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg
Kazu Yamamoto k...@iij.ad.jp writes:
Hi,
Andreas - want me to go ahead and get you some hardware to test Ben's
patch in the mean time? This way we'll at least not leave it hanging
until the last moment...
I will also try this with two 20-core machines connected 10G on
Monday.
I
On October 20, 2014 at 2:35:27 PM, Richard Eisenberg (e...@cis.upenn.edu) wrote:
Having done so, I'm not 100% convinced that this is the right thing to do. I
would love feedback
on my full, concrete proposal available at
https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs
Making tabs warn by default has been requested many times before, and
now that the compiler is completely detabbed, this should become
possible to enable easily, and we can gradually remove warnings from
everything else.
I hate this, but I assume there will be an easy flag to turn this warning
Perhaps you misunderstood my proposal if you think it would prevent anyone
else from defining instances of those classes? Part of the proposal was
also adding support to the compiler to allow for a multiple files to use a
single module name. That may be a larger technical challenge, but I think
Hello *,
As I am still new in this, I will ask.
Were there any attempt to automate GHC build process on Windows with some
kind of CI engine, like Hudson, Jenkins, etc.?
It seems to be rather helpful to publish build results if not after each
commit, but at least once every day.
WDYT?
--
Yes, all you need to do is to add -fno-warn-tabs to ghc-options.
On Tue, Oct 21, 2014 at 10:54:31AM -0500, Stephen Paul Weber wrote:
Making tabs warn by default has been requested many times before, and
now that the compiler is completely detabbed, this should become
possible to enable easily,
On Oct 21, 2014 1:22 PM, John Lato jwl...@gmail.com wrote:
Perhaps you misunderstood my proposal if you think it would prevent
anyone else from defining instances of those classes? Part of the proposal
was also adding support to the compiler to allow for a multiple files to
use a single module
Hello,
There is a lot of building infrastructure and I believe most of it is
listed on [1]. For example the nightly builders [2] where there are
indeed 2 windows buildmachines working (but they seem to fail to build
currently).
I believe there is ongoing work on adding windows machines to
One other benefit of multiple files to use a single module name is that it
would be easy to separate testing code from real code even when testing
internal/non-exported functions.
On Tue, Oct 21, 2014 at 1:22 PM, John Lato jwl...@gmail.com wrote:
Perhaps you misunderstood my proposal if you
For a while, I tried working around this using a branch summary patch,
which is just an empty commit I kept on top of the patchset which then
Phabricator would hit.
It was really annoying and Git kept swallowing up. So I eventually gave
up and just arc diff'd each patch in the set individually.
Kazu Yamamoto k...@iij.ad.jp writes:
Hi,
I measured the performace of GHC head, 7.8.3 and 7.8.3 + Ben's patch
set.
Server: witty 8080 -r -a -s +RTS -Nn *1
Measurement tool: weighttp -n 10 -c 1000 -k -t 19 http://192.168.0.1:8080/
Measurement env: two 20 core (w/o HT) machines
Kazu Yamamoto k...@iij.ad.jp writes:
Hi,
Hi Kazu,
Andreas - want me to go ahead and get you some hardware to test Ben's
patch in the mean time? This way we'll at least not leave it hanging
until the last moment...
I will also try this with two 20-core machines connected 10G on
Monday.
Ben,
Hmm, uh oh. Thanks for testing this. I'll try to reproduce this on my
end. It looks like it shouldn't be so hard as even the single-threaded
performance regresses drastically. Just to confirm, you are using the
latest revision of D347?
I used the following as you suggested:
Ben,
This may be due to lacking INLINEs on definitions added in
GHC.Event.Internal [1]. I'm currently in the middle of reproducing these
results on an EC2 instance to confirm this. So far the results look much
more consistent than my previous attempts at benchmarking on my own
hardware.
If
Kazu Yamamoto k...@iij.ad.jp writes:
Ben,
This may be due to lacking INLINEs on definitions added in
GHC.Event.Internal [1]. I'm currently in the middle of reproducing these
results on an EC2 instance to confirm this. So far the results look much
more consistent than my previous attempts at
I already pushed it. The commit in question is
5dce47eb8415eb31e1c6759b6f6a2ef5bfe32470. Thanks for the benchmarking!
I believe this is in bgamari/ghc (for GHC 7.10?).
I'm using bgamari/packages-base for GHC 7.8 and asking to push the
same commit to this repo.
Actually I compared the latest
Kazu Yamamoto k...@iij.ad.jp writes:
I already pushed it. The commit in question is
5dce47eb8415eb31e1c6759b6f6a2ef5bfe32470. Thanks for the benchmarking!
I believe this is in bgamari/ghc (for GHC 7.10?).
I'm using bgamari/packages-base for GHC 7.8 and asking to push the
same commit to this
Ahh, yes. Sorry, I forgot you were on 7.8. Just pushed a new patch to
the event-rework-squashed branch [1].
I believe that you are trying to merge your patches to GHC 7.8.4?
If not, I will work on the GHC head branch.
--Kazu
___
ghc-devs mailing
Well, Bas was wondering whether this would be possible. At this point
I'm a bit on the fence; on one hand it's not a crucial fix (we have a
workaround in usb) and it may involve changes to exported interfaces
(although not very high visibility). On the other hand, it's a pretty
easy change to
Kazu Yamamoto k...@iij.ad.jp writes:
Well, Bas was wondering whether this would be possible. At this point
I'm a bit on the fence; on one hand it's not a crucial fix (we have a
workaround in usb) and it may involve changes to exported interfaces
(although not very high visibility). On the
Out of curiosity are these numbers from single runs or do you average?
Run three times and took the middle in this time.
What are the uncertainties on these numbers? Even on the Rackspace
machines I was finding very large variances in my benchmarks, largely
due to far outliers. I didn't
Hi Austin,
You need to set the CPU into C0 using /dev/cpu_dma_latency. Here's a
short paper with a program to show the way to do it[1].
This paper is what I'm looking for. Thanks!
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
26 matches
Mail list logo
