← 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:00 | twb joined #darcs | |
| 00:02 | mornfall | Hm. |
| 00:03 | packageDeps in Cabal have changed both-ways-incompatibly between 1.6 and 1.8. *sigh* | |
| 00:03 | Or. Hm. | |
| 00:05 | But I am running 1.8.0.2 and it works here. Wtf. | |
| 00:07 | Maybe it's picking up 1.6 for whatever reason. | |
| 00:07 | Would it be bad to require 1.8 for darcs-2.4? | |
| 00:08 | There are two options: | |
| 00:08 | - revert the --exact-version patch | |
| 00:08 | - require 1.8 | |
| 00:08 | twb | Does Cabal 1.8 work on GHC 6.10? |
| 00:08 | mornfall | The latter makes it possible to avoid double compilation of darcs. |
| 00:08 | twb | Does it work on GHC 6.8? |
| 00:09 | mornfall | Let's see. |
| 00:10 | twb | Is it possible to use some sort of conditional, so that GHC 6.12 / Cabal 1.8 users get single compilation and the nice exact-version feature, but older releases can still at least compile Darcs? |
| 00:11 | mornfall | You can, it seems, cabal-install Cabal 1.8 on GHC 6.8. |
| 00:12 | twb | mornfall: IMO if 1.8 works on 6.8, then it should be OK to require it. |
| 00:12 | I'd still ask the list before pushing any requirement, though. | |
| 00:13 | mornfall | It may be a little late in the 2.4 cycle for this. Dunno. |
| 00:13 | Probably RMs call. | |
| 00:13 | +' | |
| 00:13 | twb | Granted. |
| 00:13 | Setup.lhs:225:43: Not in scope: `packageDeps' | |
| 00:13 | Hmph | |
| 00:13 | mornfall | Yes, that's what I am talking about. |
| 00:13 | twb | And I am using GHC 6.12 |
| 00:14 | But cabal-install is still old | |
| 00:14 | Bleh, even ghc --make Setup fails | |
| 00:14 | mornfall | Well, the problem is that it only works with *old* Cabal. |
| 00:14 | And not with new cabal. | |
| 00:14 | twb | Oh, I see. |
| 00:15 | mornfall | But since I have 6.10, cabal configure for some reason picks up the system Cabal not my $HOME Cabal and things work. |
| 00:15 | twb | mornfall: could be you're using --global? |
| 00:16 | mornfall | Well, it picks up local packages for the build. |
| 00:16 | It only picks system Cabal for compiling Setup. | |
| 00:18 | twb | IMO that's a bug |
| 00:22 | mornfall | It looks like one, yes. |
| 00:23 | isaacd joined #darcs | |
| 00:25 | mornfall | twb: Btw, about that bad index... |
| 00:25 | twb | Go on |
| 00:25 | mornfall | twb: Are you sure you can reproduce that with current darcs? |
| 00:26 | twb | I was just going to force a recompile against 0.4.5 to check |
| 00:26 | Only I ran into that issue | |
| 00:26 | mornfall | If you unpull the --exact-version patch, it should compile. |
| 00:27 | (Should be near the top of the stack.) | |
| 00:27 | twb | OK |
| 00:38 | mornfall: hash problem still present for me | |
| 00:38 | wth | |
| 00:39 | --exact-version reports "darcs compiled on Jan 10 2010, at 14:41:15" | |
| 00:39 | mornfall | That's quite interesting. |
| 00:40 | twb | Oh you fucking cocksucker cabal 1.8 |
| 00:40 | mornfall | Are you going from fresh repo? |
| 00:40 | twb | It's in ~/.cabal/bin-linux instead of ~/.cabal/bin-x86-64 |
| 00:41 | mornfall | Explains a lot. |
| 00:41 | twb | But *why* is $arch "linux" instead of "x86_64" now? |
| 00:42 | mornfall | No idea. |
| 00:43 | twb | afk, work |
| 01:05 | back | |
| 01:07 | This is my .cabal/config http://pastebin.com/feb0028c | |
| 01:12 | mornfall: I can confirm that the 00000 hash index issue is NOT present in a clean build that includes "resolve issue1731: bump hashed-storage dependency to 0.4.5" | |
| 01:13 | mornfall | Good. |
| 01:13 | If this is in the tracker, please mark it as fixed then. (I can't recall.) | |
| 01:14 | twb: Looks like a cabal bug, re $arch. | |
| 01:15 | twb | It is, but I don't know the number ^_^;;; |
| 01:15 | Kowey told me yesterday, so if I can find the channel logs I can get the ID | |
| 01:17 | mornfall | I have Issue1677 |
| 01:20 | sm joined #darcs | |
| 01:21 | kpreid_ joined #darcs | |
| 02:12 | gbeshers joined #darcs | |
| 02:25 | mxc joined #darcs | |
| 02:56 | twb joined #darcs | |
| 03:04 | zooko joined #darcs | |
| 03:14 | zooko | <davidsarah> I quite often get random errors from the trac server that go away on retry |
| 03:16 | isaacd joined #darcs | |
| 03:17 | zooko | <zooko> Yes, that's because darcs takes too long to compute the answers to queries about the repository, but trac caches the answers so it works the second time you ask. :-( |
| 03:17 | from #tahoe-lafs | |
| 03:17 | just now | |
| 03:17 | twb | zooko: is trac using --max and --match 'hash XXX' and similar tricks? |
| 03:18 | zooko | I'll check. |
| 03:19 | Hey, what is the actual command-line that is measured in the "annotate" benchmark? | |
| 03:20 | So here is an example command-line that users of http://allmydata.org want to run all the time and which takes way too long: | |
| 03:20 | darcs annotate --xml-output --match "hash 20090703010749-66853-98e0d3750d2b097bcfcb07fd5aabfee97d169547.gz" src/allmydata/client.py | |
| 03:20 | You can grab http://allmydata.org/source/tahoe/trunk if you want to try it yourself. | |
| 03:21 | Oh, also you might like to see the same trac+darcs setup on the darcs source repo: | |
| 03:22 | http://allmydata.org/trac/darcs-2/browser | |
| 03:22 | revision log -> http://allmydata.org/trac/darcs-2/log/ | |
| 03:22 | pick a changeset | |
| 03:22 | http://allmydata.org/trac/darcs-2/changeset/7838/ | |
| 03:22 | Actually if you pick that one you'll get a fast response, since I just clicked on it. :-) | |
| 04:03 | zooko joined #darcs | |
| 04:25 | zookol joined #darcs | |
| 04:54 | zooko joined #darcs | |
| 04:54 | zookol` joined #darcs | |
| 05:08 | zookol` left #darcs | |
| 06:19 | sshc_ joined #darcs | |
| 06:24 | sshc__ joined #darcs | |
| 06:26 | gour joined #darcs | |
| 07:14 | sshc joined #darcs | |
| 07:31 | tux_rocker joined #darcs | |
| 07:44 | balor joined #darcs | |
| 07:55 | lelit joined #darcs | |
| 08:02 | darcscommitbot joined #darcs | |
| 08:03 | darcswikibot joined #darcs | |
| 09:13 | kowey joined #darcs | |
| 09:24 | gour | kowey: ping |
| 09:24 | kowey | good morning, gour |
| 09:24 | gour | kowey: morning, may i ask you one non-darcs or wxhaskell question? |
| 09:25 | kowey | sure, but let's move this to #haskell |
| 09:25 | gour | ok |
| 09:47 | gour left #darcs | |
| 10:07 | darcswikibot | 19 Jan 10:06 - note price of beds (kowey) |
| 10:36 | malcolmw joined #darcs | |
| 11:09 | mxc joined #darcs | |
| 11:47 | lelit` joined #darcs | |
| 11:50 | gal_bolle joined #darcs | |
| 11:54 | gh_ joined #darcs | |
| 11:58 | gal_bolle | hi all |
| 12:53 | darcswikibot | 19 Jan 12:52 - registration deadline (kowey) |
| 12:53 | kowey joined #darcs | |
| 12:53 | kowey | mornfall: did you ever get a chance to look at that potentially-bad-repo with the bad index on darcs check (issue1710)? |
| 12:54 | if I understand correctly, we can reliably trigger the failure, but we still don't know how to reproduce the circumstances that lead up to it? | |
| 13:02 | intripoon joined #darcs | |
| 13:18 | mornfall | kowey: Well, the repo is a result of the failure. |
| 13:18 | kowey: That check complains is not a failure, that's the right behaviour (since the index is actually busted). | |
| 13:24 | kowey | nod |
| 13:24 | ok, so that copy of the repo has not been particularly useful for reproducing the failure? | |
| 13:24 | mornfall | Unfortunately not. Unless we know the state before and the commands to go from the good state to the bad state... |
| 13:25 | kowey | OK |
| 13:25 | hopefully I can figure this out in time... there are some constraints | |
| 13:25 | it's mostly like just finding the right suffix of the context file for the good state | |
| 13:25 | one day :-) | |
| 13:31 | mornfall | kowey: Are you sure you didn't, by any chance, rm -f _darcs/index_invalid, at some point? : - ) |
| 13:32 | Oh wait. | |
| 13:32 | Interesting. | |
| 13:32 | But you say you don't run apply --test, right? | |
| 13:32 | And it's even correct. Nevermind. | |
| 13:33 | kowey | dissapointingly, I can't reproduce this if I setpref test true |
| 13:34 | (the failure, I mean); am now trying again with the original pref | |
| 13:34 | one more potential clue is that when I do darcs revert, darcs thinks I removed those four files mentioned | |
| 13:34 | mornfall | That's expected side-effect of them missing in the index. |
| 13:35 | kowey | ok |
| 13:35 | mornfall | Darcs thinks they do not exist in the working copy. |
| 13:35 | kowey | that makes sense |
| 13:35 | what I'm trying to do is to fetch up to some point before the sprint | |
| 13:35 | and then see if I can trigger the failure again just by pushing patches | |
| 13:36 | but I'd like to make the failure faster to reproduce, hence my interest in setpref test true | |
| 13:36 | mornfall | Sure. |
| 13:38 | Mon Jun 22 13:32:39 CEST 2009 Petr Rockai <me mornfall.net> |
|
| 13:38 | * Invalidate the index in add_to_pending, as it was getting rebuilt too soon. | |
| 13:38 | kowey: Could be that the darcs you were using at the time of the bug didn't have this patch? | |
| 13:39 | Do we have --exact-version? | |
| 13:41 | Hm, but there's no reason add_to_pending would be called in your situation. | |
| 13:41 | kowey | the bad news is that I don't have that darcs anymore -- I think I stupidly replaced it with a newer version |
| 13:42 | too bad life doesn't have (automated) revision control | |
| 13:42 | mornfall | Well, I'll wait if you manage to reproduce with current darcs, I guess. I have gone through the code once again and still don't see a problem. |
| 13:42 | Btw. it should be possible to reproduce this using apply alone. | |
| 13:43 | No way darcs check could screw the index up, testing or not. | |
| 13:43 | Just apply, whatsnew -- if it lists anything, you hit the bug. | |
| 13:43 | kowey | that's helpful |
| 13:44 | mornfall | Should be about infinitely faster than running check. |
| 13:44 | kowey | I'll use that technique instead |
| 13:45 | mornfall | Ok, I have a new working hypothesis. Could something run a darcs command while apply was running in that same repository? |
| 13:46 | There is a race condition there... | |
| 13:46 | 1) apply updates the tentative state | |
| 13:46 | 2) apply invalidates index | |
| 13:46 | --> 3) someone else runs darcs whatsnew (or anything that needs unrecordedChanges) | |
| 13:46 | 4) apply finalizes tentative changes, leaving a bad index and no index_invalid marker behind | |
| 13:47 | At --> 3), the index is updated from current non-tentative pristine and the invalid marker is discarded. | |
| 13:47 | kowey | is there a good way to deliberately trigger this case? |
| 13:48 | mornfall | Well, if inventory optimisation takes a long time (in darcs it takes a while), you could probably run darcs wh in a loop and then run apply. |
| 13:48 | It would probably trigger in a couple of tries. | |
| 13:49 | Kablaam, triggered. | |
| 13:49 | On the first try. | |
| 13:50 | while true; do darcs wh; done | |
| 13:50 | darcs pull -a | |
| 13:50 | (in parallel) | |
| 13:50 | Now the question remains if this is your bug, or a different one. | |
| 13:51 | kowey | hmm, so for this to have been my bug, I would have needed to somehow access that repo (darcs wh) while I was pushing to it |
| 13:51 | which seems unlikely for the first push | |
| 13:51 | mornfall | Yes. |
| 13:51 | kowey | sounds like a new ticket to make! |
| 13:56 | meh... no luck so far with reproducing this with just push and whatsnew | |
| 14:02 | mornfall | kowey: You could possibly switch to apply and whatsnew as well -- although not sure that makes things any more convenient. |
| 14:05 | But I seriously doubt you can reproduce it. | |
| 14:05 | kowey | hmm, so one discouraging variable is we don't know what version of darcs I was doing the apply with |
| 14:05 | sigh, presumed-dead, then? | |
| 14:05 | mornfall | Well, we have a bug with the exact same symptoms, but it requires parallel interaction of two darcs processes. |
| 14:06 | Moreover, the code doing apply is deterministic -- if it works for one patch adding files, it has to work for all. | |
| 14:06 | Since you cannot reproduce, and I don't see any non-determinism in apply, the bug simply does not exist in a single-darcs-running situation. QED. | |
| 14:07 | : - ) | |
| 14:08 | It has however been demonstrated to exist in a situation where multiple darcs processes interact over a single repository (one writing, other(s) reading). Due to uncertainity of your situation at the point of the bug, by Occam's razor, this is your bug. | |
| 14:08 | kowey | hmm |
| 14:10 | mornfall | Now the question is whether to go buy earphones or do something more productive. |
| 14:34 | gal_bolle | what is the 'a' for in data KeyPress a = … in SelectChanges.hs? |
| 14:35 | kpreid__ joined #darcs | |
| 14:38 | kowey | huh... I don't remember |
| 14:38 | it may just be cruft | |
| 14:39 | I think there was a time when I tried to encode the actions into the KeyPresses | |
| 14:39 | but I found that to be really cumbersome (even if it eliminated redundancy) | |
| 14:40 | gal_bolle | ok |
| 14:41 | kowey | yeah, my only guess is that there must have been a mystery third field that used that type variable before I submitted the patch |
| 14:41 | sorry for the noise | |
| 14:42 | gal_bolle | it's gone |
| 14:42 | (almost) | |
| 14:43 | kowey | would you mind having a look at Heffalump's patch146? |
| 14:43 | this implements the idea of making filler patches go away, if I understand correctly | |
| 14:45 | gal_bolle | ok |
| 14:46 | iiuc, it's not intended for application (or is it?) | |
| 14:50 | kowey | not yet, I think he said we should "not waste time on the code until we've decided we want the UI" |
| 14:50 | but I suspect there's really no reason to keep the filler patches around if we can hide them, ie. that nobody's going to protest | |
| 14:50 | gal_bolle | ok, so it's a does-the-UI-make-sense-to-florent opinion you want |
| 14:52 | kowey | well, I think I meant the code (because I think we do want the UI) |
| 14:53 | but starting with does-the-UI-make-sense-to-florent is good | |
| 14:53 | keeping in mind that we can grab some of the text from patch123 | |
| 14:53 | particularly, the bit that tells you how to split patches | |
| 14:54 | gal_bolle | ok |
| 14:55 | kowey | thanks |
| 14:58 | mornfall | That would have been the piano for today. |
| 14:58 | What now. | |
| 14:59 | kowey | no earphones purchased? |
| 14:59 | or wait, does that mean you did some X in place of piano? | |
| 15:02 | mornfall | No, it means I practiced piano and didn't get anywhere. :) |
| 15:02 | But the shop's open till 18 (2 hours yet). | |
| 15:02 | So I still have a chance. | |
| 15:02 | My old ones have fallen apart and I could use some to listen to music and practice intonation on train &c. | |
| 15:03 | gal_bolle | kowey: about Heffalump's patch: there is a downside to defaulting patches to 'n' |
| 15:03 | if you play with 'j/k', they will mysteriously appear out of nowhere | |
| 15:04 | if you do the sequence eyykk, you will see a new hunk appear | |
| 15:05 | |Mike| | Hi guys, i do have a problem with darcs-monitor. It aligns all patches in 1 line. |
| 15:05 | Instead below each other. | |
| 15:07 | (I only removed %DIFF% from the email template) | |
| 15:07 | mornfall | Interesting. |
| 15:08 | Anyone has any experience with Sennheiser CX 400 (II)? | |
| 15:08 | kowey | gal_bolle: hmm... that's a good point - if we keep the filler patches, at least it's explicit (albeit confusing) |
| 15:09 | hi |Mike|... unless there are another darcs-monitor users around here, you might want to contact Antti-Juhani via email | |
| 15:09 | *other | |
| 15:09 | mornfall | kowey: Well, I don't think the filler patch is a problem, as long as it is not first in the sequence. |
| 15:09 | kowey: If you first get what you expect, then it shouldn't be that hard to work out what the extra patch means. | |
| 15:09 | gal_bolle | agree |
| 15:09 | kowey | and we'll avoid making it first in the sequence by not encouraging users to edit the first chunk |
| 15:10 | gal_bolle | especially if they are both marked [from interactive edit] |
| 15:10 | kowey | sounds like SelectChanges will need to bulge out a bit to handle that |
| 15:10 | mornfall | Actually, it is consistent with the record invariant that whatever you say 'n' to will show up in whatsnew after the record is done. |
| 15:10 | kowey | probably doable :-) |
| 15:10 | |Mike| | kowey: okay, do you have his email address somewhere ? :) |
| 15:10 | gal_bolle | kowey: SelectChanges' heart is ripped open on my operation table |
| 15:11 | kowey | |Mike| : http://hackage.haskell.org/package/darcs-monitor |
| 15:11 | gal_bolle: uh-oh... might be tricky to get this into the 2.4 branch (we'll also have to check with Reinier to see what he makes of all this) | |
| 15:11 | perhaps we can postpone this addition till 2.5 | |
| 15:12 | (ie. the [from interactive edit]) | |
| 15:12 | gal_bolle | no problem |
| 15:12 | * kowey | is quite fond of the 'back to TAG' messages during darcs get now |
| 15:15 | mornfall | Gone shopping. I have been postponing this for far too long. |
| 15:18 | gh_ | a gitit question: i have a mirror of wiki.darcs.net and i made changes and recorded patches locally, but my running instance of gitit does not see the changes, except in the "recent activity" page. how can i really see my changes locally ? |
| 15:23 | lispy joined #darcs | |
| 15:24 | lispy joined #darcs | |
| 15:25 | lispy | Good morning |
| 15:25 | kowey | morning, lispy |
| 15:37 | mornfall: could you please make a note of the race condition on the tracker somewhere? | |
| 15:39 | gh_ | ah, I needed to disable the cache |
| 16:11 | gal_bolle left #darcs | |
| 16:24 | mornfall | kowey: Still no fundraising update? |
| 16:26 | kowey | :-( I'm afraid not |
| 16:26 | mornfall | Bummer. |
| 16:26 | My earphone purchase voyage was a fail. They no longer sell Sennheiser at the shop I tried. | |
| 16:27 | Have to pick different seller. | |
| 16:27 | kowey | I think next year, we need to do the fundraising even earlier |
| 16:27 | probably start in December and aim for the New Year | |
| 16:34 | Igloo | kowey: There was an e-mail from them ysesterday, wasn't there? |
| 16:35 | kowey | there was? |
| 16:36 | huh, could you forward that to me? | |
| 16:37 | maybe the fact that I'm not on the Oversight Committee is why I'm no longer on that list | |
| 16:37 | Igloo | Seems broken if that's the case |
| 16:37 | kowey | sheesh, I should have just called it a Steering Committee and not made things complicated |
| 16:37 | Igloo | kowey d.n? |
| 16:37 | kowey | please |
| 16:37 | Igloo | Sent |
| 16:38 | * kowey | checks his spam filters to be sure... |
| 16:38 | Igloo | Hmm, it does claim to be for "November 2009", though |
| 16:38 | kowey | foiled! stupid flakey uni proxy servers |
| 16:38 | Igloo | But it includes things that happened in January |
| 16:39 | kowey | ok, check spam filter first, then apologise for nagging, then update donations page (notes to self) |
| 16:41 | ilbot2 joined #darcs | |
| 16:41 | Topic for #darcsis now http://www.darcs.net | http://wiki.darcs.net/IRC | latest is 2.3.1 | |
| 16:42 | dcoutts joined #darcs | |
| 16:45 | kowey | wow, folks should really use Google Checkout to pay us |
| 16:45 | lispy | kowey: why is that? |
| 16:47 | kowey | no fees! |
| 16:47 | they must have finally worked out some arrangement being a non-profit | |
| 16:48 | * kowey | gratefully updates the donations page |
| 16:48 | kowey | ... and cannot see the results due to proxy server |
| 16:51 | sm: and now I have a reason to be using hledger ;-) | |
| 17:02 | mornfall | kowey: About the race, OK to take issue1710 for that? |
| 17:02 | Or you are still not convinced it is the same bug? :) | |
| 17:07 | tux_rocker joined #darcs | |
| 17:16 | isaacd joined #darcs | |
| 17:17 | mornfall | kowey: Btw. do you agree that for 2.5, we shall require Cabal 1.8? |
| 17:18 | I could presumably send patches to HEAD to require it now. | |
| 17:18 | tux_rocker: And you could please rollback that --exact-version enhancement from the release branch? | |
| 17:21 | sm | kowey: yay |
| 17:21 | tux_rocker joined #darcs | |
| 18:08 | sshc_ joined #darcs | |
| 18:11 | tux_rocker joined #darcs | |
| 18:13 | sshc__ joined #darcs | |
| 18:37 | arjanb joined #darcs | |
| 19:09 | lispy joined #darcs | |
| 19:26 | darcscommitbot | 19 Jan 19:25 - Encourage more use of Google Checkout (no fees) for donations. (Eric Kow) |
| 19:29 | 19 Jan 19:27 - Tidy up donations page a little bit. (Eric Kow) | |
| 19:34 | mornfall joined #darcs | |
| 19:41 | isaacd joined #darcs | |
| 20:52 | lispy | gah, I really wish my irc client could remember my ignore list |
| 22:54 | Igloo_ joined #darcs | |
| 23:11 | ertai joined #darcs | |
| 23:11 | kolibrie joined #darcs | |
| 23:11 | C-Keen joined #darcs | |
| 23:12 | sshc joined #darcs | |
| 23:13 | kowey joined #darcs | |
| 23:13 | thorkilnaur joined #darcs | |
| 23:35 | sm joined #darcs |
← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text | plain, newest first