20MB of bandwidth represents 20 additional seconds to do an initial
clone on my 1 megabyte/second connection. ghc.git is already about
75MB, so it wouldn't dramatically change the experience either way.
Just a data point.
On 12/06/2013 12:47 PM, Carter Schonwald wrote:
personally i don't car
personally i don't care about the bandwidth, and others are correct about
the value of logs. If theres a way to get both, awesome! If not, 20mb here
and there i don't care.
On Fri, Dec 6, 2013 at 11:26 AM, Johan Tibell wrote:
> On Fri, Dec 6, 2013 at 4:43 PM, Herbert Valerio Riedel wrote:
>
>>
Hi,
Am Freitag, den 22.11.2013, 23:23 + schrieb Joachim Breitner:
> It is updated regularly (currently a cronjob every 15 minutes, ideally
> by push hooks), and each push triggers a build of exactly these recorded
> versions of all components via travis:
> https://travis-ci.org/nomeata/ghc-com
On Fri, Dec 6, 2013 at 4:43 PM, Herbert Valerio Riedel wrote:
> On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote:
> > Whichever way to go, we should write down the options and consequences
> and
> > communicating them widely enough so no core devs get surprised.
> >
> > Commit IDs for the test
On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote:
> Whichever way to go, we should write down the options and consequences and
> communicating them widely enough so no core devs get surprised.
>
> Commit IDs for the test suite are referenced in e.g. various Trac issues,
> on mailing lists (altho
Well spotted. I'm on a train, hence email response. Maybe you can paste this
into the ticket?
There are two different issues here.
'''First''', `isDoubleFinite` is declared as non-side-effecting:
{{{
foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int
}}}
But (as you c
My only concern with this is that we consider the workflow and tooling
issues that I outlined in
http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2718
The main points are making sure the workflow for submodules doesn't have
too much friction, that it's integrated nicely into sync-a
Trac tickets with links to commits are the important case. If the
commit IDs change, someone will have to run a script over the Trac
database and rewrite all those links to testsuite commits to the new
ones. Sounds possible, but it'll be at least a few hours work I'd guess.
I'm in favour of
Whichever way to go, we should write down the options and consequences and
communicating them widely enough so no core devs get surprised.
Commit IDs for the test suite are referenced in e.g. various Trac issues,
on mailing lists (although rarely), and perhaps even in code.
On Fri, Dec 6, 2013 a
On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote:
> When we merge in the testsuite repo, can we still keep the old commit IDs?
> They're referenced from all over the place.
...if we want to preserve the old testsuite's commit-ids, then we'll
have to live with carrying around those superflous la
Hi,
Am Freitag, den 06.12.2013, 13:01 +0100 schrieb Johan Tibell:
> When we merge in the testsuite repo, can we still keep the old commit
> IDs? They're referenced from all over the place.
that depends on the style of merge:
* With pathname rewriting:
+ git can easily trace the history of a
Hi,
When we merge in the testsuite repo, can we still keep the old commit IDs?
They're referenced from all over the place.
On Fri, Dec 6, 2013 at 12:07 PM, Joachim Breitner
wrote:
> Hi,
>
> Am Freitag, den 06.12.2013, 11:05 +0100 schrieb Herbert Valerio Riedel:
> > PS: if anyone wonders why the
Hi,
Am Freitag, den 06.12.2013, 11:05 +0100 schrieb Herbert Valerio Riedel:
> PS: if anyone wonders why the testsuite.git history is so large: there
> were a few *huge* binary files with bad compressibility checked in by
> accident, such as the one removed via
>
>[..]
>
> s/dph/words/dph-words-fas
On 2013-12-05 at 14:32:10 +0100, Herbert Valerio Riedel wrote:
[...]
> whereas, when I create a new git repo containing only the HEAD commit
> from testsuite.git, the resulting single packfile:
>
> 204K Dec 5 14:19
> .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.idx
> 2.5M D
14 matches
Mail list logo
