Camelia, the Perl 6 bug

IRC log for #darcs, 2013-02-21

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:29 whaletechno joined #darcs
01:21 mizu_no_oto joined #darcs
01:53 mizu_no_oto joined #darcs
02:01 favonia joined #darcs
02:37 intripoon joined #darcs
02:50 mizu_no_oto joined #darcs
04:02 mizu_no_oto joined #darcs
04:44 preflex_ joined #darcs
06:01 gh_ joined #darcs
06:29 carter joined #darcs
06:41 lelit joined #darcs
07:41 stepcut joined #darcs
07:48 Igloo joined #darcs
08:19 amgarchIn9 joined #darcs
08:39 donri joined #darcs
09:12 raichoo joined #darcs
09:13 florent_ joined #darcs
09:14 jnaimard hi all
09:19 stepcut joined #darcs
09:32 gh_ hi jnaimard
09:38 jnaimard I did manage to lose some of my sprint work while rebasing
09:38 jnaimard (used revert -a while I hadn't added a file, oh well)
10:03 stepcut joined #darcs
10:06 donri rebasing in darcs sounds scary
10:08 iago joined #darcs
10:09 jnaimard i actually didn't need rebase to make that mistake
10:10 jnaimard that's vcs 101: check unrecorded changes before you revert them
10:10 jnaimard i made the mistake before i started rebasing, in fact
10:20 donri aha
10:20 donri but i've heard horror stories about darcs rebase in here before ;)
10:21 donri would be nice if the "stash" workflow was easier with darcs
10:21 jnaimard rebase does have some rough edges
10:21 jnaimard but I find it nice to use now
10:22 jnaimard of course I don't have a lot of points of comparison
10:22 jnaimard yes, stashing could be made easier
10:23 jnaimard i'm not sure what is the right way to do that though
10:23 jnaimard adding an explicit stash feels a bit ad-hoc
10:24 donri i'm thinking it would create a patch bundle á la record && send -O && obliterate
10:25 donri but in a single command, not requiring a name (instead enumerate stash-N.dpatch), maybe put the bundle in _darcs somewhere to not mess up rec --look-for-adds
10:26 jnaimard you can already group send -O && obliterate into obliterate -O
10:26 donri ah neat
10:26 jnaimard what you suggest could be revert -O
10:26 * jnaimard tries to invoke a grumpy old man
10:27 donri are you suggesting revert -O or saying it exists?
10:28 jnaimard I'm suggesting it merely
10:28 donri sounds good
10:29 gh_ should be super easy to implement
10:29 jnaimard indeed
10:29 donri another option might be to make revert always "stash" and unrevert prompt for patches to unrevert
10:29 gh_ or always copy the unrevert patch to /tmp/ with an incremental name
10:30 jnaimard do you have a git/hg equivalent command(s) you're trying to reproduce?
10:30 jnaimard at some point, it becomes easier to just give it a name
10:30 gh_ I guess git stash
10:30 donri i mean change the unrevert thing to store multiple reverts and never overwrite (other than with some gc command like optimize)
10:30 donri yea git stash, but trying to think of a darcsier UI
10:31 jnaimard how do you restore changes once they've been git stashed?
10:31 donri git stash apply
10:32 jnaimard and how does it let you choose between what you've stashed?
10:33 donri i think it will prompt, unless you pass it a stash name (you can name stashes at creation)
10:33 donri When no <stash> is given, stash@{0} is assumed, otherwise <stash> must be a reference of the form stash@{<revision>}.
10:33 donri i was wrong
10:34 donri but i'm not sure the git UI fits darcs very well
10:35 jnaimard no, but we can see what assumptions they make
10:35 jnaimard it seems either you give a name, or you use it as a stack
10:36 donri cf. in-repo branches and darcs preference for directories-as-branches, which is why i thought stashing to patch bundles might be more darcsy
10:36 donri yeah
10:38 kmels_ joined #darcs
10:38 donri actually with that in mind i'm not sure i like the idea of putting it inside _darcs. duno.
10:39 jnaimard you can try using record + obliterate -O and see what you like/dislike
10:40 jnaimard it'd be nice to hear what you think
10:44 donri it works nicely. i'd like to not need to name the patch, and not be prompted for the patch for obliterate. just 'darcs revert -O' and be done with it.
10:44 donri thanks for ob -O anyway! i'll remember it
10:46 jnaimard i see, with revert -O using current time to name the bundles or some such
10:47 donri that could work
10:50 jnaimard thanks for the suggestion
10:50 donri thanks for listening :)
11:20 kmels joined #darcs
11:35 lelit joined #darcs
11:36 owst joined #darcs
11:36 jnaimard hi owst
11:36 owst hi jnaimard
11:37 owst I see you nuked some work :-(
11:47 jnaimard not too much
12:43 gh_ joined #darcs
12:53 gh_ there is more negative feedback about non-interactive `darcs changes`
12:53 gh_ on the darcs-users list.
12:57 jnaimard Is it too late to change the default for 2.10
12:57 jnaimard ?
12:58 Heffalump no
12:58 Heffalump I thought the negative feedback was about it not using less.
12:59 Heffalump Mind you, since most commands are interactive, it makes sense to change changes.
13:00 gh_ I agree
13:00 jnaimard one could argue for 'y' to be 'p' rather than 'v' in changes (if more than one screenful(
13:01 gh_ good point.. I never use 'v' in changes
13:04 gh_ I wonder if some people would be surprised by interactive changes by default, and would not know how to escape it
13:04 gh_ (with 'q')
13:05 Heffalump I think the switch would certainly be disruptive.
13:06 jnaimard it'll all be solved in the js webui
13:06 * jnaimard ducks
13:08 * jnaimard just broke 2/3 of the tests…
13:18 mizu_no_oto joined #darcs
13:19 mizu_no_oto joined #darcs
13:26 jnaimard gh_: the trackdown test is *really* slow, maybe the longest two tests could not be done with --linear
13:30 gh_ are those test07 and test08 ?
13:32 gh_ the thing is, it compiles its own haskell script at the beginning
13:33 jnaimard i'm not sure
13:33 gh_ it could be a bash script instead of a haskell script
13:33 jnaimard i think this would be these
13:34 jnaimard maybe it's ghc that's slow, i don't know
13:35 jnaimard it seemed to be that from skimming over the test code, but really I don't know
13:36 gh_ maybe we should only have test scripts that take at most 5 seconds each one
13:36 jnaimard compiling the haskell script is not that long
13:37 jnaimard 5 seconds * 388 = 25 minutes…
13:38 gh_ "at most"
13:38 jnaimard yes, but 388 is ever-increasing
13:39 jnaimard I'd like to be able to say "do random tests for 2 minutes and report"
13:39 jnaimard or something like this
13:40 gh_ I'm not sure what the "long repos" of this test are supposed to check..
13:41 gh_ we could keep only test 1 to 6
13:42 jnaimard that would probably be bette
13:42 jnaimard r
13:42 gh_ ...which brings the exec time down to 23s for Darcs1 and Darcs2
13:43 gh_ removing test6 -> 14s
13:48 jnaimard that's what an exponential does to you!
13:48 * owst rembers Heffalump saying something about needing Haskell scripts rather than bash scripts, for windows?
13:49 jnaimard i don't know how u
13:49 jnaimard how much faster a single haskell executable would be
13:50 jnaimard ie how long the test suite spends forking 388 shells
13:50 owst Yeah
13:50 Heffalump owst: that's for when darcs is given a command to run, e.g. a n editor
13:50 Heffalump *an* editor
13:50 Heffalump the normal test harness shell scripts work fine in general
13:50 owst and doing a bunch of repeated set-ups for "darcs init --repo R; cd R; touch foo; darcs rec -alm foo"
13:50 owst right
13:51 owst The tests were pitifully slow when I was watching Heffalump run them
13:53 * gh_ sends a patch for the trackdown test
13:54 jnaimard I have spooky action at a distance in the test for issue1105
13:55 owst jnaimard: ?
13:57 jnaimard sending a patch, one moment
14:01 jnaimard if you do darcs changes -a with "changes author me" in _darcs/defaults, it succeeds
14:01 jnaimard while darcs changes doesn't (as it should)
14:01 jnaimard note that changes --author me does not work
14:10 owst jnaimard: so the bug is that -a ignores incorrect flags?
14:11 mizu_no_oto joined #darcs
14:11 jnaimard i'm not sure
14:12 jnaimard it ignores *some* incorrect flags when they come from *_darcs/defaults*
14:12 jnaimard --author seems to trigger the bug
14:12 owst Oh, so `darcs cha -a --author foo` still breaks?
14:13 jnaimard yes
14:13 owst what about the -a after --author?
14:13 jnaimard and darcs cha -a still breaks with for instance "--summary arg" in the default file
14:13 jnaimard owst: fails too
14:14 owst Weird!
14:15 jnaimard yes
14:27 jnaimard it's not only -a, -s does that too
14:27 jnaimard any option actually, it seems
14:31 owst So any broken options in _darcs/defaults are ignored, if you pass flags directly when invoking darcs?
14:31 jnaimard yes
14:41 gh_ I'd like to replace sigPIPE.sh by this much faster version, but I don't know why `darcs changes | head -1` fails in the end : http://hpaste.org/82794
14:42 owst What error does it fail with?
14:43 owst What's that test even testing?
14:43 gh_ I don't know how to see the error
14:43 owst Run the shell script manually
14:43 gh_ yes, I'm using -t sigPIPE.sh
14:43 owst tests/sigPIPE.sh
14:44 owst (you'll need chmod +x first)
14:44 owst or I suppose `bash tests/sigPIPE.sh`
14:44 gh_ it uses the lib
14:44 owst It doesn't actually use it though
14:44 owst AFAICT
14:47 gh_ when I run it manually the exit code of darcs cha | head -1 is 0
14:47 owst So, success?
14:47 owst What is the output of darcs cha?
14:47 owst (and the exit code)
14:51 gh_ doesn't fail
14:52 gh_ only fails with ` | head` appended to it
14:52 owst but the exit code was 0 with | head, that's not a failure?
14:52 owst Oh, you mean it fails when run by the test harness with `| head` ?
14:53 gh_ yes
14:53 gh_ interestingly, `darcs --version | head -1` does not fail
14:53 gh_ could it be an encoding issue ?
14:54 owst What have you changed, relative to the working test?
14:54 owst presumably, the old test works?
14:54 gh_ the old test generated (slowly) its own repo, looping through many darcs rec and darcs tag
14:54 owst Right
14:57 owst What is the test actually testing, though?
14:59 owst I don't understand how it could fail in the harness, but not manually.
14:59 owst the harness essentially creates a clean dir, copies the test in there, and then executes `bash test`
15:01 gh_ it testes http://bugs.darcs.net/issue160
15:01 gh_ basically: piping long outputs of darcs could produce sigPIPE errors
15:02 owst Oh I see
15:03 gh_ other variant: replacing head by cat removes the error
15:11 owst gh_: for me, running your test manually gives an exit code of 2
15:13 gh_ ok..
15:14 owst And it's darcs that's giving that exit code
15:14 owst echo ${PIPESTATUS[0]}
15:14 owst gives you the exit code of the 0-th pipe component
15:14 owst (need to remove `. lib` for that to get run after the broken command)
15:15 * owst goes back to work
15:15 gh_ ok thanks
15:16 gh_ removing "." is enough to remove the error...
15:17 owst set -vex -o pipefail
15:17 owst That probably does something relevant!
15:17 owst gh_: also, the format is already defined in lib
15:18 owst s/format/format checking/
15:19 mizu_no_oto joined #darcs
15:21 jnaimard owst: judging from the sprint report picture, you would be Ma Dalton
15:24 * owst doesn't get it, even after Googling :-0
15:25 jnaimard http://en.wikipedia.org/wiki/​The_Daltons_%28Lucky_Luke%29
15:25 gh_ so it means the test catches some failure of darcs. yet nothing is apparent.
15:26 owst jnaimard: by that link, you are the most dangerous! :-)
15:27 jnaimard I don't know where they get dangerous from
15:27 jnaimard i'd rather say irritable
15:38 owst jnaimard: re: issue2305, why do you want to have to hit C-c twice?
15:39 jnaimard I don't want to
15:39 owst "darcs should have started getting those patches, stopping only if I had
15:39 owst |hit Ctrl-C a *second* time."
15:39 owst Err,
15:39 jnaimard that's what a user who really wants to stop darcs right now and get a non-working repo would have to do
15:39 jnaimard hence "only if"
15:40 owst Oh I see, so you want it to get the patches it needs, and no more
15:40 jnaimard yes
16:24 owst Cool: going to this page on the wiki breaks darcs: http://darcs.net/_diff/Development/Regr​essionTests?to=20130216150056-66cc6-185​a291b937f5989733f4ef1db739d63f751b8d4
16:25 owst Server error: UnknownError: darcs changes returned error status.
16:25 owst darcs: Couldn't find first patch affecting ./development/RegressionTests.page in pis_and_fs
16:36 jnaimard amusing
16:53 gh_ uh... tests involving lighttpd that ran 10 minutes ago are now skipped
17:01 * Heffalump appears
17:02 Heffalump owst: errk...
17:04 gh_ ok, remaining lighttpd processes I had to kill
17:07 owst How do I get the wiki repo?
17:07 owst I can't find how on the wiki
17:08 gh_ Wiki source: darcs get --lazy http://darcs.net/darcs-wiki
17:08 gh_ written in every page's footer
17:08 owst haha! so it is
17:12 stepkut joined #darcs
17:13 gh_ oh, the default as of now is `get --no-packs`
17:14 owst Err.
17:15 owst HEAD darcs is hanging for me, when I say `darcs cha Development/RegressionTests.page`
17:15 gh_ I remember we decided this in the 2011 sprint and never but it back on by default :s
17:15 owst 2% cpu, memory fixed
17:16 owst Oh, it's downloading patches, that's strange - I didn't get --lazy, or CTRL-C
17:47 amgarchIn9 joined #darcs
18:09 * Heffalump considers biting the bullet and doing the disk/display split in ShowPatch
18:14 gh_ yay
18:14 jnaimard is it possible to have an alias for a command with different flags
18:15 jnaimard (make log an alias for changes --all)
18:15 gh_ yes
18:15 gh_ status is an alias for whatsnew -sl
18:15 jnaimard thanks i'll have a look
18:22 schlaftier joined #darcs
18:29 gh_ looks like curl timeout is always 30 seconds no matter wha
18:29 gh_ t
18:30 amgarchIn9 joined #darcs
18:32 stepkut joined #darcs
18:35 rdesfo joined #darcs
18:36 carter joined #darcs
18:44 Heffalump gh_: you think that's the problem with packs?
18:46 gh_ Heffalump, no, I'm trying to make tests/issue1599-automatical​ly-expire-unused-caches.sh run faster by setting the timeout to 1 second
18:54 schlaftier joined #darcs
19:10 rdesfo joined #darcs
19:22 snorble_ joined #darcs
19:27 gh_ the timeout is in fact more something like 2 minutes
19:28 gh_ I'm beginning to suspect it has never been possible to change it in darcs
19:38 Igloo joined #darcs
19:45 sm gh_: nice job on http://blog.darcs.net/2013/02/da​rcs-hacking-sprint-8-report.html btw
19:46 sm and I wonder why it's not showing at planet.darcs.net
19:49 Igloo joined #darcs
19:50 sm hm. Updated manually without problem, but the last update via cron was yesterday.
19:50 raichoo joined #darcs
20:12 mizu_no_oto joined #darcs
20:13 rdesfo left #darcs
20:38 Igloo joined #darcs
20:41 `nand` joined #darcs
20:48 sm owst: fixed your feed on http://planet.darcs.net/
20:51 Igloo joined #darcs
21:26 markstos joined #darcs
21:27 markstos I've just recorded about 400 text files of modest size, and am attempting to do a local push with them using darcs 2.9.7, with --debug-verbose enabled. The output gets to "Done merging us" and then hangs. Is this to be expected? There is no conflict... these files don't exist on the other end.
21:28 Heffalump is it using CPU?
21:28 markstos yes, 100%.
21:29 Heffalump so just one patch?
21:29 markstos Yes.
21:29 Heffalump I can't think of any good reason for that.
21:29 * Heffalump tries to think of further debugging steps
21:30 jnaimard good night all
21:30 markstos The test case is easy enough, it's this Perl distribution, primarily: https://metacpan.org/release/Perl-Critic
21:30 markstos The files are in here: http://cpan.metacpan.org/authors/id/T​/TH/THALJEF/Perl-Critic-1.118.tar.gz
21:30 Heffalump so a fresh repo with a patch adding those files?
21:31 markstos I haven't done that step on my end to test the reduced case yet,
21:31 Heffalump how big is the existing repo?
21:31 markstos and actually, I was only adding these files to source control now because it was supposed to be "easy". I can defer the project until later.
21:31 markstos Which size metric do you want?
21:31 Heffalump patches
21:32 Heffalump just roughly
21:32 markstos About 18,000
21:32 markstos The repo I'm pushing from is a neglected branch, so it probably has a big delta from the trunk. That could be an issue, too.
21:32 Heffalump ah, so it's a long way behind the trunk?
21:32 markstos It has lots of patches from the trunk it hasn't pulled.
21:33 Heffalump in that case you're merging lots of patches with the new one, which goes some way to explaining the use of CPU
21:33 markstos Yes, 329 patches behind.
21:33 Heffalump but nonethless if there's no conflict it shouldn't be very slow
21:34 Heffalump ok, I'm trying pushing a fresh patch with those files in between otherwise empty repos and it took 10-15s
21:34 Heffalump which seems excessive
21:34 markstos Thanks for the support. As a practical measure, I'm going to give up today. We can re-add these files later from another dev's repo that is more up-to-date.
21:34 Heffalump in general when I've had trouble with push, pull sometimes behaves better, FYI
21:34 Heffalump I have no solid explanation for why
21:34 markstos You could try again with --debug-verbose to see where the time is being spent.
21:34 Heffalump I will
21:35 markstos Oh, that's curious. I'll try that now.
21:35 Heffalump you know about --timings too?
21:35 Heffalump though apparently not everything gets timings even if you use it :-)
21:35 markstos No, I don't.
21:36 markstos I'm trying a pull now. It's hanging at the same spot. I'll give a minute or so, and then give up.
21:36 Heffalump oh the lack of consistency is because the 'remote 'darcs command doesn't get sent the timings
21:36 markstos I've looked through the patches generated by the Sprint some. Definitely a burst of activity there.
21:36 Heffalump another thing to yry (feel free to give up at any point, of course) is to send -o the patch, then do a darcs apply in the other repo
21:37 markstos Thanks for the tip. I think I'll try again from a more-synced repo at some point.
21:37 Heffalump btw, you're sure none of the missing patches might do something like adding and then removing this same set of files?
21:37 Heffalump that would likely explain a lot of conflict-untangling work
21:38 markstos OH.
21:38 markstos It could be that some of these files have been added and removed before, instead of never-added.
21:40 Heffalump hmph, --timings seems to lie to me!
21:40 * markstos shakes fist at --timings
21:41 Heffalump (it's claiming everyhting happens on the sending side in the blink of an eye, when it doesn't)
21:41 markstos Ah, that's no good.
21:41 Heffalump although this whole push seems substantially less efficient than it should be, it doesn't come close to explaining your experience.
21:41 Heffalump so that must be based on the extra patches
21:42 Heffalump I shall consider this a further internal nudge to work on my repo obfuscator a bit more.
21:42 Heffalump so if easy, please do preserve the repos
21:42 stepkut joined #darcs
21:43 markstos Won't it be more interesting to work on problems someone is actually having when obfuscator is done, instead of a problem I had once sometime in the past (and no else seems to have).
21:43 Heffalump perhaps you're right
21:44 markstos There seems to be a reasonable probability I will produce interesting test cases in the future, though. :)
21:46 Heffalump :-)
21:46 Heffalump I suspect you have the biggest darcs repos in active use anywhere
21:49 markstos Or the other person is keeping quiet and not running into any problems.
21:50 markstos It continues to work very well for our team and project, and we've based on workflow around, not to mention knowing it very well.
21:50 Heffalump how big is your team?
21:50 markstos We've been "stuck" with issues only rarely, and never for very long.
21:51 markstos 4 active committers (3 programmers, one designer). 5 other people have been trained on darcs but are no longer active committers.
21:52 markstos All dev and alpha repos are on the same machine.
21:53 markstos In some cases, we use the method of oblit'ing all copies of  a patch to fix something. That' s just a bit of manual work or a little bash scripting on machine, but would be a headache with larger team and repos scattered across laptops, etc.
21:53 markstos Of course, the local push/pulls likely help with performance too.
21:54 markstos We tag about every two weeks, that likely helps some too.
21:55 markstos We tag in production, just before we pull a new release in, because everything else is a super-set of production, so the production tags are safe to pull everywhere. We can't safely tag anywhere else first, because of our heavy use of cherry-picking... we would end trying to pick a patch behind a tag.
21:56 markstos The patch-index work has probably helped as a lot. I think I've already normalized the performance gains, and started to use certain commands more often.
21:57 markstos I hear there's another company sponsoring a developer to work on darcs. Do we know what features they are working on?
21:59 gh_ they would like to add some history abotu who pulled/pushed what patch in a given repo
22:06 Heffalump markstos: there's some traffic on the list about this
22:08 markstos Found the Trello board for it: https://trello.com/board/darcs-​factis/51098501825caeb428000288
22:09 markstos I want this feature, too: "Export dependency graph of one or multiple repositories. UI for querying dependencies."
22:09 markstos Particularly for getting a "network view" of which unique patches reside in each of a number of connected repos.
22:09 markstos Something like the "branches" view on the Hub.
22:12 mizu_no_oto joined #darcs
22:12 markstos darcs-history looks usefulu for us, too: http://www.informatik.uni-kiel.de/~s​ebf/darcs/darcs-history/README.html
22:39 amgarchIn9 joined #darcs
22:52 favonia joined #darcs
23:01 iago joined #darcs
23:03 Igloo joined #darcs
23:09 gh_ the "Applying to pristine... " step after getting a packed repo with extra patches is super slow
23:09 gh_ totally ruins the point of packs :)
23:10 gh_ it's even worse since it uses lots of CPU, above being slow
23:17 gh_ ok, even without extra patches it seems
23:34 mizu_no_oto joined #darcs
23:37 mizu_no_oto joined #darcs
23:39 kmels joined #darcs
23:54 favonia joined #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary