On Mon, 04 Feb 2008 16:17:50 +, David Roundy wrote:
That's great to hear. BTW, you don't actually need to move that back,
as you can issue darcs mv a b *after* a mv a b... I still think
it's something [what originally asked] that can maybe be alleviated,
but not solved completely
Applied (once tests pass). Thanks, Eric!
David
On Wed, Feb 06, 2008 at 11:52:17AM +, [EMAIL PROTECTED] wrote:
Tue Feb 5 15:53:22 GMT 2008 Eric Kow [EMAIL PROTECTED]
* (Re)upgrade createPS and generatePS to Data.ByteString versions.
Tue Feb 5 15:54:20 GMT 2008 Eric Kow [EMAIL
On Tue, Feb 05, 2008 at 10:30:57AM -0800, Jason Dagit wrote:
On Feb 5, 2008 6:43 AM, David Roundy [EMAIL PROTECTED] wrote:
On Mon, Feb 04, 2008 at 09:05:55PM -0800, Jason Dagit wrote:
On Feb 4, 2008 4:30 PM, Dmitry Kurochkin [EMAIL PROTECTED] wrote:
Some fixes and cleanups for
Wed Feb 6 16:30:57 GMT 2008 Eric Kow [EMAIL PROTECTED]
* Test for issue436.
As suggested by Edwin Thomson.
New patches:
[Test for issue436.
Eric Kow [EMAIL PROTECTED]**20080206163057
As suggested by Edwin Thomson.
] {
addfile ./tests/issue436.sh
hunk ./tests/issue436.sh 1
+#!/bin/sh
+set
So, I haven't had a chance to look into the freezing function yet, but
I did do an informal performance comparison using the Data.ByteString
version and the --disable-bytestring version.
In short, the bytestring upgrade helps... a little bit.
Doing a local get of the GHC repository, best of
On Wed, Feb 06, 2008 at 04:42:02PM +, Eric Kow wrote:
So, I haven't had a chance to look into the freezing function yet, but
I did do an informal performance comparison using the Data.ByteString
version and the --disable-bytestring version.
In short, the bytestring upgrade helps... a
droundy:
On Wed, Feb 06, 2008 at 04:42:02PM +, Eric Kow wrote:
So, I haven't had a chance to look into the freezing function yet, but
I did do an informal performance comparison using the Data.ByteString
version and the --disable-bytestring version.
In short, the bytestring upgrade
On Wed, Feb 06, 2008 at 11:44:42AM -0500, David Roundy wrote:
Maybe we can egg on the bytestring people and get them to submit
patches taking this further down (for example, they could improve our
between newlines and nth newline stuff).
That'd be nice.
I should note, though, that we can
On Wed, Feb 06, 2008 at 08:46:44AM -0800, Don Stewart wrote:
droundy:
On Wed, Feb 06, 2008 at 04:42:02PM +, Eric Kow wrote:
Maybe we can egg on the bytestring people and get them to submit
patches taking this further down (for example, they could improve our
between newlines and
On Wed, Feb 06, 2008 at 08:52:12AM -0800, Don Stewart wrote:
droundy:
On Wed, Feb 06, 2008 at 11:44:42AM -0500, David Roundy wrote:
Maybe we can egg on the bytestring people and get them to submit
patches taking this further down (for example, they could improve our
between newlines
droundy:
On Wed, Feb 06, 2008 at 11:44:42AM -0500, David Roundy wrote:
Maybe we can egg on the bytestring people and get them to submit
patches taking this further down (for example, they could improve our
between newlines and nth newline stuff).
That'd be nice.
I should note,
time darcs pull -a time darcs obliterate --last 100 -a
time darcs obliterate --last 1000 a time darcs pull -a
obliterate-old: 98.3 97.0 96.9
obliterate-new: 45.0 45.5 45.6
pull-old: 55.9 55.7 56.4
pull-new: 33.2 29.3 30.8
So a 53% improvement on obliterate --last 1000 (note that
New submission from Eric Kow [EMAIL PROTECTED]:
It would be really useful to have a quick and dirty benchmarking script that we
can either distribute with or alongside darcs
The script would just encode some current darcs benchmarking practices: namely,
getting a repository, obliterating a 1000
On Feb 6, 2008 8:48 AM, David Roundy [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 11:44:42AM -0500, David Roundy wrote:
Maybe we can egg on the bytestring people and get them to submit
patches taking this further down (for example, they could improve our
between newlines and nth
On Feb 6, 2008 9:24 AM, Eric Kow [EMAIL PROTECTED] wrote:
New submission from Eric Kow [EMAIL PROTECTED]:
It would be really useful to have a quick and dirty benchmarking script that
we
can either distribute with or alongside darcs
The script would just encode some current darcs
time tar xjvf ciphercycles-20070205.tar.bz2
hg 0m2.4s
time darcs-1.1.0pre init
0m0.6s
time darcs-1.1.0pre add -r ciphercycles-20070205
0m2.8s
time darcs-1.1.0pre record --all [EMAIL PROTECTED] -m'init
import of ciphercycles-20070205'
0m46.7s
# and now with darcs-2
time tar xjvf
Excerpts from bugs's message of Wed Feb 06 17:24:02 UTC 2008:
New submission from Eric Kow [EMAIL PROTECTED]:
It would be really useful to have a quick and dirty benchmarking script that
we
can either distribute with or alongside darcs
The script would just encode some current darcs
On Wed, Feb 06, 2008 at 11:29:42AM -0700, zooko wrote:
time tar xjvf ciphercycles-20070205.tar.bz2
Any chance you could write up a little script that generates something
functionally equivalent to this directory for a benchmarking script?
Also, could you repeat this with the --hashed format? I
Sorry,
I guess my last compile/testrun with type witnesses didn't happen. I
just noticed a compile error in Depends.lhs.
Please ignore this patch as it will be superseded by a correct one
amend-recorded one.
Thanks,
Jason
On Feb 6, 2008 2:16 PM, Jason Dagit [EMAIL PROTECTED] wrote:
Wed Feb
time darcs-2pre get --verbose --debug-verbose --hashed http://
darcs.haskell.org/ghc
took 253m32.6s
___
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
per droundy's request, here are timings of this same task with hashed-
format:
time tar xjvf ciphercycles-20070205.tar.bz2
time darcs-2pre init --hashed
0m0.0s
time darcs-2pre add -r ciphercycles-20070205
0m5.7s
time darcs-2pre record --all [EMAIL PROTECTED] -m'init import
of
I started on this about three years ago. You are welcome to re-use my work from
then:
http://lists.osuosl.org/pipermail/darcs-devel/2005-March/001524.html
http://mark.stosberg.com/darcs_hive/darcs_speed_test/
Mark
--
nosy: +markstos
status: chatting - deferred
title: automated
I have also accidentally done a plain mv numerous times when I should have
done a darcs mv. My suggestions fo r implementing this would be:
- darcs mv with no arguments could be interactive...it would look for likely
moves and then prompt the user to confirm each one. I suppose could you also
I agree with the revised wish that darcs send -o also provide the e-mail of
the remote repo, realizing the language would need to be different...it would
just be factually reporting the address, insteading of claiming that an e-mail
has been sent there.
--
nosy: +markstos
status:
Hi,
zooko [EMAIL PROTECTED] writes:
Also, what's the memory use look like? Could this be an effect of
swapping?
No it can't, because I don't have swap on this machine. :-)
I know that the memory use is below 500 MB, or else it would have
crashed because I have only 500 MB on this
25 matches
Mail list logo
