Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2014-01-26

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

All times shown according to UTC.

Time Nick Message
00:18 stulli joined #darcs
01:48 dolio joined #darcs
02:23 gh_ joined #darcs
02:37 intripoon joined #darcs
02:40 vikraman joined #darcs
02:40 vikraman joined #darcs
02:50 mizu_no_oto joined #darcs
03:57 lingxiao joined #darcs
04:05 amgarching joined #darcs
05:23 mizu_no_oto joined #darcs
08:05 schlaftier joined #darcs
08:07 lingxiao joined #darcs
08:29 lelit joined #darcs
10:56 lingxiao joined #darcs
11:55 raichoo joined #darcs
13:01 lingxiao joined #darcs
13:18 notdan Heffalump: hi, do you know any bugs/patches suitable for newcommers to darcs dev? The wiki page is horribly outdated, unsurprisingly
13:18 notdan Heffalump: but I would surely love to hack darcs a bit
13:40 amgarching joined #darcs
14:12 amgarching joined #darcs
15:07 sm morning
15:08 sm http://bugs.darcs.net/issue?%40search_text=&title=&%40columns=title&topic=6&id=&%40columns=id&creation=&%40columns=creation&%40sort=creation&creator=&activity=&%40columns=activity&actor=&priority=&%40group=priority&milestone=&status=-1%2C1%2C2%2C3%2C4%2C5%2C6%2C16%2C17&%40columns=status&resolvedin=&assignedto=&%40columns=assignedto&%40pagesize=1000&%40startwith=0&%40sortdir=on&%40action=search is the most recent ProbablyEasy open issues
15:08 sm in each priority, as a starting point
15:38 Heffalump notdan: updating the wiki page and/or asking questions about the things that are wrong on it would be great
15:39 f-a joined #darcs
15:41 Heffalump notdan: also, darcsden work is itself pretty valuable to the ecosystem so if you feel there are easier to approach issues there do just do that
15:42 Heffalump gardening existing tickets is also valuable - though certainly please do direct darcs dev work if that's what you're interested in - just ask here if you feel stuck (and keep asking if you don't get a reply)
15:44 notdan thanks :)
15:44 mizu_no_oto joined #darcs
15:44 notdan I was thinking about something that does not require the theory of patches, because I don't know any
15:45 Heffalump it's supposed to be intuitive :-) But obviously it isn't always in practice.
15:45 Heffalump and I'm very happy to answer that kind of question if you do need help e.g. something that half involves patches and half doesn't
15:46 Heffalump generally the "magic" there is inside the Darcs.Patch namespace, with some leakage into the rest of the code which has to use the patch API
15:46 Heffalump and general leakage due to poorly factored code in some places
15:49 Heffalump there's also darcs-bridge that could do with some love
15:50 sm there's a lot of darcs hacking you can do without knowing patch theory
15:50 Heffalump yes, definitely
15:50 Heffalump what kinds of things are you generally interested in?
15:51 * Heffalump disappears, back in a while
15:51 notdan hm, darcs-bridge begin http://hub.darcs.net/owst/darcs-bridge-export-branch ?
15:52 notdan I will probably try to tackle http://bugs.darcs.net/issue851
16:00 sm notdan: the latest on repo conversion is gh recently submitted a patch integrating darcs-fastconvert in darcs as "darcs log --export". He was going to move it to "darcs export" (and hopefully, add "darcs import")
16:00 notdan is there a standard way of doing an interactive prompt in darcs?
16:00 sm I think it's in the patch tracker but not yet in darcs-screened
16:02 * sm wonders about some UML-style diagrams for documenting darcs architecture, like http://hledger.org/wiki/#hledger_s_data_model
16:04 notdan sm: that would be very useful; or just a simple list with comments will suffice http://jaspervdj.be/hakyll/tutorials/a-guide-to-the-hakyll-module-zoo.html
16:05 notdan you've got a new wiki on the hledger site? cool
16:08 sm yeah I needed one for work to make UML diagrams in, and dokuwiki+plantuml/markdown plugins is working so well I replaced the hledger wiki
16:09 sm revived
16:09 notdan Hm, so for the interactive part the only utils are promptChar and similar functions in Util.Prompt
16:11 Heffalump notdan: I think those are the standard ones
16:11 Heffalump whatever SelectChanges does is probably the most canonical
16:13 notdan yeah, looking at it at the moment
16:18 mizu_no_oto joined #darcs
16:20 amgarching joined #darcs
16:33 notdan Heffalump: argh, sorry, do you remember the chat we had about -DPACKACGE_VERSION_STATE breaking the compilation on OSX?
16:33 notdan I made a quick hack that time, but I didn't make a patch or anything, very stupid of me
16:34 notdan anyway, removing this line seems to work: http://hub.darcs.net/co-dan/darcs-screened/patch/20140126163054-e7f45
16:34 notdan and you actually told me that PACKAGE_VERSION_STATE macro was not necessary
16:34 Heffalump from what I recall, there's one macro that's necessary and one that isn't
16:35 Heffalump can you find the conversation in IRC logs?
16:38 notdan yeah found it I think
16:38 gh_ joined #darcs
16:39 notdan http://pastebin.com/r02juLDs it's not complete unfortunately
16:39 Heffalump I meant that #darcs is centrally logged - see the topic
16:39 Heffalump what was the date?
16:40 Heffalump anyway, sounds like removing PACKAGE_VERSION_STATE completely but keeping PACKAGE_VERSION is correct
16:41 notdan ah, sorry, totally forgot about central logs :)
17:01 Heffalump anyway, not quite sure what you're asking now, but do you need anything more from me?
17:06 notdan Well, since the PACKAGE_VERSION_STATE is no longer needed, and it prevents darcs from compiling on recent mac setups I was wondering if it makes sense to apply this patch: http://hub.darcs.net/co-dan/darcs-screened/patch/20140126163054-e7f45 ?
17:06 colDrMcBeardman joined #darcs
17:33 lelit joined #darcs
17:44 notdan Welp, got some basic stuff working: https://files.app.net/t0hsU5Ah.png :)
17:46 sm nice, what issue is that ?
17:48 notdan http://bugs.darcs.net/issue851
18:12 notdan What are the FL/RL for?
18:13 notdan they are like relation-preserving lists
18:14 notdan Hm it seems that I need to make a zipper out of FL. Shall I make an ad-hoc one or maybe it will make more sense to write some general functions in the Darcs.Patch.Witness.Ordered
18:23 gh_ joined #darcs
18:25 schlaftier joined #darcs
19:08 notdan Oh, there is a zipper in the code! FZipper
19:09 sm aha
19:26 gh_ mornfall, it's not possible to have more than one "library" field in a .cabal file. Hence, just copy-pasting (and fixing) hashed-storage.cabal into darcs.cabal won't do, and it has to merge/disappear into (lib)darcs.
19:38 colDrMcBeardman i just started looking at darcs source code but i'm totally overwhelmed. i wanted to try to get darcs changes to print patch hashes, but i'm lost in src/Darcs/UI/Commands/Log.hs
19:38 colDrMcBeardman (i mean without --xml, of course)
19:42 gh_ look for the toXml function
19:43 notdan So you can get a hash from 'PatchInfo' using 'makePatchname'
19:45 notdan also the 'changelog' function at line 289 in module Darcs.UI.Commands.Log can be helpful
19:45 colDrMcBeardman gh_, groovy
19:45 Heffalump notdan: FL and RL are lists annotated with "patch contexts" in the types
19:46 colDrMcBeardman i'm just trying some little things to familiarize myself, but would a patch to print hashes be welcome?
19:46 Heffalump colDrMcBeardman: I think so ,if it's not already possible in some reasonable way
19:47 colDrMcBeardman Heffalump, one thing i thought was nice about git was being able to match the hashes, and seeing them in the log would help
19:47 Heffalump colDrMcBeardman: there's a checklist for whether a new feature makes sense here: http://darcs.net/Development/NewFeature but in general I think you're right that making them more explicit would be useful
19:47 colDrMcBeardman the regex match on commit desc in darcs is cool, but hashes are basically DVCS answer to a CVS or SVN or P4 version number.
19:48 colDrMcBeardman Heffalump, cool, thanks.
19:48 Heffalump also take care about what the hash means - is it invariant if the patch is pulled into another context?
19:49 colDrMcBeardman Heffalump, i thought there were different hashes and that there was a unique hash that every patch had no matter what.
19:50 Heffalump colDrMcBeardman: probably, I can never remember the details
19:50 Heffalump if you just hash the metadata and not the contents it would be invariant. If you hash the contents too it can change each time you commute
19:50 gh_ colDrMcBeardman, the unique hash would be the salt that appears in the "Ignore-this:" field
19:50 Heffalump gh_: that's a salt, not a hash
19:50 Heffalump not all patches have it
19:51 gh_ Heffalump, oops
19:51 Heffalump it was added solely to make sure that two people couldn't accidentally record exactly the same-named patch
19:51 gh_ I was not aware of that
19:51 gh_ this yes
19:51 Heffalump so it's random data
19:52 notdan Are change == hunk in this context: http://bugs.darcs.net/issue851 ?
19:52 gh_ maybe the unique hash we are looking for would be the hash of the patch when commuted as close as possible to the beginning of the history, or to the latest tag?
19:53 Heffalump gh_: close as possible to the beginning is the ideal canonical one, but is expensive to commute
19:53 gh_ Heffalump, agreed
19:53 colDrMcBeardman is the makePatchname hash just on the metadata?
19:53 Heffalump to the latest tag isn't uniquely determined, because patches don't depend on tags
19:53 gh_ Heffalump, ah, so it's worse than I thought :-)
19:53 Heffalump notdan: roughly, though e.g. replace primitives are also changes
19:54 notdan thanks. what would be a summary of a change/hunk then be?
19:54 notdan be then*
19:55 Heffalump I think it summarizes per file
19:55 Heffalump not qutie sure
19:57 gh_ colDrMcBeardman, anyway I think it's a good idea to be able to see the hash of patches without using --to-xml.
19:58 colDrMcBeardman ah, here's info: http://darcs.net/Internals/Hashes
19:58 notdan ok, better ask Eric then
19:59 colDrMcBeardman so the first one, patch Hash, is what we want, and that's the one used with xml, so i could just lift the mkPatchName into the normal logging.
19:59 colDrMcBeardman i wonder also, doing a hash match has to be (imperceptibly?) faster than running a regex on every commit, right?
19:59 Heffalump notdan: what's the context of "summary"?
19:59 Heffalump colDrMcBeardman: depends if darcs caches the hashes or not :-)
20:00 colDrMcBeardman true.
20:00 colDrMcBeardman if not, would be much slower :-P
20:00 f-a left #darcs
20:00 colDrMcBeardman it's gotta be O(n) either way, but the constant would be bigger for regex if the hashes are cached.
20:01 Heffalump yeah
20:01 Heffalump in pratice people probably use name substrings most of the time
20:03 colDrMcBeardman Heffalump, yeah, although if darcs used the patch hashes everywhere, you could then have the same commit message over again
20:03 colDrMcBeardman which would be good for things like "convert bob's tabs to spaces. again. again. again....."
20:04 colDrMcBeardman or hlint, that kind of redundant, periodic message.
20:05 sm you can already do that, in which case darcs matches the most recent one
20:06 colDrMcBeardman sm, ok, i thought i had committed two with the same name but also remembered hearing of times when darcs would yell at you for trying to give two patches same name.
20:07 colDrMcBeardman so that's a case where being more explicit with the hashes in log might help from a usability standpoint. esp. since patches aren't ordered by date.
20:14 notdan Heffalump: http://bugs.darcs.net/issue851 <- context
20:21 lingxiao joined #darcs
20:40 gh_ colDrMcBeardman, detecting duplicate patch names sounds costly.. I don't remember darcs doing it ever, but maybe it did in the old times
20:48 colDrMcBeardman gh_, i really don't know. i was a git luser until a few months ago.
20:48 Heffalump notdan: "view a summary" exists in other darcs commands like darcs pull
20:48 colDrMcBeardman gh_, but git still lacks porcelain. it's more like a rotting wooden toilet.
20:49 colDrMcBeardman whereas darcs is quite nice. i'd like to help on the performance issues eventually. it would be nice to not be scared to merge things frequently.
20:49 Heffalump are you getting conflict blowups or just general poor performance?
20:50 colDrMcBeardman Heffalump, i don't have big repos yet, just reading about things.
20:50 colDrMcBeardman also looking at darcs2dot i can see where some people get issues.
20:50 colDrMcBeardman i don't know how much progress has been made since some of the griping on the mls.
20:51 Heffalump we've had darcs-2 patches for a long time now, which makes quite a big difference to the exponential blowups
20:51 Heffalump if you have a new format repo (whcih you will if you made it any time recently)
20:52 colDrMcBeardman Heffalump, just saying that since darcs-2 i saw a post that even darcs devs don't do much merging.
20:52 Heffalump ah, that's more of a UI thing - lots of nested conflicts are still pretty ugly if you don't resolve.
20:52 colDrMcBeardman there's something to be said for making people make sure their stuff should apply cleanly to the upstream.
20:53 colDrMcBeardman but i can see myself and one of my codebases having the "merge guy"
20:53 colDrMcBeardman I wondered why the conflict marking doesn't include the patch hash for where it came from. i guess that's on the trac somewhere.
20:53 Heffalump it's actually quite technically challenging to achieve
20:53 colDrMcBeardman that's way beyond me at this point, i haven't even read half the source code.
20:54 Heffalump I've go a fork (quite stale) that can do it
20:54 colDrMcBeardman that's the impression i got.
20:54 sm applying cleanly and minimising conflicts in your upstream repo is the way to go IMHO
20:54 Heffalump I like the mercurial philosophy of keeping the original context.
20:54 Heffalump I just want conflict resolutions to be easier to use.
20:54 Heffalump and to hide if you want
20:56 colDrMcBeardman sm, yeah, it's better to keep the upstream with "clean" history.
20:58 dolio It's better for your tools to present history cleanly, with an option to dig in, while still allowing you to not manually do a lot of busy work to keep history 'clean.'
20:58 colDrMcBeardman would doing a lot of conflict resolution in your personal repo have the same issues, though, performancewise?
20:58 Heffalump we need yet another patch format to sort it out once and for all (with an as-yet undefined implementation)
20:59 sm my understanding is that accumulating a lot of conflicts within your repo will tend to slow things down over time. I don't have any numbers on that, I just avoid it
20:59 dolio Not just busywork, really.
21:00 colDrMcBeardman sm, if you're working on something and you update from upstream, you might be bound to have conflicts.
21:00 colDrMcBeardman depending on your workflow.
21:00 dolio Merges can introduce their own bugs related to making the two branches compatible, and it is useful to know that either branch worked properly prior to the merge.
21:00 Heffalump dolio: exactly
21:01 sm yes, my workflow in that case is to amend my local patches (like doing a git pull --rebase, but not as convenient)
21:01 dolio Whereas rewriting history as is typical in some communities completely destroys that information.
21:03 colDrMcBeardman sm, how do you do that command-wise?
21:03 sm colDrMcBeardman: darcs unrecord the local patches (hopefully not many), darcs pull, resolve conflicts, re-record.
21:04 colDrMcBeardman my experience with merging is mostly use of p4, in which case i would amend my local copy. i think that is the right way, and gives you the behavior dolio says
21:04 sm darcs head also has a rebase command which may help here
21:05 colDrMcBeardman sm, ok, so you back everything out, darcs pull marks up your working directory, and you recommit as if your unpushed changes were new on top of the latest from upstream?
21:06 sm right
21:06 sm which I think is exactly like git pull --rebase, right
21:07 Heffalump colDrMcBeardman: what about when merging branches with p4? Then you have a conflict resolution as part of the merge.
21:10 colDrMcBeardman Heffalump, yeah, with p4 the workflow is similar, but the history is not kept tidy.
21:10 colDrMcBeardman i had my own branch at work and would pull upstream in and fix things in my branch,
21:10 colDrMcBeardman so it would pollute the history
21:14 dolio What does history being "polluted" mean?
21:14 dolio Not a straight line?
21:18 Heffalump I guess it's quite a subjective term
21:18 Heffalump I would say that reflects your own development history quite accurately
21:19 Heffalump but it looks uglier from mainline's point of view
21:19 dolio Maybe it means that git bisect will work well with it. I hear that doesn't work so well with non-linear histories. :)
21:19 Heffalump good point
21:19 Heffalump though perhaps it ought to
21:19 dolio Even though non-linear histories should give it _more_ information to bisect with.
21:20 colDrMcBeardman dolio, i mean with things that get a message like `merged stuff from upstream'
21:20 Heffalump ah yes, commits for clean merges, the classic thing that darcs avoids
21:21 dolio Is p4 not distributed?
21:21 colDrMcBeardman which is what my p4 tree was filled with because i would pull every morning before working
21:21 colDrMcBeardman dolio, centralized.
21:21 colDrMcBeardman it's aggravating to use, to
21:21 colDrMcBeardman *too
21:21 dolio We use mercurial at work, and I could do your thing by pulling, merging my stuff into head and then pushing.
21:21 dolio Which is what we do.
21:21 Heffalump dolio: yes, but you'll still have a merge commit
21:21 dolio And only ever allow one head for each named branch on the central repository.
21:22 * Heffalump uses p4 at work and is reasonably happy with it, except when he runs into its design flaws with merging
21:22 dolio Heffalump: Yes, but that's the commit where you describe what all the stuff you're merging in does.
21:22 Heffalump OTOH we used to use clearcase before, so it's easy to feel better when I remember that
21:22 colDrMcBeardman Heffalump, heheh
21:23 Heffalump dolio: hmm, true. Part of my personal vision for darcs is that it will allow patches that group together other patches with a summary message.
21:23 colDrMcBeardman p4 wasn't really that bad, but i had my own branch, so it got kind of not entirely unlike distributed doing it that way.
21:23 dolio Heffalump: At least, that's in theory. And I hear that bazaar has support for viewing history in exactly that way. it looks linear, with names of the merge points, but you can drill down into side branches that were merged for more detail.
21:23 colDrMcBeardman but we were constantly running into merge problems on an 800KLOC base.
21:24 colDrMcBeardman the "merge guy" was a sad and angry shell of a man.
21:24 dolio In practice, a lot of people write "merged". And git does that for you automatically, which makes it even easier to get wrong. :)
21:25 colDrMcBeardman any it doesn't help that you can get a clean merge that is semantically broken garbage.
21:25 dolio Yeah, that's another reason git's default policy there is bad.
21:26 Heffalump darcs does that too :-)
21:27 dolio Yeah. I guess at least there's nothing in the repo signifying, "with this commit, these two branches are merged"?
21:28 dolio You just have two bad bundles of patches in a basket.
21:29 dolio Of course, darcs might not have that once you fix the problem, unless you manually specify dependencies.
21:32 colDrMcBeardman dolio, well, if you pulled something in that applied cleanly, you could still have semantic problems.
21:32 colDrMcBeardman maybe bob removed f because no other code called it and your latest feature calls f.
21:32 colDrMcBeardman won't compile.
21:32 dolio Yes, I know.
21:32 dolio That's why we always run compiles and tests before committing a merge in mercurial at work.
21:33 dolio Or else, if  you break something, we yell at you. :)
21:33 colDrMcBeardman heh. we had a dunce cap or some other token for the guy that broke the build.
21:33 colDrMcBeardman and you were made fun of until you passed it on.
21:51 dolio Really, thinking about it, I'm not sure you can even conceive of darcs vs. mercurial and git in the same way, with regard to merges.
21:51 dolio Because 'branches' are just separate repositories.
21:52 dolio You don't pull and get two branches in one repository waiting to be merged.
21:53 dolio So, to implement the same policy, you make sure you only push to the public branch after having resolved any semantic conflicts.
21:54 colDrMcBeardman dolio, darcs is like having an "important" node in the graph -- it's not centralized, but it sort of lifts the good practices of centralization
21:54 colDrMcBeardman that workflow is possible with git, hg, etc., but not as ... encouraged? as with darcs.
21:55 dolio Even locally, if you want to merge like mercurial...
21:56 dolio You'd 'get' a new copy from your local copy for the merge, pull into that from whatever other source you're merging with, fix up, then push back to your other local copy.
21:58 dolio Of course, it's a little dicey anyway, because darcs doesn't store history at all in the same sense as the others do.
21:59 dolio And you wouldn't necessarily be able to reconstruct either pre-merge state without some other source of knowledge about which patches were in each.
22:31 werebutt joined #darcs
22:31 werebutt left #darcs
23:18 Heffalump there was some discussion about adding a "track history" feature about a year ago
23:18 Heffalump off the top of my head, my answer was "tag like crazy"
23:26 mizu_no_oto joined #darcs
23:34 dolio I don't know how good an answer that is. Although, oddly, it's almost exactly what the Vim source does.
23:35 dolio Every patch has a commit with the actual change followed by some patch version tag.
23:35 dolio Despite being in mercurial, and the repository being entirely linear (because development is mailing list based, I think).

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