Camelia, the Perl 6 bug

IRC log for #darcs, 2012-12-24

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

All times shown according to UTC.

Time Nick Message
00:15 owst Gah! darcs-fastconvert: src/Darcs/Patch/V2/Real.hs:(612,17)-(614,35): Irrefutable pattern failed for pattern Data.Maybe.Just a2'o
00:15 owst I can't even import the GHC git repo now :-(
00:18 Heffalump :-(
00:19 owst And that was after about 3 hours of waiting
00:28 owst Heffalump: any ideas about how to represent a commute, without doing the commute? I want to take a linearised (in darcs patches + tags) git DAG, read it in, fudge it about (i.e. determine dependencies at the merge/fork points of teh DAG and commute appropriately) and then determine what needs to be exported. I want to "lazily" commute the contents of the patches, but be able to inspect their infos
00:29 owst I'm trying to figure out what I'm finding so hard about reversing the import structure-collapsing (DAG -> Sequence)
00:30 owst the answer is all of it :-)
00:33 owst I guess you're not there, so maybe I'll note down my proposed plan of attack:
00:33 Heffalump I'm here
00:33 Heffalump just thinking
00:33 owst Ah
00:34 Heffalump so do you ever need the contents?
00:34 owst Yes, eventually. But in the case of an incremental export, it'd be nice to only have to compute the contents of the patches you particularly need to export
00:35 owst I'd like to compute some DAG-like structure, given the linear sequence of patches, and then traverse that structure, and print out the necessary contents
00:35 owst s/contents/export-data/
00:36 Heffalump ok, so you have a linearised git DAG which might contain a bunch of tagged merges that originated in git-land
00:36 owst Yep, I can explain the exact tags again if you like?
00:36 Heffalump might as well
00:39 owst Ok, so the way the importer works is to just read in patches and incrementally add them to a "working" inventory, stashing it away after each commit/patch.
00:39 owst A fork point in the input stream says "go back to this inventory and add patches from there"
00:39 owst brb phone
00:40 sm__ joined #darcs
00:42 owst A merge point is simply "these 2 inventories were merged, here are the conflict resolutions".
00:42 owst But upon seeing a merge, the importer does:
00:42 owst a) tag the state of the target repo (i.e. before the merged-in patches are pulled in)
00:43 owst b) reload the state of the repo at the merged-in inventories, and tag that
00:43 owst s/at the/given the/
00:44 owst c) do a darcs merge of the target repo and the source repo, and then apply any resolution changes
00:44 owst d) tag the post-merge state
00:44 owst so, we have 3 tags: pre-target, pre-source, post
00:44 Heffalump so the commute that you'd like to make lazy is just undoing the merge
00:44 owst yes
00:44 Heffalump but conflictor bugs mean it can fail
00:45 owst Well, that bug I pasted was the import side
00:45 owst :-(
00:45 owst i.e. doing a complicated merge
00:45 Heffalump oh, so the merge itself failed?
00:45 owst yeah
00:45 Heffalump ok, so you're just screwed then :-(
00:45 Heffalump but ignoring that...
00:45 mizu_no_oto joined #darcs
00:45 owst Yeah, ignore that ;-)
00:45 Heffalump on the export side, you want to find the patches in the darcs repo that aren't in the git repo?
00:46 owst For now, I'd just like to unravel the tag structure
00:46 Heffalump why do you need to?
00:46 owst ...to recreate a "DAG" of patches
00:46 owst so that I can dump the patches in their original form
00:47 Heffalump ah, cos you might just be exporting, rather than re-bridiging to sthe same git repo
00:47 owst exactly
00:47 owst I need to 1-1 map between what git has and what darcs has in the bridge case, but that's essentially easy
00:48 Heffalump would it help if you also tagged the "fork points" you mention above?
00:48 owst Umm
00:48 Heffalump though I guess those are an internal implementaiton detail in a sense so it's bit ugly to do that
00:48 owst Yeah
00:48 owst I think the 3 tags are all I should need
00:49 owst The tricky part is figuring out when some patches have already been seen, and therefore shouldn't be exported again
00:49 owst (which can arise if you merge a branch into itself, for instance)
00:50 Heffalump do you just use the current darcs patch order to determine the git commit order?
00:50 owst Yeah, unsafe, but meh
00:50 owst I stuggling enough with just that, for now ;-)
00:50 Heffalump if you want safety you need to tag after every patch, right? Would that also help with the merge problem?
00:51 owst Yeah, that would let you reorder a repo back into the correct order, but I don't think it would help with the merge problem
00:51 owst since I'm for now just assuming it's in the correct order
00:52 Heffalump but with merges, you need to know which branch to apply the patch to, and having the tags after each patch would tell you the right parent immediately
00:52 Heffalump because each tag would depend on one patch and one other tag.
00:52 Heffalump directly depend, that is
00:54 owst I don't think I follow the part about knowing which branch to apply to
00:55 Heffalump ok, point out the flaws in the following naive export algorithm:
00:55 owst Ok
00:55 Heffalump (assuming the tags)
00:55 Heffalump starting at the beginning of the repo, iterate through the git tags
00:55 Heffalump for each tag, it should depend directly on precisely one patch and one parent tag
00:56 Heffalump the parent tag tells you the commit id of the parent of the current commit, and the patch tells you what the current commit itself is
00:57 Heffalump the only special thing about merges is that the post-merge tag will depend on one patch (the conflict resolution fixup) and two or more base tags (the pre-merge tags)
00:57 Heffalump only other thing is that in general you might need to commute the patch to get it into the right context to make the commit
00:58 Heffalump which I guess may be the entire point of your problem, thinking about it :-)
00:58 owst Yes
00:58 owst it is :-)
00:59 Heffalump ok, so it's easy enough to do the commute, though I'm not sure how efficient it is
00:59 owst what are git tags in your first step?
00:59 Heffalump getPatchesBeyondTag does it
00:59 Heffalump git tags are the things you created for each commit when doing the import
00:59 owst ok
01:00 Heffalump (obviously something different will have to happen when the export originates on the darcs side)
01:01 owst ?
01:01 Heffalump '?'?
01:01 owst I'm only considering exporting from the darcs side
01:01 owst git->darcs is easy
01:01 Heffalump sorry, I mean when the patches being exported originate from darcs, so don't have the "git tags"
01:01 owst Oh!
01:02 mal`` joined #darcs
01:03 owst Are PatchSet tags always clean?
01:03 mal`` joined #darcs
01:03 owst else the first case of getPatchesBeyondTag looks strange
01:03 Heffalump if it's in the tag position of TaggedPatchSet, yes
01:03 owst Right
01:04 Heffalump sorry, of Tagged
01:04 Heffalump that's where the benefit of "clean tags" comes from
01:05 owst Where is the code that enforces that?
01:05 owst presumably, where the inventories are split up?
01:05 Heffalump I'm not entirely sure what steps are taken to enforce it.
01:05 owst heh, are any?
01:06 Heffalump I mean, if the code is correct it's all ok because the inventories are written out in the right way
01:06 Heffalump but if you manage to make an incorrect Tagged I suspect nothing would catch it
01:07 owst "the inventories are written out in the right way" <- what's the right way?
01:07 Heffalump split at clean tags
01:07 Heffalump i.e. if you have a correct PatchSet then the on-disk structure is correct so you have a correct PatchSet when you read it back in
01:07 owst Oh, ok, I see
01:07 Heffalump which may be what you meant by "where the inventories are split up"
01:08 owst It was I suppose
01:08 owst it wasn't clear that's what I meant, to me, or to you I guess ;-)
01:08 Heffalump anyway, so I now understand in more detail what you meant about having a datastructure to represent the DAG
01:09 owst ok, cool. "unravel tags/patches linearly encoding a dag, back into the original dag"
01:09 Heffalump and actually having a graph like that is exactly the same thing I'm thinking about with graphictors and with the code I wrote ages ago for tests that represent arbitrary patch graphs
01:10 Heffalump back in a bit
01:10 owst ok
01:17 Heffalump hmm, or perhaps you don't need anything that complicated
01:17 Heffalump I think to actually export a patch, you need its tag and its parent's tag to be clean
01:18 owst Yes, that sounds reasonable
01:18 Heffalump perhaps it's good enough to just do that if needed
01:19 Heffalump perhaps maintain a mapping from tag to a PatchSet where the tag is at the head and clean
01:20 Heffalump each time you see a tag (where tag = the special "git tag", not any others), make a new entry in the map that's basically Tagged newTag newPatch (PatchSet from parent tag)
01:20 Heffalump and the whole lot will be lazy
01:22 * owst is digesting that
01:28 owst I wish there was a way to show the explicit dependencies and no other contents of a patch in darcs changes
01:28 owst That would help me with my hunt for a counter-example :-)
01:28 Heffalump should be easy enough to code that up
01:28 Heffalump the info is right there in the PatchInfo
01:29 owst in teh Named
01:29 owst PI doesn't hold deps
01:29 Heffalump yes, sorry
01:29 * owst found that out earlier ;-)
01:29 owst True; why wish, when I can code
01:46 favonia joined #darcs
02:07 bsrk joined #darcs
02:08 mizu_no_oto joined #darcs
02:42 intripoon_ joined #darcs
03:42 mizu_no_oto joined #darcs
03:55 mizu_no_oto joined #darcs
04:36 mizu_no_oto joined #darcs
10:35 mekeor joined #darcs
10:45 C-Keen g
11:01 owst Heffalump: one tricky part of storing a Map Tag Tagged is that the witnesses aren't useful, I think
11:01 mizu_no_oto joined #darcs
11:23 mizu_no_oto joined #darcs
11:51 mizu_no_oto joined #darcs
12:36 owst Ugh, updating containers was a pain!
13:55 favonia joined #darcs
16:01 bsrk joined #darcs
16:04 Heffalump owst: afreed
16:04 Heffalump s/afreed/agreed/
16:36 sm__ joined #darcs
16:58 Reisen joined #darcs
17:00 Reisen This might be too general a question to ask but, I'm kind of confused how to really use darcs, I'm looking at the changes to xmonad, and I see listed for the first few patches, some from 2012, 2009, 2010, and then a few from 2012 again
17:01 Reisen If I understand right, patches can be re-ordered if they don't break dependencies so, I assume the 2009/2010 patches are listed there simply because they had no dependencies and got re-ordered
17:01 Reisen But I'm kind of confused then what use --to/from-patch are, if the order doesn't really necessarily mean much in a specific range
17:05 owst Reisen: the answer is: exactly!
17:06 Reisen Rofl, so I'm not crazy ;p
17:06 owst from-patch says "in the current sequence of patches, drop all patches up-to this one"
17:07 Reisen Sure, I just mean, it doesn't seem to have any use, say in a project with thousands of patches, the sequence of patches isn't necessarily going to tell you much
17:08 owst Depends what you mean by "tell you much"
17:08 Reisen I'm literally only about ~30 minutes into playing with darcs so I might just be missing the obvious
17:09 Reisen It just seems like, I can't think of any situation where the from,to commands would be useful because the 'changes' order is only helpful if I already know a few related patches are grouped
17:09 owst indeed so
17:09 Reisen And where they are for that matter
17:10 Reisen Is that something you're meant to be aware of in darcs? I'm still pretty confused by it to be honest
17:11 owst I don't use --from-patch much
17:11 owst darcs is different to most/all other VCSs
17:11 owst You might find that you start to use "-p 'patch name'" a lot
17:12 Reisen Hmm
17:12 owst e.g. `darcs cha -p 'foo patch' -v` would show you exactly what that patch did
17:12 owst patches are just context-aware diffs, which can be freely re-ordered
17:12 owst -ish. :-)
17:14 owst_ joined #darcs
17:22 Reisen I guess I'm just going to have to try it for a bit to get it I guess, thanks owst_
17:22 owst_ Reisen: np - do ask if you think "how do I do that?"
17:22 owst_ ...and can't figure it out :-)
17:23 Reisen Will do, thank you
17:26 Reisen Actually quick question because I'm struggling to find it but, is there a way to visualize the patch tree?
17:27 owst In terms of dependencies between patches?
17:27 Reisen Yeah
17:27 owst Unfortunately not
17:27 Reisen Ah, that's a shame
17:27 owst It's something people seem to want a lot
17:27 owst but it's computationally pretty tough
17:28 Reisen How come? Just out of interest, if you can explain without too much detail
17:29 Reisen If I imagine it correctly, I'm guessing in most cases most patches don't have that many dependencies? Is the issue just that the tree would be extremely wide?
17:29 owst When patches are added to a repository, they aren't pushed as far back into the sequence as they could be (in terms of *textual* dependencies), which is what you want to draw a dependency graph - the graph tool would have to push every patch back as far as possible
17:30 owst Yeah, something like that
17:30 Reisen Interesting
17:31 mizu_no_oto joined #darcs
17:54 Reisen owst: won't bother you too much, but got a question
17:55 owst fire away
17:55 Reisen When I tag something, am I ok to think about it as being a pointer to the last patch that gets my working directory to the state when I tagged it?
17:56 owst more than that - it's *all* the patches that got your working dir to its current state
17:56 Reisen Yeah sorry, I meant that ;p, I figured it would imply all the dependencies as well
17:57 Reisen Or do you literally mean that the tag will contain all the information about which patches?
17:57 Reisen I thought it would be possible to just say 'this patch represents the working directory at this time', and the dependencies could be resolved from it
17:57 owst No, it lists the patch identifiers (name, author, date, ...)
17:58 Reisen Oh, hmm
17:58 owst dependencies only come into play when you get textual dependence
17:58 Reisen My head must be stuck thinking about revision histories in other vcs's
17:59 owst i.e. a patch that changes a line will *textually* depend on the patch that added the old line
18:00 Reisen Hmm
18:00 owst darcs patches are sort-of just diffs
18:00 owst tags let you snapshot some sequence of patches and refer to them as a collection
18:01 owst you can't reorder a tag and a patch that it refers to
18:01 owst but you can reorder a tag and a patch that it *doesn't* refer to
18:01 Reisen So without tags there's no real way to get the state of the working directory at some point in time
18:01 owst no
18:01 Reisen Ok that makes sense
18:01 owst cool
18:01 Reisen I was still picturing this as something like git's tree, but with diffs between revisions
18:02 owst nope, there's nothing tracking anything like the git parent structure
18:02 Reisen Now I'm imagining more a just a bunch of patches for a single state
18:02 Reisen Ok
18:03 owst One thing that is true, is that if you only re-order patches, you won't change what you see on disk
18:03 Reisen Actually this suddenly seems a lot cooler than I first thought
18:04 owst that's not entirely true in darcs, since it has to support conflicting patches (i.e. those that can't be re-ordered due to textual dependencies)
18:04 owst it is cool
18:04 owst :-)
18:04 Reisen Kind of lurched at the idea I couldn't check my past history at first, but I guess that's the point, you don't really need a history
18:04 Reisen The patches are the history
18:04 Reisen Hmm
18:05 Reisen How hard is it to check a bunch of changes to a certain area of code just out of interest?
18:05 Reisen I assume if some code changes 3 or 4 times, those patches will all have dependencies on each other so it should be possible right?
18:05 owst do you use another VCS normally? can you describe what you mean in terms of a git command?
18:06 owst I'm not sure what "check a bunch of changes to a certain area" means
18:07 owst if you change some lines, record a patch, change overlapping line and record another patch then those the second patch will "depend" on the first
18:08 owst `darcs annotate FILE` will show you which patch made each line be in its current form, in FILE
18:08 owst Reisen: out of interest, which version of darcs are you using?
18:09 Reisen 2.5.2, my cabal list is really outdated, this laptop hasn't been booted for 6 or 7 months at least
18:09 Reisen But one second I kind of killed my thought process looking at annotate
18:09 owst that's old, we've fixed a lot of bits and pieces since then
18:09 owst heh, ok
18:17 raichoo joined #darcs
18:28 Reisen owst: sorry I vanished there, I was kind of confused myself as to what I was asking
18:28 owst np
18:29 Reisen Went to play with darcs again hoping it would just come to mind again, still not sure, will bring it up again if I remember ;p
18:29 Reisen Brb though, guests
18:29 owst ok, enjoy
18:45 mekeor joined #darcs
18:48 Reisen owst: annotate is what I was looking for
18:48 Reisen Thanks for helping me with everything by the way, I appreciate it
18:51 owst Ah cool. Recent darcs have had an optimisation that make annotate much much faster
18:51 Reisen I'll give it a try, 8 month old arch install, I'd update but
18:52 Reisen I honestly think I'll have less headaches just formatting than sorting out updating at this point with systemd and other things
18:52 owst have fun with sysvinit->systemd
18:52 owst ;-)
18:52 Reisen Yeah rofl
18:52 owst Fairly painful
18:52 * owst is on Arch too, on 2 computers
18:52 Reisen Had any issues? I've heard a few problems from a couple of friends so far with
18:53 owst You can of course just install GHC/Haskell platform manually
18:53 owst rather than use the pacman packages
18:53 Reisen systemd going on and booting while fsck tried to do its job
18:53 owst Oh? Ouch
18:53 owst Not had that one
18:53 owst No real problems, AFAICR
18:54 Reisen Guess I just have to hope for a similar experience
18:55 * owst wants `darcs show tag --containing PATCH`
18:55 owst It would make it easier to determine which version Reisen needs to get, to have the new annotate
18:57 Reisen Does sound like something that would be useful, do you know what the equivelent would be in something like mercurial?
18:58 owst I don't know the command, but it'd be fairly easy to implement
18:59 * owst doesn't know Mercurial, just Git, but even that's rusty these days
18:59 Reisen hg log -r 'descendents(X) and head()' it seems
19:00 Reisen yeah I'm a little rusty in general, part of why I'm checking out darcs ;p
19:00 Reisen Starting a new project and trying to decide on something to use
19:00 owst a personal project?
19:01 Reisen Sadly no, but no one in the group has any vcs experience (oh god), and we need one
19:02 Reisen I've used mercurial most and It's friendly so that was my first choice for us to use, but I think darcs might actually be better
19:02 Reisen Most of my confusion is just thinking about other VCS's, then darcs, but I think maybe darcs might be
19:02 Reisen easier to think about for us as a group for someone who hasn't used it before
19:02 owst I'm not really sure what to recommend. I use darcs for personal projects, and it's fine, but conflict handling is pretty involved in darcs.
19:02 Reisen Ah
19:02 owst which you'd hit for a group project
19:03 owst *be more likely to hit
19:03 owst You may never get conflicts ;-)
19:03 Reisen ;p, I guess I'll mess with darcs more first either way
19:04 owst Cool
19:04 Reisen I just like the idea of being able to just say 'ok we're using darcs', and have people mail patches around without having to think about branching and a central repos and such
19:05 owst you don't need a central repo for Mercurial, though?
19:06 Reisen No, but emailing is easier than getting ssh access setup somewhere, majority of the team are windows, I'm trying to find the easiest way to get some kind of version control involved
19:06 Reisen Not starting till late January though, plenty of time
19:06 owst to send patches in darcs, you need to be able to determine which patches the other person has/hasn't got
19:07 owst so normally, you'd make their copy of the repo accessible, through ssh, or some such
19:07 Reisen Ah of course that makes sense, I was imagining being able to select the last few patches you had done, hmm
19:07 owst well, you can do that
19:08 owst but it's a bit strange :-)
19:08 Reisen More pain than I was thinking though, hmm
19:08 Reisen Yeah
19:08 owst "it can be done" TM
19:08 Reisen Rofl
19:09 Reisen I'm going to experiment with darcs a bit more anyway I guess, mercurial is my goto for now though
19:11 Reisen THanks again owst
19:12 owst np
19:13 mizu_no_oto joined #darcs
19:58 owst joined #darcs
21:30 donri joined #darcs
21:57 mizu_no_oto joined #darcs
22:11 owst joined #darcs
22:16 gh_ joined #darcs
22:24 mizu_no_oto joined #darcs
23:45 mizu_no_oto joined #darcs

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