| lifeless | spiv: ping | 02:19 |
|---|---|---|
| lifeless | spiv: do we still exit-hard from bzr? and if we do, does that run finally blocks. | 02:19 |
| spiv | lifeless: we do | 02:23 |
| spiv | lifeless: but we do it at the top level, i.e. in the 'bzr' script | 02:23 |
| spiv | lifeless: so there won't be any finally blocks on the call stack, because the call stack will only have one frame on it :) | 02:24 |
| spiv | (There may be finally blocks in generators that haven't run, but those would be unlikely to be run as a result of final garbage collection anyway) | 02:25 |
| lifeless | ok cool | 02:25 |
| lifeless | I wants a review from you | 02:25 |
| lifeless | (waiting for LP API's) | 02:26 |
| lifeless | and bzr | 02:26 |
| lifeless | \o/ | 02:26 |
| lifeless | oh darn. forgot to merge trunk | 02:27 |
| lifeless | I'll do that after, it will be just NEWS to move stuff to the right section | 02:27 |
| lifeless | spiv: https://code.edge.launchpad.net/~lifeless/bzr/fix-terminal-spew/+merge/28024 | 02:28 |
| spiv | Will take a look, thanks. | 02:28 |
| lifeless | thank you | 02:28 |
| lifeless | I guess for correctness, now I've seen that, I really should grab sys.info etc | 02:37 |
| lifeless | and pass it down | 02:37 |
| lifeless | it wasn't obvious that that should be done in Aaron's patch, though the issue still existed | 02:37 |
| lifeless | I'm inclined to not bother until we'd behave differently in an __exit__ call thought. | 02:37 |
| lifeless | spiv: I'd like to land the cleanup stuff soonish :) | 03:40 |
| === naoki is now known as naoki-away | ||
| spiv | lifeless: just finishing review :P | 03:52 |
| spiv | lifeless: just sent | 03:54 |
| lifeless | thanks | 03:55 |
| lifeless | so | 04:01 |
| lifeless | DebugMedium | 04:01 |
| lifeless | I mean | 04:01 |
| lifeless | _DebugCounter | 04:01 |
| lifeless | spiv: turtles all the way down | 04:05 |
| lifeless | context managers have all the same issues as cleanups :) | 04:07 |
| lifeless | ohhh nice | 04:09 |
| lifeless | I can use this to make the test log handling better. | 04:09 |
| spiv | lifeless: tangentially: https://bugs.edge.launchpad.net/launchpad-code/+bug/596726 | 04:09 |
| ubot5 | Launchpad bug 596726 in Launchpad Bazaar Integration "Poor support for merge proposals superseded by different branch (affected: 1, heat: 6)" [Undecided,New] | 04:09 |
| lifeless | thanks | 04:09 |
| lifeless | I was asking in lp-dev earlier about it | 04:10 |
| spiv | lifeless: turtles all the way down, but some of those turtles are in shark-infested waters ;) | 04:10 |
| spiv | I've been meaning to file a bug about that for a while, having a contemporary example to point at was just enough of a spur to make me to it :) | 04:11 |
| lifeless | :) | 04:12 |
| lifeless | so | 04:12 |
| lifeless | you can read my mails | 04:12 |
| lifeless | but top level | 04:12 |
| lifeless | - test log support is the same logic needed to make this object better | 04:12 |
| lifeless | - it looks like a cleanup stack to me | 04:12 |
| lifeless | except for deprecation warnings, they are special. | 04:12 |
| lifeless | I don't think you can reenable them, I mean. | 04:13 |
| lifeless | but I don't want to increase scope more than needed | 04:13 |
| spiv | Hmm, cleanup stack does fit nicely. | 04:13 |
| === naoki-away is now known as naoki | ||
| spiv | It is a pretty large scope creep for this patch. | 04:13 |
| lifeless | I think I'll do a minimal job now and more in a separate patch this avo | 04:14 |
| spiv | My suspicion is that in practice the _DebugCounter's weakref callback will trigger early enough to make the atexit irrelevant | 04:14 |
| lifeless | We should either fix it | 04:14 |
| lifeless | or delete it | 04:14 |
| lifeless | I'm happy to fix it | 04:14 |
| spiv | But I'd want to do some interactive testing or something to be confident about that, rather than just cross our fingers :) | 04:15 |
| spiv | IIRC, and I might not, the atexit was best-effort paranoia, but the goal was that it wouldn't be triggered. | 04:15 |
| lifeless | we almost certainly lead ssh processes if the atexit triggers | 04:16 |
| lifeless | leak | 04:16 |
| spiv | If a bzrlib-wide cleanup stack existed then that would fit much better than atexit :) | 04:16 |
| spiv | I guess you'd make BzrLibraryState an ObjectWithCleanups? | 04:16 |
| lifeless | yes | 04:17 |
| spiv | Cool. I was a bit unsure about the value of this change initially, but I'm totally sold now :) | 04:17 |
| spiv | Btw, you're right about the implicit None return, I think that would propagate the way we want. It's nice that it defaults like that. | 04:18 |
| spiv | I'd forgotten about that :) | 04:19 |
| lifeless | I've added | 04:19 |
| lifeless | return False # propogate exceptions. | 04:19 |
| lifeless | for clarity | 04:19 |
| lifeless | and, I can start adding tests with just a little more work. | 04:20 |
| lifeless | hmm I think I want to put this in a new module soon | 04:20 |
| MTecknology | There is a 'bzr serve' command - is there some incredibly awesome bzr server daemon that might make life for my code server management easier? | 04:23 |
| lifeless | spiv: actually no; I'll decorate. | 04:24 |
| lifeless | spiv: because circular imports. | 04:24 |
| spiv | lifeless: whee | 04:25 |
| ferringb | random query; say I've got an integration branch, w/ tags for specific releases. say said branch has moved on from 0.1, but I need to cut a 0.1.1 | 04:26 |
| MTecknology | Is 'bzr serve' for a server with a single user that holds all the branches and access is granted to anyone? | 04:26 |
| ferringb | I build the changes up, and the new tag in a branch off of 0.1. what exactly is the resultant graph if I try to merge it back? will the tag that gets pulled in actually include the >0.1 changes w/in that branch, or properly be just hte 0.1->0.1.1 branch to the side that occured? | 04:27 |
| spiv | 'bzr serve' doesn't (yet) do any sort of access control. | 04:27 |
| spiv | It leaves that to the OS. | 04:27 |
| lifeless | ferringb: I don't quite understand the question | 04:27 |
| spiv | (well, it restricts access to files inside the directory given to --directory, but aside from that) | 04:27 |
| MTecknology | spiv: I'll be extremely excited when it can - that's coming... next week? | 04:27 |
| spiv | MTecknology: ha, if only :) | 04:28 |
| ferringb | lifeless: possibly because I'm just confusing myself ;) | 04:28 |
| MTecknology | spiv: thanks | 04:28 |
| spiv | MTecknology: not coming soon, sadly | 04:28 |
| lifeless | MTecknology: its not on the roadmap at all | 04:28 |
| lifeless | MTecknology: we'd accept a tasteful patch, I'm sure :) - why do you need it? | 04:29 |
| ferringb | lifeless: ok. got a branch releases are cut from- specifically releases from tag's, right? said branch is already well past 0.1... I need to cut a 0.1.1, aka just minor bugfixes... so I build out a 0.1.1 branch, including the tag. | 04:29 |
| spiv | We may tackle it as part of the 3.0 UI revamp, but even there it's not a great priority. | 04:29 |
| ferringb | lifeless: when I merge it back to the central branch, the 0.1.1 tag will point at just the changeset for 0.1.1? or will it be those changes for 0.1.1 including the other crap in the main branch? | 04:29 |
| * ferringb figures it'll behave, but is just checking | 04:29 | |
| lifeless | spiv: http://pastebin.com/8cC31j76 | 04:30 |
| lifeless | ferringb: perhaps if you sketched this in bzr commands I'd understand :) | 04:30 |
| lifeless | like | 04:31 |
| MTecknology | lifeless: right now I have different user accounts for each team - It's getting kind of messy - not that managing it is hard - I made a plugin to make it easier too | 04:31 |
| spiv | MTecknology: as lifeless says, we'd welcome a patch for it, we certainly aren't opposed to the concept, but it isn't work we're planning to do ourselves any time soon. | 04:31 |
| lifeless | bzr branch -r 0.1 trunk 0.1 | 04:31 |
| lifeless | cd 0.1 | 04:31 |
| lifeless | do stuff | 04:31 |
| lifeless | bzr commit -m '0.1.1 | 04:31 |
| lifeless | bzr tag 0.1.1 | 04:31 |
| lifeless | cd ../trunk | 04:31 |
| lifeless | bzr merge ../0.1.1 | 04:31 |
| lifeless | bzr commit -m 'merge 0.1.1 into trunk' | 04:31 |
| lifeless | ferringb: ^ is that what you mean ? | 04:32 |
| MTecknology | spiv: I think I'm committed to a little too much to learn python right now - but I can put this on the list for when i do learn it | 04:32 |
| ferringb | lifeless: integration ==> more like 0.2, ok? bzr branch integration -r tag:0.1 mine-0.1.1; cd mine-0.1.1; set of bzr merges/commits; bzr tag 0.1.1;cd ../integration;bzr merge ../mine-0.1.1 | 04:32 |
| lifeless | sure | 04:32 |
| lifeless | ok so bzr log -r tag:0.1.1 | 04:32 |
| lifeless | in integration | 04:32 |
| ferringb | lifeless: so with that setup, having done that, if I go an do bzr branch integration -r tag:0.1.1 ; it will come through as just that side branches changes, correct? | 04:32 |
| lifeless | yes | 04:32 |
| lifeless | the tag won't change the revision it points at when it gets copied by a merge | 04:33 |
| lifeless | you need to explicitly run 'tag' again to change the revision a tag points at. | 04:33 |
| ferringb | yep | 04:33 |
| ferringb | just verifying. mostly it's the fact that it's kind of retroactively inserting a dead branch into the target's history is all | 04:34 |
| spiv | lifeless: +1, although separately we should consider what to do about e.g. SFTPLock.__del__ and other __del__ methods, that in principle could trigger any time. | 04:34 |
| ferringb | bad phrasing, but that's where I was curious if bzr would behave properly- haven't tried this yet with it. | 04:34 |
| lifeless | spiv: I'm adding some docs | 04:34 |
| spiv | lifeless: and SFTPLock.__del__ at elast expects trace.warning to work | 04:34 |
| lifeless | ferringb: no worries; I wanted to be sure I answered the right question:) | 04:34 |
| * ferringb wonders why you're not using a weakref finalizer there | 04:35 | |
| lifeless | ferringb: we call os._exit() | 04:35 |
| spiv | ferringb: yes, that would be better, although for the specific issue at hand it won't help | 04:35 |
| lifeless | ferringb: to avoid the very slow gc of (potentially) a GB or more of memory | 04:35 |
| ferringb | figured, more I spotted the __del__ | 04:35 |
| lifeless | oh right | 04:35 |
| ferringb | http://www.pkgcore.org/trac/pkgcore/browser/snakeoil/snakeoil/weakrefs.py <-- might be of interest; specifically the metaclass | 04:35 |
| lifeless | we are largely deleting the __del)) methods | 04:36 |
| ferringb | been experimenting with it lately... basically is the full power of __del__ w/out any of the issues, although it doesn't play perfectly w/ any isinstance checks people use due to it slipping a proxy in | 04:36 |
| spiv | lifeless: for that specific flavour of "warn if __del__ happens on unclean object", I think a "warn_if_bzrlib_still_initialized" method would be an ok solution | 04:36 |
| ferringb | the code there is a bit rough also, mainly since I'm still playing with it to verify there isn't some insane corner case that causes me holy hell | 04:37 |
| spiv | it's not critical if that warning happens in the window between "tear down bzrlib" and "stop the VM" | 04:37 |
| ferringb | lifeless: re: moving away from __del__... same, there just have been several cases where I really needed something like that, and it was way too much of a mess to write a weakref finalizer for each instance. hence coming up w/ the full proxy/metaclass trick instead. | 04:38 |
| lifeless | spiv: well, it could hold onto the library state | 04:38 |
| ferringb | re: that metaclass trick, I'd be curious also if either of you see a flaw with it. there are some variants (most of which require you to specify exactly what the finalizer will access), thus implementing another (doesn't need specifying what is needed for finalizing). | 04:41 |
| spiv | ferringb: Sorry, that code is a bit too gnarly for me to consider properly right at the moment | 04:43 |
| spiv | ferringb: it does sound like an interesting idea... although at the extreme if a __del__ method could be mechanically turned into a weakref callback without any downsides I'd hope that Python would do that automatically ;) | 04:44 |
| ferringb | it can't fully transparently, technically | 04:45 |
| ferringb | roughly... snakeoil has a rather extreme proxy implementation. it lies it's ass off completely- matches special methods, methods, etc. you can spot that the proxy is in use, but it's only in a couple of cpython level cases. | 04:46 |
| ferringb | thats part of the key trick here. | 04:46 |
| spiv | Right. There are edge-cases like how __del__ can resurrect the object. | 04:47 |
| * ferringb notes proxy isn't even getting to that | 04:47 | |
| ferringb | the trick here is that people are using the proxy itself | 04:47 |
| ferringb | when the proxy falls out of memory, the weakref gets fired, which finalizes the proxy target | 04:47 |
| ferringb | said finalization punts the strong refs holding it in memory in the process | 04:48 |
| ferringb | you could do a resurrect I suspect in this case, but it would be hard to actually pull it off by it's nature. when the weakref fires, the bugger is pretty well dead in every scenario I can come up with | 04:48 |
| ferringb | spiv: reason for the special method proxying namely comes down to that the vm would behave differently w/ the proxy... consider if the proxy target has an __iadd__ or something. no special method on the proxy (which the vm decides on it's own), it takes a different route | 04:50 |
| ferringb | hence this particular proxy scanning the target class and making a class w/ all of the necessary special methods in place | 04:50 |
| spiv | That's what I mean: there's a fundamental difference in capability there between __del__ and a weakref callback, so there's a limit to what you can do to automatically replace one with the other. | 04:51 |
| ferringb | resurrection is about the only thing I can think of that is missing. | 04:51 |
| ferringb | literally. because all that's tracked is the proxy falling away (which has zero data), when it goes out of memory it just turns around and tells the real object "hey asswipe, pretend like a __del__ just got ran on ya" (specifically real_object.__finalizer__(), which is whatever __del__ method was defined... moved to said name to avoid the known gc issues w/ __del__) | 04:52 |
| ferringb | rephrasing... resurrection of the proxy itself. the real instance (the target) still is strong ref'ed at that point. | 04:54 |
| ferringb | spiv: roughly that answer your concern? | 04:54 |
| lifeless | spiv: incremental eyeball please; I think this is sufficient to land. rev 5231 | 04:56 |
| spiv | ferringb: possibly! It's a bit much to digest when I'm about to go get lunch :) | 04:56 |
| spiv | lifeless: ok | 04:56 |
| ferringb | spiv: well, if it's of interest feel free to poke me/yell. may not be in here, but am looking to get a second set of high level eyes on that one | 04:57 |
| lifeless | spiv: ok, its up now | 04:57 |
| lifeless | spiv: I thought it had gone, but wifi glitched it | 04:57 |
| * ferringb notes he needs to clean up the implementation and flesh out tests in fully also, but so far it's behaving exactly as expected | 04:57 | |
| spiv | "We hope you enjoy this library." Aw :) | 04:58 |
| lifeless | spiv: :) | 04:59 |
| spiv | lifeless: typo: "my looking it up" should be "by ..." in __init__.py | 04:59 |
| lifeless | thanks | 05:00 |
| lifeless | 12 lines of comment => global variables suck | 05:00 |
| spiv | lifeless: typo: "needs to be alled" should be "... called", same file | 05:01 |
| lifeless | bah | 05:02 |
| lifeless | the table here is too high | 05:02 |
| spiv | lifeless: why the switch to making the caller of initialize have to call __enter__ manually? | 05:02 |
| lifeless | spiv: I wrote some docs that looked odd | 05:02 |
| lifeless | spiv: so I changed them to be nice and then altered the code to match | 05:02 |
| lifeless | bzrlib.initialize is nicer if you can say | 05:03 |
| lifeless | with bzrlib.initialize() as bzrstate: | 05:03 |
| spiv | *nod* | 05:03 |
| lifeless | rather than having to lookup the actual class in use to use the with statement | 05:03 |
| lifeless | as we're changing the contract anyway | 05:03 |
| spiv | I thought that might be it. Seems reasonable, but I wanted to make sure I understood. | 05:04 |
| lifeless | (to must call __exit__ or your log statements are not guaranteed) | 05:04 |
| lifeless | I figured adding in 'please call __enter__' wasn't much worse. | 05:04 |
| lifeless | which reminds me | 05:04 |
| lifeless | we didn't make that explicit in NEWS | 05:04 |
| spiv | lifeless: aside from those two typos in comments, all good. Merge at will! | 05:05 |
| spiv | Oh yeah, feel free to highlight this more in NEWS too :) | 05:05 |
| lifeless | gimme 2 secs | 05:05 |
| lifeless | I'll pastebin and you can shoo to eat | 05:06 |
| lifeless | http://pastebin.com/2tXXy0v9 | 05:08 |
| lifeless | thats the full NEWS diff now | 05:08 |
| lifeless | spiv: ^ | 05:09 |
| lifeless | I'll assume you're off eating and land witha promise to tweak later if needed, in 5 or so | 05:09 |
| spiv | lifeless: +1 | 05:12 |
| lifeless | thanks! | 05:17 |
| lifeless | parthm: hi | 05:48 |
| parthm | lifeless: hi | 05:51 |
| lifeless | parthm: do you want to talk about the regex compilation stuff | 05:57 |
| parthm | lifeless: my personal preference is towards an error based approach. | 05:58 |
| lifeless | great | 05:58 |
| parthm | lifeless: i am ok with warnings for operations like 'st' but specifically 'add' is something i would really prefer to error out. | 05:58 |
| parthm | it sort of reminds me of bug #549310 | 05:58 |
| ubot5 | Launchpad bug 549310 in Bazaar "bzr should not try to guess username but require setting it with whoami (affected: 1, heat: 6)" [Wishlist,Fix released] https://launchpad.net/bugs/549310 | 05:58 |
| lifeless | yes | 05:58 |
| lifeless | I think we should just error across the board, because if the file is damaged, nothing is going to be behaving sensibly anyway | 05:59 |
| lifeless | I've seen error modes in other programs that spew a bunch of junk | 05:59 |
| lifeless | and then say 'oh, XXX is wrong' | 05:59 |
| lifeless | and users just get flummoxed at the sheer volume of info attacking them | 05:59 |
| parthm | lifeless: i agree. i was just typing out my opinion on the mp. hopefully we can have some discussion there and come to an agreement. | 06:00 |
| parthm | i think it may be best to keep the discussion on the mp (rather than the mailing list) as its one of those bikeshed topics :) | 06:01 |
| lifeless | well | 06:01 |
| lifeless | I think it can go either way | 06:02 |
| lifeless | I can give you a detailed review | 06:02 |
| parthm | lifeless: do you prefer the mailing list? | 06:02 |
| lifeless | but it seems to me that we can use much clearer code if we do errors; and its much more visually clear to the user as well | 06:02 |
| lifeless | parthm: MP is fine. | 06:02 |
| lifeless | I'm going to take a break and organise dinner ingredients and so forth | 06:03 |
| lifeless | I'll pop in in a bit to discuss where we go in detail | 06:03 |
| parthm | lifeless: sure. i will update the mp with my comment. i think you and i are in agreement. maybe with some more discussion with jam, poolie and vila we can all agree on one thing :) | 06:04 |
| lifeless | its been stalled for a bit | 06:07 |
| lifeless | I'm patch pilot this week | 06:07 |
| lifeless | so I want to | 06:07 |
| lifeless | - unblock it | 06:08 |
| lifeless | - land something that is clearly better than what we have | 06:08 |
| lifeless | what we have is backtraces | 06:08 |
| lifeless | changing that to a single line or so error will be a clear improvement | 06:08 |
| lifeless | it doesn't preclude a warning based approach in future | 06:08 |
| lifeless | but neither is it contingent on us deciding that we don't want a warning based approach. | 06:09 |
| lifeless | that is to say, we don't actually need agreement here, because it can be changed in the future and we're not making it much different to the status quo | 06:09 |
| lifeless | uhm by agreement I mean 'capital A Agreement' if that makes sense | 06:10 |
| lifeless | we do need agreement that its an improvement over the status quo, but I think that that is triival | 06:10 |
| parthm | lifeless: yes. both (warning or error) are an improvement over the current situation. i can cleanup the error based patch and put it up for review. | 06:12 |
| parthm | lifeless: i have put up my thoughts on the mp. https://code.edge.launchpad.net/~parthm/bzr/300062-invalid-pattern-warnings/+merge/26809 | 06:13 |
| chx | how can i specify the last revision of a branch? HEAD, tip , call it whatever bzr help revisionspec talks about a lot of stuff but i can't find this. | 07:20 |
| Bambi_BOFH | hi all. is this traceback something that would be worth reporting as a bug? http://paste.ubuntu.com/452801/ (i included the yum install, so you can see where the packages are from) | 07:21 |
| Bambi_BOFH | bzr has printed an actual error, but then backtraced anyway | 07:21 |
| spiv | chx: -1 | 07:21 |
| chx | -1 ??? | 07:21 |
| chx | that's like 1 revision before HEAD, no? | 07:22 |
| Bambi_BOFH | (i suspect its died because its on nfs, but thats by the by) | 07:22 |
| spiv | chx: it's HEAD | 07:23 |
| spiv | chx: e.g. compare 'bzr log --line -r -1' with 'bzr log --line | head -1' | 07:23 |
| spiv | chx: FWIW, 'bzr help revisionspec' tries to say so explicitly in the 'revno:' section | 07:24 |
| spiv | Bambi_BOFH: yes, except that I happen to know this bug is fixed in 2.1.2 :) | 07:25 |
| spiv | Bambi_BOFH: but any time bzr gives a traceback is a bug | 07:25 |
| spiv | Bambi_BOFH: (sometimes it's a bug in a plugin rather than bzr itself, but still a bug, and if you're unsure bzr devs are happy to reassign the bug report to the appropriate plugin for you) | 07:26 |
| Bambi_BOFH | spiv: fab! fixed before i found it, the way i like bugs. i'll branch onto local disk until the package is updated. thanks very much :) | 07:26 |
| spiv | Bambi_BOFH: you're welcome :) | 07:26 |
| Bambi_BOFH | :) | 07:27 |
| chx | spiv: hrm, my brain is too convoluted for 'last' | 07:28 |
| Bambi_BOFH | sorry about ask-and-run, but back to work ;) *waves* | 07:29 |
| vila | hi all ! | 07:43 |
| lifeless | hiya | 07:44 |
| === radoe_ is now known as radoe | ||
| vila | sheesh, get away you | 08:11 |
| lifeless | ? | 08:11 |
| vila | xchat spurious launch | 08:11 |
| vila | lifeless: the test suite run on windows in 1h10 now, onlya couple of failures left, not related to the leaks (but masked by them previously) | 08:12 |
| lifeless | cool | 08:12 |
| spiv | Woo! | 08:12 |
| vila | I no longer fail a test that encounter a hung thread (since there are few enough now to let the test suite complete), but I'd like some way to collect the info and report about them | 08:13 |
| lifeless | addDetails | 08:13 |
| lifeless | on the test | 08:13 |
| vila | yeah, you mentioned that, how will they be displayed ? | 08:13 |
| lifeless | and in the result look for a specific name || mime type | 08:14 |
| lifeless | aggregate the info that matches, print in stopTestRun | 08:14 |
| lifeless | I love it when API's come together | 08:14 |
| lifeless | vila: it will look however you want it to | 08:14 |
| vila | and is there some way to collect them to display a nice total in the end..ohh, I need to look at that then | 08:14 |
| vila | but can these summaries be carried by subunit too ? | 08:15 |
| vila | and any idea about making them apparent in hudson ? (And are there different steps/features needed ?) | 08:15 |
| vila | and where is lp-loom-propose so I can run a single command and have multiple mp with their pre-requisite branch set ? :-P | 08:16 |
| lifeless | addDetails will be carried by subunit | 08:17 |
| lifeless | hudson - defer that, possibly depends on how much effort we're willing to put in :) | 08:17 |
| lifeless | for looms I think one large MP may make more sense most of the time | 08:17 |
| lifeless | but certainly you should file a bug on bzr-loom now, saying that it doesn't do what you need with lp-propose - set a task on bzr too saying that lp-propose needs appropriate extension points for loom | 08:18 |
| vila | cough, the whole diff is now ~6000 lines, nobody will review that this century :-) | 08:19 |
| vila | there are some heavy cleanups there (heavy in lines, not intent, aka trivial) | 08:19 |
| lifeless | vila: 'most of the time' | 08:19 |
| vila | yeah, kidding ;) | 08:19 |
| lifeless | vila: I don't mean one diff btw | 08:20 |
| vila | I know, that's what I do generally | 08:20 |
| lifeless | vila: N diffs, one merge proposal. | 08:20 |
| vila | oooohhhh | 08:20 |
| vila | lifeless: but without your annotated review into place... | 08:20 |
| lifeless | what do you think ? | 08:20 |
| spiv | lifeless: N diffs, one merge proposal is an interesting idea. | 08:20 |
| vila | N diffs will be nice, but some diffs overlap | 08:21 |
| spiv | lifeless: I suspect that for sufficiently large work you might end up with more than 1 conversation, though | 08:21 |
| spiv | lifeless: although it's hard to know without the experience of trying it :) | 08:21 |
| lifeless | I'm sure you will | 08:22 |
| vila | yup, I *expect* multiple discussions on the leaking-tests loom | 08:22 |
| lifeless | right now there is no room for experimenting | 08:22 |
| spiv | At the same time, N unlinked conversations is unlikely to be a good match either. | 08:22 |
| lifeless | so we need to write some code ;) | 08:22 |
| spiv | It's interesting, actually. | 08:23 |
| vila | lifeless: regarding the up-thread commits in a loom, you said: don't commit until a conflict occurs (or something close enough) right ? | 08:23 |
| lifeless | near enough yes | 08:23 |
| lifeless | though this week I'm PP, not expecting to do much loom loving | 08:24 |
| vila | lifeless: does that mean you do merges with non-conflicted threads as additional parents ? | 08:24 |
| vila | lifeless: just talking :) | 08:24 |
| lifeless | vila: uhh | 08:24 |
| lifeless | I don't know, does it ? | 08:24 |
| vila | lifeless: not today, but how do you leave a clean committed tree to work with ? | 08:25 |
| spiv | I bet for many things I do that I can a) think of a nice split into N related diffs for review to make the pieces digestible for reviewrs, and b) that I could also guess which parts would tend to generate the most discussion. And I bet the boundaries of a) and b) don't exactly line up. | 08:25 |
| vila | spiv: split more :) | 08:25 |
| lifeless | vila: you don't | 08:26 |
| vila | lifeless: you mean you leave the tree uncommitted ? | 08:26 |
| lifeless | vila: needs to subtract merged-and-not-committed from status/diff and commit | 08:26 |
| spiv | vila: at some point splitting harms reviewability because you lose the sense of how the piece tie together | 08:26 |
| vila | spiv: that's why I want a graph rather than a list of threads | 08:26 |
| lifeless | vila: alternatively, phrased, the tree basis need not match any thread tip, we'd get a commit, then rebase the commit to the thread they committed to. | 08:27 |
| lifeless | vila: or something. | 08:27 |
| spiv | vila: partly that might be solved by a nice way for a reviewer to flip between viewing a piece by itself and viewing it in the integrated whole, or possibly steps in between | 08:27 |
| lifeless | vila: I expect to find many bugs and limitations doing this | 08:27 |
| vila | spiv: certainly | 08:27 |
| spiv | vila: I want a graph of threads too, but I think that's tangential | 08:27 |
| lifeless | spiv: I really don't like the UI that I expect that to generate. | 08:28 |
| vila | lifeless: I'm pretty sure there should be a solution that doesn't involve rebase | 08:28 |
| lifeless | vila: rebase isn't intrinsically wrong | 08:28 |
| spiv | vila: e.g. sometimes you refactor something in a very low level of the patch stack/graph driven by a need near the top of the stack | 08:28 |
| lifeless | avoiding it because its rebase is a mistake | 08:28 |
| spiv | vila: the discussion of "I think this bit should be done differently" really wants to have as context all of that (but still somehow with as little of the rest of the patch stack/graph as possible, to minimise noise) | 08:29 |
| spiv | lifeless: I fear the UI too, but the model is just too irresitably nice I think. | 08:29 |
| vila | I'm not against rebase, but I think it's an incomplete concept. Good enough to use in many cases but being able to filter the ancestry in various parts of the UI should provide the best of both worlds | 08:29 |
| lifeless | vila: filtering non-intentional ancestry is a hack, I think | 08:30 |
| vila | well, the UI should be s/up-thread/go-thread/ | 08:30 |
| spiv | lifeless: My intuition is that a good UI is tractable, partly because the graphs people want aren't going to be *that* complex. | 08:30 |
| lifeless | vila: the reason looms are so noisy is because I once held the view that filtering non-intentional changes wsa sufficient | 08:30 |
| vila | my intuition there is that the loom history should be displayed nicely in qlog (whether it can do that today is not part of this discussion :) | 08:31 |
| spiv | lifeless: It might be interesting to try a limited graph: where you can at have N threads in parallel, but they must all join together again at the next level. | 08:32 |
| lifeless | sounds more like a desire than intuition :) | 08:32 |
| lifeless | spiv: loom supports that today | 08:32 |
| spiv | lifeless: technically, yes | 08:32 |
| lifeless | spiv: albeit manually. | 08:32 |
| spiv | lifeless: the UI doesn't make it very usable | 08:32 |
| vila | lifeless: how so ? | 08:32 |
| lifeless | vila: intuition is a guess | 08:32 |
| spiv | lifeless: but I think that's easily 90% of the cases people (well, me at least :) want more-than-a-linear-stack for :) | 08:33 |
| vila | yes, a guess waiting for concrete steps to become real :) | 08:33 |
| lifeless | spiv: I still haven't heard a case that is uniquely solved by graph that my less-merges stack isn't entirely suitable for | 08:33 |
| lifeless | vila: still, if you replace 'intuition' in your sentence about qlog, with guess, it doesn't parse. | 08:34 |
| vila | spiv, lifeless: Indeed the leaking-tests have threads to prepare a feature and parallel threads that uses this feature in different areas, each of them worth reviewing independently | 08:34 |
| lifeless | spiv: and I'm sure that the UI for a stack is so much nicer than a graph :) | 08:34 |
| lifeless | spiv: if there was a compelling 'I need a graph' argument, I'd be in like a flash | 08:35 |
| vila | s/should/could/,, I meant, each thread should be a vertical line and the whole graph shows when each thread have been taken into account in upper threads | 08:35 |
| lifeless | spiv: there's only one graph based patch manager out there that I know of - topgit - and I hear interesting things about its usability. | 08:35 |
| vila | a stack is fine as long as each node can be a loom too :) | 08:36 |
| spiv | lifeless: can you point me to the less-merges stack parts? | 08:36 |
| lifeless | spiv: no code yet | 08:36 |
| lifeless | spiv: only the discussions at UDS + various back of head thoughts | 08:36 |
| lifeless | spiv: I've been mulling on this a while, but not written it up. | 08:37 |
| lifeless | I should | 08:37 |
| spiv | lifeless: part of what I'm after UI-wise is to make it hard to accidentally mix threads that I as a user consider parallel, and to have that situation shown nicely in show-loom etc | 08:37 |
| spiv | lifeless: please do :) | 08:37 |
| lifeless | spiv: look back a few days in this channel | 08:37 |
| lifeless | I laid out the technical bits to vila | 08:37 |
| lifeless | 'vila.*lifeless.*loom' should be a good search | 08:38 |
| lifeless | spiv: the basic idea is to only record a merge during up-thread when a conflict occurs, and then only with the causative branch. | 08:38 |
| lifeless | spiv: to give someone the full set of merged branches together when they're working in the working tree, using some sleight of hand - e.g. a hidden temporary commit. | 08:39 |
| spiv | lifeless: that would be a nice incremental improvement | 08:39 |
| lifeless | the two things are tied together | 08:39 |
| spiv | lifeless: but I don't think that's enough to really nicely support what I'm thinking of | 08:39 |
| vila | haaa, hidden commit, ok | 08:39 |
| spiv | lifeless: I don't have a concrete use case in front of me to drive my opinion at the moment, though, so it's hard to be sure if I'm right or not :) | 08:40 |
| spiv | lifeless: I need to get back in the habit of using looms regularly :/ | 08:40 |
| spiv | lifeless: but part of the reason I fell out of the habit was the mental friction with forcing a mental DAG of work into a linear stack | 08:41 |
| lifeless | spiv: so, do you routinely have 3+ branches on disk, merged non-stacklike together ? | 08:41 |
| spiv | lifeless: I routinely don't separate out the work at all, because I'm not using looms. I make exceptions for obviously unrelated bits :) | 08:42 |
| vila | routinely, no, but I currently have a loom with 8 threads, 3 of them being parallel | 08:42 |
| spiv | lifeless: my recollection from when I was using looms is that I tended to want trunk->something, then something->X, something->Y, something->Z, then [X,Y,Z]->integrated, and maybe integrated->put-icing-on-the-feature-cake :) | 08:44 |
| vila | spiv: hehe, very close to my current loom :) | 08:45 |
| vila | spiv: something == ServerInAThread, X == http-leaks, Y == smart server leaks, Z == sftp leaks, ice-on-cake == socket leaks aka transport.disconnect | 08:46 |
| vila | X, Y and Z being independent from each other | 08:46 |
| lifeless | spiv: does ->X mean 'X builds on something' | 08:47 |
| lifeless | spiv: or 'something needs X' | 08:47 |
| vila | spiv: by the way, regarding smart server, the tests use a TCP server (no ssh) and seem to create a lot of different (independent) connections, does that ring a bell ? | 08:48 |
| spiv | lifeless: "builds on" | 08:48 |
| spiv | vila: what does "the tests" refer to here? | 08:49 |
| vila | spiv: the observation is that there are a lot of independent threads created (one for each connection) which means multiple client connections not sharing a single connection | 08:49 |
| lifeless | spiv: so, in the form I'm describing you would do the following: | 08:49 |
| spiv | vila: generally speaking each test that uses a smart server makes its own server, and thus its own client connection when get_transport is called | 08:49 |
| vila | spiv: AFAICS all the tests that use SmartTCPServer_for_testing and its variants | 08:49 |
| lifeless | spiv: sitting on something; hack hack hack; bzr commit --to-thread:X | 08:49 |
| lifeless | spiv: which would: | 08:49 |
| vila | spiv: I'm talking about a single server receiving multiple connections (~10/20) for a single tests | 08:50 |
| vila | test, no s | 08:50 |
| spiv | vila: I wouldn't expect that, no | 08:50 |
| vila | spiv: ok, good to know, we may have a bug or two there then | 08:50 |
| lifeless | - make a thread X based on trunk; get the diff against the synthetic base for tree:, confirm the resulting diff, save it. | 08:51 |
| lifeless | once you have X | 08:51 |
| spiv | vila: unless those tests are actually constructing ~10-20 transports from scratch, rather than reusing them | 08:51 |
| vila | spiv: the test code itself doesn't seem to support this idea (and I didn't observe that for other servers) | 08:51 |
| spiv | (i.e. calling get_transport a lot, or passing URLs rather than transports around without also passing possible_transports, etc) | 08:51 |
| vila | spiv: but ssh may mask that somwhow | 08:52 |
| lifeless | then the diff for the next --to-thread would be checked for conflicts against both X and trunk | 08:52 |
| spiv | vila: very few tests involve SSH | 08:52 |
| vila | spiv: if you exclude sftp, yes | 08:52 |
| lifeless | the one after that against X, Y and trunk, etc (probably by walking back down till it gets a hit) | 08:52 |
| spiv | vila: I do, because we are talking about smart server tests :P | 08:53 |
| vila | spiv: sure, I was making sure we were still on the page | 08:53 |
| lifeless | spiv: essentially, to model it simply, I'm talking about keeping all the threads integrated all the time, in a floating set of rebased revisions. | 08:54 |
| lifeless | but never logging or working directly with them in the UI | 08:54 |
| spiv | lifeless: I'm not immediately grasping this concept, or how I'd use it. | 08:54 |
| spiv | lifeless: which may be a good or bad sign ;) | 08:54 |
| vila | lifeless: it's close to the mental model I've built since our last discussion | 08:55 |
| spiv | lifeless: give that it's almost EOD here, probably best to write it up properly somewhere rather than try to clarify it for me on IRC :) | 08:55 |
| vila | (close because it doesn't run yet even in my head ;) | 08:55 |
| vila | and that I'm unclear about which commits should be part of the final result or filtered out or something | 08:56 |
| vila | But I'm sold on the idea that each thread ends up with a cleaner history than today | 08:57 |
| === oubiwann is now known as away | ||
| spiv | lifeless: perhaps I should counter with a proper proposal of the UI I'm thinking of, I *think* it wouldn't be very complex at all, but writing it up will help me find out if I'm missing something. | 08:58 |
| lifeless | spiv: writing it up will require some untinterrupted tuit time | 08:59 |
| lifeless | spiv: so next week, perhaps | 08:59 |
| lifeless | spiv: that said, I would love to see a good description of how you see a graph based one working | 08:59 |
| lifeless | spiv: I would like to note two things of particular concern I'd be looking to understand | 09:00 |
| vila | eeerk, AttributeError: 'ObjectWithCleanups' object has no attribute 'addCleanup' with bzr.dev@5310 py2.6.0 on osx | 09:00 |
| lifeless | merge bases | 09:00 |
| spiv | vila: 'add_cleanup' is the name... | 09:00 |
| lifeless | oh wow | 09:00 |
| spiv | So, um, wow :) | 09:00 |
| lifeless | htf did that pass pqm | 09:00 |
| spiv | what lifeless said. | 09:00 |
| lifeless | I bet I know | 09:00 |
| vila | smart/medium.py line 506 | 09:00 |
| lifeless | I bet _DebugCounter or whatever it is called | 09:01 |
| lifeless | isn't tested. | 09:01 |
| vila | lifeless: exactly | 09:01 |
| lifeless | spiv: so merge bases - how do we avoid lots of criss crosses | 09:01 |
| lifeless | spiv: CLI ui representation of the graph - including a sensible 'merge' or some such | 09:02 |
| vila | http://paste.ubuntu.com/452826 | 09:02 |
| lifeless | not that we should limit ourselves to cli | 09:02 |
| lifeless | but I'd like usable on CLI, for loom, because Ubuntu devs loves their consoles | 09:02 |
| vila | s/addCleanup/add_cleanup/ fixes it | 09:03 |
| lifeless | yes | 09:03 |
| spiv | vila: right. +1 land it :) | 09:03 |
| lifeless | whats that saying about untested code? | 09:03 |
| vila | +1 on using addCleanup instead :) | 09:03 |
| spiv | lifeless: In my head I think I have good answer for the CLI ui | 09:03 |
| spiv | lifeless: not sure why you expect more criss-crosses, though | 09:04 |
| vila | lifeless: that we should thank our testers ? (NOT !) :) | 09:04 |
| lifeless | spiv: I've simulated DAGs by hand | 09:05 |
| lifeless | spiv: and universally had equal-distant common ancestors along each path, leading to criss-cross complains and merge hell | 09:05 |
| spiv | lifeless: interesting | 09:09 |
| spiv | lifeless: I'll have to chew on that. Thanks! | 09:10 |
| vila | spiv: sent to pqm | 09:12 |
| lifeless | spiv: a posible explanation is - consider trunk->X, trunk->Y, (, Y -> something) | 09:28 |
| lifeless | spiv: both X and Y are commonly one-commit on trunk | 09:28 |
| lifeless | spiv: and clearly equally good the next time you merge trunk->something | 09:28 |
| desen | greetings. i want to translate an open source application. can i use the bazaar + launchpad solution with ease ? | 12:53 |
| desen | i have registered a SSH key and i'm really stuck - dunno what to do next | 12:54 |
| desen | T_T | 12:54 |
| Kamping_Kaiser | ask the proejct how they want patches submitted :) | 12:58 |
| spiv | Ooh, a way to reproduce https://bugs.edge.launchpad.net/bzr/+bug/522637 | 14:02 |
| ubot5 | Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 10, heat: 54)" [High,Confirmed] | 14:02 |
| cbz | is there any bzr-svn command to rationalise the cache on windows? | 14:10 |
| spiv | rationalise in what way? | 14:12 |
| cbz | remove the bits that aren't needed/used | 14:15 |
| spiv | You can probably use the sqlite3 command-line tool to VACUUM the cache database, I guess. | 14:21 |
| spiv | Well, to be pedantic, it's a cache, so none of it is *needed*... so you can just delete the svn-cache directory entirely ;) | 14:22 |
| spiv | I don't think there are any commands in the bzr-svn plugin for that. | 14:23 |
| spiv | File a bug asking for them, maybe? | 14:23 |
| * spiv -> zzz | 14:23 | |
| cbz | :) | 14:26 |
| maxb | cbz: How do you define "bits that aren't needed"? | 14:33 |
| MTecknology | spiv: but it's only 08:30 | 14:35 |
| === away is now known as oubiwann | ||
| MTecknology | How hard would it be to make a section in bzr that's available to anyone w/o setting up shared keys? | 15:05 |
| === oubiwann is now known as away | ||
| CaMason | hi guys. Just installed bazaar explorer on windows, and it wont launch | 15:29 |
| CaMason | if I run `bzr explorer`, it says ERROR: No module named trace. You may need to install this Python library separately" | 15:29 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| CaMason | nvm I reinstalled the full package and it works. I'd like to get rid of tortoisebzr though | 15:48 |
| MTecknology | !info python-tracer | CaMason | 16:18 |
| ubot5 | CaMason: python-tracer (source: pytracer): Centralized trace management using sys.settrace. In component universe, is optional. Version 0.2.3-1 (lucid), package size 8 kB, installed size 104 kB | 16:18 |
| lifeless | morning | 17:07 |
| === deryck is now known as deryck[lunch] | ||
| === nlisgo_ is now known as nlisgo | ||
| lifeless | bbiab, taking lynne -> airport | 18:07 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| DanC | broken link on http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html "In the event that we’re wrong and another tool completely takes over, you can use fast-export to switch your code base across if and when another tool better meets your needs." | 18:29 |
| DanC | to http://doc.bazaar.canonical.com/migration/en/data-migration/fast-export.html | 18:29 |
| === deryck[lunch] is now known as deryck | ||
| ciss | hi, i need some help with reverting to a previous revision: i reverted to a tagged revision, 3 revisions ago, but the files changed after that revision are listed as modified. shouldn't their content be reverted to that revision instead? | 18:57 |
| ciss | i used bzr revert -r tag:mytag | 18:58 |
| ciss | ah, ok ... so revert only reverts the file contents, but doesn't "undo" the revisions that followed. how do i "uncommit" each revision since that specific one? | 19:00 |
| ciss | never mind, got it. | 19:02 |
| ciss | grmpf. i uncommitted a few revisions, tried to do an upload, but bzr tells me that the branch and the uploaded tree have diverged, even if i use --full. am i missing something? | 19:04 |
| ciss | got it. one has to use --overwrite. | 19:12 |
| jono | hey all | 20:29 |
| jono | quick q | 20:29 |
| jono | I can push a branch to LP fine, but how do I push something to something other than LP? | 20:29 |
| jono | such as a webserver | 20:30 |
| ciss | jono, "bzr upload" will creates a working tree in the destination | 20:32 |
| jono | ciss, so do I use bzr push or bzr upload? | 20:32 |
| jono | what is the difference? | 20:32 |
| jono | I just have a branch locally and I want to push it regularly to another machine | 20:32 |
| jono | so someone else can pull from it | 20:33 |
| jono | and we both have access to the same sftp destination | 20:33 |
| lifeless | abentley: I hope the tweaks I made to your terminal spew patch are ok with you | 20:33 |
| abentley | lifeless, me too. | 20:33 |
| lifeless | hah | 20:34 |
| jam | jono: if you just want to share a branch via sftp, then ... do so | 20:34 |
| jam | bzr push sftp://host/path | 20:34 |
| jam | you might want to | 20:34 |
| jam | bzr init-repo sftp://host/path/repo | 20:34 |
| jam | first, but it isn't strictly necessary | 20:34 |
| jono | ok cool | 20:34 |
| jono | thanks! | 20:34 |
| lifeless | abentley: I take it that means you haven't looked ? | 20:36 |
| abentley | lifeless, right. | 20:36 |
| lifeless | kk | 20:36 |
| lifeless | please do let me know before 2.2 final is released, I'll be happy to tweak further | 20:36 |
| lifeless | andrew and I went over it with some care though, I'm fairly sure you'll approve | 20:37 |
| abentley | lifeless, actually, I do see at least one problem. The ContextManager protocol demands that you call __exit__ on the return value of __enter__, but you're calling it unconditionally on library_state. | 20:51 |
| lifeless | abentley: oh! we must have misunderstood the protocol. | 20:57 |
| lifeless | I followed what I saw you had done in the ui_factory | 20:57 |
| lifeless | so both of the uses must be wrong | 20:57 |
| lifeless | I'll read the context manager protocol PEP and submit a fixup branch | 20:57 |
| lifeless | abentley: http://docs.python.org/reference/datamodel.html 3.4.10 says you call __enter__ and __exit__ on the same object | 20:58 |
| lifeless | abentley: the return value of __enter__ is bound to the name used in the as clause | 20:58 |
| lifeless | so the example I gave was wrong, but the code itself is fine | 20:59 |
| lifeless | hmm, and __enter__ in both cases could usefully return self, for now. | 20:59 |
| lifeless | thanks for calling that to attention | 21:00 |
| abentley | lifeless, you're right. | 21:00 |
| lifeless | abentley: proposal proposed | 21:09 |
| abentley | lifeless, approved. | 21:11 |
| lifeless | thanks | 21:12 |
| lifeless | abentley: the draft patch you gave me for pqm was very useful | 21:13 |
| lifeless | abentley: the api turned out to be rather more rabbit warren, but it got me started | 21:13 |
| abentley | lifeless, I'm glad. | 21:14 |
| james_w | lifeless: getting mixed up between "testr run --failing" and "testr failing" is very confusing :-) | 21:23 |
| lifeless | james_w: I can imagine | 21:23 |
| lifeless | james_w: we should fix that | 21:24 |
| james_w | show-failing or something would avoid it at least | 21:24 |
| lifeless | james_w: testr st --failing ? | 21:29 |
| lifeless | james_w: I dunno, having a direct simple command is noce too | 21:29 |
| lifeless | james_w: perhaps testr run --auto | 21:29 |
| james_w | I would prefer testr show --failing to st | 21:29 |
| james_w | I would imagine st would be something like "104 tests, 56 failures, 4 skips" | 21:30 |
| lifeless | yea | 21:30 |
| lifeless | stats is pretty basic at the moment | 21:30 |
| lifeless | heck, testr is pretty basic | 21:30 |
| james_w | lifeless: testr run --auto would loop by itself? | 23:01 |
| lifeless | james_w: no, I meant auto as in 'automatically choose the tests to run' | 23:02 |
| lifeless | james_w: so all tests if none are failing, or failures only if there are failures. | 23:02 |
| james_w | right | 23:02 |
| lifeless | james_w: maybe that is what you meant by loop by itself | 23:02 |
| james_w | I was just thinking that a loop around that could be quite useful, depending on how long your testsuite took | 23:02 |
| lifeless | inotify++ | 23:03 |
| lifeless | + a background status window in your editor | 23:03 |
| james_w | for my fast testsuite projects a "run everything as fast as possible, then iterate over failing", in a pane of my terminal would be good | 23:03 |
| james_w | yeah | 23:03 |
| poolie | lifeless, i think requiring people to call __enter__ and __exit__ is a bit ugly in python2.4 code | 23:03 |
| james_w | plus some way to go from path -> test filter to run would be good for larger projects | 23:04 |
| lifeless | james_w: yes, I'm looking forward to the new subunit discovery patch - you saw it needs tweaking right ? | 23:04 |
| james_w | yeah | 23:04 |
| james_w | just been distracted the last few days | 23:04 |
| lifeless | poolie: It is a bit ugly. OTOH I don't know any python 2.4 library users other than loggerhead, and it supports being a plugin now as well. | 23:05 |
| james_w | any thoughts on a way to infer test patterns based on path in testr? | 23:05 |
| lifeless | poolie: being a context manager is quite a bit nicer for python2.5 and up | 23:05 |
| james_w | might seed my thoughts for a flight sometime soon | 23:05 |
| poolie | mm and i guess showing that it's a context manager is worthwhile on 2.4 | 23:05 |
| lifeless | james_w: please; be nice to be friendly for C etc | 23:05 |
| lifeless | james_w: it is perhaps a general problem, and one that a separate tool should solve, testr could use that. Thats perhaps too fine grained: just offering food for thought | 23:06 |
| james_w | yeah, that's where I'm stuck. Would be easy to write a way to call a python function and pass the path, but that doesn't fit too well with .testr.conf | 23:06 |
| james_w | hmm, that would make it easier | 23:06 |
| james_w | perhaps something like urlconf from django if you know it? | 23:07 |
| lifeless | james_w: I'm open to doing a plugin system for testr too | 23:07 |
| lifeless | james_w: vaguely, but not intimately | 23:07 |
| james_w | mapping of regexes -> values, pick the tightest regex that matches | 23:07 |
| lifeless | james_w: another related problem you might enjoy | 23:07 |
| lifeless | james_w: 'I changed file FOO, what tests do I need to run' | 23:08 |
| james_w | plus a way to substitute groups from the match in to the value would be greaet | 23:08 |
| james_w | lifeless: ah, that's exactly the problem I'm considering :-) What were you thinking? | 23:08 |
| lifeless | james_w: many people have stabbed at this problem; theres some prior art I can dig up in python space, but essentially we are perhaps wanting that top level contract | 23:08 |
| lifeless | james_w: a database of call graphs (for python code). something similar for C (using gprof); write a interface, implement the languages we care about; profit. | 23:09 |
| lifeless | james_w: the complex bit is that you need test run instrumentation tunneled through to the db | 23:09 |
| lifeless | james_w: which perhaps subunit can help with. | 23:09 |
| james_w | that's more involved than I was envisaging | 23:10 |
| james_w | much more powerful and hands off, but... | 23:10 |
| lifeless | james_w: precisely ;) | 23:10 |
| lifeless | james_w: so, I've been building towards this for a while, finding good building blocks and making them nice. | 23:10 |
| lifeless | james_w: like testr | 23:10 |
| james_w | yeah | 23:11 |
| lifeless | james_w: I'd be delighted to have a regexp based approximation in testr | 23:11 |
| lifeless | james_w: I'd just like it to have a contract which is fairly close to what one might want for an automated solution | 23:11 |
| james_w | path -> arguments for the test command was what I was thinking, would that fit? | 23:12 |
| lifeless | jam: https://code.edge.launchpad.net/~lifeless/bzr/py3/+merge/28113 btw | 23:12 |
| lifeless | james_w: command to get paths (e.g. bzr st); command to do paths->test id list as string or filename | 23:12 |
| lifeless | james_w: perhaps | 23:12 |
| lifeless | james_w: I suggest some experimentation | 23:13 |
| lifeless | james_w: don't worry about code quality etc for now, just play around and see what tickles your fancy | 23:13 |
| james_w | yeah | 23:13 |
| james_w | I was thinking inotify, but yeah, that split would work ok | 23:14 |
| lifeless | james_w: yes, we will want a way to specify the path[s] explicitly too, both for non-vcs cases and for manual control | 23:14 |
| lifeless | inotify too | 23:14 |
| lifeless | long as we define a sensible contract, one can write backends for inotify, bzr, etc etc as well as paths just being supplied on the command line | 23:14 |
| james_w | I wouldn't want "test id list" though, because I don't want to enumate tests at that level, unless testr had a way to enumerate tests too | 23:15 |
| lifeless | james_w: testr works on enumerated tests fairly intrinsically | 23:15 |
| lifeless | its how run --failing works: it filters the stream to get failure test ids, then uses that to construct the command line to run. | 23:16 |
| james_w | yeah, but I just want to say "given bzrlib/foo.py run bzrlib.tests.test_foo" | 23:16 |
| lifeless | james_w: which is a wildcard on the test id | 23:16 |
| lifeless | james_w: inside bzrlib | 23:16 |
| james_w | lifeless: ok, I thought you meant test id list in the -F sense: an exact list of tests to run | 23:17 |
| lifeless | james_w: I did, and I can see the use for a wildcard here | 23:17 |
| james_w | ok | 23:17 |
| lifeless | james_w: I think supporting both is useful | 23:17 |
| james_w | I'll try and take a first pass at this sometime | 23:17 |
| james_w | I have my head full of another problem right now though | 23:18 |
| lifeless | naturally | 23:18 |
| lifeless | feel free to braindump wishlist bugs | 23:18 |
| lifeless | I don't mind 'it would be nice if frogs could jump | 23:18 |
| lifeless | style bugs | 23:18 |
| fullermd | Do they have to jump? Can they sort of sashay? | 23:18 |
| lifeless | poolie: on context managers | 23:20 |
| lifeless | poolie: we could provide friendly functions that call enter and exit, but I don't think its really a big deal [yet], and doing so may make the API ambiguous further down the track. | 23:21 |
| poolie | mm | 23:21 |
| poolie | i was wondering if it was worth doing the initialization at construction time | 23:21 |
| lifeless | poolie: it is clearly documented, which offsets some of the ugliness in my mind | 23:21 |
| poolie | so that it matters less whether you call enter() | 23:21 |
| poolie | probably not worth it though | 23:22 |
| poolie | iirc this function is new in 2.2 anyhow | 23:22 |
| poolie | yes it is, new in 2.2b1 | 23:22 |
| lifeless | poolie: that would be buggy I think, consider the fixture intent/use separation | 23:22 |
| poolie | what's the correspondance? | 23:23 |
| lifeless | actually, bad analgoy | 23:23 |
| lifeless | bah, analogy | 23:23 |
| poolie | anyhow, | 23:24 |
| lifeless | a better one is perhaps, for testing it would be good to be able to poke at this quite precisely | 23:24 |
| lifeless | and changing global variables in __init__ would likely make that tricky | 23:24 |
| poolie | i think if we're going to use a contextmgr, it really should be an idiomatic contextmgr | 23:24 |
| lifeless | hah, - went to say 'affects me too' from the bug filing form on bug 421360 | 23:26 |
| ubot5 | Launchpad bug 421360 in Bazaar "switch won't let me switch with a pending merge (affected: 1, heat: 0)" [High,Confirmed] https://launchpad.net/bugs/421360 | 23:26 |
| lifeless | and I filed it :P | 23:26 |
| lifeless | poolie: https://code.edge.launchpad.net/~lifeless/bzr/encoding-option/+merge/28126 | 23:38 |
| lifeless | poolie: I'd like to talk about the buffering patch some | 23:53 |
| poolie | on phone atm | 23:53 |
| lifeless | sure | 23:53 |
| lifeless | I mean, its not urgent, just I'd like to explore what we're doing in the area in a concentrated fashion :) | 23:54 |
| poolie | lifeless, what did you change? | 23:54 |
| lifeless | in the encoding-option branch? NEWS - moved to right section, added a mention of the new option, and the years in the new file copyright statements were too broad | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!