← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text | plain, newest first
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 00:05 | kpreid_ joined #darcs | |
| 00:35 | twb joined #darcs | |
| 01:05 | klapaucjusz joined #darcs | |
| 01:35 | kpreid_ joined #darcs | |
| 07:52 | lelit joined #darcs | |
| 08:02 | darcscommitbot joined #darcs | |
| 08:03 | darcswikibot joined #darcs | |
| 08:12 | JaffaCake1 joined #darcs | |
| 08:36 | gal_bolle joined #darcs | |
| 09:24 | kowey joined #darcs | |
| 09:24 | kowey | morning |
| 09:25 | gh_ joined #darcs | |
| 09:25 | gal_bolle | morning |
| 09:26 | gh_ | hi |
| 09:26 | lambdabot | gh_: You have 1 new message. '/msg lambdabot @messages' to read it. |
| 10:36 | mornfall | kowey, Heffalump, the optimize --pristine is not about FS lookup -- the size prefix was a hack that is no longer needed, and not having it makes certain code a lot simpler ... the other thing is that old darcs versions did not sort the directory listings, so directory hashes were more or less random. |
| 10:36 | (The simpler code works for non-optimized pristine, but tends to be slower...) | |
| 10:36 | It seems that on ext3, the size prefix improves performance. :( | |
| 10:36 | But I have to go again. | |
| 10:37 | See you around. | |
| 12:47 | gh_ | http://bugs.darcs.net/issue1731 <- shouldn't this be marked as fixed now ? |
| 13:07 | mornfall | 10221.3ms d=4985.8 |
| 13:07 | Now that's bogus. | |
| 13:07 | Heffalump | oh yes :-) |
| 13:07 | we really should use criterion | |
| 13:08 | though perhaps it'll do too much work | |
| 13:08 | mornfall | Heffalump: Criterion would run for better part of 3 hours on that single testcase, I suspect. |
| 13:08 | Hm. No, only 30 minutes, sorry. | |
| 13:08 | But it's still lot of time. | |
| 13:09 | This entry is clearly problematic because only 2 runs were done, and with wildly different results. | |
| 13:09 | It's all about time/precision tradeoff. | |
| 13:09 | More time = more precision. | |
| 13:10 | Criterion is not going to help with it, other than maybe saying that he wants x precision no matter how long that will take. | |
| 13:11 | Heffalump | it provides a better measure of precision than just taking stddev |
| 13:11 | mornfall | Sure, but it's not going to help with the basic problem. :) |
| 13:12 | It can just tell us how bad the problem is, not solve it. | |
| 13:12 | Heffalump | I think it also reports results that it thinks are dodgy, doesn't it? |
| 13:12 | right | |
| 13:12 | mornfall | But we can already see that the problem is quite bad through that exorbitant stddev. |
| 13:13 | Heffalump | only because you looked, I didn't notice it. To detect it automatically we'd have to set some threshold for stddev or stddev/mean that we were happy with. |
| 13:14 | mornfall | Yes, but a single really bad run could make things run nearly forever that way. |
| 13:15 | However, the amount of variance is somewhat alarming anyway. | |
| 13:16 | kowey | my hope is that in the long run we can have benchmarking in bits and pieces |
| 13:16 | store benchmarks offline | |
| 13:16 | mornfall | I have noticed that in the backlog. Not sure that's going to fly though. |
| 13:16 | kowey | err, store benchmarks, then feed them to criterion offline to find out how much more benchmarking you'll need to run |
| 13:16 | Heffalump | mornfall: that's what I mean about criterion; I thought it solves the problem of figuring out thresholds |
| 13:17 | mornfall | Heffalump: That probaly yes. Although its thresholds are tuned for sub-second benchmarks, IIUIC. |
| 13:17 | kowey | we ought to just try it and see what happens, bring bos in for help if necessary |
| 13:18 | (as opposed to saying "it seems like it can't work") | |
| 13:18 | Heffalump | one thing though, please don't post any blog posts with those silly graphs :-) |
| 13:18 | mornfall | Sure, go ahead. :) I'm not stopping anyone from trying. |
| 13:19 | kowey | silly graphs? as in with two dots in them? |
| 13:20 | mornfall | Heffalump: Btw. where do you see the important regressions? |
| 13:25 | Heffalump | one sec |
| 13:27 | mornfall | kowey: Those new benchmarks on the wiki are yours? |
| 13:27 | kowey: Are you sure your system is OK? Since darcs get --complete on darcs darcs repo takes ~11s with cold cache for me, which is about 20 times less than your benchmark numbers... | |
| 13:27 | Heffalump | on GHC: get (full), pull 1000, wh, wh mod, check, repair all seem slower. |
| 13:28 | mornfall | Or maybe this is a OSX related problem? |
| 13:28 | kowey | hmm, what might be wrong with it? |
| 13:28 | maybe getting lispy to try it with his somewhat newer Mac would help | |
| 13:28 | mornfall | Heffalump: get is bogus, since op/nonop should have 0 impact. The get code did not change at all. |
| 13:28 | kowey | if this osx related, could it be something about HFS+ ? |
| 13:29 | mornfall | kowey: Dunno, I am just saying that it works 20 times faster for me. |
| 13:29 | I doubt my system is 20 times faster than yours... :) | |
| 13:29 | kowey | hmm, hopefully lispy has turned up some results in his hunt for a Mac that the Darcs Team can use |
| 13:30 | mornfall | Heffalump: (So based on those 2 observations, there shouldn't really be a regression -- 2.3.1 and op 2.3.99.2 is the same...) |
| 13:30 | Heffalump | hmm, ok |
| 13:30 | kowey | I can report that the bit that just does cp -a seems to take a long time on my Mac |
| 13:30 | Heffalump | btw, does the index also get corrupted if we remove pending (rather than editing it)? |
| 13:30 | mornfall | Heffalump: Hm. Or maybe the op variant *is* faster, since it's also faster on 2.3.1 and I am not particularly sure why that would be. |
| 13:30 | Heffalump | (where corrupted = out of date but not noticed) |
| 13:32 | mornfall | Likely, yes. You change the "working" state without giving darcs a way to notice that. |
| 13:32 | It tracks timestamps in the working copy, but pending is assumed to be private and nothing else than darcs should be touching it. | |
| 13:32 | Heffalump | I don't think we should release 2.4 like that. Like it or not, that's a very well-known workaround for darcs not doing what you want. |
| 13:34 | mornfall | Well, we have to store the hash of pending somewhere then and complain if it does not match. |
| 13:36 | Heffalump | actually, can this lead to repo corruption? |
| 13:36 | mornfall | It can lead to things showing up in whatsnew/record/... that were done in pending and are no longer in effect. |
| 13:37 | Heffalump | ok, but you can't actually record an invalid patch |
| 13:37 | mornfall | In case of editing, things not showing up. |
| 13:37 | Heffalump | never mind then, I confused myself |
| 13:37 | mornfall | Unless you edit an invalid patch into pending, no. |
| 13:37 | The effects of pending on index are files appearing or disappearing, not changing content. | |
| 13:41 | kpreid_ joined #darcs | |
| 13:41 | mornfall | Heffalump: Check/repair do more work in 2.3.99.1 than in 2.3.1 and aren't that much slower. |
| 13:42 | Heffalump | yeah, I remember that now |
| 13:42 | mornfall | Heffalump: The rest is hashed-storage getting a little slower between 0.3 and 0.4 I suppose. I think it's more scalable, but hard to give numbers on that since even the biggest repo (GHC) is comparatively tiny in number of files. |
| 13:44 | Hm. For some reason darcs-2.3.0 seriously dislikes my optimized copies of ghc/ghc-testsuite. | |
| 13:44 | As in taking 10 seconds to whatsnew. | |
| 13:44 | Oh. | |
| 13:45 | Now that's interesting. | |
| 13:46 | Doesn't seem to have any issues on the benchmark. | |
| 13:50 | Heffalump: For all I can tell, HEAD is faster in whatsnew than 2.3 in ghc-testsuite (which is between 4 and 5 times bigger than GHC itself, on filecount). | |
| 13:51 | 370ms v. 244ms on average of 100 runs | |
| 13:53 | (and 90ms vs 220ms of user CPU time) | |
| 13:53 | npouillard | Hi, all. The patch tracker seems to send mails where Message-ID is equal to In-Reply-To |
| 13:54 | which is rather strange/wrong | |
| 13:54 | any idea? | |
| 13:56 | mornfall | One of those figures was reverse (smaller goes with smaller). |
| 13:58 | npouillard | kowey: any idea? |
| 13:58 | mornfall | Heffalump: Another thing seems to be that whatsnew on non-optimised repositories is quite problematic indeed. The new index always produces directory hashes consistent with what optimize --pristine does. |
| 14:00 | Heffalump: In non-optimized hashed pristine, the directory hashes are all "wrong" for new darcs and it has to look at all directory listings all the way to files, which puts it somewhere between 2.3 and 2.2 in performance. | |
| 14:01 | For 2.3, things worked much better, because in most wild pristine copies, the directory listings were accidentally sorted and the index hashes matched those present in pristine. | |
| 14:14 | kowey | npouillard: no, but thanks for pointing this out |
| 14:15 | npouillard | kowey: who is able to fix that? |
| 14:15 | kowey | do you have an example of this? |
| 14:16 | I just looked at a message, and saw Message-Id: <1265797541.87.0.743562763322.issue1738 darcs.net> |
|
| 14:16 | npouillard | any mail ? |
| 14:16 | kowey | and In-Reply-To: <1265622422.04.0.165920446393.issue1738darcs.net> |
| 14:17 | oh hang on, I think http://bugs.darcs.net/msg10005 demonstrates this | |
| 14:17 | npouillard | patchXXX ones |
| 14:18 | yes I think this is about patch ones and not issue ones | |
| 14:20 | kowey | ok, well if you'd be interested in looking at this with me, it's darcs get --lazy http://darcs.net/darcs-bugtracker for our config files, I think |
| 14:20 | perhaps it's in one of the detectors. Or there could be some sort of bug in roundup itself | |
| 14:26 | npouillard: I've filed http://bugs.darcs.net/issue1751 | |
| 14:26 | npouillard | kowey: thx for filling it |
| 14:27 | kowey | oh! it's not the difference between issue and patch tracker |
| 14:27 | but between email interface and web interface, I suspect | |
| 14:28 | hang on, but that doesn't really make sense either since people don't generally use the patch tracker through the web | |
| 14:32 | npouillard | kowey: what is the purpose of extensions/messages_as_mbox.py |
| 14:34 | kowey | that's a feature by twb |
| 14:34 | I think I've tracked it down a little bit btw | |
| 14:35 | there's a comment in the core roundup code that says something like "# Default the reply to the first message" | |
| 14:44 | npouillard: sorry, I just realised I gave you a non-answer. It's a feature that lets you view the tracker contents in your mailer, if I understand correctly | |
| 14:45 | if you click on the mbox link attached to any issue (or patch?) then you get an mbox file which you can then look at in your mailer | |
| 14:46 | Korusef joined #darcs | |
| 14:58 | kpreid_ joined #darcs | |
| 14:59 | Korusef joined #darcs | |
| 15:37 | kowey | sigh, loads of roundup log entries from bing.com for http://bugs.darcs.net/file106 |
| 15:39 | lispy joined #darcs | |
| 15:46 | npouillard | kowey: ok thanks for the ex |
| 15:46 | ..planantion | |
| 15:46 | lispy joined #darcs | |
| 15:47 | npouillard | and so this feature can not be responsible for the bug... |
| 15:47 | lispy | hey |
| 15:48 | kowey: I left stage 3 benchmark running last night but I didn't have time to look at it this morning to know if it finished | |
| 15:50 | kowey | great! we were just wondering if there was something particularly slow about Macs |
| 15:50 | I'm beginning to think that it's me un-thinkingly choosing the journaling default when I formatted my drive for the first time | |
| 15:50 | lispy | kowey: and I wouldn't call the requests unreasonable (now they are sufficiently well-defined that I have a script for part of it), but there have been a lot and sometimes I just get behind on them |
| 15:51 | kowey | ... and now I think I understand my friend's claim that journaling for laptops is potentially silly (unlikely to have power failure?) |
| 15:51 | lispy | <shrug> I care about my data and I don't like to wait for full disk scans |
| 15:51 | Plus, my mac usually locks up when I reboot iut | |
| 15:51 | Like every 3-4 months | |
| 15:52 | So, to me journaling seems sane | |
| 15:52 | Also, I don't care enough to fight the osx installer on this issue :) | |
| 15:54 | kowey: I do think laptops tend to have drives with lower rpms, which translates to slower seek times (I'm pretty sure), and possibly slower streaming rates | |
| 15:54 | kowey: We should try it on a solid state drive :) | |
| 15:54 | kowey | 7200 rpms here |
| 15:54 | lispy | ah, that's not bad |
| 15:54 | kowey | I made a point of that (although with the whinny noise it makes, I wonder if that was wise) |
| 15:55 | lispy | I think I'm at 5200? 5400? I'd have to check |
| 15:55 | kowey | and also maybe I should have deliberately gotten a slower one, if I was interested in darcs being faster |
| 15:57 | lispy | kowey: For the darcs-benchmarking a thought just occured to me |
| 15:58 | kowey: It might be smart to have a --max-memory=... flag and we just pass that to darcs in the form of RTS options | |
| 15:58 | kowey: I think it's -M1G for example to limit to one gig of memory | |
| 15:58 | kowey | I wouldn't mind a patch for that :-) [or I can just add it to the bugs db] |
| 15:59 | lispy | oh, even better. Just have a --rts-opts="..." that gets passed |
| 16:00 | wow lots of darcs email | |
| 16:00 | kowey | one of the problems I'm faced with is that every time I want to add a functionality, I have to thread it through a whole bunch of functions |
| 16:01 | (or adopt some kind of abstraction that says "here's the global stuff") | |
| 16:01 | lispy | *cough* reader monad |
| 16:02 | You probably have (or want?) a record with all the params to darcs? | |
| 16:02 | Then it seems like you could ReaderT over IO to add that record | |
| 16:02 | And when you need a field do a look up | |
| 16:03 | (here, I'm assuming a lot of darcs-benchmark is in IO) | |
| 16:04 | kowey | I'll have to dig through the code later |
| 16:04 | I've somehow found myself in the middle of squashing spammy/porn attachments on bugs.darcs.net | |
| 16:04 | lispy | weird |
| 16:04 | kowey | as it seems that people are landing on our tracker by searching for keywords |
| 16:04 | kpreid_ joined #darcs | |
| 16:04 | lispy | I wish our spam stopping was more automated |
| 16:04 | kowey | so the seo's are winning |
| 16:05 | lispy | seo's? |
| 16:05 | kowey | search engine optimisers |
| 16:05 | lispy | gotcha |
| 16:05 | kowey | well, I guess this isn't quite it |
| 16:05 | this is stuff from ages ago | |
| 16:05 | one thing we did to throttle the spamminess of things was to force bugsdarcs.net through mailman |
|
| 16:06 | to get moderation | |
| 16:06 | lispy | Hmm...(reading darcs email) looks like Ganesh the whole review |
| 16:06 | kowey | strangely, (touch wood) we're not getting any spammers using the web ui lately |
| 16:07 | * lispy | intentionally verb missing |
| 16:07 | lispy | "Petr, are |
| 16:07 | you ok for me to any patches I'm already happy with (so long as darcs | |
| 16:07 | compiles/the testsuite passes, of course) while the rest of the review | |
| 16:07 | is still ongoing?" | |
| 16:07 | yikes | |
| 16:07 | I thought taht would be 1 line | |
| 16:07 | Sorry | |
| 16:07 | What do you think Ganesh was asking for permission about, applying them? | |
| 16:09 | Igloo | I'm pretty sure "push" is the missing word |
| 16:10 | kowey | (currently, the technique I'm using is to [a] grep the roundup logs for bing.com referrals [b] use a regexp to isolate the files in question [c] "echo > file106" in the tracker db) |
| 16:12 | gh_ left #darcs | |
| 16:21 | gbeshers joined #darcs | |
| 17:11 | kowey | hmm, the record benchmark appears to fail systematically under Linuk |
| 17:12 | ah-hah! | |
| 17:12 | lispy | ? |
| 17:12 | Water is displaced by mass? | |
| 17:12 | kowey | askUser |
| 17:13 | Linux is a red herring here; it's just "any computer that Eric doesn't use regularly" | |
| 17:13 | Igloo | :-) |
| 17:13 | lispy | heh |
| 17:13 | What is going on? | |
| 17:14 | Igloo | Presumably a missing -A flag |
| 17:14 | kowey | yep |
| 17:15 | * kowey | didn't mean to be cryptic |
| 17:15 | Igloo | The testsuite really ought to tell darcs not to use things like the user's settings or global cache |
| 17:17 | kowey | yeah. right now it sets HOME to the playground |
| 17:17 | so that's the user cache gone (err, I hope) | |
| 17:18 | for the user settings we could play whack-a-mole on the environment variables, but that seems like not a very nice way to do it | |
| 17:18 | Igloo | Ah, you set vars rather than using ~/.darcs? |
| 17:18 | kowey | darcs respects some variables |
| 17:18 | kpreid_ joined #darcs | |
| 17:19 | kowey | that said, I forget what the precedence is |
| 17:19 | maybe we could override stuff by dumping entries into not-quite-HOME/.darcs | |
| 17:19 | (but that's still whack-a-mole) | |
| 17:19 | Igloo | I mean, that's why it knows your address, despite $HOME being set? |
| 17:19 | kowey | right |
| 17:20 | oh, you meaning me and not the generic you | |
| 17:20 | * Igloo | thinks setting an explicit env is the way to go |
| 17:20 | Igloo | Right |
| 17:20 | kowey | of course you wouldn't be asking me how to use darcs |
| 17:20 | err, the you-you | |
| 18:00 | kpreid_ joined #darcs | |
| 19:05 | kpreid_ joined #darcs | |
| 19:24 | gbeshers joined #darcs | |
| 20:18 | arjanb joined #darcs | |
| 21:05 | kowey joined #darcs | |
| 21:17 | kowey | yay, more benchmarks (windows this time) |
| 22:22 | kpreid_ joined #darcs |
← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text | plain, newest first