Camelia, the Perl 6 bug

IRC log for #darcs, 2011-05-12

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

All times shown according to UTC.

Time Nick Message
00:05 jonkri left #darcs
00:16 kyagrd left #darcs
00:51 owst joined #darcs
00:57 mornfall left #darcs
00:58 mornfall joined #darcs
00:58 mornfall left #darcs
00:58 mornfall joined #darcs
01:08 gal_bolle left #darcs
01:10 JaffaCake1 joined #darcs
01:13 JaffaCake left #darcs
01:36 sm_ joined #darcs
01:38 sm__ joined #darcs
01:39 gwern left #darcs
01:39 sm left #darcs
01:39 sm__ is now known as sm
01:41 sm_ left #darcs
01:56 gwern joined #darcs
01:56 gwern left #darcs
01:56 gwern joined #darcs
02:27 gwern left #darcs
02:36 gwern joined #darcs
02:36 gwern left #darcs
02:36 gwern joined #darcs
02:42 gwern left #darcs
02:50 dankna left #darcs
03:00 gwern joined #darcs
03:22 secorp joined #darcs
04:38 gwern left #darcs
04:41 gwern joined #darcs
04:41 gwern left #darcs
04:41 gwern joined #darcs
04:54 gwern left #darcs
05:01 gwern joined #darcs
05:33 sm left #darcs
05:44 jeltsch joined #darcs
05:44 jeltsch left #darcs
06:02 jderque joined #darcs
06:04 Gwern-away joined #darcs
06:04 Gwern-away left #darcs
06:04 Gwern-away joined #darcs
06:06 gwern left #darcs
06:25 Gwern-away left #darcs
06:30 gwern joined #darcs
06:31 balor_ joined #darcs
06:33 balor_ left #darcs
06:33 balor_ joined #darcs
06:37 kolmodin joined #darcs
06:37 kolmodin left #darcs
06:37 kolmodin joined #darcs
07:40 Weltraumschaf joined #darcs
07:54 balor_ left #darcs
08:02 gwern left #darcs
08:06 jderque left #darcs
08:10 gwern joined #darcs
08:14 JaffaCake1 is now known as JaffaCake
08:21 raichoo joined #darcs
08:22 gwern left #darcs
08:36 gwern joined #darcs
08:36 gwern left #darcs
08:36 gwern joined #darcs
08:36 plopix Heffalump: a shared repository is owned by group users and if a uses a 'darcs get' the gid is changed in primary gid of user
08:36 kowey joined #darcs
08:48 shenshei joined #darcs
08:49 Gwern-away joined #darcs
08:49 Gwern-away left #darcs
08:49 Gwern-away joined #darcs
08:52 gwern left #darcs
08:55 lelit plopix: that's the usual behaviour, what did you expect instead?
08:57 lelit I mean, when you "cp" a file owned by someone else (if you have read perms that is) the new file will have you/your-primary-group as owner
08:57 mornfall You could (ab)use group sticky bits to work around that.
08:58 lelit you mean when that is set on the container folder?
08:58 mornfall Yep.
09:11 Weltraumschaf hi, where can i find explanation of the new conflict markers with the ===. its not dewscribed here http://wiki.darcs.net/ConflictsFAQ
09:17 kowey http://darcs.net/manual/Darcs_comman​ds.html#SECTION006111000000000000000 talks about them
09:17 kowey it'd be fantastic if somebody could update the conflicts FAQ accordingly
09:35 Gwern-away left #darcs
09:55 gwern joined #darcs
09:55 gwern left #darcs
09:55 gwern joined #darcs
10:04 jderque joined #darcs
10:04 Weltraumschaf thx
10:11 gwern left #darcs
10:16 gwern joined #darcs
10:16 gwern left #darcs
10:16 gwern joined #darcs
10:21 gwern left #darcs
10:31 gwern joined #darcs
10:31 gwern left #darcs
10:31 gwern joined #darcs
10:40 gwern left #darcs
10:41 gwern joined #darcs
10:41 gwern left #darcs
10:41 gwern joined #darcs
10:58 gwern left #darcs
11:01 gwern joined #darcs
11:01 gwern left #darcs
11:01 gwern joined #darcs
11:21 gwern left #darcs
11:28 gwern joined #darcs
11:43 gwern left #darcs
11:48 gwern joined #darcs
11:48 gwern left #darcs
11:48 gwern joined #darcs
11:58 gwern left #darcs
11:59 raichoo left #darcs
12:09 raichoo joined #darcs
12:10 dankna joined #darcs
12:14 gwern joined #darcs
12:14 gwern left #darcs
12:14 gwern joined #darcs
13:02 gwern left #darcs
13:06 jderque left #darcs
13:14 gwern joined #darcs
13:21 gwern left #darcs
13:35 gwern joined #darcs
13:35 gwern left #darcs
13:35 gwern joined #darcs
13:40 gwern left #darcs
14:01 gwern joined #darcs
14:04 gal_bolle joined #darcs
14:08 raichoo left #darcs
14:09 gwern left #darcs
14:21 gwern joined #darcs
14:21 gwern left #darcs
14:21 gwern joined #darcs
14:51 sm joined #darcs
15:02 Gwern-away joined #darcs
15:02 Gwern-away left #darcs
15:02 Gwern-away joined #darcs
15:05 secorp left #darcs
15:05 gwern left #darcs
15:08 Gwern-away is now known as gwern
15:08 etarasov joined #darcs
15:11 dixie hehe
15:11 dixie http://qubodup.soup.io/post/129797622/G​it-vs-Subversion-vs-Mercurial-vs-Bazaar
15:12 shenshei left #darcs
15:12 balor joined #darcs
15:12 kowey that's including plugins, I suppose
15:13 kowey oh, nevermind, misread
15:14 owst So he's looking for Arch packages that pull from a repo to build the latest package... as he says, not sure what you can learn from it.
15:16 Phlogistique "the underground Bazaar"
15:31 balor left #darcs
15:31 balor joined #darcs
15:42 raichoo joined #darcs
15:43 raichoo left #darcs
15:43 zooko joined #darcs
15:43 zooko Hello, people of #darcs!
15:43 zooko I'm having this trouble again, which I've reported before and someone explained that it couldn't possibly be doing that or I must be confused.
15:44 zooko The trouble is, davidsarah has posted a patch on our trac:
15:44 zooko http://tahoe-lafs.org/trac/tah​oe-lafs/ticket/1404#comment:2
15:44 zooko And when I run darcs apply on it, darcs says:
15:44 zooko darcs: Cannot apply this patch bundle, since we're missing:
15:44 zooko Sun Jan 30 09:49:23 MST 2011  david-sarah@jacaranda.org
15:44 zooko * scripts/common.py: don't assume that the default alias is always 'tahoe' (it is, but the API of get_alias doesn't say so). refs #1342
15:44 zooko
15:45 zooko But, I really doubt that davidsarah's patch "docs: remove out-of-date docs/testgrid/introducer.furl and containing directory. fixes #1404", which I'm trying to apply, actually depends on "scripts/common.py: don't assume that the default alias is always 'tahoe' (it is, but the API of get_alias doesn't say so). refs #1342"
15:45 zooko I'm sure it doesn't, because it doesn't even ...
15:45 * zooko double checks
15:48 zooko So the new one that I'm trying to apply has hunk ./docs/testgrid/introducer.furl, rmfile ./docs/testgrid/introducer.furl and rmdir ./docs/testgrid.
15:48 zooko The old one that it is saying it is missing has hunk scripts/common.py
15:48 zooko So there's no way that one depends on that other one.
15:48 gal_bolle left #darcs
15:51 kowey hi zooko: it's not really a question of dependencies
15:51 shenshei joined #darcs
15:52 zooko Hi kowey.
15:52 kowey darcs send on davidsarah's side just pessimistically assumes whatever context the remote repo has at the time of send
15:53 kowey it does not make any effort to produce what is called a "minimal" context, ie. by commuting the patch down to actually the minimum number of dependencies it needs
15:53 zooko So, that's what I thought, which is why I added these instructions for our contributors to work around this:
15:53 zooko http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Patch​es?action=diff&version=21&old_version=20
15:54 zooko But then I couldn't reproduce it and then someone -- lispy? -- on this channel told me I was wrong and this was all unnecessary
15:54 zooko So I undid the workaround instructions: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Patch​es?action=diff&version=23&old_version=22
15:54 zooko But apparently I was right and I need to re-establish the workaround?
15:54 kowey forgive me for asking (this is a bit of a "have you tried turning it off and on"), but are you sure the repo you are applying the patch to is up to date?
15:55 zooko It is not up to date.
15:55 zooko I didn't intend for it to be up to date.
15:56 kowey when you say it's not up to date, you mean it contains fewer patches than http://tahoe-lafs.org/source/tahoe-lafs/trunk pristine ?
15:56 zooko Yes.
15:57 kowey ah, I notice their patch was for davidsarah@dev.allmydata.org:/home/darcs/tahoe/trunk
15:58 zooko Yes.
15:58 kowey so basically, if davidsarah normally just push/pull against that repo
15:58 zooko So, I feel like I must be missing something conceptually here. Isn't the ability to apply only a subset of the patches, i.e. the ones that the desired patch depends on, kind of the core thing that differentiates darcs from the rest?
15:58 zooko Why does this core thing not work with "darcs apply" when it works with "darcs pull"?
15:59 kowey well hang on, let's get to things one step at a time
15:59 kowey are you confident now that the issue is just a limitation, and not an actual bug?
15:59 kowey or should we establish the forensics behind that fact first?
16:00 zooko Yes, I understand that.
16:01 zooko Last time around I was confused about the difference between the "extra" patches being in davidsarah's repo from which they are running "darcs send" vs. the "extra" patches being in the repo to which they are targetting the darcs send.
16:01 zooko There are 3 repos involved here, compared with only 2 repos for push or pull.
16:01 kowey OK thanks
16:01 zooko So the workaround instructions I wrote were incorrect, as they were saying that you needed to avoid extraneous patches in your -- source -- repo when doing "darcs send".
16:02 kowey hmm
16:03 kowey well, before trying to think about what the correct instructions are, let's think a bit more about what we should expect darcs to do
16:03 kowey (sorry, this is just a UI curiosity for me -- ie. what would users of darcs send and apply expect?)
16:03 zooko I guess the correct workaround for our workflow is for the person doing the applying: instead of just running "cd $MYREPO && darcs apply $PATCH", you should do "darcs get --lazy $TRUNK pristine && cd pristine && darcs apply $PATCH && cd ../$MYREPO && darcs pull --patch="$PATTERN" ../pristine && cd .. && /bin/rm -rf ./pristine".
16:03 zooko :-)
16:03 kowey one workflow which may work for you is
16:04 kowey darcs get http://mainrepo --context foo.dpatch
16:04 kowey cd mainrepo
16:04 zooko What's --context mean?
16:04 kowey darcs apply ../foo.dpatch -i
16:05 kowey when given a context file (a dpatch file happens to double as a context file), darcs get --context will grab the repo and unapply all the patches that are not listed in that bottom part of the patch bundle
16:05 kowey OK, the --context is superfluous come to think of it :-)
16:06 kowey but darcs get --context will basically make the repo you're getting look like the intersection of davidsarah's repo and the repo they were sending to at the time of the send
16:06 zooko Ok.
16:06 zooko Cool.
16:06 kowey (which can be handy for looking at line numbers, and also getting a better sense of what the original author intended)
16:07 kowey (particularly when you're trying to untangle a conflict -- this lets you get an "X thinks 'foo'" and "Y thinks 'bar'" understanding)
16:08 kowey I think your workflow looks right, I'm not completely sure
16:08 zooko Okay thanks, I think I understand the issue now.
16:08 kowey we have a similar issue with our screened/reviewed distinction
16:09 kowey and I have some scripts that manage the bureaucracy a bit
16:09 zooko I still don't know why the logic that chooses to pull only a subset of patches from a repo can't also choose to apply only a subset of patches when running "darcs apply $PATCHFILE", and then stop and complain *only* when it needs a patch and that patch isn't available.
16:10 jderque joined #darcs
16:10 zooko For example, in that work-around work-flow that you and I just sketched out
16:10 zooko At the end of it, you run "darcs pull --patch="$PATTERN" ../mainrepo"
16:10 zooko And darcs pulls *only* $PATTERN plus any required dependencies -- it doesn't pull all patches from ../mainrepo.
16:10 zooko So why can't it do the same thing if I just say "darcs apply $PATCHFILE"?
16:11 kowey I think you can use darcs apply -p btw
16:11 kowey but that's not really answering your question
16:12 kowey one way to look at the situation, is that darcs pull and darcs apply are (like in your model) doing the same thing, right? grabbing some patches from a repository (in the pull case), or a virtual repository (ie. a bundle) in the apply case
16:13 zooko Okay, I suppose so.
16:13 kowey and in that way of looking at it, nobody ever got around to writing an extra bit of code that makes it such that when you try to "pull" patches from a bundle
16:13 kowey and those patches are not literally in the bundle
16:13 kowey that it should some smart virtual repository magic by fetching said patches from elsewhere
16:14 kowey so that's one way to understand the situation
16:14 zooko No, that's not what I'm asking for.
16:14 zooko All I'm asking for is that it does not stop because of the fact that the bundle mentions a patch that I don't have but also don't need.
16:14 zooko So in this case there is only one patch in the bundle.
16:15 kowey how do you know you don't need the patch in question?
16:15 zooko Plus, it *mentions* all the patches that were in the central repo at the time of "darcs send".
16:15 zooko By the same way that you know you don't need it when you do "darcs pull" in our work-around work-flow.
16:15 kowey OK, so that's the interesting missing bit of mental model I should fill in
16:15 kowey (thank-you, this is very educational for me, but I may not remember the lessons at a useful point)
16:16 kowey the missing bit of mental model
16:16 kowey is that the mechanism for darcs to determine if it needs the patch in question requires it to actually have the patch in question
16:16 kowey so when you do a darcs pull, and it does all its cherry picking magic
16:16 kowey it actually fetches the patches you're trying to cherry pick past so that it can calculate its commutations
16:17 kowey do you agree that this patch fetching was missing from your mental model?
16:17 zooko Yes.
16:17 kowey basically it has to actually look at the patch first to know it doesn't need it
16:18 zooko sigh
16:18 kowey so in the case of darcs pull, fetching the patch is straightforward, just grab it
16:18 kowey in the case of darcs apply, well all we have is the name of the patch
16:18 kowey a *smarter* darcs might somehow try to grab the patch from a third party
16:18 kowey unfortunately, the current darcs isn't that smart
16:19 kowey (and also it's not clear if such smartness would end up biting us in the long run)
16:19 zooko Also that would open up other failure modes.
16:19 zooko Yeah what you said.
16:19 kowey sorry, this is one of the downsides of our whole-history approach
16:20 kowey ie. when we mean whole history, we're actually talking about the patch contents too
16:20 kowey :-(
16:22 zooko I still think there is an opportunity for optimization here.
16:22 zooko If I have a repo with patches P1..PN in it.
16:22 zooko And then I add PN+1 to that repo.
16:22 zooko And then I add PN+2 to that repo.
16:22 zooko Then it can never be the case that PN+1 depends on PN+2.
16:22 kowey I'm afraid I have to run, but hopefully the rest of #darcs can comment
16:22 zooko No matter what commutations PN+1 or PN+2 go through.
16:23 zooko Thanks for the help!
16:23 kowey thanks for improving darcs :-)
16:23 kowey left #darcs
16:56 owst left #darcs
17:04 zooko left #darcs
17:10 zooko joined #darcs
17:16 Heffalump zooko: so if a rpo contains P1...PN; PN+1; PN+2 and you send PN+1 only, you get a context with PN+2 in it?
17:17 Heffalump if so, that's fixable without a lot of work (I think) so worth a bug specifically about that.
17:17 zooko Heffalump: my current understanding is that if you send *to* a repo with Q1..QN from a repo with P1..PN; PN+1; PN+2 and you send PN+1 then it makes a context with Q1..QN in .
17:17 zooko Maybe my understanding is still somewhat wrong though.
17:18 Heffalump I would have expected it to use intersection(P1..PN,Q1..QN)
17:18 Heffalump mine might be wrong too, I'm just thiking about the underlying mechanics
17:21 dixie oh maybe I just get the point of the discussion, so when I do "darcs send" to some remote/public repo the context of dpatch should not include dependencies on patches not in target repo (and not part of the dpatch being sent).
17:22 dixie hmm :-) not very good english.
17:23 dixie when "darcs send" want to declare dependency on some patch not in "public target repo" it should include it in dpatch.
17:34 zooko dixie: I am still somewhat uncertain of my understanding, but I think darcs currently does what you should said correctly.
17:34 zooko The problem I'm having is different. There are three repos: A, B, and C. A person does a darcs send from A to B, then a different person applies the resulting patch to C.
17:35 zooko My problem is: C sometimes doesn't have all the patches from B.
17:35 zooko The workaround is: the second person, the applier, has to maintain a mirror of B, apply the patch to that mirror, then use "darcs pull" to move just the patch (plus any deps) to C.
17:43 Heffalump is C actually available to the person doing the send from A?
17:44 Heffalump the general problem is that it's computationally expensive to send against a minimal context, and if we can't see C, then the only remaining middle ground is some kind of heuristic guess at what to send against.
17:44 secorp joined #darcs
17:47 balor left #darcs
17:48 zooko Heffalump: I still think there is a possibility for improvement without guessing, by recording the set of patches that a given patch *might* depend on.
17:49 zooko That set can only monotonically shrink on closer inspection, right?
17:49 zooko So an initial, cheap-to-compute answer is "all patches in the repo where it was recorded'.
17:50 Weltraumschaf left #darcs
17:50 Heffalump remember we're takling about a given patch *representation*.
17:51 Heffalump And the set of things that can depend on (in the sense of X depends on Y if you need Y to be able to apply X) changes when you pull X into another repo.
17:51 Heffalump this sense of dependency is different from the normal darcs sense where a patch depends on another patch if you can't commute them; that is invariant.
17:55 zooko Ah.
17:55 zooko That sounds wrong that this sense of dependency can increase.
17:55 Heffalump why?
17:55 zooko I.e. there is a patch P which doesn't depend on Q, and when you pull some more patches into the repo the P does depend on Q. That shouldn't happen.
17:56 zooko Or, there is a patch P in a repo, and then you pull patch Q into the repo and now P depends on Q. That shouldn't happen.
17:56 zooko Is that what you mean?
17:56 zooko Sorry, gotta run...
17:56 Heffalump remember it's just the representation
17:56 Heffalump but it doesn't happen that way round, it only happens if you pull P into a nother repo, or if you do a reorder in the original repo
17:58 balor joined #darcs
18:03 Heffalump in any repo, the representation of a patch can only depend on the representation of the patches before it.
18:03 Heffalump and operations in a single repo always add new patches at the end, apart from optimize --reorder.
18:08 exlevan left #darcs
18:09 exlevan joined #darcs
18:13 gwern left #darcs
18:15 gwern joined #darcs
18:15 gwern left #darcs
18:15 gwern joined #darcs
18:22 lelit` joined #darcs
18:37 lelit` left #darcs
18:40 owst joined #darcs
18:50 secorp left #darcs
19:11 Heffalump
19:11 Heffalump sorry
19:32 owst left #darcs
19:56 Modius joined #darcs
20:17 owst joined #darcs
20:19 gal_bolle joined #darcs
20:28 kowey joined #darcs
20:31 gal_bolle left #darcs
20:34 dankna left #darcs
20:35 zooko lelit: I just got this error message from my trac: Warning: HTML preview using PygmentsRenderer failed (IntegrityError: columns repo_id, node_id, rev, up_to_line are not unique)
20:35 zooko Reloading, it went away and I got proper syntax highlighting.
20:36 dankna joined #darcs
20:41 raichoo joined #darcs
20:41 jderque left #darcs
21:06 zooko left #darcs
21:22 Modius What's the darcs/camp relationship - is Camp = darcs 3?
21:23 Heffalump no formal relationship
21:24 Modius That youtube vid (http://projects.haskell.org/camp/unique ) - does that basically describe darcs functionality as well?
21:24 Heffalump yes
21:25 Heffalump camp is a personal project of Igloo, who spent a lot of time working on darcs in the past. At the moment his main focus is making a formal proof of correctness of what camp does.
21:26 Heffalump we don't really know what the long-term outcome will be. In theory it could become darcs 3, though I think it's more likely that darcs will learn lessons from camp rather than becoming camp.
21:26 Modius I don't know much about proofs - does this have anything to do with what the DVCS actually *does*?  Or is it just a theoretical exercise?
21:27 Heffalump it's proving that what it does has the properties we expect, so yes it does have something to do with it
21:28 Modius History/popularity have been dragging me toward git; but I find darcs intriguing (the camp video made a good summary)
21:29 Modius It's something that's been eating at me - that changes in one view aren't history, they're just changes.
21:30 Heffalump it's generally considered by people who have used both to have a much nicer UI, and the patch handling is (we claim!) very natural. On the other hand it does have some performance and reliability problems, and a much smaller ecosystem.
21:32 alexsuraci left #darcs
21:34 Modius And the core primitive is the patch, right?  No "branches" (or what we'd call big branches are separate repos, right?)
21:38 Heffalump correct
21:50 alexsuraci joined #darcs
21:51 kowey left #darcs
22:23 raichoo left #darcs
22:29 alexsuraci left #darcs
22:33 alexsuraci joined #darcs
22:40 dankna left #darcs
22:40 exlevan left #darcs
22:40 ocharles left #darcs
22:44 dankna joined #darcs
22:44 exlevan joined #darcs
22:44 ocharles joined #darcs
23:28 etarasov left #darcs
23:29 etarasov joined #darcs
23:36 etarasov left #darcs
23:37 etarasov joined #darcs

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