| poolie | hi spiv | 00:20 |
|---|---|---|
| spiv | Hi poolie. | 01:08 |
| poolie | hi there | 01:24 |
| === poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for | ||
| === poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | ||
| fullermd | Aaugh, I'm channelling vila. I just spent a good 30 seconds wondering how my bzr got broken so it didn't recognize the 'renvo' command. | 02:08 |
| poolie | :) | 02:08 |
| poolie | there is a bzr-autocorrect plugin | 02:08 |
| fullermd | I'm holding off 'till it corrects bugs in the commits. | 02:09 |
| poolie | :) | 02:14 |
| poolie | spiv i might pull in jml's try_import idea | 02:22 |
| spiv | poolie: ooh, that might be quite nice | 02:23 |
| poolie | mgz: hello? | 07:24 |
| poolie | oh actually i wanted martin vg | 07:39 |
| poolie | so many of them | 07:39 |
| vila | fullermd: glad to see you back ;) | 07:49 |
| vila | fullermd: you want https://launchpad.net/bzr-guess so you get: | 07:49 |
| vila | $ bzr renvo | 07:49 |
| vila | Command 'renvo' not found, perhaps you meant 'revno'? [y/n]: | 07:49 |
| vila | doesn't work for urls so I still needs hhtp to be defined in /etc/services though | 07:50 |
| bob2 | hahaha | 07:51 |
| === Ursinha-afk is now known as Ursinha | ||
| poolie | bonjour vila | 08:50 |
| vila | poolie: hellllo ! | 08:51 |
| poolie | vila, are you actually the pp this week? or was that for last week? | 08:51 |
| poolie | wow i like the pqm queue length graph | 08:52 |
| vila | last week, sorry I wanted to send the mail earlier but... | 08:52 |
| poolie | i think i understand now | 08:52 |
| poolie | np | 08:52 |
| poolie | i was thinking of doing a patch that takes jml's try_import function into bzr | 08:52 |
| vila | hehe yeah, the pqm one is funny to look at for the spikes ;) | 08:52 |
| poolie | probably just copying that file (which is MIT-licenced) | 08:52 |
| vila | hmm, good idea (for the feature), I'm a bit at a loss for the license issues though... | 08:53 |
| poolie | i puzzled about it for a while | 08:53 |
| vila | you can include MIT-licensed stuff in a GPL project ? | 08:53 |
| poolie | i'm pretty sure you can | 08:53 |
| poolie | according to wp | 08:54 |
| vila | yeah, it would make sense (but who is wp ?) | 08:56 |
| poolie | wikipedia | 08:56 |
| poolie | the mit licence text is a bit apparently selfcontradictory | 08:57 |
| vila | bah of course :) | 08:57 |
| poolie | also it's not actually labelled as "this is the MIT licenec" | 08:57 |
| poolie | i recognize the general type of course | 08:57 |
| vila | by the way, could you have a look at my two config-lock mps which are blocking 3 other mps to land ? | 08:58 |
| poolie | yeah | 08:59 |
| poolie | i'm going to stop in a bit; i'll do that now | 08:59 |
| poolie | what are you intending for this week? | 08:59 |
| vila | hmm, good question :) | 08:59 |
| poolie | also, which two branches? i see several | 09:00 |
| vila | config-locks and config-lock-branch | 09:00 |
| vila | the three other are approved but have these ones as pre-requisites | 09:00 |
| poolie | ok | 09:01 |
| vila | sp this week I have a couple of mps I should keep reviewing, a patch-needswork bug, a bit more work on babune, windows corrupts the subunit stream, maverick is still hanging (I suspect paramiko there and/or some subprocess that needs its stderr handled with spiv's last trick), there is also a resolve --take-other bug or two | 09:03 |
| vila | s/sp// wth ? | 09:04 |
| vila | ha, s/sp/so/ gee I can't even understand my tyops no ? I blame fullermd | 09:04 |
| poolie | did you ever see http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html :) | 09:04 |
| vila | s/no/now/ eeerk | 09:04 |
| poolie | (just cause you had 'abit' in your comment) | 09:05 |
| poolie | maverick in the chroot is hanging? | 09:05 |
| vila | hehe, yeah I read a bit a while ago | 09:05 |
| vila | yees | 09:05 |
| vila | there is a bug filed for that, let me see | 09:05 |
| vila | and hardy is hanging too lately (but that's a vm) | 09:06 |
| vila | bug 788235 | 09:06 |
| ubot5 | Launchpad bug 788235 in Bazaar "blackbox.test_serve.TestBzrServe.test_bzr_serve_port_(readwrite|readonly) hangs on maverick " [High,Confirmed] https://launchpad.net/bugs/788235 | 09:06 |
| vila | and it's either paramiko IPv6 issue or a full stderr pipe | 09:07 |
| vila | mwhudson: ping, AIUI you have some experience with using openID for jenkins, I have a couple of related questions | 09:08 |
| poolie | why do the tests use threads? | 09:09 |
| poolie | well, i suppose because you want to check that the lock guards the entire write operation? | 09:11 |
| vila | to test concurrency | 09:11 |
| poolie | :/ | 09:11 |
| poolie | i quite dislike thread tests | 09:11 |
| poolie | they seem to often have spurious failures or hangs | 09:11 |
| vila | I want to test things that are occurring during the lock | 09:11 |
| vila | poolie: I'd like to debug this thread disliking :) | 09:11 |
| poolie | and i'm not convinced they are always a reliable test of the real case | 09:11 |
| poolie | :) | 09:12 |
| vila | concurrency is hard, this doesn't mean threads are bad | 09:12 |
| poolie | so threads give you concurrency that is by default uncontrolled | 09:13 |
| poolie | things will serialize only as much as you specifically require | 09:13 |
| vila | well yes, I test the problematic cases | 09:13 |
| poolie | this means there may be different traces on different executions of the test | 09:13 |
| vila | I could be wrong and miss some, but I have to start somewhere | 09:14 |
| vila | I try to avoid that | 09:14 |
| vila | (assuming that by 'traces' you mean threads could execute the tested code in different order | 09:15 |
| poolie | so that's one way it seems likely to give tests that may pass or fail from one run to the next | 09:15 |
| poolie | another is that our tests tend to make a fair use of monkeypatching | 09:15 |
| vila | that would be a bug in the test | 09:15 |
| poolie | or similar techniques | 09:15 |
| poolie | (which may be an antipattern itself) | 09:15 |
| vila | right, you need a way to inject sync points | 09:15 |
| poolie | and that's going to interact very poorly with threading | 09:15 |
| vila | not if done with care | 09:15 |
| poolie | i do wonder if, if the right sync points exist, you can just do something synchronously there | 09:16 |
| poolie | right, i'm not saying it's impossible to use it correctly, just that it has the possibility of problems that don't occur with synchronous code | 09:16 |
| vila | that's what the tests aim for, make sure one thread always wait for the other | 09:16 |
| poolie | my impression is the majority of our intermittent-failure tests have been concurrency related | 09:16 |
| poolie | either threads or processes | 09:16 |
| poolie | and also that server threads have caused a fair number of other hard-to-eliminate bugs | 09:17 |
| vila | my experience is that fixing them has always mean add an explicit sync | 09:17 |
| poolie | right, probably | 09:17 |
| vila | i.e. we were using uncontrolled concurrency | 09:17 |
| poolie | so in these tests, for example | 09:18 |
| poolie | imbw but i tihnk if the background thread gets an unexpected exception, the test will just hang | 09:18 |
| vila | which ones ? config-lock-branch ? | 09:18 |
| poolie | config-locks | 09:19 |
| poolie | my specific thing would be, why not just at the moment the config is saved, do the other operations in the same thread | 09:19 |
| poolie | if it's totally synchronous, why do you need another threda? | 09:19 |
| vila | hmm, generally, with synchronous code, you can't just stop the execution exactly where you want | 09:20 |
| poolie | what do you mean? | 09:20 |
| vila | in test_writes_are_serialized, I want to stop when the lock is held but the write has just occurred | 09:21 |
| vila | in test_read_while_writing, lock held, write hasn't occurred yet | 09:22 |
| vila | and so on | 09:22 |
| poolie | ok, but by overriding the method you can stop it at exactly those points | 09:23 |
| vila | ? | 09:23 |
| vila | and how would you resume ? | 09:23 |
| poolie | perhaps i'm missing something | 09:24 |
| poolie | i was just going to say that in your c1_save code | 09:24 |
| vila | perhaps me too :) | 09:24 |
| poolie | rather than triggering the Event | 09:24 |
| poolie | just actually do the inspections or other manipulations you want to have happen, ie check that it's locked, that you get contention trying to address it from another object, that you can still read from it | 09:25 |
| vila | hmm | 09:26 |
| vila | you may be right | 09:26 |
| vila | but this has a cheating smell... | 09:26 |
| poolie | ? | 09:27 |
| vila | testing concurrency in a single thread | 09:28 |
| vila | now, these tests are hard to read, some helpers are needed | 09:28 |
| poolie | hm | 09:28 |
| poolie | so the thing is the concurrency we actually care about is between different processes, quite likely on different machines | 09:29 |
| vila | I was kind of waiting for more examples to find them | 09:29 |
| vila | right | 09:29 |
| poolie | anything we do from within a single test process is just an approximation to that | 09:29 |
| * vila nods | 09:29 | |
| vila | but a bit closer than doing it in a single thread | 09:29 |
| poolie | well | 09:29 |
| poolie | how? | 09:30 |
| vila | also, if I define hook for load/save/get/set (which I must do anyway) I should be able to write clearer tests | 09:30 |
| poolie | yes | 09:30 |
| poolie | i was thinking this the other day actually | 09:30 |
| poolie | that perhaps we are too much in the habit of using knowledge about the implementation in writing tests | 09:31 |
| vila | how ? Well, at least each thread is supposed to represent a different process which should help think about the issues | 09:31 |
| poolie | eg overriding methods, rather than putting in hooks | 09:31 |
| poolie | mm | 09:31 |
| poolie | i just don't think it actually does help | 09:31 |
| poolie | many of these things, we actually will have a separate in-memory object for each client | 09:31 |
| vila | indeed, using threads is supposed to help focusing on specifying: what if this process is *here* and this other one try to do X | 09:31 |
| poolie | like your c1 c2 | 09:31 |
| poolie | i think seeing a flattened trace of all of the actions across all actors is perhaps clearer | 09:32 |
| poolie | anyhow | 09:33 |
| poolie | does that help explain my dislike of them a bit more? | 09:33 |
| vila | right, that's where I smell the cheating in the sense that flattening the trace is more arbitrary than setting *one* break point | 09:33 |
| vila | yes | 09:34 |
| poolie | what do you mean by 'one break point'? | 09:34 |
| poolie | one synchronization point? | 09:34 |
| vila | I think it's one area where I lack clarity and fail to explain why we should continue in this direction ;) | 09:34 |
| vila | yes | 09:34 |
| vila | I think about them as breakpoints: stop there while I look around | 09:35 |
| poolie | right, it is more arbitrary | 09:35 |
| poolie | but they're both arbitrary on any particular run of the tests; it's just that the threaded approach is arbitrary in an unpredictable way | 09:35 |
| vila | and also that they don't exist in production, I need them only for tests | 09:35 |
| poolie | it may just once happen to catch something interesting, but perhaps not be able to reproduce it | 09:36 |
| poolie | this isn't good | 09:36 |
| vila | well, it's arbitrary only on the parts I don't care about | 09:36 |
| vila | so the idea is that if all parts we care about are covered by different tests, we're good | 09:36 |
| vila | hehe | 09:36 |
| vila | of course this isn't good | 09:36 |
| poolie | well, but then why is this any better than having a totally deterministic trace? | 09:36 |
| vila | because you still ignore all the other possible traces | 09:37 |
| poolie | .. but you just said they don't matter | 09:37 |
| vila | oh, sorry, wait a sec | 09:37 |
| vila | right, we are both talking about what seems more natural I think | 09:39 |
| vila | I start having some experience with threads so I'm less concerned about the related problems there | 09:41 |
| vila | I still don't know if the same kind of tests can be written without them, it's possible but I have a vague feeling that some cases will be... either harder or less clear | 09:41 |
| vila | Also I didn't focus on clarity for these ones, I just cargo-culted them (we have the same ones for the actual implementation) | 09:42 |
| vila | all of them would benefit from hooks and helpers to make them clearer | 09:43 |
| vila | hmm | 09:43 |
| vila | but what you'd like is a try at not using threads for them I presume ? ;) | 09:43 |
| poolie | http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf "The Problem with Threads" | 09:43 |
| vila | don't you have one with 'solution' in it ? ;D | 09:43 |
| poolie | :) | 09:44 |
| poolie | i'd like to avoid using threads where possible | 09:44 |
| vila | ok, time to reveal the hidden agenda :) | 09:45 |
| vila | I'd like threads to always be hidden behind generators | 09:45 |
| poolie | i think both from a general-approach perspective (like in that paper) and also from the empirical results of tests that have caused problems, this is worthwhile | 09:45 |
| vila | but we're far from that | 09:45 |
| vila | you want to get rid of all the tests that needs a server running in a concurrent thread ? | 09:46 |
| poolie | perhaps ideally yes, but that may be one of the harder ones to fix | 09:46 |
| vila | just reading the abstract of that article, I agree with the problem | 09:46 |
| poolie | i think code like this mp is a really easy case | 09:46 |
| vila | but the solution is to teach developers to deal with it, not hope for a language to magically address it (hint: it won't) | 09:47 |
| poolie | hm | 09:47 |
| vila | so not using threads for simple cases... won't help us to learn | 09:48 |
| poolie | :) | 09:49 |
| poolie | it will help us learn how to avoid them ;-) | 09:49 |
| vila | which will make threads even more scary because we'll have to deal with them on complex cases (and I suffered a lot from that in the thread/socket leaks saga) | 09:49 |
| poolie | hm, maybe | 09:49 |
| vila | bah, avoiding them is easy, we've done that for the last 20 or 30 years | 09:50 |
| vila | now Intel is stuck with adding more cores and we're still not using them properly :) | 09:50 |
| poolie | i think CSP-like architectures are one important way to go | 09:51 |
| vila | I know I've been asking for grace periods on several other topics in the config loom, but I really think we *need* to go forward (not backward) with threads | 09:52 |
| poolie | i think directly creating threads inside application-type code or individual tests does not seem like it's really learning? | 09:52 |
| poolie | why? | 09:52 |
| vila | threads and generators | 09:53 |
| vila | once you start thinking about the data you need to process as generators instead of lists, you're reached the first step. | 09:53 |
| lifeless | but python :P | 09:54 |
| vila | The second step is then to split the data production into parallel producers | 09:54 |
| lifeless | I don't think you want threads in general production code that doesn't strictly require them, do you? | 09:54 |
| vila | GIL is not a concern anymore as soon as your producers involve IOs | 09:54 |
| vila | today ? no | 09:54 |
| vila | tomorrow ? | 09:54 |
| poolie | are you really saying this is strictly needed for configs? | 09:54 |
| poolie | for the first iteration of them? | 09:54 |
| vila | poolie: certainly not | 09:54 |
| vila | but I know of only two sites were threads are explicitly used in tests (here and in mass_import) | 09:55 |
| poolie | there were some others, but i think they've ÿ | 09:56 |
| poolie | now been deleted or rewritten | 09:56 |
| poolie | well, also servers | 09:56 |
| vila | right, I excluded servers (you can't have servers without threads) | 09:56 |
| vila | by the way, if we were to apply your approach to client/server tests.... | 09:57 |
| poolie | well, two things | 09:57 |
| poolie | first, i'm primarily saying "don't use them where it's not necessary" and to test them at the moment it may be necessary | 09:58 |
| poolie | secondly, it is at least conceptually possibly to make synchronous calls into the server code and back out | 09:58 |
| poolie | and that might well make tests more deterministic and easier to debug | 09:58 |
| poolie | so, can we split this? | 10:00 |
| vila | It seems you're still thinking that using threads means non-determinist behaviour, that's may be true by default, but it's unfair to exclude synchronization from the picture, one way or the other you *have* to take it into account. Flattening a concurrent execution is just one way to express the synchronization | 10:00 |
| poolie | please don't use threads to simulate multiple processes in the config tests | 10:00 |
| poolie | yes, that's correct, but i think it's overall the best way | 10:00 |
| poolie | to quote that paper | 10:01 |
| poolie | " deterministic ends should be accomplished | 10:01 |
| poolie | with deterministic means | 10:01 |
| poolie | " | 10:01 |
| vila | argh, would you at least accept a followup for that ? The intent here was to test the new design by re-using the existing tests :-/ | 10:01 |
| poolie | but they're new tests | 10:02 |
| vila | copy/pasted | 10:02 |
| poolie | are they copies of something that is already used? | 10:02 |
| vila | yes, same file | 10:02 |
| vila | same author :) | 10:02 |
| vila | old bug | 10:02 |
| poolie | :/ | 10:02 |
| poolie | a lot of stuff in bzr deals with concurrency across processes | 10:03 |
| poolie | i can forsee the test suite getting pretty gross if that's all done with threads | 10:03 |
| poolie | and these are actually _longer_ than they would be if written without it | 10:03 |
| poolie | i need to go | 10:04 |
| poolie | if you really want to do it as a follow on i could live with it | 10:05 |
| poolie | but, i'd rather just have it fixed now | 10:05 |
| poolie | hopefully the discussion was useful anyhow? | 10:05 |
| vila | useful, yes, I think we still disagree but that shouldn't block progress ;) | 10:06 |
| poolie | well | 10:07 |
| poolie | i'd like to understand some time why you like them for testing | 10:07 |
| poolie | and what you think we should do with them generally | 10:07 |
| vila | sure, I will also think about how to write such tests in a linear way | 10:09 |
| vila | I'm sure there is room for both ;) | 10:09 |
| vila | So there is no need to force them on readers that dislike them when they don't buy us something else | 10:10 |
| vila | poolie: I started on them when I *had* to (leaks). It turned out I gather valuable experience for the udd importer and continued there. I think it's a valuable long term goal we can't really afford to miss (and that's certainly where we need to discuss more). | 10:13 |
| vila | poolie: I also failed to summarize what I learned there (what are the symptoms to look for, what are the common errors, what are the safe tricks, etc) | 10:14 |
| spiv | vila: FWIW, I share poolie's dislike of threads | 10:14 |
| spiv | I haven't read that PDF yet, but one aspect that really troubles me about using them in tests for concurrency is that they are always non-deterministic to some extent unless your analysis of how the states of the concurrent operations interact is perfect. | 10:15 |
| vila | I realize they don't have a good press and I can see that python implementation is really minimal | 10:15 |
| vila | spiv: right to the point | 10:15 |
| spiv | If you fail to notice a race, you get intermittent problems. | 10:16 |
| spiv | Now *finding* problems is great | 10:16 |
| spiv | But we don't put random fuzz tests in our test suite | 10:16 |
| vila | the other face of the coin is: how correct is our implementation regarding concurrency if we don't explore it with tests ? | 10:16 |
| spiv | (Or perhaps I should say "in our unit test suite") | 10:16 |
| spiv | I'm all in favour of writing tests to discover bugs. But then I want small, focused, isolated, deterministic tests that those bugs are fixed as much as possible. | 10:17 |
| vila | but poolie is right that there may be other approaches to explore that | 10:17 |
| vila | me too | 10:18 |
| vila | I think this is can *also* be achieved with threads | 10:18 |
| vila | great power, etc | 10:18 |
| spiv | So by all means write tools to race threads/processes/etc against each other | 10:19 |
| spiv | And let's fix the bugs we find | 10:19 |
| spiv | But not build our primary test suite on that. | 10:19 |
| vila | eerk, generic tools to race arbitrary executions is a no-go, the combinatory (sp?) explosion wall is right there | 10:20 |
| spiv | Same as fuzz testing. | 10:21 |
| spiv | (Which really ought to do…) | 10:21 |
| vila | ? | 10:21 |
| spiv | s/really/we really) | 10:21 |
| spiv | http://en.wikipedia.org/wiki/Fuzz_testing | 10:22 |
| vila | still ? :-/ | 10:22 |
| vila | yeah, same issue | 10:22 |
| spiv | It's absolutely valuable to do that sort of testing. It finds bugs. | 10:22 |
| spiv | But I don't think it pays off to have that in the primary test suite. | 10:23 |
| vila | meh | 10:23 |
| vila | Oh | 10:23 |
| vila | You meant " tools to race threads/processes/etc" but not in the core test suite | 10:23 |
| vila | But the config tests starting the discussion are not fuzzy at all, they *are* deterministic | 10:24 |
| spiv | Then I'd prefer them to not use threads | 10:25 |
| vila | I think I heard the message :) | 10:25 |
| spiv | Because our experience with threads in tests are that they often aren't deterministic even when we think they are. | 10:25 |
| vila | I think I now that quite well... | 10:26 |
| spiv | I'm sure you do :) | 10:26 |
| vila | which is why I'm working on making them clearer by acquiring the knowledge about we fail to recognize the race conditions which requires sync points which in turn make it possible to re-gain determinism where we need it | 10:27 |
| spiv | It's just not possible in general is my suspicion | 10:27 |
| vila | But I'll repeat: "there is no need to force them on readers that dislike them" | 10:27 |
| spiv | Because say you carefully analyse the code and add in all the necessary synchronisation points | 10:28 |
| vila | spiv: well, my experience there is that it's not *that* hard | 10:28 |
| spiv | As soon as someone changes the code it may invalidate that analysis | 10:28 |
| spiv | But you can't know that without redoing it | 10:28 |
| vila | this remark is not specific to threads | 10:28 |
| spiv | (And even then, we get it wrong sometimes) | 10:28 |
| vila | neither is this one :D | 10:29 |
| spiv | Right, but normally mistakes in understanding code doesn't lead to non-deterministic tests | 10:29 |
| vila | concurrency hard, let's have beer (TM lifeless) :) | 10:29 |
| vila | s//is/ | 10:29 |
| spiv | Especially tests with failure conditions that include hanging! | 10:29 |
| vila | yup, but some hangs are easier to avoid than others | 10:30 |
| spiv | As opposed to a simple "state machine didn't end up in state X (and here's the sequence of transition it took)" | 10:30 |
| spiv | If you want to argue we need more experience with threads, I'd argue we need more experience with explicit state machinees :) | 10:31 |
| vila | spiv: you're preaching the choir :) | 10:31 |
| vila | we need more experience with both anyway :) | 10:31 |
| spiv | Well, let's start with the non-evil one then :P | 10:31 |
| vila | spiv: are you suggesting rewriting our thread-based servers on top of asyncore (not over my dead body) ? | 10:32 |
| spiv | asyncore over my dead body too! | 10:32 |
| vila | hehe | 10:33 |
| spiv | asyncore in fact is partly terrible because it doesn't separate out concerns like “state of my protocol decoder” from “state of my IO event loop implemented on select on sockets” | 10:34 |
| spiv | You might notice that the bzrlib.smart.protocol module provides e.g. a decoder that is decoupled from any particular form of IO | 10:35 |
| spiv | You just feed it bytes (however and whenever you acquire them) and it tells you what protocol events they generate | 10:35 |
| spiv | So actually, yes, I do want to replace the vast bulk of uses of SmartTCPServer in the test suite with no threads and no real IO at all, just direct calls into the server logic from the client. | 10:36 |
| spiv | It would have many benefits, like make walking through HPSS logic via pdb much nicer — you'd be able to follow the call from the client into the server's processing, and then follow the response out of the server and back into the client quite smoothly | 10:38 |
| spiv | Whereas stepping through the multi-threaded interactions with pdb if you want to inspect more than one thread at once is quite painful | 10:39 |
| vila | impossible even | 10:39 |
| spiv | Nothing's impossible ;) | 10:39 |
| spiv | But yes, close enough. :) | 10:39 |
| vila | crossing the thread boundary is the key point and you generally don't know where you can safely step a single python line | 10:40 |
| vila | and each time you fail you have to start all over again which is indeed painful | 10:40 |
| vila | spiv: do you know any technic that would allow attaching a pdb session from a console to an existing python process ? | 10:42 |
| vila | hmm | 10:42 |
| spiv | vila: you can attach gdb | 10:49 |
| spiv | which in natty is a bit more python-aware | 10:50 |
| vila | ha, but I really want a pdb session ;) | 10:50 |
| vila | anyway, even that sounds... complex, I'm not sure you can even reach a safe model where each thread can be stepped by a different pdb... so | 10:51 |
| vila | spiv, poolie : I think one misunderstanding in this discussion is that if I indeed recognize that threads are non-deterministic but I try to use them in deterministic ways | 11:06 |
| vila | and I'm not saying the later is easy, but it is achievable (since that's what I did with the thread/socket leaks (I know of at least one more pending bug which is triggering an intermittent failure on babune though)) | 11:07 |
| jam | vila: read the paper from poolie, it is quite interesting, and a nice structuredway of looking at "how do you make threading deterministic, and how can we do better" | 11:07 |
| vila | jam: yup, I'm reading it | 11:08 |
| vila | and I think I'm advocating the same thing: use idioms that ensure determinism | 11:09 |
| vila | this is vastly obfuscated in the config tests, so I can understand the concerns here :D | 11:09 |
| vila | it's just too bad I didn't commit this week-end while diagnosing bug 789167 | 11:11 |
| ubot5 | Launchpad bug 789167 in Bazaar "bzrlib.tests.blackbox.test_serve.TestBzrServe.test_server_exception_with_hook is fragile" [Critical,Fix released] https://launchpad.net/bugs/789167 | 11:11 |
| jam | vila: can you change the topic to make me pp. For some reason Empathy doesn't want me to do anything with /topic or manually editing it. | 11:11 |
| vila | at least two times I had examples where the tests were exhibiting a particular point very precisely and with only a few lines of code | 11:12 |
| vila | jam: poolie already did that earlier | 11:12 |
| jam | vila: hm... empathy still says "vila" for me... | 11:18 |
| vila | jam: blame empathy :) | 11:19 |
| jam | i blame you, but only because I have no other choice :) | 11:32 |
| jam | back in a bit | 11:33 |
| === vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam, yes jam not vila | ||
| === vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | ||
| vila | jam: what topic do you see now ? (I made and revert a change while you were away) | 14:05 |
| jam | I see my name on it now | 14:10 |
| jam | not sure when that was fixed | 14:10 |
| jam | and I restarted in the mean time | 14:11 |
| vila | that probably fixed it | 14:11 |
| vila | poolie's change went out of my scrollback so it was probably during our night, but I saw it this morning when scrolling, irc logs may still mention it (if you're interested) | 14:13 |
| jam | vila: test_writes_are_serialized, why not just use a callback rather than thread locking? | 15:39 |
| vila | primarily and as far as the current proposal is concerned: because I copied/adpated an existing test :) | 15:46 |
| vila | secondarily: It sounded like the easiest way to test concurrency back when I implemented the test for the actual design to fix bug #525571 | 15:47 |
| ubot5 | Launchpad bug 525571 in Launchpad itself "No locking when updating files in ~/.bazaar" [High,Fix released] https://launchpad.net/bugs/525571 | 15:47 |
| vila | and I think the related mp is https://code.launchpad.net/~vila/bzr/lockable-config-files/+merge/33424 and nobody mentioned threads in that time :) | 15:51 |
| vila | at the time ? | 15:56 |
| jam | at the time | 16:01 |
| jam | anyway, I'll try to give a closer look tomorrow, but I will say event based interlocking seems like callbacks would be just as good, and much more straightforward. | 16:01 |
| vila | these tests won't stay in the middle/long term, I don't really care about working on them | 16:04 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === elmo__ is now known as elmo | ||
| jerryb | two bazaar questions: 1. Working on just part of a large project. I have checked out the trunk and want to create a branch for my work BUT don't want to copy the whole trunk. How can I do this with Bazaar? | 18:48 |
| jerryb | Question 2. If I propose a merge of my branch for a project and it is accepted and merged into trunk, can I then remove my branch from launchpad and remove my working copy? | 18:50 |
| === zyga is now known as zyga-afk | ||
| maxb | 1. You can't work with just a subtree of a branch. | 19:04 |
| maxb | 2. Remove from Launchpad: sure, if you want, but why bother? Remove local working copy: of course. | 19:04 |
| cody-somerville | weird. | 19:05 |
| cody-somerville | I'm using the pipeline plugin | 19:05 |
| cody-somerville | I renamed the directory containing the pipeline | 19:05 |
| cody-somerville | and now it isn't working. It says: | 19:05 |
| cody-somerville | bzr: ERROR: Not a branch: "/home/cody-somerville/Projects/live-build/live-build.old/.bzr/pipes/sg-2.x/ | 19:05 |
| cody-somerville | /". | 19:06 |
| cody-somerville | (remove whitespace on second line) | 19:06 |
| maxb | I believe absolute paths to other pipes in a pipeline are stored in the pipe branches config files | 19:06 |
| cody-somerville | this is doing *any* command | 19:06 |
| jerryb | maxb: Thanks! | 19:06 |
| cody-somerville | its add \n/ to .bzr/branch/location for some reason | 19:06 |
| cody-somerville | *adding | 19:06 |
| * cody-somerville will try echoing into the file the current contents with the -n option to see if that fixes it. | 19:08 | |
| cody-somerville | and it does | 19:08 |
| cody-somerville | how strange how that even happen | 19:08 |
| cody-somerville | oh, I know | 19:09 |
| cody-somerville | It was an absolute path so after renaming it, it didn't work anymore. I edited it to fix it, editor of course adds newline | 19:10 |
| cody-somerville | How do I fix this error I get when trying to push a new branch to launchpad?: https://pastebin.canonical.com/47961/ | 19:33 |
| cody-somerville | seems second time is the charm | 19:41 |
| beuno | cody-somerville, yeah, looks like some branches need upgrading | 19:44 |
| === hunger_ is now known as hunger | ||
| === yofel_ is now known as yofel | ||
| * jelmer wavez0rs | 20:54 | |
| === Vorpal_ is now known as Vorpal | ||
| === soren_ is now known as soren | ||
| === maxb_ is now known as maxb | ||
| michaelh1 | Morning. Is there a way to turn revisions into patch files with one patch per revision, and each file automatically named? (Google fails me...) | 23:36 |
| michaelh1 | Apparently git format-patch does something like this. | 23:37 |
| jelmer | michaelh1: hi | 23:37 |
| jelmer | michaelh1: if you have bzr-git installed, "bzr send --format=git" can do something similar | 23:38 |
| jelmer | michaelh1: it's not quite as well polished though | 23:38 |
| * michaelh1 tries it... | 23:40 | |
| michaelh1 | Ah, it blows up with an exception. I am running the dev ppa though... I'll file a bug | 23:41 |
| jelmer | thanks | 23:41 |
| michaelh1 | Is there a way of installing the latest release and latest dev side by side? | 23:43 |
| jelmer | michaelh1: not easily, though I should note that if this is broken in the dev version it's probably broken (or missing) in the release version too | 23:44 |
| === milleja464 is now known as milleja46 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!