Re: [darcs-devel] New performance regression?
David Roundy wrote: On Thu, Feb 07, 2008 at 03:26:09PM +, Simon Marlow wrote: I just updated my darcs2 to try out the new ByteString changes and see if I could reproduce Erik's results, and I'm seeing a bit regression in the performance of unpull: I'll try to take a look at this tomorrow... I've spent my darcs time for the day working out zooko's performance regression. Who knows, maybe I've fixed yours? :) I just updated and tried again, and now pull has regressed too, by an order of magnitude :-( You should be able to reproduce this pretty easily with a darcs2 ghc repository. I get no progress messages at all from pull for quite a while, and the 400-patch pull now takes over 100s where it previously took 10. Unpull is also taking about 100s on this machine, where previously it took 15. This happens to be with --disable-bytestring, if that matters (probably not, I guess). Cheers, Simon ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] New performance regression?
On Fri, Feb 08, 2008 at 10:03:52AM -0500, David Roundy wrote: On Fri, Feb 08, 2008 at 10:53:57AM +, Simon Marlow wrote: You should be able to reproduce this pretty easily with a darcs2 ghc repository. I get no progress messages at all from pull for quite a while, and the 400-patch pull now takes over 100s where it previously took 10. Unpull is also taking about 100s on this machine, where previously it took 15. Oddly enough in my quick darcs2-format test, I don't see the slowdown, but on the hashed-format test I do. This may be some sort of hysteresis effect. I'll try using your darcs2 repository, but first I want to debug the darcs get slowness (or at least lack of progress). :( Okay, I've got a data point: darcs obliterate --last 580 -a is fast (well, the old speed) while darcs obliterate --from-tag ... -a is slow (where on my test case there are 580 patches after the tag). So it seems to be in the patch selection code. On the other hand, I still see now slowness in pull! :( -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue468] darcs + ext2ifs (WinXP) = Crash
With no further feedback from the requestor in over six months, I'm marking this as wont-fix for. (More like presumed-dead). No one else has reported a dupe during that time. -- nosy: +eivuokko, jaredj, markstos, rgm, wglozer status: chatting - wont-fix topic: +Windows __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue468 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] New performance regression?
David Roundy wrote: On Fri, Feb 08, 2008 at 10:03:52AM -0500, David Roundy wrote: On Fri, Feb 08, 2008 at 10:53:57AM +, Simon Marlow wrote: You should be able to reproduce this pretty easily with a darcs2 ghc repository. I get no progress messages at all from pull for quite a while, and the 400-patch pull now takes over 100s where it previously took 10. Unpull is also taking about 100s on this machine, where previously it took 15. Oddly enough in my quick darcs2-format test, I don't see the slowdown, but on the hashed-format test I do. This may be some sort of hysteresis effect. I'll try using your darcs2 repository, but first I want to debug the darcs get slowness (or at least lack of progress). :( Okay, I've got a data point: darcs obliterate --last 580 -a is fast (well, the old speed) while darcs obliterate --from-tag ... -a is slow (where on my test case there are 580 patches after the tag). So it seems to be in the patch selection code. Indeed, I can confirm that. On the other hand, I still see now slowness in pull! :( It's very strange - certainly this morning I saw very long pull times in both directions between my two repositories, and now I'm only seeing it in one direction. To summarise, with my two repos called A and B: oblit in either A or B slow with --from-patch, fast with --last pull A - B fast pull B - A *slow* Ah, but I have clues. repo A has some strange corruption. Spaces in filenames have been replaced by (literally) \32. $ \ls InstallShield Component\32\DefinitionsREADME Setup\32\Files decyg.plRegistry\32\Entries Shell\32\Objects File\32\Groups runexe.c String\32\Tables Glasgow\32\Haskell\32\Compiler.ipr Script\32\Files Text\32\Substitutions this is what it should look like: $ \ls InstallShield Component Definitions READMESetup Files decyg.pl Registry Entries Shell Objects File Groups runexe.c String Tables Glasgow Haskell Compiler.ipr Script Files Text Substitutions I have to go now so I can't investigate any more, but my best guess is that this happened when I did 'darcs repair' yesterday using a darcs2 that was built with bytestring support turned on. Cheers, Simon ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] darcs patch: Make HashedIO.lhs compile with type witn... (and 1 more)
Fri Feb 8 10:41:26 PST 2008 Jason Dagit [EMAIL PROTECTED] * Make HashedIO.lhs compile with type witnesses Fri Feb 8 10:41:49 PST 2008 Jason Dagit [EMAIL PROTECTED] * Add Depends and HashedIO to witnesses in make file New patches: [Make HashedIO.lhs compile with type witnesses Jason Dagit [EMAIL PROTECTED]**20080208184126] hunk ./src/Darcs/Repository/HashedIO.lhs 54 then fail $ Hash failed hash: ++ fn else return (fn,hf) -applyHashed :: Patchy q = Cache p - [DarcsFlag] - String - q - IO String +applyHashed :: Patchy q = Cache p - [DarcsFlag] - String - q C(x y) - IO String applyHashed c fs h p = do s - slurpHashed c fs h let ms = withSlurpy s $ apply fs p case ms of [Add Depends and HashedIO to witnesses in make file Jason Dagit [EMAIL PROTECTED]**20080208184149] hunk ./GNUmakefile 113 witnesses: src/Darcs/Patch/Real.hi src/Darcs/Patch/Properties.hi src/Darcs/Patch.hi \ src/Darcs/Repository/ApplyPatches.hi src/Darcs/Patch/Bundle.hi \ - src/Darcs/Patch/Match.hi + src/Darcs/Patch/Match.hi src/Darcs/Patch/Depends.hi src/Darcs/Repository/HashedIO.hi DARCS_FILES := $(DARCS_FILES_DEPS)\ $(patsubst %,src/%,$(MODULES_AUTOCONF))\ Context: [eliminate unsafe debugMode from Globals: it didn't work if _debugMode changes value. David Roundy [EMAIL PROTECTED]**20080208170051] [clean up putDebug. David Roundy [EMAIL PROTECTED]**20080208164512] [make the identifying of remote repositories more efficient. David Roundy [EMAIL PROTECTED]**20080208160806 We cut out a download of hashed_inventory and an attempt at getting _darcs/inventory. ] [cut useless git-format code. David Roundy [EMAIL PROTECTED]**20080208154517] [add more debug messages in Repository. David Roundy [EMAIL PROTECTED]**20080208152458] [add a bunch more debug messages in get. David Roundy [EMAIL PROTECTED]**20080208152405] [issue390: whatsnew 'stats' more files than needed. Mark Stosberg [EMAIL PROTECTED]**20080208032646] [eliminate spaces in GNUmakefile. David Roundy [EMAIL PROTECTED]**20080207232825] [don't build tarball when making website. David Roundy [EMAIL PROTECTED]**20080207232754] [give darcs get instructions rather than links to browse urls. David Roundy [EMAIL PROTECTED]**20080207230912] [Make broken-pipe.sh test fail on MacOS X. Eric Kow [EMAIL PROTECTED]**20080207220914 1) seq is non-portable, so that had to be replaced with something anyway. 2) the test worked with 20 items, but failed with a 100 ] [Pipe 'darcs foo --help' through a pager. Eric Kow [EMAIL PROTECTED]**20080207215526] [Fix ChangeLog entry. Eric Kow [EMAIL PROTECTED]**20080125232739] [Add links to darcs repositories to main webpage Jason Dagit [EMAIL PROTECTED]**20080207224120] [amended Depends.lhs for type witnesses Jason Dagit [EMAIL PROTECTED]**20080207221706] [add more debug messages. David Roundy [EMAIL PROTECTED]**20080207200156] [speed up pending handling. David Roundy [EMAIL PROTECTED]**20080207200051 In fixing a bug, I thoughtlessly made pending handling O(N^2) more often than it needs to be... which was the safe choice, because it was previously the fast code that had the bug. ] [add debug output regarding disabling of progress reports. David Roundy [EMAIL PROTECTED]**20080207193719] [add progress reporting while writing patch file in record. David Roundy [EMAIL PROTECTED]**20080207193649] [add a few more debug messages in record. David Roundy [EMAIL PROTECTED]**20080207193626] [fix performance regression in unrecord. David Roundy [EMAIL PROTECTED]**20080207193529 This also reverts to the old behavior of producing unsorted patches when asked for record -a, but sorted patches when the -a flag is omitted. :( ] [avoid giving excessive (usually useless) debug info. David Roundy [EMAIL PROTECTED]**20080207191129] [define filterFL. David Roundy [EMAIL PROTECTED]**20080207191113] [resolve conflict in Pull.lhs. David Roundy [EMAIL PROTECTED]**20080206223143] [make Depends.lhs compile with type witnesses Jason Dagit [EMAIL PROTECTED]**20080206214552] [ratify another use of hGetContents. David Roundy [EMAIL PROTECTED]**20080206184718] [cleanup in Pull.lhs. David Roundy [EMAIL PROTECTED]**20080206184600] [Test for issue436. Eric Kow [EMAIL PROTECTED]**20080206163057 As suggested by Edwin Thomson. ] [remove use of patchset_complement. David Roundy [EMAIL PROTECTED]**20080206182548] [change Slurpy to not store the file as list of lines. David Roundy [EMAIL PROTECTED]**20080206164113] [fix GHCFLAGS, so make ghci will work properly. David Roundy [EMAIL PROTECTED]**20080206161052] [cut from OldFastPackedString same functions Eric cut from ByteString version. David Roundy [EMAIL PROTECTED]**20080206155350] [Pipe help text through a pager. Eric Kow [EMAIL PROTECTED]**20080205210324] [Ability to pipe a document through a pager. Eric Kow [EMAIL PROTECTED]**20080205210313] [Remove ununsed functions from FastPackedString. Eric Kow [EMAIL
[darcs-devel] [issue659] Release Darcs 2.0
I nominate issue579 to be fixed for the Darcs 2 release. The issue title is: Darcs2: changes shows revised history -- superseder: +Darcs2: changes shows revised history __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue659 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: Make HashedIO.lhs compile with type witn... (and 1 more)
On Fri, Feb 08, 2008 at 10:42:31AM -0800, Jason Dagit wrote: Fri Feb 8 10:41:26 PST 2008 Jason Dagit [EMAIL PROTECTED] * Make HashedIO.lhs compile with type witnesses Fri Feb 8 10:41:49 PST 2008 Jason Dagit [EMAIL PROTECTED] * Add Depends and HashedIO to witnesses in make file Applied, thanks! -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue663] bu when pulling with conflicts
New submission from Olivier Schwander [EMAIL PROTECTED]: Hello, Here is a trace of a darcs pull. Darcs failed to pull pathed leading to conflicts and said me to email to this list. The version used is 1.0.9 (release) (from Debian Sid). The repository contains some file that were sharply deleted and recreated because I have forgotten there was a darcs repository in my /home. I have no idea if it is a real bug or only a bad use from me, sorry if it is the case. Don't hesitate to ask more precisions. Thanks, Olivier -- messages: 3239 nosy: beschmi, droundy, kowey, olivier.schwander, tommy status: unread title: bu when pulling with conflicts __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue663 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: Change read_repo to return SealedPatchSet
Looks good. Applied. David On Feb 8, 2008 5:28 PM, Jason Dagit [EMAIL PROTECTED] wrote: David, This refactor makes it easier to make HashedRepo.lhs compile with type witnesses enabled. Thanks, Jason Fri Feb 8 14:14:09 PST 2008 Jason Dagit [EMAIL PROTECTED] * Change read_repo to return SealedPatchSet ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue667] performance regression: darcs-1 vs. darcs-2-hashedformat on getting the darcs-unstable repository
New submission from Zooko [EMAIL PROTECTED]: time darcs-1.0.9 get http://darcs.net/repos/unstable real20m55.913s time darcs-2pre get --hashed http://darcs.net/repos/unstable-hashed real39m5.057s again: time darcs-2pre get --hashed http://darcs.net/repos/unstable-hashed real38m46.288s -- messages: 3252 nosy: beschmi, droundy, kowey, tommy, zooko status: unread title: performance regression: darcs-1 vs. darcs-2-hashedformat on getting the darcs-unstable repository __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue667 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] New performance regression?
On Thu, Feb 07, 2008 at 03:26:09PM +, Simon Marlow wrote: Incedentally, I'm doing a get on this repository right now, and darcs2 has been silent (no progress info at all) for a couple of minutes, even though I can see it downloading stuff... oh, now it says Identifying repository. This is rather a tricky scenario: the hashed_inventory of this repository takes 36s to download on my computer using wget. Our current assumption in the progress-reporting code is that any given download will be fast, and the result is that this particular operation is going to take a minimum of 36 seconds with no change in progress output. As it turns out, we download hashed_inventory twice when we only need download it once, so that slows things down dramatically. I can easily get rid of one of these downloads (which is just checking the format of the repository, something that can more easily be done with a check of _darcs/format, which always exists for hashed and darcs-2 repositories). I'd actually also like to cache the contents of hashed_inventory, in a way that would enable us to guarantee that it's only downloaded once, which is good both for efficiency and for atomicity (to make sure we don't use two versions of the remote repository but assume they're the same). I'm testing (and planning to push) a patch now that'll cut 36 seconds on this get for me, by avoiding one download of hashed_inventory, but I don't see how to avoid a 36s wait with no new progress report without very dramatically rewriting our libwww/libcurl bindings. -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] Trailing whitespace in _darcs/inventory
Hi, The inventory file has a single trailing space after the ] patch end marker. It also adds a space to empty lines in the patch name. Is there a reason behind this? -Ori ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: copy over updated shell_harness to bugs.
On Thu, Feb 07, 2008 at 08:46:21PM -0500, Mark Stosberg wrote: Thu Feb 7 20:44:40 EST 2008 Mark Stosberg [EMAIL PROTECTED] * copy over updated shell_harness to bugs. Besides giving more consistent results, this is necessary for me to be able to run the broken-pipe.sh test from a directory with a space in it. I'm not clear as to why this change is needed. It looks like you're causing the bug shell test to fail, which is precisely the opposite of what it's intended to do. Perhaps you could figure out which of these changes are actually wanted? David ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] Trailing whitespace in _darcs/inventory
On Fri, Feb 08, 2008 at 05:33:19PM +0200, Ori Avtalion wrote:
The inventory file has a single trailing space after the ] patch end
marker. It also adds a space to empty lines in the patch name.
Is there a reason behind this?
The trailing space after ] is I believe just an artifact because we use
the same code for printing patch names in the patches themselves (before a
{ usually), but I'm not sure.
The space where there are blank lines is just a consistency thing: every
line in the long comment is preceded by a space. If the line happens to be
blank (or composed of only white space) it's still treated the same. We
could add a special case for blank lines, but it's hard to see a good
reason to do so.
--
David Roundy
Department of Physics
Oregon State University
___
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] New performance regression?
On Fri, Feb 08, 2008 at 10:53:57AM +, Simon Marlow wrote: David Roundy wrote: On Thu, Feb 07, 2008 at 03:26:09PM +, Simon Marlow wrote: I just updated my darcs2 to try out the new ByteString changes and see if I could reproduce Erik's results, and I'm seeing a bit regression in the performance of unpull: I'll try to take a look at this tomorrow... I've spent my darcs time for the day working out zooko's performance regression. Who knows, maybe I've fixed yours? :) I just updated and tried again, and now pull has regressed too, by an order of magnitude :-( Argh. That's odd, my testing (which is on a --hashed repository) suggests that pull still hasn't regressed, although I can reproduce your unpull regression. You should be able to reproduce this pretty easily with a darcs2 ghc repository. I get no progress messages at all from pull for quite a while, and the 400-patch pull now takes over 100s where it previously took 10. Unpull is also taking about 100s on this machine, where previously it took 15. Oddly enough in my quick darcs2-format test, I don't see the slowdown, but on the hashed-format test I do. This may be some sort of hysteresis effect. I'll try using your darcs2 repository, but first I want to debug the darcs get slowness (or at least lack of progress). :( -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue468] darcs + ext2ifs (WinXP) = Crash
It was confirmed to be a bug in ext2ifs. I thought I had reported that, but see now that I did not. Sorry about that! frank On Feb 8, 2008 11:21 AM, Mark Stosberg [EMAIL PROTECTED] wrote: With no further feedback from the requestor in over six months, I'm marking this as wont-fix for. (More like presumed-dead). No one else has reported a dupe during that time. -- nosy: +eivuokko, jaredj, markstos, rgm, wglozer status: chatting - wont-fix topic: +Windows __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue468 __ __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue468 __It was confirmed to be a bug in ext2ifs. I thought I had reported that, but see now that I did not. Sorry about that!frankOn Feb 8, 2008 11:21 AM, Mark Stosberg [EMAIL PROTECTED] wrote: With no further feedback from the requestor in over six months, Im marking this as wont-fix for. (More like presumed-dead). No one else has reported a dupeduring that time.--nosy: +eivuokko, jaredj, markstos, rgm, wglozerstatus: chatting - wont-fix topic: +Windows__Darcs bug tracker [EMAIL PROTECTED]http://bugs.darcs.net/issue468 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: issue390: whatsnew 'stats' more files than needed.
On Fri, Feb 08, 2008 at 05:33:26AM +0200, Yuval Kogman wrote: On Thu, Feb 07, 2008 at 22:27:15 -0500, Mark Stosberg wrote: Thu Feb 7 22:26:46 EST 2008 Mark Stosberg [EMAIL PROTECTED] * issue390: whatsnew 'stats' more files than needed. strace is not found everywhere, I suggest at the very least skipping unless -X my $strace = `which strace` Perhaps File::Which is preferable. Sounds like a reasonable request. On the other hand, since this is still in bugs/, it's expected to fail (for now), so we've only got to fix this by the time that we fix the bug, so I'm applying now. -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue665] Odd progress report message when reverting
New submission from Ori Avtalion [EMAIL PROTECTED]: When a large revert operation takes place, the user is greeted to the message: Reading inventory of repository /home/me/devel/project inventory which in time turns into Finished reverting. The last word, inventory, is out of place. The line is printed by finishedOneIO in read_repo_private [src/Darcs/Repository/DarcsRepo.lhs] Since reading the inventory file is the only IO operation in read_repo_private (or more precisely: finishedOneIO is called only once), there is no progress to report. The message would make more sense if there were other files being read and the the word inventory would have been replaced by their names, to show the progress. But, this isn't the case here. -- messages: 3247 nosy: beschmi, droundy, kowey, salty-horse, tommy priority: bug status: unread title: Odd progress report message when reverting __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue665 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: Change read_repo to return SealedPatchSet (and 2 more)
On Feb 8, 2008 5:34 PM, Jason Dagit [EMAIL PROTECTED] wrote: Fri Feb 8 17:32:15 PST 2008 Jason Dagit [EMAIL PROTECTED] * make Cache p work with type witnesses I think this last one does the wrong thing. For some reason if a type signature starts with: RepoPatch p = Cache p Then I have to give two type witnesses to both Cache and p. So I would have to change it to: RepoPatch p = Cache (p C(x y)) C(x y) Instead of what I expected: RepoPatch p = Cache p C(x y) Any idea where I went wrong? Thanks, Jason ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
