[darcs-devel] [issue648] get leaves mystery rmfiles (old format)
New submission from Eric Kow [EMAIL PROTECTED]: This sounds scary, so I'm marking it as urgent (happens with latest darcs unstable 2.0.0pre3) on Ubuntu Linux Gutsy % darcs get http://mark.stosberg.com/darcs_hive/darcs_speed_test % darcs what -s rmfile ./darcs0696OB-new rmfile ./darcsIWCPDL-new rmfile ./darcsJ4efzl-new rmfile ./darcsVxJosv-new rmfile ./darcsllv7Ib-new rmfile ./darcsoOK5q5-new -- messages: 3177 nosy: beschmi, droundy, kowey, tommy priority: urgent status: unread title: get leaves mystery rmfiles (old format) topic: Darcs2 __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue648 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] strace timing logs Re: a couple of quick timings
On Feb 7, 2008, at 12:38 AM, Petr Rockai wrote: Not sure what OS are you using, but at least Linux will still work if you are very tight with memory and have no swap. It will just work extremely slowly, since all it can swap is code pages (which are in the executables so they don't need extra swap space). It's usual that when you have no swap and run out of memory on Linux, trivial operations can take extremely long time. Are you sure about this? It seems like this could be a problem only when total amount of memory required by your applications is epsilon less than the physical memory, and it remains at just that level for a long period of time. I've been running without swap for about four years now, and I've never observed trivial operations to take an extremely long time. (Indeed, the reason that I turned off swap is that now, without swap, all operations finish quickly -- there is no swap thrash state to cause operations to drag on for minutes or hours.) Have you ever observed this phenomenon or is it just something you've heard about? Please make sure this is not a memory problem, since otherwise the timing is fairly worthless (and the issue is really in memory usage)... Also, checking what kind of load is on the machine (with say top) could help -- is it CPU-intensive or IO-intensive workload? Or is it mostly idling? Wait, why would the timing be worthless? The timing is a measure of how long it takes darcs and hg to do a task which I need to do (import ciphercycles tarball) on a machine that I need to use to do it. Hg works fine in this situation. Anyway, I'm re-running it now, with strace -r -tt for detailed timing information. top shows that darcs is using 94 M virt, 88 M res, and consistently using about 40% to 50% CPU (it is sharing CPU with a ghc compile). The darcs status-update-line output (you know, the nice new keep-the-user-informed feature of darcs-2) currently says Writing pristine 2049/2058 : e07cd73fa2a129ece7aa452f7fe29b6c6185e8e1, and has said this same thing for at least ten minutes. time strace -o tar.strace.log.txt -r -tt tar xjvf ciphercycles-20070205.tar.bz2 0m2.7s time strace -o darcsinit.log.txt -r -tt darcs init --hashed 0m0.3s time strace -o darcsadd.log.txt -r -tt darcs add -r ciphercycles-20070205 0m7.8s time strace -o darcsrecord.log.txt -r -tt darcs record --all -- [EMAIL PROTECTED] -m'init import of ciphercycles-20070205' 34m20.0s (Hm, perhaps sharing the CPU with ghc compile made it take twice as long. Or perhaps doing the strace logging slowed it down.) And now for Mercurial: time strace -o tar.strace.log.txt -r -tt tar xjvf ciphercycles-20070205.tar.bz2 0m2.3s time strace -o hginit.strace.log.txt -r -tt hg init 0m0.2s time strace -o hgaddremove.strace.log.txt -r -tt hg addremove 0m1.9s time strace -o hgcommit.strace.log.txt -r -tt hg commit -m'init import of ciphercycles-20070205' 0m5.5s Here is a .tar.bz2 containing all of the strace logs produced -- https://zooko.com/stracelogs.tar.bz2 . They contain fine-grained (microsecond) timing of each system call, so they should be a good help diagnosing why darcs is thousands of times slower than hg for this. Here's the first clue: wc -l straceit*/*.strace.log.txt 12662 straceit/darcsadd.strace.log.txt 323 straceit/darcsinit.strace.log.txt 1912200 straceit/darcsrec.strace.log.txt 14150 straceithg/hgaddremove.strace.log.txt 59911 straceithg/hgcommit.strace.log.txt 3614 straceithg/hginit.strace.log.txt 15736 straceithg/tar.strace.log.txt 15448 straceit/tar.strace.log.txt 2034044 total So darcs made 1.9 million system calls to do darcs record while hg made 60,000 system calls to do hg commit. Regards, Zooko ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] [issue659] Release Darcs 2.0
On Thu, Feb 07, 2008 at 05:56:52PM -, Mark Stosberg wrote: Based on the bug tracker activity, my sense is that Darcs 2 is already better than 1.0.9, with no significant regressions that I'm aware of. Another major regression is the slowdown of record when adding many files, which was recently reported (off bug-tracker) by Zooko. -- 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] [issue659] Release Darcs 2.0
New submission from Mark Stosberg [EMAIL PROTECTED]: This ticket is created to track the release of Darcs 2.0. Other bugs or features that are blocking the release can associated as superceders. When those are all resolved, the release should happen. Based on the bug tracker activity, my sense is that Darcs 2 is already better than 1.0.9, with no significant regressions that I'm aware of. I'm adding issue648 as a superceder to start with, which refers to strange rmfile entries appearing in whatsnew after a pull. -- messages: 3204 nosy: beschmi, droundy, kowey, markstos, tommy priority: feature status: unread superseder: get leaves mystery rmfiles (old format) title: Release Darcs 2.0 __ 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] a couple of quick timings
On Wed, Feb 06, 2008 at 08:34:57PM -0700, zooko wrote: On Feb 6, 2008, at 11:58 AM, David Roundy wrote: 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? You can get that actual tarball with: Thanks for the test case, Zooko, and for pointing out this regression! Could you rerun your timings when you have pulled this change: Thu Feb 7 15:00:51 EST 2008 David Roundy [EMAIL PROTECTED] * speed up pending handling. 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. I believe I've fixed the main regression. On my computer, your record took 45s, and I got it down to just under twice the time that darcs 1.0.9rc1 took. I gather your computer is faster. At this point, I think I've fixed the scaling issues (although I'm not certain, there could remain some O(N^2) issues with a smaller prefactor), and the remainder may just be micro-optimization. We changed our list type for holding sequences of patches (besides generalizing to support alternate patch semantics), and it could well be that there's a factor of two slowdown somewhere in there. Hopefully soon someone will volunteer to create a timings framework. I've now found two handy inverse sequences time darcs obliterate --last 100 -a time darcs pull -a and time darcs unrecord --last 1 -a time darcs record -m foo -a where this latter test came about because of your test case. The first was Simon M's test case. If we can generate more of these pairs of inverse operations that display slowdowns that'd be great. Once I've got something like this that I can reproduce (and also reproduce with darcs 1, so I know that we've got a regression), it's generally only a matter of a few hours to find the main causes. -- 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] [issue651] bad folder urls in darcs.cgi
New submission from Nicolas Limare [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 from http://darcs.net/cgi-bin/darcs.cgi/stable/debian?c=patches or http://darcs.net/cgi-bin/darcs.cgi/stable/debian/?c=patches (note the trailing slash) you get for the first (oldest) patch a link to http://darcs.net/cgi-bin/darcs.cgi/stable/debian?c=annotatep=20030301134611-e9342-23bac40309679b53a63d2edca43f7f0a2591a6ab.gzch=20030301134611-e9342-23bac40309679b53a63d2edca43f7f0a2591a6ab.gzo=./debian On this page, annotate links are broken; The problem seems to be that a / is missing at the end of the o parameter. It is very annoying for browsing the repo through the cgi. I ran some diff between my version (1.0.9, debian stable) and the last unstable version, and the only change seems to be the site url (abridgegame - darcs). - -- Nicolas LIMARE labo. j-l lions - univ. pierre et marie curie [EMAIL PROTECTED] http://www.ann.jussieu.fr/~limare/ +33 (0) 144 272 721 175 rue du chevaleret - 75013 paris - france -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqn1mvviFAPpCP08RAtm/AJ9gZ2MqukTNJehwP39DXIBn/ayWqACgkUPh QCp6+TdIWreUGr2NZ0SsN+g= =+EML -END PGP SIGNATURE- -- messages: 3189 nosy: beschmi, droundy, kowey, limare, tommy status: unread title: bad folder urls in darcs.cgi __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue651 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue652] push a partial repo to an empty repo fails
New submission from Nicolas Limare [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = Error message = $ darcs push Pushing to youkan:/srv/dev/darcs/megawave-4... darcs: bug in darcs! fromJust error at Push.lhs:136 compiled 13:47:48 Nov 20 2006 Please report this to [EMAIL PROTECTED], If possible include the output of 'darcs --exact-version'. = Version = $ darcs --exact-version darcs compiled on Nov 20 2006, at 13:48:04 # configured Mon Oct 9 15:12:44 EDT 2006 ./configure --no-create --no-recursion Context: [TAG 1.0.9rc1 Tommy Pettersson [EMAIL PROTECTED]**20061008175207] = What I wanted to do = * set an empty distant repo * set an empty local repo * fill it with the current source * push it to the server repo * set an empty distant branch repo * set a local branch repo from the previous local repo * push it to the server branch repo = What I did (IIRC) = on the distant server: mkdir megawave-3 cd megawave-3 darcs initialize cd .. mkdir megawave-4 cd megawave-4 darcs initialize locally: darcs get youkan:/srv/dev/darcs/megawave-3 cd megawave-3 (add the source) darcs add --recursive ./ darcs record -a darcs tag --checkpoint darcs push cd .. darcs get --partial megawave-3 megawave-4 (update _darcs/prefs/repos and _darcs/prefs/defaultrepo) darcs push (here comes the error) = My understanding = I guess the culprit is the --partial option, but from the doc it made sense for me. So it might a minima be a documentation bug :) = Context = First time I start to *really* use darcs, for more than a personal backup service. - -- Nicolas LIMARE labo. j-l lions - univ. pierre et marie curie [EMAIL PROTECTED] http://www.ann.jussieu.fr/~limare/ +33 (0) 144 272 721 175 rue du chevaleret - 75013 paris - france -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqlotvviFAPpCP08RArLbAKCZ1s82Ho8Tz6axVZcN6rQvtPAA5gCfXL8o 4YG3o7rCdCUUv6YrLeXMoMY= =YmHf -END PGP SIGNATURE- -- messages: 3188 nosy: beschmi, droundy, kowey, limare, tommy status: unread title: push a partial repo to an empty repo fails __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue652 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue650] bad folder urls in darcs.cgi
New submission from Nicolas Limare [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 from http://darcs.net/cgi-bin/darcs.cgi/stable/debian?c=patches or http://darcs.net/cgi-bin/darcs.cgi/stable/debian/?c=patches (note the trailing slash) you get for the first (oldest) patch a link to http://darcs.net/cgi-bin/darcs.cgi/stable/debian?c=annotatep=20030301134611-e9342-23bac40309679b53a63d2edca43f7f0a2591a6ab.gzch=20030301134611-e9342-23bac40309679b53a63d2edca43f7f0a2591a6ab.gzo=./debian On this page, annotate links are broken; The problem seems to be that a / is missing at the end of the o parameter. It is very annoying for browsing the repo through the cgi. I ran some diff between my version (1.0.9, debian stable) and the last unstable version, and the only change seems to be the site url (abridgegame - darcs). - -- Nicolas LIMARE labo. j-l lions - univ. pierre et marie curie [EMAIL PROTECTED] http://www.ann.jussieu.fr/~limare/ +33 (0) 144 272 721 175 rue du chevaleret - 75013 paris - france -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqyh7vviFAPpCP08RAhyCAJsGR0qR2jQT3dwjHZeXNiHpas2HeQCgn4W1 rmAt1sOH58WfyZBCEeuld5U= =Ji2D -END PGP SIGNATURE- -- messages: 3186 nosy: beschmi, droundy, kowey, limare, tommy status: unread title: bad folder urls in darcs.cgi __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue650 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue654] can't push after cancelling send
New submission from Alex Shinn [EMAIL PROTECTED]: My remote server went down earlier so I couldn't push to the main repository. Someone else needed a patch I had just made, so I tried sending it with darcs send --to addr but I get: darcs failed: Not a repository: (/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) So I just decided to wait, but now that the server is back up I can't push anymore: chernushka:hato$ darcs push darcs: bug in darcs! Empty filename in is_relative Please report this to [EMAIL PROTECTED], If possible include the output of 'darcs --exact-version'. chernushka:hato$ darcs --exact-version darcs compiled on Oct 6 2007, at 14:09:30 # configured Sat Jun 16 09:59:48 PDT 2007 ./configure /usr/local/share/config.site /usr/local/etc/config.site Context: [TAG 1.0.9 Tommy Pettersson [EMAIL PROTECTED]**20070603213706] -- messages: 3190 nosy: alexshinn, beschmi, droundy, kowey, tommy status: unread title: can't push after cancelling send __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue654 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] New performance regression?
On 07/02/2008, Simon Marlow [EMAIL PROTECTED] 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: $ darcs2 unpull --from-tag=2007-09-25 -a 134.18s real 128.56s user 2.32s system 97% darcs2 previously this was ~15 seconds. Uh-oh! But just to make sure, is it the ByteString changes at fault, or other darcs stuff? Have you tried with it with --disable-bytestring? -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 ___ 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: 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? :) -- 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] strace timing logs Re: a couple of quick timings
On Thu, Feb 07, 2008 at 06:47:08AM -0700, zooko wrote: Please make sure this is not a memory problem, since otherwise the timing is fairly worthless (and the issue is really in memory usage)... Also, checking what kind of load is on the machine (with say top) could help -- is it CPU-intensive or IO-intensive workload? Or is it mostly idling? Wait, why would the timing be worthless? Well, it would make the timing worth a whole lot less than a measurement of the memory use. Knowing whether it's a memory-use issue vs a cpu-use (or system-call-use) problem makes a big difference. The timing is a measure of how long it takes darcs and hg to do a task which I need to do (import ciphercycles tarball) on a machine that I need to use to do it. Hg works fine in this situation. Anyway, I'm re-running it now, with strace -r -tt for detailed timing information. top shows that darcs is using 94 M virt, 88 M res, and consistently using about 40% to 50% CPU (it is sharing CPU with a ghc compile). The darcs status-update-line output (you know, the nice new keep-the-user-informed feature of darcs-2) currently says Writing pristine 2049/2058 : e07cd73fa2a129ece7aa452f7fe29b6c6185e8e1, and has said this same thing for at least ten minutes. time strace -o tar.strace.log.txt -r -tt tar xjvf ciphercycles-20070205.tar.bz2 0m2.7s time strace -o darcsinit.log.txt -r -tt darcs init --hashed 0m0.3s time strace -o darcsadd.log.txt -r -tt darcs add -r ciphercycles-20070205 0m7.8s time strace -o darcsrecord.log.txt -r -tt darcs record --all -- [EMAIL PROTECTED] -m'init import of ciphercycles-20070205' 34m20.0s (Hm, perhaps sharing the CPU with ghc compile made it take twice as long. Or perhaps doing the strace logging slowed it down.) And now for Mercurial: time strace -o tar.strace.log.txt -r -tt tar xjvf ciphercycles-20070205.tar.bz2 0m2.3s time strace -o hginit.strace.log.txt -r -tt hg init 0m0.2s time strace -o hgaddremove.strace.log.txt -r -tt hg addremove 0m1.9s time strace -o hgcommit.strace.log.txt -r -tt hg commit -m'init import of ciphercycles-20070205' 0m5.5s Here is a .tar.bz2 containing all of the strace logs produced -- https://zooko.com/stracelogs.tar.bz2 . They contain fine-grained (microsecond) timing of each system call, so they should be a good help diagnosing why darcs is thousands of times slower than hg for this. Here's the first clue: wc -l straceit*/*.strace.log.txt 12662 straceit/darcsadd.strace.log.txt 323 straceit/darcsinit.strace.log.txt 1912200 straceit/darcsrec.strace.log.txt 14150 straceithg/hgaddremove.strace.log.txt 59911 straceithg/hgcommit.strace.log.txt 3614 straceithg/hginit.strace.log.txt 15736 straceithg/tar.strace.log.txt 15448 straceit/tar.strace.log.txt 2034044 total So darcs made 1.9 million system calls to do darcs record while hg made 60,000 system calls to do hg commit. Thanks, that's a good clue! -- 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] [issue658] push a partial repo to an empty repo fails
New submission from Nicolas Limare [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = Error message = $ darcs push Pushing to youkan:/srv/dev/darcs/megawave-4... darcs: bug in darcs! fromJust error at Push.lhs:136 compiled 13:47:48 Nov 20 2006 Please report this to [EMAIL PROTECTED], If possible include the output of 'darcs --exact-version'. = Version = $ darcs --exact-version darcs compiled on Nov 20 2006, at 13:48:04 # configured Mon Oct 9 15:12:44 EDT 2006 ./configure --no-create --no-recursion Context: [TAG 1.0.9rc1 Tommy Pettersson [EMAIL PROTECTED]**20061008175207] = What I wanted to do = * set an empty distant repo * set an empty local repo * fill it with the current source * push it to the server repo * set an empty distant branch repo * set a local branch repo from the previous local repo * push it to the server branch repo = What I did (IIRC) = on the distant server: mkdir megawave-3 cd megawave-3 darcs initialize cd .. mkdir megawave-4 cd megawave-4 darcs initialize locally: darcs get youkan:/srv/dev/darcs/megawave-3 cd megawave-3 (add the source) darcs add --recursive ./ darcs record -a darcs tag --checkpoint darcs push cd .. darcs get --partial megawave-3 megawave-4 (update _darcs/prefs/repos and _darcs/prefs/defaultrepo) darcs push (here comes the error) = My understanding = I guess the culprit is the --partial option, but from the doc it made sense for me. So it might a minima be a documentation bug :) = Context = First time I start to *really* use darcs, for more than a personal backup service. - -- Nicolas LIMARE labo. j-l lions - univ. pierre et marie curie [EMAIL PROTECTED] http://www.ann.jussieu.fr/~limare/ +33 (0) 144 272 721 175 rue du chevaleret - 75013 paris - france -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqyhsvviFAPpCP08RAkFDAKC2E9x7p670Jvz7dIq4NTMB8iww0gCffX4O nLElEpVzzSajGhnEqRSx8DY= =yZwf -END PGP SIGNATURE- -- messages: 3194 nosy: beschmi, droundy, kowey, limare, tommy status: unread title: push a partial repo to an empty repo fails __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue658 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: Fix ChangeLog entry. (and 2 more)
Applied. Thanks! David On Thu, Feb 07, 2008 at 02:12:12PM -0800, Eric Kow wrote: Fri Jan 25 23:27:39 GMT 2008 Eric Kow [EMAIL PROTECTED] * Fix ChangeLog entry. Thu Feb 7 21:55:26 GMT 2008 Eric Kow [EMAIL PROTECTED] * Pipe 'darcs foo --help' through a pager. Thu Feb 7 22:09:14 GMT 2008 Eric Kow [EMAIL PROTECTED] * Make broken-pipe.sh test fail on MacOS X. 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 ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] darcs patch: Add links to darcs repositories to main webpage
Applied. Thanks! David On Thu, Feb 07, 2008 at 02:42:42PM -0800, Jason Dagit wrote: Quick and dirty hack to add links to the darcs.net webpage. Please edit as needed. Thanks, Jason Thu Feb 7 14:41:20 PST 2008 Jason Dagit [EMAIL PROTECTED] * Add links to darcs repositories to main webpage Content-Description: A darcs patch for your repository! New patches: [Add links to darcs repositories to main webpage Jason Dagit [EMAIL PROTECTED]**20080207224120] hunk ./doc/index.html.in 83 lia href=http://bugs.darcs.net/?user=guest;pass=guest;Bug Tracking System/a /li lia href=http://darcs.net/cgi-bin/darcs.cgi;Darcs repository browser/a/li /ul + + h3Darcs source repositories/h3 +ul + lia href=http://darcs.net/repos/stable;Darcs Stable/a/li + lia href=http://darcs.net/repos/unstable;Darcs Unstable in Darcs 1.x format/a/li + lia href=http://darcs.net/repos/unstable-hashed;Darcs Unstable in hashed repository format/a/li +/ul -- 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] [issue660] Make it easier to find darcs source repositories from darcs.net
New submission from Jason Dagit [EMAIL PROTECTED]: The main darcs webpage at http://darcs.net does not immediately show you where to get access to the darcs source repositories. Furthermore, http://darcs.net/repos is not browse-able making it harder to discover the repositories that are available. -- messages: 3222 nosy: beschmi, dagit, droundy, kowey, tommy priority: wishlist status: unread title: Make it easier to find darcs source repositories from darcs.net __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue660 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue610] when to use a $PAGER
While the exact use-cases of the pager are still discussed, I noticed that darcs help command launches a pager, but darcs command --help doesn't. -- nosy: +salty-horse, wferi -wferi __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue610 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] PatchPlugins / XML files
Hi, On http://wiki.darcs.net/DarcsWiki/PatchPlugins there is discussion about different atomic patch types. The page points out that test files are different from binary files and suggests that those two cases might be handled adequately. It also points out that XML is different from both text and binary. (XML is kind of like text but the file might have no line endings, patches really shouldn't break the well-formedness of documents, etc.) I've looked, but so far I haven't seen whether anything like treating structured data like XML separately from text and binary has been attempted. Is anyone else interested in this sort of thing? Or has handling XML in darcs already been addressed and I just haven't seen it yet? Thanks, Allan. ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue647] wish: automated benchmarking and comparison
I should mention that I've found a couple of patterns useful in tracking down performance bugs: darcs obliterate --last 100 -a darcs pull -a darcs unrecord --last 1 -a darcs record -a -m foo It would be helpful for a benchmarking code to focus on inverse pairs like this, because they're very easy to work with when tracking down code. And a good start for a benchmarking framework would simply be something that sets up a few repos and then runs the above on each of them. David __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue647 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] darcs patch: Add links to darcs repositories to main webpage
Quick and dirty hack to add links to the darcs.net webpage. Please edit as needed. Thanks, Jason Thu Feb 7 14:41:20 PST 2008 Jason Dagit [EMAIL PROTECTED] * Add links to darcs repositories to main webpage New patches: [Add links to darcs repositories to main webpage Jason Dagit [EMAIL PROTECTED]**20080207224120] hunk ./doc/index.html.in 83 lia href=http://bugs.darcs.net/?user=guest;pass=guest;Bug Tracking System/a /li lia href=http://darcs.net/cgi-bin/darcs.cgi;Darcs repository browser/a/li /ul + + h3Darcs source repositories/h3 +ul + lia href=http://darcs.net/repos/stable;Darcs Stable/a/li + lia href=http://darcs.net/repos/unstable;Darcs Unstable in Darcs 1.x format/a/li + lia href=http://darcs.net/repos/unstable-hashed;Darcs Unstable in hashed repository format/a/li +/ul /td td width=150/td Context: [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 PROTECTED]**20080205191951 (!) :: PackedString - Int - Word8 consPS :: Char - PackedString - PackedString mallocedCString2PS :: CString - IO PackedString unpackWords :: PackedString - [Word8] mapPS :: (Char - Char) - PackedString - PackedString foldlPS :: (a - Char - a) - a - PackedString - a foldrPS :: (Char - a - a) - a - PackedString - a elemPS :: Char - PackedString - Bool spanPS :: (Char - Bool) - PackedString - (PackedString, PackedString) breakFirstPairPS :: wordsPS :: PackedString - [PackedString] splitWithPS :: (Char - Bool) - PackedString - [PackedString] gzReadFileLazily :: FilePath - IO LazyFile readFileLazily :: FilePath - IO LazyFile readHandleLazily :: Handle - IO [PackedString] We don't have any particular 'responsability' to keep FastPackedString generic. If these functions aren't likely to be used in darcs code anytime soon, we might as well remove them. ] [Upgrade readIntPS to Data.ByteString version. Eric Kow [EMAIL PROTECTED]**20080205182938] [Fix 'patch cannot contain newlines' in broken-pipe.sh test. Eric Kow [EMAIL PROTECTED]**20080205163541] [Ratify Data.ByteString IO imports. Eric Kow [EMAIL PROTECTED]**20080205162823] [Upgrade more FastPackedString functions. Eric Kow [EMAIL PROTECTED]**20080205162710 (!), unlinesPS (still concat . intersperse), findLastPS ] [Upgrade spanEndPS and breakPS to Data.ByteString version. Eric Kow [EMAIL PROTECTED]**20080205155420] [(Re)upgrade createPS and generatePS to Data.ByteString versions. Eric Kow [EMAIL PROTECTED]**20080205155322] [enable context printing of darcs-2 patches. David Roundy [EMAIL PROTECTED]**20080205163917] [generalize context viewing a bit. David Roundy [EMAIL PROTECTED]**20080205163511] [add isHunk method in effect, as precursor to more general context-showing code. David Roundy [EMAIL PROTECTED]**20080205162221] [add test for issue68. David Roundy [EMAIL PROTECTED]**20080205154147 Note that I haven't been able to reproduce this bug, but from
[darcs-devel] darcs patch: amended Depends.lhs for type witnesses
Thu Feb 7 14:17:06 PST 2008 Jason Dagit [EMAIL PROTECTED]
* amended Depends.lhs for type witnesses
New patches:
[amended Depends.lhs for type witnesses
Jason Dagit [EMAIL PROTECTED]**20080207221706] {
hunk ./src/Darcs/Patch/Depends.lhs 421
\end{code}
\begin{code}
-commute_to_end :: RepoPatch p = FL (Named p) C(x y) - PatchSet p C(y)
+commute_to_end :: forall p C(x y). RepoPatch p = FL (Named p) C(x y) - PatchSet p C(y)
- FlippedSeal (FL (Named p)) C(x)
commute_to_end select from = ctt (mapFL patch2patchinfo select) (concatRL from) NilFL
where
hunk ./src/Darcs/Patch/Depends.lhs 429
-- the patches we are going to throw away past the patches we plan to keep.
-- This puts them at the end of the PatchSet where it is safe to discard them.
-- We return all the patches in the PatchSet which have been commuted.
- ctt :: RepoPatch p = [PatchInfo] - RL (PatchInfoAnd p) C(() y) - FL (Named p) C(y x)
+ ctt :: [PatchInfo] - RL (PatchInfoAnd p) C(() v) - FL (Named p) C(v u)
- FlippedSeal (FL (Named p)) C(x)
hunk ./src/Darcs/Patch/Depends.lhs 431
- ctt [] _ acc = flipSeal acc
+ -- This unsafeCoerceP should be fine, because if we run out of
+ -- patches in the selection the ending context of the second param
+ -- should be x (because we have commute all of the selected sequence,
+ -- with context C(x y), past the elements of the second parameter.
+ -- Unfortunately this is hard to express in the type system while
+ -- using an accumulator to build up the return value.
+ ctt [] _ acc = flipSeal (unsafeCoerceP acc)
ctt sel (hp::ps) acc
| info hp `elem` sel
= case commuteFL (hopefully hp : acc) of
}
Context:
[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 PROTECTED]**20080205191951
(!) :: PackedString - Int - Word8
consPS :: Char - PackedString - PackedString
mallocedCString2PS :: CString - IO PackedString
unpackWords :: PackedString - [Word8]
mapPS :: (Char - Char) - PackedString - PackedString
foldlPS :: (a - Char - a) - a - PackedString - a
foldrPS :: (Char - a - a) - a - PackedString - a
elemPS :: Char - PackedString - Bool
spanPS :: (Char - Bool) - PackedString - (PackedString, PackedString)
breakFirstPairPS ::
wordsPS :: PackedString - [PackedString]
splitWithPS :: (Char - Bool) - PackedString - [PackedString]
gzReadFileLazily :: FilePath - IO LazyFile
readFileLazily :: FilePath - IO LazyFile
readHandleLazily :: Handle - IO [PackedString]
We don't have any particular 'responsability' to keep FastPackedString
generic. If these functions aren't likely to be used in darcs code
anytime soon, we might as well remove them.
]
[Upgrade readIntPS to Data.ByteString version.
Eric Kow [EMAIL PROTECTED]**20080205182938]
[Fix 'patch cannot contain newlines' in broken-pipe.sh test.
Eric Kow [EMAIL
Re: [darcs-devel] darcs patch: issue390: whatsnew 'stats' more files than needed.
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. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] [issue661] put = Malformed patch bundle
New submission from Mark Stosberg [EMAIL PROTECTED]: I'm marking this as urgent because darcs reports this as a bug itself, and it's rather easy to trigger with the current darcs-unstable. #!/bin/sh IFS=''; export IFS; EMAIL=tester; export EMAIL; set -ev; rm -rf tmp; darcs init --darcs-2 --repodir=tmp touch tmp/t.t cd tmp darcs add t.t echo 'content't.t darcs record -am 'initial add' echo 'remote change't.t darcs record -am 'remote change' darcs put tmp2 Result is: darcs failed: Malformed patch bundle: 'hunk ./t.t 1' is not 'Context:' +content Context: Patch bundle hash: 5818289a101f72e75fbbb0caf2475b58ef48bf86 Apply failed! shell returned 2 -- messages: 3227 nosy: beschmi, droundy, kowey, markstos, tommy priority: urgent status: chatting title: put = Malformed patch bundle topic: Darcs2, IncludesExampleOrTest __ Darcs bug tracker [EMAIL PROTECTED] http://bugs.darcs.net/issue661 __ ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] a couple of quick timings
On Feb 7, 2008, at 1:11 PM, David Roundy wrote:
Thanks for the test case, Zooko, and for pointing out this regression!
Could you rerun your timings when you have pulled this change:
I pulled your latest patches and ran it again and it took around 20
seconds.
Way to go! That is within an order of magnitude of Mercurial, which
is, IMO, the gold standard of performance for portable (i.e., non-
git) decentralized revision control tools.
Hm, no it isn't actually within one order of magnitude (base 10) --
here are some timing results and some more strace results:
MAIN wonwin-mcbrootles-computer:~$ grep ^real time-darcs109-
record.log.txt
real0m9.330s
real0m9.903s
MAIN wonwin-mcbrootles-computer:~$ grep ^real time-darcs2pre-
record.log.txt
real0m21.069s
real0m20.032s
real0m19.069s
MAIN wonwin-mcbrootles-computer:~$ grep ^real time-darcs2pre-hf-
record.log.txt
real0m24.494s
real0m23.897s
real0m23.920s
MAIN wonwin-mcbrootles-computer:~$ grep ^real time-darcs2pre-d2f-
record.log.txt
real0m24.028s
real0m24.099s
real0m23.737s
MAIN wonwin-mcbrootles-computer:~$ grep ^real time-hg-commit.log.txt
real0m2.388s
real0m2.028s
real0m2.074s
real0m2.045s
Here are strace logs of darcs and hg:
https://zooko.com/strace_logs-d2f_vs_hg.tar.bz2
MAIN wonwin-mcbrootles-computer:~$ wc -l hg_commit.strace.log.txt
d2f_record.strace.log.txt
59769 hg_commit.strace.log.txt
137595 d2f_record.strace.log.txt
HACK zooko-laptop:/tmp$ grep ^ ... open(
hg_commit.strace.log.txt | wc -l
7934
HACK zooko-laptop:/tmp$ grep ^ ... open(
d2f_record.strace.log.txt | wc -l
14183
$ find ciphercycles-20070205/ | wc -l
2100
So it looks like darcs is doing almost twice as many open() calls as
hg. Next, I chose a filename at random and grepped for that filename
in the strace logs:
$ grep aes-128-poly1305-2/estream-c.c d2f_record.strace.log.txt
0.65 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.54 open(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3
0.000151 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.000164 open(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3
$ grep aes-128-poly1305-2/estream-c.c hg_commit.strace.log.txt
0.85 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.000100 open(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
O_RDONLY|O_LARGEFILE) = 4
0.000108 open(/home/zooko/playground/timing/.hg/store/data/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c.i,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
0.000158 lstat64(/home/zooko/playground/timing/.hg/store/data/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c.i,
0xbf8698d8) = -1 ENOENT (No such file or directory)
0.74 open(/home/zooko/playground/timing/.hg/store/data/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c.i,
O_RDWR|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 4
0.41 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.75 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.76 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
So darcs is lstat'ing and opening the file twice, where hg is
lstating and opening the file once.
Digging in further, here are the relevant excerpts of the log from
the strace of darcs:
0.65 lstat64(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
{st_mode=S_IFREG|0644, st_size=847, ...}) = 0
...
0.54 open(/home/zooko/playground/timing/
ciphercycles-20070205/ciphers/aes-128-poly1305-2/estream-c.c,
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3
0.64 fstat64(3, {st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.48 fcntl64(3, F_GETFL) = 0x8800 (flags O_RDONLY|
O_NONBLOCK|O_LARGEFILE)
0.33 fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
0.32 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb7f4f4) =
-1 ENOTTY (Inappropriate ioctl for device)
0.39 fstat64(3, {st_mode=S_IFREG|0644, st_size=847, ...}) = 0
0.48 read(3,
