Camelia, the Perl 6 bug

IRC log for #darcs, 2010-04-14

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

All times shown according to UTC.

Time Nick Message
00:21 gbeshers joined #darcs
01:17 Korusef joined #darcs
01:20 twb joined #darcs
01:50 alexsuraci joined #darcs
02:30 Korusef joined #darcs
02:48 Korusef joined #darcs
03:08 Korusef joined #darcs
03:29 Korusef joined #darcs
03:53 trofi joined #darcs
05:40 twb joined #darcs
06:10 twb joined #darcs
06:23 balor joined #darcs
06:56 JaffaCake joined #darcs
07:02 darcscommitbot joined #darcs
07:03 darcswikibot joined #darcs
07:20 sxs joined #darcs
07:21 gal_bolle joined #darcs
07:36 gh_ joined #darcs
07:43 lelit joined #darcs
08:14 alpounet joined #darcs
10:33 JaffaCake joined #darcs
12:18 JaffaCake1 joined #darcs
12:46 tibbe joined #darcs
12:47 tibbe Someone should really assign a mentor to the second Darcs SoC proposal
12:47 tibbe Eric is currently listed as mentor for both
12:50 mornfall Well, I am listed as possible mentor on one.
12:50 mornfall But no idea how to reassign.
12:58 mornfall tibbe: Any idea what needs to be done to change the mentor?
13:01 tibbe mornfall: decide who's going to mentor, tell me (or Edward)
13:19 dino- Is it still possible to make anew d1 repo?
13:19 dino- s/anew/a new/
13:19 dino- Is this what --old-fashioned-inventory does?
13:21 kpreid_ joined #darcs
13:22 idnar dino-: you probably want --hashed, unless you need to work with quite an old darcs
13:23 idnar but yeah, --old-fashioned-inventory is the old format
13:28 dino- I need to work on the broken d1 -> d2 convert
13:28 mornfall The GHC repo on darcs.haskell.org is now hashed. (Maybe this is old news, but woo.)
13:28 mornfall dino-: What do you mean?
13:29 mornfall dino-: About darcs convert?
13:29 dino- http://bugs.darcs.net/issue1760
13:29 mornfall dino-: You don't need old-fashioned for that. With hashed, it should break the same.
13:29 dino- This issue says not only does it take a long time, but the resulting d2 repos are damaged
13:29 mornfall dino-: Corruption is unrelated to this, though.
13:30 dino- ok
13:30 mornfall It says that happens with 2.3.1.
13:30 dino- ok. I had only tested with the HTab repo that was attached to 1232 (missing prefs after convert), and never let it complete myself.
13:31 lisppaste2 joined #darcs
13:32 dino- By the time it gets to patch 8 or 10 it's going away for minutes.
13:32 dino- iirc
13:56 Korusef joined #darcs
13:58 kpreid_ joined #darcs
14:12 dino- I created a new repo with --hashed and have 7 patches in it. I will add more patches to confirm, but I don't think I'm seeing the slow behavior that I do with a repo that reports as Format: darcs-1.0
14:14 mornfall Oh? Heffalump said he saw it with hashed, too, I think.
14:14 dino- Maybe I need more patches, will triple them to 20 or so.
14:15 dino- But with that HTab test repo from issue 1232 clearly slowing down by 6, 7, 8
14:29 tibbe left #darcs
15:02 kpreid_ joined #darcs
15:11 dino- I tried it the other way too, obl down a darcs-1.0 repo to a dozen patches, still bogs after patch 8.
15:11 mornfall Can you write whatever you have found down on the issue tracker?
15:12 dino- Will do.
15:44 trofi joined #darcs
15:53 FunctorSalad_ joined #darcs
15:54 FunctorSalad_ am I doing something else wrong? Or does darcs consider a change to a giant multiline regex atomary?
15:54 FunctorSalad_ s/regex/sexp/
15:55 FunctorSalad_ (I'd like it to treat the lines as normal lines)
16:00 lispy FunctorSalad_: I don't understand the question
16:01 lispy ?dict atomary
16:01 lambdabot Supported dictionary-lookup commands:
16:01 lambdabot all-dicts devils easton elements foldoc gazetteer hitchcock jargon lojban vera web1913 wn world02
16:01 lambdabot Use "dict-help [cmd...]" for more.
16:01 lispy ?all-dicts atomary
16:01 lambdabot No match for "atomary".
16:02 lispy FunctorSalad_: I don't understand the question, but perhaps the diff algorithm does not work the way you expect?  Finding a perfect diff is computationally expensive so diff algorithms focus on "good enough" diffs
16:05 FunctorSalad_ lispy: maybe I said it badly... I mean that when I modify a few lines in the giant sexp, darcs gives me a hunk where the whole thing is deleted and one where the new version is added
16:05 FunctorSalad_ with 'atomary' I meant that it doesn't seem to try to look into the parts of the sexp
16:05 lispy FunctorSalad_: it's probably not computing a perfectly minimal diff.  If you use GNU diff do you get the same results?
16:06 lispy Or maybe you changed the line endings?
16:06 kolmodin joined #darcs
16:06 lispy It's hard to say without looking at it, I guess
16:06 FunctorSalad_ (could the problem be not diff-related at all, and be emacs's backup-by-rename? i.e., rename the old file to a backup, and write the new version as a fresh file)
16:06 FunctorSalad_ but I didn't think darcs monitored such things
16:07 FunctorSalad_ lispy: I shall try with GNU diff (does darcs invoke that?)
16:07 lispy darcs uses a built in LCS algo that I think was written by Igloo originally
16:08 Igloo I think it's changed since then
16:08 FunctorSalad_ FWIW, the sexp in question is emacs's "custom-set-faces" :)
16:08 FunctorSalad_ which contains all the face definitions
16:08 lispy FunctorSalad_: it's possible that lots of that changed in some small way
16:09 FunctorSalad_ (btw, LCS?)
16:09 FunctorSalad_ (don't know what it is :))
16:10 FunctorSalad_ but are you saying that it can't be darcs parsing the parentheses and considering the whole sexp as one "unit"?
16:11 Igloo No, darcs is line-based
16:11 FunctorSalad_ hmm ok, I'll try to get a GNU diff somehow
16:11 iago joined #darcs
16:12 FunctorSalad_ (I'm expecting that that will display just a few lines)
16:12 FunctorSalad_ hmm so should I record the file and then rollback it to get my hands on both versions as files?
16:14 lispy FunctorSalad_: you could copy the current one to a new name, and then revert
16:15 FunctorSalad_ by the way, it *does* seem to work smoothly for the customize-set-variables sexp, just not -faces
16:21 lispy FunctorSalad_: FWIW, I've found this to be a pretty good reference: http://en.wikipedia.org/wiki/Diff
16:22 lispy FunctorSalad_: if you think our diffs are suboptimal, perhaps you should create a bug ticket
16:22 lispy FunctorSalad_: bugs@darcs.net or http://bugs.darcs.net
16:23 FunctorSalad_ lispy: ok, here's a 'darcs record' transcript (sorry, took me so long to deansify it ;)) http://pastebin.org/151085
16:23 FunctorSalad_ hunk #2 exemplifies this fact that for customize-set-variables, it works fine
16:24 FunctorSalad_ will try gnu diff now...
16:24 FunctorSalad_ lispy: I'm not sure enough yet that it isn't some oversight on my part, to create a ticket ;)
16:24 lispy FunctorSalad_: you might need to compare line endings / whitespace.  They sure look similar to me
16:25 FunctorSalad_ lispy: hmm everything that ever touched these files is linux :)
16:25 FunctorSalad_ (if I'm understanding correctly that you mean CRLF vs CR)
16:26 FunctorSalad_ (or LF, don't remember)
16:27 FunctorSalad_ lispy: ah, I have an idea. maybe the set-variables (the first sexp in the file) works properly because the two versions align? whereas the second sexp (set-faces) is displaced by changing length of the first?
16:28 lispy Maybe?
16:28 FunctorSalad_ but I thought darcs usually handles that
16:28 lispy yeah, diff usually deals okay with shifting of content
16:33 FunctorSalad_ diff --minimal fails too :o
16:33 FunctorSalad_ odd...
16:37 FunctorSalad_ ok, I feel stupid now. emacs actually permuted the two toplevel sexps between the versions
16:37 FunctorSalad_ (these two are not under my direct control, emacs writes them)
16:37 FunctorSalad_ sorry, didn't consider that possibility
16:38 FunctorSalad_ (wasn't visible from either the darcs or the gnu diff :))
16:38 FunctorSalad_ unless you read the line numbers
16:40 kowey joined #darcs
16:41 FunctorSalad_ sorry for the false alarm...
16:42 kowey there's a ticket requesting patience diff on the tracker
16:42 lambdabot kowey: You have 1 new message. '/msg lambdabot @messages' to read it.
16:43 Igloo patience diff?
16:44 * Igloo asks google
16:44 lispy Dr. Darcs paging patient diff?
16:45 kowey http://bramcohen.livejournal.com/73318.html may be a good one
16:45 FunctorSalad_ kowey: are you implying that that notices transpositions?
16:45 FunctorSalad_ (of large blocks)
16:46 FunctorSalad_ that sounds hard ;)
16:46 kowey oh no, I'm just being a superficial (skimming) idiot
16:46 FunctorSalad_ can one in principle hook up a sexp-level diff to darcs?
16:46 kowey sorry, bad habit :-) I saw diff-dissatisfaction and just automatically switchboarded to "patience diff"
16:47 FunctorSalad_ (I'll never get around to that anyway, but ...)
16:47 kowey perhaps if you expanded on that question (to what extent do you mean "hook up?")
16:47 FunctorSalad_ kowey: heh I think everyone does that more or less
16:48 FunctorSalad_ kowey: I mean whether darcs works on top of an arbitrary `diff' program
16:49 FunctorSalad_ (so you could exchange the `diff' if you implement some interface)
16:49 kowey not at the moment, but maybe with some refactoring?
16:50 kowey although mornfall has suggested one day freezing the diff algorithm to make it possible to achieve equivalence with snapshot based VCS
16:50 Igloo If you don't make line-based diffs then you'd also need to define commutation rules
16:51 lispy FunctorSalad_: yeah you could do that.  On a related note, Simon Thompson came to visit and we were investigating the idea of tree based diffs for darcs
16:52 lispy kowey: I think it would be better to have the format specify the diff algo used and not just have OneTrueDiff.
16:52 lispy kowey: and I think mornfall's suggestion can fit into that if the hunk has a record of which diff was used
16:53 kowey I think the idea was to guarantee that if you did darcs get from a git repo in two places, you always get the same patches
16:55 FunctorSalad_ I'm in over my head here, I know little about darcs in depth
16:55 FunctorSalad_ lispy: but tree-based diffs sound awesome for any kind of source code
16:56 kowey it's sort of the general dream of Darcs - not tree based diffs per se
16:56 kowey but arbitrary patch types
16:56 lispy Maybe  I'm reading too deeply into the implications, but it sounds like you'd also be losing the ability to add more patch types in that case.  It seems better to add support for knowing which diff was done.  What you might lose is 1) extra maintenance 2) sometimes one darcs might default to different diffs so you'd end up with different patches
16:57 FunctorSalad_ I once made a sort of "diff" for haskell values implementing Data.Data.Data, it's almost trivial ;)
16:57 kowey the silly example I sometimes used being to have cherry picking in your Photoshop undo stack
16:57 FunctorSalad_ (produces a tree where every node is "Same", "Mixed", or "HeadsDiffer: ...")
16:58 FunctorSalad_ ("Same" being a leaf and "Mixed" containing a constructor name of the type in question and some subdiffs)
16:59 FunctorSalad_ (head=constructor there)
17:00 FunctorSalad_ of course it gets less trivial with more sophisticated things like detecting relocation of a subtree
17:02 mornfall It's not a suggestion.
17:02 mornfall I was merely stating the requirements for snapshot v. patch equivalence.
17:02 mornfall I never said it was a good idea to go that route. :)
17:03 kowey I suppose the hypothetical git-plugin could have stable diff, with Darcs being able to evolve however it wants
17:03 mornfall Yes.
17:04 mornfall That's the only safe way to treat snapshot-based VCS-es.
17:05 lispy If snapshot-by-default made darcs more efficient, and then we generate current patch objects to share patches, that seems like an interesting approach though.  A possible hybrid between current darcs and current git.
17:05 mornfall On the other hand, you could get around that limitation by bumping the darcs patch format number.
17:05 mornfall lispy: Well, it doesn't necessarily make anything more efficient.
17:06 lispy mornfall: our on disk representation seems to be a lot bigger than git's over time.
17:06 mornfall lispy: Not for the loose format, just for the packed one.
17:06 lispy And I think that might be because we're storing so many deltas
17:06 kowey we could also have some sort of representation of the high-level patches to "explain" the diffs
17:06 kowey much like how the pending patch works, but for each individual changeset
17:07 kowey "you see -R foo +A bar; but with my high-level patch, you know that this -R foo +A bar was actually caused by mv foo bar"
17:08 mornfall That's of course mandatory for all non-hunk patches.
17:08 lispy kowey: that's probably how the tree based patches will work
17:09 mornfall Well, all non-derivable patches I mean.
17:09 lispy kowey: we were considering flatting them to hunks to apply them, but trying to keep them as trees as much as possible
17:09 mornfall But anyway, I don't see much promise in snapshot-based storage for darcs.
17:09 mornfall All snapshot-based systems eventually degenerate to some sort of delta compression anyway.
17:10 kowey mornfall: yep.. by "high-level" I just mean "not diffs"
17:10 mornfall And it's not *that* much better than diffs.
17:10 mornfall Not enough to compromise our future flexibility for it.
17:14 lispy kowey: oh, I think I see what you mean.  It's like storing a reference or a function call to what the patch does.  And later if you need the patch you can use that to actually compute it.
17:17 kowey hmm, let me see if we agree on what we think I mean
17:18 kowey you can infer a patch between two snapshots by computing a diff on them, right?
17:18 kowey only the patch is not so nice because it's all hunks
17:19 kowey most of the time actually, that's all you want, but sometimes you want to do "darcs replace" or "darcs mv" or something fancier
17:19 lispy Right.  So in pending we just store that the diff should happen?
17:19 kowey so you store an "explanation" that says "mv foo bar"
17:19 lispy Actually, in Pending, i guess we store things like AddFile/RemoveFile but not the hunk request
17:20 lispy kowey: explanation for the user or does darcs evaluate them?
17:20 kowey well, I'm not the expert here, but I think of pending (and also the explanation) as being the intermediary state between the two snapshots
17:20 kowey old - pending - new
17:21 kowey and I think sometimes through commutation you have to store a few hunks here and there in pending
17:22 kowey so the idea behind this old-pending-new approach is that instead of computing the hunks between old-new directly, you just apply pending to some tmp state, and compute the diff between pending and new
17:22 kowey a smaller set of hunk patches
17:25 lispy I certainly would love to decouple the contents of hunks from the rest of the patch stuff
17:25 lispy For pragmatic reasons if nothing else
17:25 kowey my thinking is that if every git changeset contained this sort of "explanation patch" (eg. in its changelog as a silly example), then you could do darcs in git
17:29 lispy glguy has told me that some things he would need from darcs to consider it a replacement for git are: 1) merges need to be in the log, 2) a way to enforce a distinction between the types of merges that can happen locally vs. remotely.  (git has a notion of a fast-forward merge).
17:30 kowey for #1 he wants issue891 - history tracking (which depends on the more general issue1613 - patch annotations)
17:30 mornfall Well, that's totally orthogonal to snapshot-vs-patch based.
17:31 kowey it's just that by coincidence, the snapshot-based ones currently lend themselves to history tracking
17:31 kowey whereas darcs has totally neglected in in favour of patch management (my sloppy terminology)
17:32 kowey hg, as I understand it, is even more fanatical by default than git about history tracking
17:32 gal_bolle joined #darcs
17:34 Igloo fast-forward merge?
17:34 kowey concidentally recently discussed in my query to sjt about branching http://lists.osuosl.org/pipermail/​darcs-users/2010-April/023645.html
17:35 * kowey actually should not have started that discussion (due to time pressure), but was too darn curious
17:35 lispy Igloo: yeah.  Have you ever tried to push with git and it tells you it failed?  It's usually because the remote end doesn't support non fast-forward merge.
17:35 kowey err, http://marklodato.github.c​om/visual-git-guide/#merge may be a better guide
17:36 kowey sjt's point was that Darcs could have a much more liberal notion of "fast forward"
17:36 lispy Igloo: it's a way of ensuring that merges happen in local repos where people (in theory) verify that they have the repository state they expect before pushing the result of the merge
17:38 mornfall kowey: You mean --skip-conflicts? :)
17:38 mornfall kowey: But I think that a --fast-forward kind-of switch is ProbablyEasy.
17:38 mornfall kowey: Just check that remote is subset of local.
17:38 kowey why yes, come to think of it :-) [skip-conflicts]
17:39 mornfall Well, for apply, check that given context is same as our context (modulo commutation).
17:39 kowey I was just trying to understand what sjt meant when he said we needn't worry about what happens when people push to the wrong branch
17:40 kowey as long as --skip-conflicts tells you it skipped conflicts, --fast-forward probably isn't necessary (?)
17:41 mornfall kowey: The key difference is that sometimes clean merges lead to unindentend (and broken) results.
17:42 mornfall kowey: And you may want to disallow such clean merges as well, encouraging people to first try the result locally.
17:42 kowey ah! so you meant --fast-forward in the strict sense
17:42 mornfall kowey: In a semi-strict sense. :) The completely strict one would require same repository order (but that doesn't make any difference as long as darcs is correct).
17:42 kowey so --fast-forward would just say "nope! remote repo has patches you don't have, no-can-push"
17:42 mornfall Yes.
17:43 mornfall "Please pull first."
17:43 kowey hmm, sounds nice... but it's raising my oh-noes-new-flag grumpiness
17:43 mornfall Like when CVS cries "foo out of date".
17:43 kowey but maybe worthwhile anyway
17:44 kowey I'd better head back and cook me some dinner, see ya!
17:48 * mornfall just microwaved what remained of his lunch. :)
18:05 gh_ joined #darcs
18:22 abuiles joined #darcs
18:57 drk-sd joined #darcs
18:57 drk-sd evening!
19:00 mornfall Evening.
19:35 sm joined #darcs
20:21 alpounet joined #darcs
20:57 alexsuraci_ joined #darcs
22:50 zooko joined #darcs
22:51 zooko Folks: when I run this "darcs query" command nothing happens until I hit C-c.
22:51 zooko I left it running for 15 minutes.
22:51 zooko Now I'd like to try again with some sort of verbose debugging output.
22:52 zooko But it tells me that "-v", "--debug", and "--progress" are all invalid options.
22:54 drk-sd zooko: what « darcs query » command ? what args do you try it with?
22:57 zooko darcs query contents --quiet --match "hash 20080107232302-92b7f-34c300e2a012​4fe689b74ed40068c9e9bb4f9e46.gz" "docs/running.html"
23:00 kpreid_ joined #darcs
23:01 drk-sd (i can't help you, sorry)
23:03 idnar --help says that --debug / --debug-verbose / --verbose are valid options
23:03 idnar so that's odd
23:05 zooko idnar: zooko@localhost:~$ darcs --version
23:05 zooko 2.3.0 (release)
23:05 zooko Maybe --debug was added in 2.4?
23:05 idnar ah, possibly; I do have 2.4 here
23:08 drk-sd (so do i)
23:08 lispy I think --debug has been around for quite a while
23:08 lispy But I could be mistaken
23:08 lispy My memory for such things is terrible
23:11 zooko It definitely has for pull.
23:11 zooko Not sure about query nee show.

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