Camelia, the Perl 6 bug

IRC log for #darcs, 2009-08-12

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

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 gwern the wiki is updated
01:13 gwern should be faster now
01:13 gwern (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 gwern 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 kowey (and all we need to do now is auto-expire pages on darcs apply?)
09:57 kowey "The next major release is 2.4, expected in northern-hemisphere winter 2009/2010." *chuckle*
09:58 kowey 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 mornfall : - )
10:07 mornfall 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 gwern kowey: it seems faster and more memory efficient to me in my scientific open-a-bunch-of-random-tabs test
12:24 gwern kowey: though I haven't tried editing
12:28 gwern 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 kowey 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 gwern (do we push often?)
12:34 gwern 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 kowey 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 gwern 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 kowey if people push a lot, that is
12:36 kowey 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 gwern 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 gwern the file being static html
12:38 gwern if youre curious ssh in and do less DarcsWiki/cache/Fundraising.page
12:39 gwern 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 kowey 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 gwern kowey: are post-apply hooks run after each patch, or after each bundle?
12:42 gwern 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 gwern 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/node7​.html#SECTION00710000000000000000
12:46 mornfall Like, hpc reports, haddock rebuilds and so on.
12:46 mornfall You don't want to run the testsuite 10 times in a row just to throw away 9 of the results.
12:46 mornfall 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 mornfall And yes, if the bundle fails as a whole, you can trackdown locally, or something.
12:47 mornfall 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 mornfall 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 kowey 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 kowey on my way...
13:08 gwern eureka! the rss seems to work!
13:09 gwern I don't know how to verify the rss feed, but there's something there!
13:10 kowey ooh where?
13:11 kowey 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 kowey how would people feel about Darcs Hacking Sprint #3 being in London?
13:22 kowey in November...
13:22 kowey 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 kowey 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 sm let me look again
16:36 sm most of my roundup scripting knowhow is in pythonrc.py,
16:37 kowey in case you have to use it a lot?
16:37 kowey 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 sm 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 sm in the tracker dir
16:40 kowey sm: yeah this time, it's not roundup's fault
16:40 kowey 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 sm twb doesnt appear in that list though
16:40 kowey hmm... I probably should dump my scripts in the tracker repo
16:41 kowey I don't think you can detect these automatically
16:41 kowey so I'd like to make a script that I can run, say "merge-roundup turnbull stephen"
16:41 kowey "merge-users ashleymoran ashley.moran"
16:41 kowey 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 kowey sm: totally random unrelated thought - have you heard of the wikicreole project?
16:43 kowey 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 sm I see pandoc as the wiki translation tool
16:45 sm kowey: it's got a strange name, but maybe reassignlinks is mergeusers ?
16:45 sm 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 sm ?
16:47 kowey like say twb1 creates a bug
16:47 kowey if I run this, and search for bugs created by twb, do I get twb1's bugs?
16:47 kowey 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 kowey 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 sm 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 sm 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 kowey 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 seydar 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 kowey 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 kowey seydar: are you familiar with diff/patch?
17:15 seydar yes
17:15 kowey patch (in my view of things) is magical
17:16 kowey because if you made a patch against some file and you apply it to a similar but not identical file
17:16 kowey patch (the program) will try and guess where to apply that patch
17:17 seydar yargh yargh
17:17 seydar so darcs says "nuhuh!"
17:17 seydar and does what?
17:17 kowey well darcs just uses more information so it never has to do this
17:17 kowey it keeps track of all the patches in the history
17:18 kowey so if you apply to a patch to some file that has changed since the version that got patched...
17:18 kowey 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 kowey it doesn't mean that your C code (or whatever) will necessarily come out correct (we don't worry about semantics)
17:19 kowey but it *does* mean is that we'll always put your patches where you meant for them to go
17:19 kowey see what I mean?
17:21 seydar kiiinda
17:21 seydar so file A: r1 -> r2 -> r3 -> r4
17:21 seydar you make an r5
17:21 seydar 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 seydar they both need r4
17:22 seydar how will they be applied to the file?
17:22 kowey ok, let's say I send you r5-k
17:22 kowey and you've got r1 r2 r3 r4 r5-s
17:23 kowey 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 kowey so r1 r2 r3 r4 r5-s (^ r5-s) -- using the ^ to meant inverse
17:25 kowey undo is just taking the exact opposite, so fully mechanical operation, flipping + into -, etc
17:25 kowey 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 kowey you're back to square one
17:26 kowey 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 kowey 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 kowey commute is this operation that compares two patches in a sequence and sees if you can flip them around
17:28 kowey the result is two slightly different patches
17:28 kowey the key thing to remember about commute is that (in the absence of conflicts), it's actually pretty simple and stupid
17:28 kowey let me give you an example: say I have a patch "move file A to B"
17:29 kowey and I have another patch "add line 3 foo to B"
17:29 kowey if I "commute" these two patches, what I get is "add line 3 foo to A; move A to B"
17:29 kowey 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 kowey i.e first you moved the file
17:31 kowey then you made a change in it
17:31 seydar ah ok
17:32 kowey now imagine we wanted to commute those
17:32 kowey imagine for example, you didn't *really* want to rename that file
17:32 kowey but gosh, you've already made a whole bunch of changes to it
17:32 kowey how do you undo just the rename?
17:32 kowey ... you do it by "commuting"
17:33 kowey in this example, you want to commute px py into some py2 px2
17:33 kowey so far so good?
17:33 seydar yea
17:33 seydar 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 kowey it's surprisingly straightforward
17:33 kowey tedious more than difficult
17:34 kowey and the reason why it's actually easier than you may think
17:34 kowey 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 kowey we've got r1..r4 r5s ^r5s r5k
17:35 kowey that's not quite what we want, because now we've only got my r5 and not yours
17:35 kowey we want to merge them... and to do this all we have to do is...
17:35 kowey (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 kowey well, let's say r5s is a patch that adds something to the top of the file
17:37 kowey and r5k is something that adds something to the same file, but somewhere else
17:38 kowey so what we want to do is somehow have both of these changes
17:38 kowey 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 kowey so instead of doing magic, we just do computer nerd work, in this case, we commute ^r5s past r5k
17:40 kowey 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 kowey 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 kowey it's true that when we did r1..r4 r5s ^r5s, we were back to r4
17:42 kowey 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 kowey 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 kowey (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 kowey have I lost ya?
17:47 seydar i don't know because i don't know what r5k2 and r5ks are equivalent
17:47 seydar equivalent to*
17:48 kowey OK so the property of commutation I forgot to state (because I am not a mathematician)
17:48 kowey 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 kowey middle point?
17:49 seydar er, where one patch ends and the other one begins
17:49 kowey good
17:49 kowey good call
17:50 kowey in effect, yes after applying a to some file, you get some result
17:50 kowey which is not the same as you would have gotten if you applied b2
17:50 kowey 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 seydar how did we get here again
17:53 kowey we started from r1..r4 r5s
17:53 kowey then we went back to square one with r1..r4 r5s ^r5s
17:53 kowey then we slapped on my patch r1..r4 r5s ^r5s r5k
17:53 kowey then we commuted the last two: r1..r4 r5s r5k2 ^r5s2
17:54 seydar oh oh oh
17:54 seydar 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 kowey r1..r4 r5s r5k2 ^r5s2 => r1..r4 r5s r5k2
17:56 kowey 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 seydar 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 kowey but after a while, it just sorta sunk in
17:58 kowey so this all seems very magical because I've thrown a whole lot of new information at you
17:59 kowey 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 seydar whoa ok i got it
17:59 kowey and the whoa part comes from how you put these simple predictable things together
17:59 kowey 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 kowey so we wanted to merge these two repos (r1..r4 r5s) and (r1..r4 r5k)
18:02 kowey and to do this we did some crazy inverting and commuting operations (each of which very simple in their own right)
18:02 kowey and got back the repo (r1..r4 r5s r5k2)
18:02 kowey 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 kowey and r5k was "add line 3 + foo to A"
18:03 kowey what would happen?
18:03 kowey 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 kowey no failsauce, no magic, just commutation
18:05 kowey 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 seydar ok so the commutation is produced in isolation, thus our guarantee and the fact that we can pop off the last one...
18:07 seydar 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 kowey 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 kowey 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 kowey 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 kowey 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 kowey the ONLY thing darcs will promise you is commutation permitting you'll get a clean result
18:10 kowey 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 kowey seydar: by trusting the person who wrote the commute function
18:12 kowey 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 seydar 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 kowey I just mechanically rewrite the patches themselves
18:14 kowey 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 seydar this is too painful
18:15 seydar 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 seydar please
18:17 kowey (well I really have to go fix me some dinner - http://irclog.perlgeek.de/​darcs/2009-08-12#i_1387755 and really you're better off with somebody who knows how to make things simple )
18:17 kowey 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 gal_bolle 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 seydar because knowing that r1..r4 r5s r5k2 is the result we want assumes that it will be in the first place!
18:35 seydar this sounds like inductive reasoning
18:35 seydar 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 gal_bolle 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 gal_bolle 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 Heffalump darcs always revs the patch format if the commute/merge algorithm changes
18:41 Heffalump (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 seydar ok ok
18:42 seydar 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 Heffalump 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 Heffalump 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 gal_bolle which i don't think is certain with other systems (especially if people upgrade between merges)
18:46 gal_bolle in that sense it's distributedly deterministic
18:46 gal_bolle 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 seydar 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 seydar jusqu'a j'ai reconnu des mechant filles canadians
18:50 seydar 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 markstos And can I safely just rename "current" to "pristine" ?
19:23 Heffalump yes and yes
19:23 markstos thanks, Heffalump
19:25 markstos 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 Heffalump markstos: really? Tell mornfall.
19:25 markstos 2.2 can do it in 0.30 seconds, while 2.3 takes 10 seconds.
19:25 markstos I ran it multiple times in case there was an initial cache building.
19:26 markstos 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 Heffalump Otherwise you can update to hashed format on all the repos not on that server
19:28 Heffalump 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 Heffalump 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 markstos So we continue to use the darcs 2 binary with the darcs-1 repo format.
19:31 Heffalump ok, never mind then
19:31 Heffalump 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 Heffalump 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 mornfall 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 markstos 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 markstos 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 mornfall 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 Heffalump 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 mornfall 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 Igloo 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 mornfall 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 mornfall 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 mornfall 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 mornfall It's actually even easier to make an index-like thing for pristine, since you exactly know when and what changes.
21:20 mornfall 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 kowey if so, phew!
21:22 Heffalump if mornfall has infinite time and patience, certainly
21:22 Heffalump if he has zero time and patience, then not really
21:22 Heffalump 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 mornfall Well, both are definitely finite. But I'm trying to stay in reasonable supply.
21:24 mornfall 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 mornfall Scaled on how early or how late we try to merge.
21:26 mornfall 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 mornfall The review is an important help, but we are missing a lot of testing coverage on the darcs end of things.
21:27 mornfall 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 Heffalump And not make things worse
21:28 mornfall I wouldn't referred to "be happy about mainline". :)
21:29 mornfall "I wouldn't" I mean.
21:29 Heffalump oh, I see
21:29 Heffalump :-)
21:29 Heffalump as happy as we were before the merge
21:30 mornfall Dunno. Still not sure. The coverage bugs me.
21:30 mornfall Both on correctness and performance levels.
21:30 mornfall 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 mornfall )
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

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