← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 00:33 | gwern | @tell kowey oh, nm. apparently it was just a problem on john's server |
| 00:33 | lambdabot | Consider it noted. |
| 00:39 | copumpkin joined #darcs | |
| 00:49 | dcoutts joined #darcs | |
| 00:49 | mjrosenb joined #darcs | |
| 00:54 | lisppaste2 joined #darcs | |
| 00:56 | nothingmuch joined #darcs | |
| 01:01 | darcscommitbot joined #darcs | |
| 01:02 | nothingmuch joined #darcs | |
| 01:08 | nothingmuch joined #darcs | |
| 01:13 | gwern | ok everyon |
| 01:13 | the wiki is updated | |
| 01:13 | should be faster now | |
| 01:13 | (also, the template/appearance will be more maintainable; also, we now have categories!) | |
| 01:26 | sm joined #darcs | |
| 01:28 | sm_ joined #darcs | |
| 01:40 | gwern | whew. with the logging change, that should be all for the gitit upgrade |
| 01:41 | now I can get started on some SICP problems for tonight :) | |
| 02:51 | twb joined #darcs | |
| 03:07 | bcw joined #darcs | |
| 03:08 | bcw left #darcs | |
| 03:14 | sm joined #darcs | |
| 04:36 | adu joined #darcs | |
| 04:48 | gour joined #darcs | |
| 06:38 | lelit joined #darcs | |
| 07:01 | darcscommitbot joined #darcs | |
| 07:22 | Gwern-away joined #darcs | |
| 09:11 | Gwern-away joined #darcs | |
| 09:18 | Beelsebob joined #darcs | |
| 09:54 | kowey joined #darcs | |
| 09:54 | kowey | good morning! |
| 09:54 | lambdabot | kowey: You have 2 new messages. '/msg lambdabot @messages' to read them. |
| 09:55 | kowey | gwern: are we running the latest/greatest gitit then? this mean we're getting fast page loads now and hopefully less memory usage? |
| 09:55 | (and all we need to do now is auto-expire pages on darcs apply?) | |
| 09:57 | "The next major release is 2.4, expected in northern-hemisphere winter 2009/2010." *chuckle* | |
| 09:58 | although I think we should just say "January 2010" to keep it simple/direct/predictable | |
| 10:01 | Gwern-away joined #darcs | |
| 10:07 | mornfall | I can't help it. |
| 10:07 | : - ) | |
| 10:07 | But yeah, make it January. | |
| 10:11 | kowey | it just occurred to me that we should probably ask dons to upgrade darcs.haskell.org to Darcs 2 now that we can just cabal install it |
| 10:12 | intripoon joined #darcs | |
| 10:23 | Gwern-away joined #darcs | |
| 10:33 | kowey | dcoutts: perhaps it would be a good idea for code.haskell.org to upgrade to Darcs 2.3 so that users can use the new gzcrc cleanup stuff? |
| 10:35 | Gwern-aw1y joined #darcs | |
| 12:22 | gwern | kowey: if the last tarball you uploaded was the latest and greatest, then yes |
| 12:24 | kowey: it seems faster and more memory efficient to me in my scientific open-a-bunch-of-random-tabs test | |
| 12:24 | kowey: though I haven't tried editing | |
| 12:28 | kowey: oh, and also john just added rss support today. I'm checking it out now, but we may want to do another upload soon | |
| 12:31 | kpreid_ joined #darcs | |
| 12:32 | kowey | gwern: that's excellent news, so it's really just a matter of expiring pages on darcs push |
| 12:32 | hmm, maybe we'll get more than 1 month of gitit uptime this time | |
| 12:32 | gwern | we could just not have a hook. I think john wrote that a hard-refresh forces a re-cache |
| 12:34 | kowey | hmm, so if I push and you look at page, you may not have the very latest version of its contents unless you ctrl-R? |
| 12:34 | gwern | think so |
| 12:34 | (do we push often?) | |
| 12:34 | actually, we could probably just kill gitit and restart it as a hook :) | |
| 12:34 | kowey | heh |
| 12:35 | * gwern | is also serious |
| 12:35 | kowey | so darcs changes -s will tell us what files have changed |
| 12:35 | I'm really surprised there isn't a local mechanism to do this refresh... hmm | |
| 12:36 | gwern | hm. or maybe we could just rm -rf cache |
| 12:36 | nothing in cache, it can't serve stale results | |
| 12:36 | kowey | but wouldn't that defeat the purpose of having the cache in the first place? |
| 12:36 | if people push a lot, that is | |
| 12:36 | if the cache is simple (uses filenames, for example), we could delete specific files in the cache | |
| 12:36 | gwern | rendering isn't terribly slow |
| 12:37 | and how often do we push? | |
| 12:37 | kowey | suppose we push at least once a day |
| 12:38 | gwern | well, the cache looks like GoogleSummerOfCodeMentoring.page |
| 12:38 | the file being static html | |
| 12:38 | if youre curious ssh in and do less DarcsWiki/cache/Fundraising.page | |
| 12:39 | they regenerate lickety-split | |
| 12:39 | kowey | so if this works, we can do darcs changes -s --last=4 | grep \.page |
| 12:39 | gwern | I just deleted it and reloaded it; could barely notice a difference in load-time |
| 12:40 | kowey | so you think the KISS strategy is good? |
| 12:40 | so the cache is still beneficial, just not so beneficial that we can't afford to redo it at every push? | |
| 12:41 | gwern | in this case, yeah |
| 12:42 | kowey: are post-apply hooks run after each patch, or after each bundle? | |
| 12:42 | eg. a dpatch of 10 patches, would that be 10 invocations or 1? | |
| 12:43 | mornfall | post-apply runs after the bundle |
| 12:43 | gwern | ah. hm. that makes parsing darcs changes harder |
| 12:44 | much harder, actually | |
| 12:44 | kowey | OK... then I guess this is now useless: grep "^ M \./.*\.page" | sed -e 's!^ M ./\(.*\)\.page.*!\1!' | uniq |
| 12:44 | gwern | since patches' dates don't have anything to do with apply... |
| 12:44 | kowey | it doesn't have to be exact since we're just trying to figure out what bits of cache to delete |
| 12:44 | gwern | you can't tell from darcs changes where 'old' patches end and new ones begin |
| 12:44 | kowey | darcs will pass env variables to posthooks telling it stuff |
| 12:44 | gwern | mornfall: is there a reason to make post-apply run after the bundle? it seems to defeat this strategy which is too bad |
| 12:45 | kowey | DARCS_FILES |
| 12:45 | mornfall | gwern: Well, that's how it always worked, and also a lot of things rely on that behaviour. |
| 12:45 | gwern | oh. like what? |
| 12:45 | kowey | "Finally, DARCS_FILES contains a list of the files affected, one file per line" http://www.darcs.net/manual/no[…]10000000000000000 |
| 12:46 | mornfall | Like, hpc reports, haddock rebuilds and so on. |
| 12:46 | You don't want to run the testsuite 10 times in a row just to throw away 9 of the results. | |
| 12:46 | And I don't want to wait whole evening for the push to finish. :) | |
| 12:46 | gwern | but wouldn't you want to know that patch #5 fails, rather than the bundle as a whole? |
| 12:47 | mornfall | It's not about failures, that's handled by the test. |
| 12:47 | kowey | you could always use trackdown to narrow things down |
| 12:47 | mornfall | It's about hpc coverage, eg. |
| 12:47 | And yes, if the bundle fails as a whole, you can trackdown locally, or something. | |
| 12:47 | Whatever. | |
| 12:48 | kowey | gwern: anyway it sounds like a simple shell script using DARCS_FILES to invalidate the cache would be the way to go |
| 12:48 | mornfall | A post-patch-apply hook could be probably implemented, but not completely trivially. |
| 12:48 | Yes, DARCS_FILES is the right thing here. | |
| 12:49 | kowey | meanwhile... |
| 12:49 | gwern | rm -rf cache! rm -rf cache! |
| 12:49 | kowey | C-Keen: may I harass you for a moment? |
| 12:50 | C-Keen: in my new issue manager shoes, I've been asking for a few new regression tests, so if possible I'd like to have your patch to enable the tests/failing-foo stuff | |
| 13:01 | darcscommitbot joined #darcs | |
| 13:03 | gwern | huh. wiki.darcs.net is being spidered by msn and google |
| 13:04 | kowey | isn't that good? |
| 13:04 | Igloo | It depends whether it falls over as a result :-) |
| 13:05 | gwern | yes, just a little surprised. wonder if they noticed the downtime and being back up |
| 13:05 | Igloo | And also whether they're visiting every single history page |
| 13:05 | gwern | don't seem to be |
| 13:06 | kowey | erm... does gitit do something to dissuade that? |
| 13:06 | dcoutts | kowey: re upgrade of darcs on code.h.o: yes, good idea. I guess it's appropriate to file a ticket in the RT. |
| 13:07 | gwern | kowey: I've no idea |
| 13:07 | kowey | thanks, dcoutts! |
| 13:07 | on my way... | |
| 13:08 | gwern | eureka! the rss seems to work! |
| 13:09 | I don't know how to verify the rss feed, but there's something there! | |
| 13:10 | kowey | ooh where? |
| 13:11 | also how do categories work? it sounds like we could automatically convert our old MoinMoin categories | |
| 13:11 | gwern | kowey: oh, my local machine |
| 13:11 | kowey | oh :-) |
| 13:12 | gwern | and I'm not entirely sure how categories work. my eyes glazed over during the syntax discussion |
| 13:12 | * gwern | loves that expression. makes eyes sound tasty |
| 13:13 | kowey | dcoutts: I've sent an email to support community... I imagine that goes straight into RT? |
| 13:13 | dcoutts | right |
| 13:13 | kowey | cool |
| 13:22 | how would people feel about Darcs Hacking Sprint #3 being in London? | |
| 13:22 | in November... | |
| 13:22 | I was thinking also that we could make a point of inviting newbie Haskellers and providing training via ProbablyEasy bugs and supervision | |
| 13:28 | Igloo | kowey: Do you have a location/local organiser? |
| 13:29 | kowey | no |
| 13:29 | Igloo | Then I object |
| 13:29 | kowey | I guess I would be local enough being an hour away from Brighton |
| 13:30 | Igloo | Given the problems getting a Hackathon at ICFP last year(I think) and this, I believe that you need to start with a local organiser with a venue |
| 13:30 | kowey | would you still object if I had a location? |
| 13:30 | Igloo | Everything else is pretty easy after that |
| 13:31 | gbeshers_ joined #darcs | |
| 13:31 | Igloo | I wouldn't object to a location in London, no |
| 13:31 | kowey | OK |
| 13:32 | speaking of this year, I do need to make some more noises about the upcoming Hack Day | |
| 14:28 | gbeshers_ joined #darcs | |
| 14:58 | gour left #darcs | |
| 15:44 | sm joined #darcs | |
| 15:53 | gbeshers_ joined #darcs | |
| 16:26 | sm | hi kowey |
| 16:34 | kowey | hi sm |
| 16:35 | sm | oh, you got me.. was just going offline |
| 16:35 | let me look again | |
| 16:36 | most of my roundup scripting knowhow is in pythonrc.py, | |
| 16:37 | kowey | in case you have to use it a lot? |
| 16:37 | I've got my own little ~/roundup-tools on darcs.net which I should probably clone somewhere | |
| 16:39 | sm | or merge it |
| 16:39 | hmm nothing relevant. What's the problem again ? a second twb1 user got created, and its "assets" should be transferred to twb ? | |
| 16:39 | kowey | sure... did you mean this pythonrc.py was on darcs.net? |
| 16:39 | sm | yes! |
| 16:40 | in the tracker dir | |
| 16:40 | kowey | sm: yeah this time, it's not roundup's fault |
| 16:40 | there's actually loads of cases like this, people with multiple email addresses | |
| 16:40 | sm | "make python" in that dir starts it up and prints some stats |
| 16:40 | kowey | that I'd like to consolidate |
| 16:40 | sm | those you can see with showdupeaddressusers() |
| 16:40 | twb doesnt appear in that list though | |
| 16:40 | kowey | hmm... I probably should dump my scripts in the tracker repo |
| 16:41 | I don't think you can detect these automatically | |
| 16:41 | so I'd like to make a script that I can run, say "merge-roundup turnbull stephen" | |
| 16:41 | "merge-users ashleymoran ashley.moran" | |
| 16:41 | etc | |
| 16:41 | sm | most of the parts are here |
| 16:42 | kowey | ah! it's not in the repo itself |
| 16:43 | sm | right, not recorded. Maybe I thought it was too sensitive |
| 16:43 | kowey | OK, deliberate |
| 16:43 | sm: totally random unrelated thought - have you heard of the wikicreole project? | |
| 16:43 | it's very off-topic, so I'll just say you may be interested in it | |
| 16:44 | sm | kowey: years ago, but not since |
| 16:44 | I see pandoc as the wiki translation tool | |
| 16:45 | kowey: it's got a strange name, but maybe reassignlinks is mergeusers ? | |
| 16:45 | looks like it | |
| 16:46 | arjanb joined #darcs | |
| 16:46 | sm | I'll rename it |
| 16:46 | kowey | hmm... I wonder how you merge the reserved stuff |
| 16:46 | sm | oh I don't have access. Never mind, you can rename it |
| 16:47 | ? | |
| 16:47 | kowey | like say twb1 creates a bug |
| 16:47 | if I run this, and search for bugs created by twb, do I get twb1's bugs? | |
| 16:47 | it's not really a big deal because I can probably get by w/ the nosy list | |
| 16:49 | sm | well reassignlinks (aka mergeuser) calls reassignissues which will set twb as the owner of all twb1's bugs |
| 16:49 | kowey | owner meaning the person that's assigned to that bug, right? |
| 16:49 | sm | I guess so |
| 16:49 | kowey | not the person who filed the bug? |
| 16:50 | sm | not sure |
| 16:50 | kowey | OK, that's fine... I'm willing to accept "it's impossible, and not a good idea anyway, but we can automate the rest" as an answer |
| 16:50 | and now you've saved me the trouble of writing mergeusers to do just what we can | |
| 16:51 | sm | you can try it, nothing will be written to the db until you >>> db.commit() |
| 16:52 | so >>> reassignlinks('twb1','twb'), then use these tools to poke around and look for problems, and if you find none, go ahead and commit | |
| 16:53 | hmm | |
| 16:53 | kowey | ah, not quite... just have to write a small wrapper to pick up the user ids |
| 16:53 | gh_ joined #darcs | |
| 16:57 | kowey | sm: is there an equivalent to ghci's :r in the python interpreter? |
| 16:58 | sm | what does that do ? |
| 16:58 | kowey | reloads the current file |
| 16:59 | sm | ah.. reload(object), but I think it's pretty unreliable |
| 16:59 | kowey | so stick with C-d and up-arrow Enter |
| 16:59 | sm | probably |
| 17:03 | kowey | hmm... I should also add some code to add the secondary users' emails addresses to the first user's alternates |
| 17:05 | seydar joined #darcs | |
| 17:05 | seydar | what;s something super duper awesome about darcs? |
| 17:06 | kowey | it's super duper easy to use? |
| 17:06 | it lets you undo almost anything you want (within reason) and safely? | |
| 17:07 | seydar | what one feature would you give permission to date your sister |
| 17:08 | kowey | it never guesses how to merge things and instead of using some kind of special magic, it just performs some mechanical book-keeping operation to perform merging in a totally predictable fashion simultaneously allowing for ease of cherry picking? |
| 17:10 | seydar | iiiiiiiiiiiiiinteresting |
| 17:10 | could you... elaborate on this mystical magick ye speaketh of? | |
| 17:10 | kowey | well our point is that we don't use mystical magick |
| 17:11 | but I should probably let somebody else answer so I don't get in trouble :-) | |
| 17:13 | seydar | kowey: do it anyways |
| 17:13 | kowey | (although I might back off from my claim by saying that when it comes to conflicts, things can look pretty magical, but *most* of the time, we are relatively magic-free) |
| 17:14 | seydar: are you familiar with diff/patch? | |
| 17:15 | seydar | yes |
| 17:15 | kowey | patch (in my view of things) is magical |
| 17:16 | because if you made a patch against some file and you apply it to a similar but not identical file | |
| 17:16 | patch (the program) will try and guess where to apply that patch | |
| 17:17 | seydar | yargh yargh |
| 17:17 | so darcs says "nuhuh!" | |
| 17:17 | and does what? | |
| 17:17 | kowey | well darcs just uses more information so it never has to do this |
| 17:17 | it keeps track of all the patches in the history | |
| 17:18 | so if you apply to a patch to some file that has changed since the version that got patched... | |
| 17:18 | all it has to do is back-track through the history and then do some boring accounting work to figure out exactly the right place to put your patch | |
| 17:18 | it doesn't mean that your C code (or whatever) will necessarily come out correct (we don't worry about semantics) | |
| 17:19 | but it *does* mean is that we'll always put your patches where you meant for them to go | |
| 17:19 | see what I mean? | |
| 17:21 | seydar | kiiinda |
| 17:21 | so file A: r1 -> r2 -> r3 -> r4 | |
| 17:21 | you make an r5 | |
| 17:21 | i make an r5 as well | |
| 17:22 | kowey | right, let's call that r5-k and r5-s |
| 17:22 | seydar | kk |
| 17:22 | they both need r4 | |
| 17:22 | how will they be applied to the file? | |
| 17:22 | kowey | ok, let's say I send you r5-k |
| 17:22 | and you've got r1 r2 r3 r4 r5-s | |
| 17:23 | what we do more or less is say "ah, OK r5-k's history has r1-r4 in it, so let's start from there" | |
| 17:24 | seydar | so you apply r5-k to r4 |
| 17:24 | kowey | well, I'm not sure how to simplify the story and say something that's still correct, so I'll give it to you full bore |
| 17:24 | seydar | ready! |
| 17:24 | kowey | actually first we say, OK well "suppose we undid r5-s" |
| 17:25 | so r1 r2 r3 r4 r5-s (^ r5-s) -- using the ^ to meant inverse | |
| 17:25 | undo is just taking the exact opposite, so fully mechanical operation, flipping + into -, etc | |
| 17:25 | so far so good? | |
| 17:25 | seydar | yep yep! |
| 17:26 | kowey | so what this means is that I've got r1..r4 r5s ^r5s... which if you think about it is equivalent to r1..r4 as far as your stuff is concerned |
| 17:26 | you're back to square one | |
| 17:26 | good? | |
| 17:26 | seydar | great |
| 17:26 | kowey | since you're back to square one, I can do r1..r4 r5s ^r5s r5k |
| 17:27 | no surprises because it's exactly like doing r1..r4 r5k | |
| 17:27 | seydar | yargh yes! |
| 17:27 | kowey | now in darcs there's this function called "commute" |
| 17:27 | commute is this operation that compares two patches in a sequence and sees if you can flip them around | |
| 17:28 | the result is two slightly different patches | |
| 17:28 | the key thing to remember about commute is that (in the absence of conflicts), it's actually pretty simple and stupid | |
| 17:28 | let me give you an example: say I have a patch "move file A to B" | |
| 17:29 | and I have another patch "add line 3 foo to B" | |
| 17:29 | if I "commute" these two patches, what I get is "add line 3 foo to A; move A to B" | |
| 17:29 | does that make sense? | |
| 17:29 | seydar | do you mean "add line 3 foo to A"? |
| 17:30 | kowey | so px = (mv A B) and py = (B +3 foo) ... the sequence px py |
| 17:31 | seydar | but B doesn't exist for py |
| 17:31 | kowey | well the idea is that py was created on top of px |
| 17:31 | i.e first you moved the file | |
| 17:31 | then you made a change in it | |
| 17:31 | seydar | ah ok |
| 17:32 | kowey | now imagine we wanted to commute those |
| 17:32 | imagine for example, you didn't *really* want to rename that file | |
| 17:32 | but gosh, you've already made a whole bunch of changes to it | |
| 17:32 | how do you undo just the rename? | |
| 17:32 | ... you do it by "commuting" | |
| 17:33 | in this example, you want to commute px py into some py2 px2 | |
| 17:33 | so far so good? | |
| 17:33 | seydar | yea |
| 17:33 | wouldn't want to write the code to do this, though! | |
| 17:33 | kowey | and that py2 will be (A +3 foo) (mv A B) |
| 17:33 | it's surprisingly straightforward | |
| 17:33 | tedious more than difficult | |
| 17:34 | and the reason why it's actually easier than you may think | |
| 17:34 | is that the only thing commute ever has to worry about at a time is just two patches (the ones you're trying to commute) | |
| 17:34 | seydar | ahhh |
| 17:35 | kowey | OK, so let's go back up to the story above... |
| 17:35 | we've got r1..r4 r5s ^r5s r5k | |
| 17:35 | that's not quite what we want, because now we've only got my r5 and not yours | |
| 17:35 | we want to merge them... and to do this all we have to do is... | |
| 17:35 | (this is where you chime in...) | |
| 17:36 | seydar | cast lvl 11 Merge? |
| 17:36 | kowey | :-) |
| 17:36 | seydar | wait really? |
| 17:36 | kowey | no new technology... |
| 17:36 | seydar | but what exactly is it merging? |
| 17:37 | kowey | OK that's a good question, what exactly are we merging? |
| 17:37 | well, let's say r5s is a patch that adds something to the top of the file | |
| 17:37 | and r5k is something that adds something to the same file, but somewhere else | |
| 17:38 | so what we want to do is somehow have both of these changes | |
| 17:38 | now in the diff and patch world, one might do this by just "guessing" the right place for r5k to go, but that's scary and magical and we don't want to do that | |
| 17:39 | so instead of doing magic, we just do computer nerd work, in this case, we commute ^r5s past r5k | |
| 17:40 | this gives us a repo r1..r4 r5s r5k2 ^r5s2 (which is exactly the same as the above just with the last 2 patches commuted) | |
| 17:40 | I'd better let that sink in for a while... | |
| 17:41 | seydar | so basically we're back at r4? |
| 17:41 | kowey | not quite |
| 17:42 | it's true that when we did r1..r4 r5s ^r5s, we were back to r4 | |
| 17:42 | that's square one, right? | |
| 17:42 | seydar | yea |
| 17:42 | kowey | and then we put r5k on top of that, so that's not in square one anymore, right? |
| 17:43 | r1..r4 r5s ^r5s r5k (which is actually equivalent to r1..r4 r5 for what it's worth) | |
| 17:43 | seydar | yargh yargh |
| 17:44 | kowey | so when we commuted the last two patches, we got r1..r4 r5s r5k2 ^r5s2 which is still the same |
| 17:44 | (equivalent to?...) | |
| 17:45 | seydar | ahhh the commuting is where i got lost |
| 17:45 | kowey | so to make sure we're on the same page, what's r1..r4 r5s r5k2 ^r5s2 equivalent to, you think? |
| 17:47 | have I lost ya? | |
| 17:47 | seydar | i don't know because i don't know what r5k2 and r5ks are equivalent |
| 17:47 | equivalent to* | |
| 17:48 | kowey | OK so the property of commutation I forgot to state (because I am not a mathematician) |
| 17:48 | is that when you commute two patches (say a b), the resulting patches (b2 a2) give the same result as the original | |
| 17:48 | seydar | ah, we just no longer know where the middle point is |
| 17:48 | kowey | so (a b) == (b2 a2) |
| 17:49 | middle point? | |
| 17:49 | seydar | er, where one patch ends and the other one begins |
| 17:49 | kowey | good |
| 17:49 | good call | |
| 17:50 | in effect, yes after applying a to some file, you get some result | |
| 17:50 | which is not the same as you would have gotten if you applied b2 | |
| 17:50 | they have different middle points, right? | |
| 17:50 | seydar | yup yup |
| 17:50 | kowey | BUT if you then apply b the first one (o a) |
| 17:50 | seydar | o? |
| 17:50 | kowey | and if you apply a2 to the second one (o b2) [o for 'original'] |
| 17:51 | seydar | ok |
| 17:51 | kowey | THEN you get the same result (o a b) == (o b2 a2) |
| 17:51 | seydar | yeah! |
| 17:51 | kowey | so the person defining commutation had better darn well make sure this was the case |
| 17:52 | seydar | ok so r1..r4 r5s r5ks ^r5s2 |
| 17:52 | kowey | you're missing a 2 |
| 17:52 | seydar | s/r5ks/r5k2 |
| 17:52 | kowey | yep |
| 17:52 | seydar | r1..r4 r5s r5k2 ^r5s2 |
| 17:52 | how did we get here again | |
| 17:53 | kowey | we started from r1..r4 r5s |
| 17:53 | then we went back to square one with r1..r4 r5s ^r5s | |
| 17:53 | then we slapped on my patch r1..r4 r5s ^r5s r5k | |
| 17:53 | then we commuted the last two: r1..r4 r5s r5k2 ^r5s2 | |
| 17:54 | seydar | oh oh oh |
| 17:54 | and why did we commute them again? | |
| 17:54 | kowey | so what can we say about r1..r4 r5s r5k2 ^r5s2? what is it equivalent to? (we'll see in just a sec why we did this) |
| 17:55 | seydar | r1..r4 r5s ^r5s r5k |
| 17:55 | kowey | which in turn is equivalent to... |
| 17:55 | seydar | r1..r4 r5k |
| 17:55 | kowey | right! |
| 17:55 | seydar | but why did we have to commute them? why couldn't we just do that in the first place? |
| 17:55 | kowey | because now all we have to do is pop off that inverse patch |
| 17:56 | r1..r4 r5s r5k2 ^r5s2 => r1..r4 r5s r5k2 | |
| 17:56 | and woah, we've got something totally new here | |
| 17:56 | seydar | whoa where'd that come from |
| 17:57 | kowey | so that is the result of merging our two patches |
| 17:57 | seydar | ok gimme a second here |
| 17:57 | kowey | notice that all I did was erase something |
| 17:57 | seydar | this is some black magick man |
| 17:57 | unholy things are going on here | |
| 17:58 | kowey | haha... well this went way over my head the first few times I tried to learn it |
| 17:58 | but after a while, it just sorta sunk in | |
| 17:58 | so this all seems very magical because I've thrown a whole lot of new information at you | |
| 17:59 | if you step away from it and come back, you will come to realise that actually, the only things go on here are very simplistic operations | |
| 17:59 | seydar | whoa |
| 17:59 | whoa ok i got it | |
| 17:59 | kowey | and the whoa part comes from how you put these simple predictable things together |
| 17:59 | so it only *looks* like magic, but it really isn't | |
| 17:59 | seydar | wait no i don't |
| 18:00 | kowey | it's perfectly OK |
| 18:01 | so we wanted to merge these two repos (r1..r4 r5s) and (r1..r4 r5k) | |
| 18:02 | and to do this we did some crazy inverting and commuting operations (each of which very simple in their own right) | |
| 18:02 | and got back the repo (r1..r4 r5s r5k2) | |
| 18:02 | you with me there? | |
| 18:02 | seydar | kiiinda |
| 18:02 | kowey | (without worrying too much about how we got there, just the big picture) |
| 18:02 | seydar | now why couldn't we just apply r5k to r5s |
| 18:03 | kowey | OK, imagine r5s was "move file A to B" |
| 18:03 | and r5k was "add line 3 + foo to A" | |
| 18:03 | what would happen? | |
| 18:03 | or rather, what would happen if (without resorting to magic) you just applied r5k on top of r5s? | |
| 18:04 | seydar | failsauce would happen |
| 18:04 | kowey | we don't like failsauce |
| 18:04 | seydar | no we don't! |
| 18:04 | kowey | so through commutation we managed to translate r5k into some r5k2 (add line 3 + foo to B) |
| 18:04 | no failsauce, no magic, just commutation | |
| 18:05 | and if you apply r5k2 on top of r5s, what do you get? | |
| 18:06 | seydar | our nice clean repo |
| 18:06 | kowey | 100% predictable |
| 18:06 | seydar | WAIT! |
| 18:06 | ok so the commutation is produced in isolation, thus our guarantee and the fact that we can pop off the last one... | |
| 18:07 | but how are we promised that the endpoint of r5k2 will be our end result? | |
| 18:07 | kowey | depends on what you're asking |
| 18:07 | the only promise darcs makes is "if they commute, I can do it" | |
| 18:08 | seydar | knowing that the repo is predictable and clean requires us to know the endpoint of r5k2 |
| 18:08 | kowey | put it this way |
| 18:08 | say you got a web page | |
| 18:08 | gal_bolle joined #darcs | |
| 18:08 | kowey | and you make a patch that sticks in a big honking orange button |
| 18:08 | right? | |
| 18:09 | gal_bolle | hi all |
| 18:09 | kowey | and then I make patch that turns the background into the same shade of orange |
| 18:09 | hey gal_bolle, long time no see | |
| 18:09 | seydar | hola gal_bolle |
| 18:09 | kowey | now suppose we merge those two patches |
| 18:09 | the ONLY thing darcs will promise you is commutation permitting you'll get a clean result | |
| 18:10 | what it won't promise you is that the web page (now with big honking orange button on orange background) actually "works" | |
| 18:11 | gal_bolle | kowey: the probability that i'll be in the darcsosphere during hackaton is getting so close to zero it hits plank scale :-( |
| 18:11 | seydar | here's what i'm getting at: how do we know darcs won't put all the information for the commutation into r5k2 and nothing (or maybe just something small) in ^r5s2? |
| 18:11 | kowey | gal_bolle: you mean 30 Aug, or this Nov or even farther in the future? |
| 18:12 | seydar: by trusting the person who wrote the commute function | |
| 18:12 | seydar: also, commutation is expected to have certain mathematical properties, which I'll let the smart folks in this room talk about | |
| 18:13 | seydar | but how does IT know how to determine the middle point? |
| 18:13 | kowey | it doesn't have to |
| 18:13 | seydar | because that's where all the magic is happening |
| 18:13 | kowey | the trick is that commutation only looks the patches, not at the results |
| 18:13 | seydar | ooooooooooooh |
| 18:13 | wait, not quite | |
| 18:13 | kowey | so if I have a patch "move X to Y" and some patch "add line 3 to Y", I don't actually *care* what I'm applying to |
| 18:14 | I just mechanically rewrite the patches themselves | |
| 18:14 | there is neither middle point nor spoon | |
| 18:14 | gal_bolle | kowey: 30 aug |
| 18:14 | kowey | OK, it's not an Official Darcs event anyway ;-) |
| 18:14 | * seydar | explodes |
| 18:15 | kowey | it's pretty mindblowing what happens when you simplify things |
| 18:15 | seydar | i will never simplify anything ever again |
| 18:15 | this is too painful | |
| 18:15 | how does the commutation actually work? | |
| 18:16 | kowey | I'll have to tag somebody else into the ring, I'm afraid |
| 18:16 | seydar | NO! stand and teach |
| 18:16 | please | |
| 18:17 | kowey | (well I really have to go fix me some dinner - http://irclog.perlgeek.de/darc[…]9-08-12#i_1387755 and really you're better off with somebody who knows how to make things simple ) |
| 18:17 | seydar: can you read any Haskell? | |
| 18:17 | seydar | yes i can |
| 18:18 | sm | seydar could read about patch theory.. |
| 18:18 | seydar | thank you so much for this past hour |
| 18:18 | gal_bolle | seydar: commutation is done at the lowest level of patches, where you only have things like "replace this by that at such line" or "move that file there" |
| 18:18 | and it does not always succeed | |
| 18:18 | copumpkin | that's a nice irc logger |
| 18:19 | gal_bolle | so it only does "elementary" stuff |
| 18:20 | kowey | seydar: enjoy! keep in mind and hang on the thought tenaciously: no magic, just math (not even math I imagine some may grumble) |
| 18:33 | seydar | i still think darcs is magical |
| 18:35 | because knowing that r1..r4 r5s r5k2 is the result we want assumes that it will be in the first place! | |
| 18:35 | this sounds like inductive reasoning | |
| 18:35 | which is cheating as well | |
| 18:38 | gal_bolle | well, as kowey says, we don't say it is the result we want |
| 18:38 | it is a predictable result | |
| 18:38 | seydar | what does predictable mean here? |
| 18:38 | gal_bolle | well-defined if you prefer |
| 18:38 | Heffalump | always the same |
| 18:39 | seydar | meaning... just deterministic? |
| 18:39 | gal_bolle | yes |
| 18:39 | but a bit more than that | |
| 18:39 | seydar | are other systems non-deterministic? |
| 18:40 | Heffalump | they (can) change with new releases of the system |
| 18:41 | darcs always revs the patch format if the commute/merge algorithm changes | |
| 18:41 | (which has only happened once) | |
| 18:41 | seydar | revs? reverses? revises? |
| 18:41 | gbeshers_ joined #darcs | |
| 18:41 | Heffalump | makes a new revision of |
| 18:42 | seydar | so it will redo all the old patches to be in sync with the new format? |
| 18:42 | Heffalump | i.e. changes the format of what's written out, and continues to honour the old behaviour for old format patches |
| 18:42 | seydar | ooh |
| 18:42 | ok ok | |
| 18:42 | but are other merging systems non-deterministic? | |
| 18:42 | Heffalump | the change happened between darcs 1 and darcs 2, and there's an explicit command to "upgrade" all the old patches to the new format. Darcs 2 continues to support darcs 1 patches and will do so indefinitely. |
| 18:43 | Well, not exactly non-deterministic - presumably any given release will do the same thing if you run it repeatedly, but not guaranteed in the same way. With darcs you get a global guarantee that anyone else who does the same merge gets the same result | |
| 18:43 | Dinner, back in a (possibly long) while | |
| 18:44 | Igloo | I haven't been following, but isn't the point that they are not necessarily associative? |
| 18:45 | gal_bolle | seydar: it's also deterministic with respect to the order of merges |
| 18:46 | which i don't think is certain with other systems (especially if people upgrade between merges) | |
| 18:46 | in that sense it's distributedly deterministic | |
| 18:46 | sorry for the french | |
| 18:48 | seydar | vous parlez francais? |
| 18:48 | gal_bolle | oui, moi je suis français |
| 18:48 | seydar | hah moi jsuis americain, mais j'apprends francais a l'ecole |
| 18:48 | jsuis desolee a ne pas avoir les accents | |
| 18:49 | copumpkin | lol |
| 18:49 | seydar | de temps en temps je dis que je suis canadian |
| 18:50 | jusqu'a j'ai reconnu des mechant filles canadians | |
| 18:50 | mechantes*, canadianes* | |
| 18:51 | gal_bolle | canadiennes, mais on s'éloigne du sujet, si je puis me permettre |
| 18:51 | seydar | ok, ok |
| 19:01 | darcscommitbot joined #darcs | |
| 19:03 | jbe joined #darcs | |
| 19:21 | markstos joined #darcs | |
| 19:21 | markstos | Good day. It is a known issue that darcs 2.3 "whatsnew" can fail like this? ./_darcs/pristine: setCurrentDirectory: does not exist (No such file or directory) |
| 19:21 | And can I safely just rename "current" to "pristine" ? | |
| 19:23 | Heffalump | yes and yes |
| 19:23 | markstos | thanks, Heffalump |
| 19:25 | On my tree in the darcs 1.0 repo format, "whatsnew" is far slower with 2.3 than 2.2, unfortunately. | |
| 19:25 | Heffalump | Igloo: yes, good point re associativity |
| 19:25 | markstos: really? Tell mornfall. | |
| 19:25 | markstos | 2.2 can do it in 0.30 seconds, while 2.3 takes 10 seconds. |
| 19:25 | I ran it multiple times in case there was an initial cache building. | |
| 19:26 | It was the 2.2 time that improved significantly with multiple runs, though, probably because the OS was caching the file accesses. | |
| 19:26 | Heffalump | is your tree sharable? |
| 19:26 | markstos | We still have an old server we are waiting on getting the OS upgraded on, which is our hold-up for upgrading to the darcs-2.0 repo format. |
| 19:26 | * Heffalump | is not sure if this is a known fact, but if not we should investigate |
| 19:27 | Heffalump | you're accessing via NFS or something? |
| 19:27 | Otherwise you can update to hashed format on all the repos not on that server | |
| 19:28 | which should have the same performance gains for normal operations (but not for merging) | |
| 19:28 | markstos | No, it's a local FS, FreeBSD 6.3 |
| 19:29 | Heffalump | ok, so you can definitely do what I described on all other machines then |
| 19:29 | actually, sorry | |
| 19:29 | markstos | I can explore converting some repos to the hashed format... I kept thinking the OS upgrade was around the corner... |
| 19:29 | Heffalump | all other machines that the FreeBSD machine doesn't need to be the client in patch exchanges etc |
| 19:31 | markstos | The darcs 1 host does pull regularly from the machine with the darcs 2 binary, unfortunately. |
| 19:31 | So we continue to use the darcs 2 binary with the darcs-1 repo format. | |
| 19:31 | Heffalump | ok, never mind then |
| 19:31 | was just checking you knew about the distinction between hashed format and the darcs 2 patches | |
| 19:32 | markstos | Yes, I've reviewed that. |
| 19:56 | Heffalump | markstos: roughly what size is your repo, in terms of number of files in the working dir? |
| 19:56 | also, were you doing whatsnew -l, or whatsnew? | |
| 20:07 | markstos | Heffalump: about 5,000 files, and no "-l" |
| 20:07 | mornfall | -l is unaffected by 2.3 |
| 20:07 | And yes, plain repos are probably much worse off using the index than not using it. I should have realized that and done something about it. | |
| 20:08 | markstos | Would it be hard to just keep the old code path in that case? |
| 20:08 | Or maybe I'm like a 1% case, and no one is using darcs-1 format anymore. | |
| 20:08 | mornfall | It is probably doable. |
| 20:08 | markstos | It's my early adopter penalty. :) |
| 20:09 | mornfall | The other option is to put an index on the plain pristine as well (so you'd get two). Probably more work. |
| 20:09 | markstos | sounds like there are probably more interesting things to be working on. |
| 20:10 | mornfall | Well, I imagine it should be workable to keep to 2.2 till you can migrate to hashed, maybe? |
| 20:10 | markstos | OK, we'll darcs-2.2 is working well for us, and we have not apparently run into bad bugs fixed by 2.3. |
| 20:10 | Yes, I still personally evaluating 2.3 before installing it globally. | |
| 20:13 | gbeshers_ joined #darcs | |
| 20:14 | Heffalump | 2.3.1 should at least not use the index for non-hashed, IMO |
| 20:16 | markstos | It could just be better documented that folks are encouraged to upgrade their repo formats. |
| 20:16 | Heffalump | it's not practical for a lot of people (e.g. I have one at work which has a slightly corrupt history that doesn't survive careful inspection) |
| 20:17 | markstos | That's true. This repo doesn't survive "darcs get", but maybe it would after "darcs convert" |
| 20:18 | Heffalump | I'd hope that disabling the index for that case would be cheap. |
| 20:20 | markstos left #darcs | |
| 20:21 | seydar left #darcs | |
| 20:45 | mornfall | Heffalump: Well, there's no way to do that in darcs-hs anymore. For 2.3.1, that should be indeed relatively easy. |
| 20:46 | I have obliterated unsafeDiff, which was the piece of code, together with slurps, how to do a mtime-optimized diff. | |
| 20:50 | sm joined #darcs | |
| 20:51 | copumpkin joined #darcs | |
| 20:52 | Heffalump | oh. |
| 20:52 | why isn't treeDiff as fast on plain pristine as unsafeDiff was? | |
| 20:59 | Beelsebob joined #darcs | |
| 21:08 | mornfall | Heffalump: Because it uses hashes to skip comparison whenever the hashes match. But there are no hashes in the plain pristine, so it can't use them. |
| 21:09 | Heffalump | but unsafeDiff can't do that either |
| 21:09 | gbeshers_ joined #darcs | |
| 21:09 | mornfall | unsafeDiff would stat both files first (indirectly, through evaluating the mtime field of respective Slurpies), compare timestamps and if they matched, it would skip comparing files. |
| 21:10 | SlurpFiles, anyway. | |
| 21:11 | Heffalump | so the problem is that unhashed Trees don't have mtimes either? |
| 21:11 | mornfall | Trees just don't have any mtimes in them. |
| 21:11 | Heffalump | right |
| 21:12 | Igloo | That sounds very bad |
| 21:12 | mornfall | Igloo: It only sounds bad, but isn't. :) |
| 21:12 | Heffalump | it is bad for unhashed repos |
| 21:12 | mornfall | Well, for old-fashioned, yes. |
| 21:12 | kowey joined #darcs | |
| 21:13 | Heffalump | personally, I care about those. Generally speaking, I think any abandonment of good performance for them needs to be agreed more widely. |
| 21:13 | Igloo | Yes, I will be very supset if that ends up being in darcs |
| 21:14 | I guess I'm already upset, given it's in 2.3 for whatsnew | |
| 21:17 | mornfall | Well, see, plain pristine is a robustness disaster. |
| 21:17 | * Heffalump | quite liked it, since I could actually read it. I take your point generally, though. |
| 21:17 | mornfall | You don't have to store things in a hash-structured directory tree. But you need the hashes. |
| 21:17 | Heffalump | The key issue is not whether it's good or bad, it's that we need more buy-in before drastically crippling its performance like this. |
| 21:18 | mornfall | It doesn't matter if you lay out the pristine to reflect working. |
| 21:18 | But you need a file where you keep the path<->hash map. | |
| 21:18 | kowey | is there a way to degrade more gracefully? |
| 21:18 | mornfall | Or something. |
| 21:18 | And check the hashes. | |
| 21:18 | * Heffalump | realises he's also confused about how treeDiff can be fast at reading the working copy |
| 21:18 | kowey | (plus a mechanism to avoid silly filename issues) |
| 21:18 | Heffalump | (in the case where pristine is hashed) |
| 21:19 | mornfall | Heffalump: That's the purpose of the index. |
| 21:19 | It doesn't read the working copy, unless the corresponding hash in index is out of date. | |
| 21:19 | Igloo | So the index has mtimes of working in? |
| 21:19 | Heffalump | so the index takes over the handling of mtime stuff? |
| 21:19 | mornfall | Yes. |
| 21:20 | It's actually even easier to make an index-like thing for pristine, since you exactly know when and what changes. | |
| 21:20 | So it's cheaper to recompute hashes. | |
| 21:20 | Heffalump | kowey: the obvious way to degrade more gracefully would be to restore the old code in darcs for plain pristine handling. |
| 21:20 | mornfall | It would probably be even faster than current hashed pristine. |
| 21:20 | Heffalump | or do what mornfall is suggesting now, of course |
| 21:20 | mornfall | But you still get all the irky filename issues. |
| 21:20 | kowey | but you don't care about those for old-fashioned |
| 21:21 | mornfall | And easy corruption, but you would at least detect it and cry bloody murder. |
| 21:21 | kowey | technically speaking, which is the better route? I'm guessing that what mornfall is suggesting involves less divergence? |
| 21:22 | Heffalump | yes, I agree with that. |
| 21:22 | mornfall | Well, you can't have the "keep old code" route and darcs-hs at once. |
| 21:22 | kowey | so we have a plan then? |
| 21:22 | if so, phew! | |
| 21:22 | Heffalump | if mornfall has infinite time and patience, certainly |
| 21:22 | if he has zero time and patience, then not really | |
| 21:22 | hopefully the reality is enough towards the former than the latter :-) | |
| 21:22 | mornfall | Technically, you can, but it's probably more trouble than worth (wrt. keeping old code around for darcs-hs). |
| 21:23 | Well, both are definitely finite. But I'm trying to stay in reasonable supply. | |
| 21:24 | Which sometimes involves being unpleasant, too... | |
| 21:24 | * Heffalump | is still not really sure what really needs to be done before darcs-hs is ready for merging |
| 21:24 | Heffalump | or rather, I know some things I think need doing, but I don't yet have a full view on the complete set |
| 21:24 | mornfall | Well, there is a number of alternatives. |
| 21:25 | Scaled on how early or how late we try to merge. | |
| 21:26 | Eg. I'm interested in working on a new storage format. | |
| 21:26 | Beelsebob joined #darcs | |
| 21:26 | Heffalump | for me the number one merge criterion is "are we happy with the state darcs mainline would be in if mornfall disappeared right after the merge" |
| 21:26 | kowey | nod |
| 21:27 | mornfall | Well, I wouldn't. But I can't get to a state where I would without external help. |
| 21:27 | The review is an important help, but we are missing a lot of testing coverage on the darcs end of things. | |
| 21:27 | And to me it seems that darcs code is such a tangle that it's not easy to cut down for testing purposes. | |
| 21:28 | Heffalump | I know you wouldn't, but the point is that it should be the merge criterion because otherwise we are essentially leaving darcs mainline in an unstable state for an indefinite period while you finish off |
| 21:28 | dcoutts_ joined #darcs | |
| 21:28 | Heffalump | yes, I agree re darcs. We just have to live with the tests we have and hope that's enough. |
| 21:28 | And not make things worse | |
| 21:28 | mornfall | I wouldn't referred to "be happy about mainline". :) |
| 21:29 | "I wouldn't" I mean. | |
| 21:29 | Heffalump | oh, I see |
| 21:29 | :-) | |
| 21:29 | as happy as we were before the merge | |
| 21:30 | mornfall | Dunno. Still not sure. The coverage bugs me. |
| 21:30 | Both on correctness and performance levels. | |
| 21:30 | For most things, all we have is anecdotes. | |
| 21:30 | Heffalump | right |
| 21:30 | mornfall | And darcs-benchmark, while a start, is still inadequate. |
| 21:31 | Heffalump | but at least if we can be confident that hashed-storage is doing the right thing and in a safe way, then the lack of testing is less of a barrier to adopting it |
| 21:31 | dcoutts_ left #darcs | |
| 21:32 | mornfall | Yes, that's the way I also hope to improve testability. hashed-storage comes with its own testsuite (yes, it still has lots more that needs covering, but I'm working on it... |
| 21:32 | ) | |
| 21:35 | Heffalump | personally, my feeling is that once I was happy with hashed-storage I'd also be happy with darcs-hs, though I have yet to really look at the darcs-hs side carefully to be sure of that. |
| 22:02 | sm_ joined #darcs | |
| 22:04 | sm__ joined #darcs | |
| 22:08 | sm___ joined #darcs | |
| 22:10 | sm____ joined #darcs | |
| 22:12 | sm_____ joined #darcs | |
| 22:31 | Beelsebob joined #darcs | |
| 22:57 | sm joined #darcs | |
| 22:58 | gwern | http://blurredlinescomics.co.uk/DR1.html <-- 'Darc's requiem' |
| 23:05 | copumpkin | that's odd |
| 23:58 | sm joined #darcs |
← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text