| poolie | hi spivvo? | 01:09 |
|---|---|---|
| spiv | Hi poolie! | 01:21 |
| * spiv waits for the cold&flu pills to kick in | 01:21 | |
| === idnaria is now known as idnar | ||
| poolie | hullo there | 03:02 |
| poolie | oh what a shame | 03:02 |
| poolie | spiv are you well enough to talk over the gc cycle thing with me | 03:25 |
| spiv | poolie: probably | 03:26 |
| poolie | here or phone? | 03:26 |
| spiv | Here's probably better given the state of my sinuses | 03:27 |
| poolie | yeah | 03:27 |
| spiv | I might make the odd unpleasant sound :) | 03:27 |
| poolie | :) | 03:27 |
| poolie | so basically, vila implies that we ought to manually use weakrefs between application type objects | 03:27 |
| poolie | even when we don't want actual weakref type behaviour of "i don't care if it's there or not" | 03:27 |
| spiv | I do feel like a missed a memo about that somewhere | 03:27 |
| poolie | me too | 03:27 |
| poolie | hm | 03:28 |
| spiv | I don't really know what the justification is, exactly | 03:28 |
| poolie | so, for example | 03:28 |
| poolie | if python was not capable _at all_ of dealing with cycles | 03:28 |
| poolie | we would need a strict design rule about avoiding them, either by this method or something else | 03:29 |
| poolie | (and i'd mostly prefer the "something else") | 03:29 |
| poolie | but... is it really that bad? | 03:29 |
| spiv | I'm sure it probably helps memory be reclaimed sooner, but I'd really like to see some quantification of how much and how soon. | 03:29 |
| spiv | I guess my big question is: why do we (or at least vila) believe avoiding these cycles is significant benefit? | 03:30 |
| poolie | yes | 03:31 |
| spiv | I can certainly imagine it *might* be | 03:31 |
| poolie | and, secondly | 03:31 |
| poolie | if that problem exists, are weakrefs the best solution to it? | 03:31 |
| spiv | And I could also perhaps be sold on an argument that this forces a bit more thoughtfulness about object lifetimes | 03:31 |
| spiv | Hmm | 03:32 |
| poolie | i think a design rule of "be thoughtful about object lifetimes" makes sense | 03:32 |
| spiv | Weakrefs are certainly the most obvious solution :) | 03:32 |
| poolie | hm | 03:32 |
| poolie | i think the most obvious solution is to refactor the objects so there are no cycles | 03:32 |
| poolie | sometimes this is hard | 03:32 |
| spiv | But I suppose there are other options like splitting apart the objects more — right. | 03:33 |
| poolie | but, here, having both the branch and the config each point to a lock would do | 03:33 |
| poolie | and it doesn't seem that hard | 03:33 |
| poolie | (modulo foreign format and api versioning stuff) | 03:33 |
| spiv | I'm also not sure if the benefit is meant to be for CPython or some other VM | 03:34 |
| poolie | right, obviously this will vary by vm quite a lot | 03:34 |
| spiv | Right. | 03:34 |
| spiv | (And it wouldn't totally shock me to find that weakrefs cause surprising differences in GC behaviour on some VMs) | 03:36 |
| poolie | right, or that they make things much slower | 03:36 |
| poolie | or more precisely access through them may be slower | 03:37 |
| spiv | So I'm quite looking forward to the mail you asked vila to send, in the hope it answers some of these questions. | 03:38 |
| poolie | i might send one first | 03:40 |
| poolie | and he can respond | 03:40 |
| spiv | More mail == more good! At least in small doses :) | 03:40 |
| poolie | lifeless: does that ring any bells with you (https://lists.ubuntu.com/archives/bazaar/2011q2/072972.html) ? | 03:44 |
| lifeless | mmm | 03:47 |
| lifeless | so I think some python implementations are worse than others | 03:48 |
| lifeless | would you like me to reply to the list ? | 03:48 |
| poolie | probably yes | 03:48 |
| poolie | s//yes, unless you'd really rather prefer irc | 03:49 |
| lifeless | list is fine | 03:49 |
| lifeless | you pinged me is all :) | 03:49 |
| poolie | this ws doc is very good :) | 03:57 |
| lifeless | ? | 03:58 |
| poolie | your service analysis proposal | 04:00 |
| lifeless | ah, cool. | 04:00 |
| lifeless | thanks! | 04:00 |
| lifeless | poolie: replied to that gc mail | 04:33 |
| poolie | thanks | 04:33 |
| spiv | Hmm, what version of testtools does PQM have? | 05:24 |
| maxb | Hopefully whatever is codified in bzr-landing-dependencies | 05:44 |
| maxb | http://package-import.ubuntu.com/status/php5.html#2011-05-30%2002:58:42.080261 feels potentially transient - can I get a requeue to check? | 05:51 |
| === maxb 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 | UDD failure ratchet: 487 | ||
| spiv | maxb: hmm, I suspect it's not, but sure. | 05:53 |
| spiv | eglibc also has the same issue | 05:54 |
| maxb | oh | 05:54 |
| maxb | Whoops, I thought this was a unique new one | 05:54 |
| spiv | Oh well, requeued anyway, just in case :) | 05:55 |
| spiv | I think this is a failure revealed by the "remove stale connections from possible_transports" fix | 05:55 |
| poolie | hi maxb | 06:51 |
| poolie | ooh nice topic | 06:51 |
| maxb | :-) | 06:51 |
| maxb | So, somehow, the UDD importer has sprouted another test failure on natty since the sprint | 06:51 |
| maxb | It doesn't feel particularly complex, but I've no idea what's changed to cause it to happen now but not then | 06:52 |
| poolie | hm | 06:55 |
| * maxb wonders why BzrDir.sprout takes a source_branch argument, and then ignores it | 06:57 | |
| spiv | maxb: it doesn't? | 06:59 |
| maxb | It certainly seems to in my vim :-) | 06:59 |
| spiv | Or with less layers of negation: it isn't ignored, it's passed to _find_source_repo | 06:59 |
| spiv | (in trunk; the code was a little different in 2.3, but still not ignoring source_branch IIRC) | 07:00 |
| maxb | whoops. too many matches in close proximity, I didn't spot that one | 07:03 |
| poolie | ok, no more mail for today | 07:14 |
| spiv | maxb: yep, php5 still fails the same way | 07:31 |
| maxb | hm | 07:32 |
| maxb | I have it running locally, and all it has accomplished so far is to make my laptop quite toasty warm to the touch :-) | 07:32 |
| spiv | maxb: I suspect the possible_transports includes a smart transport that is still in use, or something like that | 07:33 |
| spiv | Or that a transport that's not safe to re-use there, e.g. you can't pull from a repo (get_stream) and push back to a repo (insert_stream) on the same smart connection at the same time. | 07:34 |
| spiv | It's interesting to me that it's a condition that's hit so rarely though. | 07:35 |
| maxb | hm. I wish we had a command "bzr delete-tags-not-in-ancestry" | 07:35 |
| spiv | maxb: should be easy enough to write that plugin... | 07:37 |
| maxb | yes. It's more of a case of "Nooooo! Not another mental context switch!" :-) | 07:38 |
| spiv | As always, it'd be good to know what the pre-existing request is in the TooManyConcurrentRequests traceback | 07:39 |
| spiv | Hmm, | 07:39 |
| spiv | I filed a bug about something that would address that a few weeks ago | 07:40 |
| spiv | https://bugs.launchpad.net/bzr/+bug/745477 | 07:40 |
| ubot5 | Ubuntu bug 745477 in Bazaar "Keep a record of recent events from bzrlib subsystems to use in crash reporting" [Medium,Confirmed] | 07:40 |
| poolie | :) | 07:47 |
| vila | hello guys, how are your cycles today ? | 08:02 |
| * vila ducks | 08:02 | |
| vila | kidding, poolie: I answered your email | 08:02 |
| vila | in summary: let's not start a jihad against gc cycles, this has never been my intent | 08:03 |
| vila | spiv: /me blinks, the failure for your start_bzr_subprocess log details was related to testools ?!?! :-( | 08:09 |
| poolie | vila, what do you mean by | 08:21 |
| poolie | " Such discussions tell me that this | 08:22 |
| poolie | > doesn't work. That is far more concerning that using weakrefs or not to | 08:22 |
| poolie | > me." | 08:22 |
| vila | That trying to do minimal implementations to make reviews easier tend to trigger issues unrelated to the proposal slowing down the whole landing | 08:22 |
| vila | There should be a better way to deal with that | 08:23 |
| poolie | hm | 08:23 |
| vila | Either there is an obvious better solution to use and the proposal and that should be done before landing | 08:23 |
| vila | Or the issue should just be discussed and a new proposal will address it | 08:24 |
| poolie | hm | 08:25 |
| poolie | i agree in general | 08:25 |
| vila | I ran into the case (as a reviewer) with i18n : I can't see an obvious way to address an issue and I tell Naoki: sorry, you can't land this | 08:25 |
| vila | I feel really bad saying that :-( | 08:25 |
| poolie | using weakrefs where they're not obviously necessary doesn't seem like the minimal implementation | 08:25 |
| poolie | this is one case where we can probably land things and continue the conversation | 08:25 |
| poolie | as i think you have | 08:26 |
| vila | right, but what do you propose as an alternative, I'm fine doing a followup for that | 08:26 |
| vila | just tell me "I'd prefer this" not "I don't like that" | 08:27 |
| poolie | do you know whether weakrefs increment the referents refcount? | 08:27 |
| vila | the former leaves me with a way to go while the later is just blocking me | 08:27 |
| poolie | i guess no | 08:27 |
| vila | ('you' and 'me' being general, not specific) | 08:27 |
| poolie | well, i think many of your things it's just been "I don't understand this" | 08:28 |
| vila | so, since the proposal, I had several discussions and I'm not sure anymore weakref is as simple as I thought | 08:28 |
| poolie | :) | 08:29 |
| vila | I still think it's less costly than leaving python handle it but... meh, I can live with just a comment saying, hey look, we create a cycle there, gnark gnark, go python have fun | 08:29 |
| poolie | why do you think that? | 08:30 |
| vila | think what ? That it's harder for python to break this cycle than to not have to worry about it ? | 08:30 |
| vila | AIUI python gc will break it, it just requires more work | 08:31 |
| vila | so 'have fun' == 'go, try harder' | 08:31 |
| poolie | i can believe it takes more cycles | 08:31 |
| poolie | is it more, or less, than dealing with the weakref? | 08:31 |
| vila | my gut feeling is that it will be very surprising that it takes less | 08:32 |
| vila | the weakref "just" dereferences once | 08:33 |
| vila | and only for lock/unlock which doesn't occur often either | 08:33 |
| vila | don't | 08:33 |
| vila | let's try again | 08:34 |
| poolie | ok, so it's basically just gut feel | 08:34 |
| vila | For me, here, using a weakref is as prophylactic as using free(ptr) ; ptr = None | 08:34 |
| poolie | hm | 08:35 |
| vila | so I know for sure I won't try to call free again on ptr (free implementations that barf on ptr == NULL (gha NULL not None) should just die) | 08:35 |
| poolie | sure | 08:35 |
| poolie | though, today, in C, with valgrind, that code is no longer such a good idea | 08:36 |
| poolie | or not unambiguously good | 08:36 |
| poolie | but anyhow | 08:36 |
| vila | I can change my habit and forget about it | 08:36 |
| poolie | mm | 08:36 |
| vila | It would make a bit more happy to understand what problems *you* have with weakref here though... | 08:36 |
| poolie | i think having one person adding weakrefs out of habit would be bad | 08:36 |
| poolie | also, relying just on gut feel as to what ought to be faster is pretty unreliable | 08:37 |
| vila | hmm | 08:37 |
| vila | And what is your gut feel here ? | 08:37 |
| poolie | i am trying to avoid making assumptions about how python performs | 08:38 |
| poolie | i think the reasonable base assumption is that it works as documented, ie unreachable objects will be gc'd | 08:38 |
| poolie | if we find a particular case where it's slow, let's work out how to fix it | 08:39 |
| poolie | if we can generalize from evidence that a particular pattern ought to be avoided, great | 08:39 |
| poolie | i don't think we have that evidence yet so let's just write the simplest thing | 08:39 |
| vila | haaaa, that I can buy easily, so what you're proposing is to just use self.branch and be done with it ! | 08:39 |
| poolie | yes, of course | 08:40 |
| poolie | sorry if that wasn't clear | 08:40 |
| vila | gee, no it wasn't | 08:40 |
| vila | but s/wasn't clear/vila didn't get it/ :) | 08:40 |
| spiv | vila: I replied to your mail | 08:40 |
| spiv | vila: to add to the conversation in here, I wouldn't assume that weakrefs are necessarily less work for the GC implementation than a regular reference. They're certainly *different* work. | 08:41 |
| spiv | vila: and yes, +1 to just ignoring cycles and letting Python take care of garbage collecting them. | 08:43 |
| vila | right, so basically we don't know, I'd be happy to write tests so we all get a better understanding but I believe this is not a priority | 08:43 |
| spiv | Right | 08:43 |
| poolie | no, it's really not | 08:43 |
| vila | s/believe/damn well know/ | 08:43 |
| spiv | If we had infinite spare time I'd be curious to know how CPython copes with e.g. 10000s of weakrefs | 08:43 |
| spiv | And of course there's the runtime cost in our code of resolving the weakref.ref instance to the actual object | 08:44 |
| vila | yup, I start to realize weakref *implementation* doesn't match my mental model which roughly was more along the lines of: takes a ref but don't increment the refcount | 08:45 |
| spiv | Right, the implementation has to be more complex than that | 08:45 |
| poolie | so | 08:45 |
| poolie | fewer lines of code, faster reviews, generally | 08:45 |
| spiv | So that if e.g. that object is deallocated and a new one allocated at the same memory location the weakref doesn't accidentally hand you the new object | 08:45 |
| spiv | vila: it may also interest you to know that it took a few releases of CPython before they really worked out all the bugs in how weakrefs interacted with the gc | 08:46 |
| spiv | vila: there's some interesting comments in gcmodule.c and a .txt file near it in the source with some of the gory details | 08:47 |
| poolie | so are we all agreed? | 08:49 |
| awilkins | The default is now urllib2 isn't it? Not curl? | 08:54 |
| jam | morning all | 08:55 |
| awilkins | The reason I'm asking is essentially about SOCKS proxy support, in both bzr and ubuntuone-client | 08:55 |
| poolie | hi jam | 08:56 |
| awilkins | ubuntuone-client at least uses python-libproxy, which means it can cope with a PAC script, but then does not know what to do about SOCKS proxies. Bazaar does not use python-libproxy, and presumable doesn't know what to do about PAC scripts. | 08:56 |
| poolie | hm | 08:57 |
| poolie | requires running arbitrary javascript iirc? | 08:57 |
| awilkins | Both of them are high-profile Canonical projects, written in Python, so it would seem that they could both benefit from coping with SOCKS and doing it the same way... the personal itch I'm scratching is that I have a PAC script I use to switch proxies at work / home, but it doesn't really work very well with many things that don't support SOCKS | 08:58 |
| poolie | without checking, i think we do use urllib2 by default | 08:58 |
| awilkins | poolie, libproxy provides the PAC script runner - ubuntuone-client uses the python binding of this library | 08:58 |
| poolie | patches to use libproxy would be welcome | 08:58 |
| awilkins | poolie, I looked at ways of handling socks with urllib2 and they involve monkeypatching it's socket implementation, I think | 08:59 |
| poolie | :/ probably | 09:00 |
| poolie | how does u1 do it? | 09:00 |
| awilkins | Not to say I want to see a switch to curl - it was far more hassle AFAIR | 09:00 |
| poolie | jelmer: hi? | 09:00 |
| awilkins | U1 doesn't - it only copes with HTTP proxies | 09:00 |
| jam | poolie, spiv, vila, jelmer: time for standup? | 09:01 |
| poolie | yes | 09:01 |
| poolie | spiv gave his apologies | 09:01 |
| poolie | also, jr, hopefully | 09:01 |
| poolie | but jelmer and jr seem to be asleep | 09:01 |
| Riddell | morning | 09:01 |
| jam | Riddell: ^^ | 09:01 |
| poolie | ... or, to have adifferent nick to what i thought :) | 09:01 |
| poolie | hello | 09:01 |
| Riddell | I'm not asleep, I'm the only one in the mumble chatroom | 09:02 |
| poolie | touché | 09:02 |
| vila | hehe | 09:02 |
| awilkins | I guess you boys will be back in 20 mins or so if you are having a stand-up | 09:06 |
| * awilkins contemplates monkeypatching sockets | 09:06 | |
| jam | awilkins: I know there was a python-dev discussion about how hard it is to override the socket interface for the http libs | 09:21 |
| awilkins | jam, A common answer seems to be "PySocksify", which involves patching the whole "socket" implementation | 09:23 |
| awilkins | http://stackoverflow.com/questions/2317849/how-can-i-use-a-socks-4-5-proxy-with-urllib2 | 09:25 |
| awilkins | Does setting socket.socket affect everything, or just the module-local import of socket? | 09:26 |
| bob2 | global | 09:27 |
| maxb | I'd suggest just using a LD_PRELOAD socksifier | 09:27 |
| bob2 | yes | 09:27 |
| bob2 | tsocks or socksify | 09:27 |
| maxb | tsocks is what I use | 09:27 |
| maxb | it has the very useful feature of conditionally socksifying based on destination address | 09:28 |
| awilkins | I use tsocks also, but it's awkward to use it on things that start up with your session. | 09:38 |
| awilkins | Like ubuntuone-client | 09:39 |
| poolie | jam: oh, i guess in particular, reviewing udd mps too would be good | 09:52 |
| poolie | i have some alpha code that gives you a tun device that redirects into socks | 09:52 |
| poolie | i wonder where | 09:52 |
| vila | jelmer: looms push don't know about lossdy, 1 failure (well 3 times the same really) http://paste.ubuntu.com/615680/ | 09:53 |
| poolie | https://code.launchpad.net/~mbp/+junk/tunnel-forward | 09:53 |
| jelmer | vila: I'll have a look - thanks | 09:54 |
| vila | jelmer: great, thanks to you, the hidden question was: will he look or should I ? :D Not urgent | 09:55 |
| === hunger_ is now known as hunger | ||
| jelmer | vila: :) | 09:56 |
| vila | all: false alarm regarding pure python compat, it was just out-of-date extensions | 09:59 |
| poolie | maybe in july we should try the sip conference system | 10:00 |
| jelmer | That might be nice; mumble is still flaky here | 10:04 |
| jelmer | I'll be sure to boot into natty rather than oneiric for next weeks' standup | 10:04 |
| poolie | wow, oneiric already? | 10:11 |
| poolie | is it good? | 10:11 |
| jelmer | It's pretty good, a lot of it is already GNOME3, and it's fairly stable usually | 10:13 |
| poolie | ok; good night | 10:21 |
| jelmer | have a good evening, talk to you later | 10:22 |
| jam | Riddell: I'm back around whenever you are | 10:39 |
| jam | jelmer: Do you have SIP set up already? | 10:39 |
| jam | we could try it (I have it set up here, and I know poolie does) | 10:39 |
| Riddell | I've not used sip | 10:40 |
| jam | Riddell: I found it reasonably easy to set up ekiga, as we have instructions on the canonical wiki | 10:41 |
| jam | I used it for the sprint | 10:41 |
| jam | since paying for 8hrs of phone time would have been bad :) | 10:41 |
| jelmer | jam: I don't have it set up yet, but I might as well have a look now if we're going to use it later | 10:43 |
| jam | jelmer: any chance you can kill jelmer_ ? | 10:43 |
| jam | anyway | 10:43 |
| jam | jelmer: I think poolie would like to switch, but I don't know any time frame | 10:43 |
| jam | mumble tends to work better for large groups (IME) | 10:43 |
| jam | but still has stuff like poor echo cancelation | 10:43 |
| jam | actually, Skype still has the best echo cancelation of any programs I've used | 10:44 |
| jelmer | Skype has worked best for me too, both on Ubuntu and Android | 10:44 |
| jelmer | I find Mumble works reasonably well compared to most SIP apps on Ubuntu, but the Android app is still not quite there yet | 10:45 |
| Riddell | ah, I need to ask sysadmin for a SIP account first | 10:46 |
| Riddell | jam: well shall we chat on mumble? | 10:47 |
| jam | Riddell: mumble's fine for me | 10:48 |
| jam | and yes, you have to email rt@ to get your voip account | 10:48 |
| Riddell | jam: you can't hear me? | 10:49 |
| jam | Riddell: I can't hear you now, it isn't turning your lips read | 10:49 |
| jam | red | 10:49 |
| jam | so it isn't getting your "activation" volume, or whatever | 10:49 |
| Riddell | jam: still no? | 10:50 |
| Riddell | the icon goes red here | 10:50 |
| jam | still nothing here | 10:51 |
| jam | Riddell: I still don't see your lips go red | 10:53 |
| jam | I can try relogging if it is maybe on my side. but you can hear me, right? | 10:53 |
| Riddell | jam: no I can't hear you | 10:53 |
| jam | relogging now | 10:53 |
| jam | Riddell: can you still hear me? | 11:57 |
| Riddell | jam: nope | 11:57 |
| jam | Riddell: ok, I'll reconnect | 11:57 |
| jam | I can hear you | 11:57 |
| jam | Riddell: Did I go silent again? | 12:02 |
| Riddell | yes | 12:02 |
| jam | :'( | 12:02 |
| jam | Riddell: do you have another voice program we can try? | 12:03 |
| Riddell | jam: could try skype | 12:03 |
| jam | Riddell: see private message | 12:05 |
| jelmer | jam, vila, Riddell, poolie, spiv: UDD meeting in #ubuntu-meeting for those interested | 12:11 |
| jam | jelmer: are you sure it is this week? I thought this was the off-week | 12:11 |
| jelmer | jam: Yep, at least according to the wiki page | 12:12 |
| jam | mgz: when you get this, I think we just need a live chat about: https://code.launchpad.net/~gz/bzr/lazy_hook_test_cleanup_785054/+merge/61586 | 12:15 |
| jam | I don't think I can just review the patch | 12:15 |
| sbarcteam | hi guys. | 14:36 |
| sbarcteam | I have failed to commit into a folder I have write access to with bzr. | 14:36 |
| sbarcteam | the folder is owned root:root, and I'm committing as another "regular" user. | 14:37 |
| sbarcteam | BUT | 14:37 |
| sbarcteam | There are ACLs, and the user can create files/folders inside repository's folder with UNIX shell. | 14:37 |
| sbarcteam | Is it possible bzr assumes UNIX permission model and avoids trying operations on files/folders owned/permitted badly by "UNIX" convention ? | 14:37 |
| sbarcteam | I did dig the bzrlib code., | 14:38 |
| spiv | sbarcteam: IIRC bzr doesn't check first (in this scenario), it just attempts to create (trusting that the OS will return a permission error if it doesn't have permission, etc). | 14:39 |
| spiv | sbarcteam: pastebin the error you get? | 14:39 |
| sbarcteam | the specific operation bzr fails upon is this locking LockDir | 14:40 |
| sbarcteam | and it gives me some kind of file. | 14:40 |
| sbarcteam | does lock files creation require special kind of access list entry ?! | 14:40 |
| spiv | Please, paste the text of the actual error into http://paste.ubuntu.com/. Perhaps run the command with -Derror to force bzr to give a traceback too. | 14:42 |
| spiv | That way we can tell which specific filesystem operation is failing. | 14:42 |
| ScottK | I'm having trouble fixing a mistaken tag. It seems no matter what I do I get conflicting tags when I try to push the change. Would someone point me to some documentation about how to handle this (I did what I thought bzr help tag was suggesting)? | 14:43 |
| spiv | ScottK: 'bzr tags -d $source' is presumably listing a different rev for that tag than 'bzr tags -d $dest'? | 14:44 |
| spiv | ScottK: either reapply the tag delete/rename/update directly to dest too, or just delete it in dest then push. | 14:45 |
| ScottK | spiv: Thanks. | 14:52 |
| mgz | jam: I'm around briefly, but out again shortly. I should be around all tomorrow though. | 15:31 |
| jam | mgz: either way | 15:32 |
| vila | spiv: eerk, you're around ! I think I fixed bug #788235 ;) | 15:32 |
| 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 | 15:32 |
| jam | I'm gone the rest of the wek | 15:32 |
| jam | week | 15:32 |
| mgz | okay, let's go over it quickly now | 15:33 |
| mgz | vila and I discussed it a little a few evenings ago, my real problem is I don't get how hooks are meant to work now | 15:34 |
| jam | they aren't (?) :) | 15:34 |
| vila | hehe | 15:34 |
| jam | mgz: so is the issue you aren't sure if hook dicts should be completely empty? | 15:35 |
| jam | or whether we should be able to reset them, or what? | 15:35 |
| mgz | I'm not sure what work needs to be done to get the level of hook isolation tests expect | 15:35 |
| mgz | currently the old code iterates over known hook objects and fiddles with their attributes | 15:36 |
| mgz | and when lazy hooks were added, some (broken) code for emptying and refilling the new _lazy_hooks dict was added | 15:36 |
| mgz | but when trying to make that code do what it appeared to be wanting to, I found 1) it made no difference in practice and 2) when I tried to test with a new hook point rather than a known one, isolation didn't work at all | 15:37 |
| vila | 2) is because you didn't register your hook (not hook point) | 15:38 |
| mgz | I call install_lazy_hook / the other install method | 15:38 |
| mgz | what else needs doing? | 15:38 |
| mgz | anyway, apart from some ugliness in the tests, what I'm trying to verify should be pretty clear from the code | 15:39 |
| vila | the misunderstandings are because we tend to call hooks what the code calls hook points (except for lazy_hook which tends to blurry the lines even more) | 15:39 |
| vila | mgz: have you tried registering your hook ? | 15:39 |
| mgz | I... don't know what that would look like | 15:39 |
| vila | I take that as a no then ;) | 15:40 |
| vila | something like hooks.known_hooks.register_lazy(your_test_module, your_hook, your_hook_class) | 15:41 |
| mgz | okay, so how do I isolate *that* to the test... | 15:42 |
| vila | hehe | 15:42 |
| vila | with a lot of effort ? | 15:43 |
| jam | mgz: presumably you'll have 2 levels of TestCase, right? | 15:44 |
| jam | the inner one which actually does some trivial thing, asserting it is isolated | 15:45 |
| jam | and the outer one as the bzrlib test case | 15:45 |
| jam | the bzrlib case can register the hook point | 15:45 |
| jam | and the inner one then fiddles with registering a test-spceific callable | 15:45 |
| jam | then when the outer one finishes running the inner one, it asserts that everything is cleaned up. | 15:46 |
| mgz | yup. | 15:46 |
| mgz | the current tests have an inner case that installs and calls a hook | 15:46 |
| vila | a hook point | 15:46 |
| jam | mgz: why is it "_clear_hooks" and "_restoreHooks" one of those is misrepresented :) | 15:46 |
| vila | but don't install the hook in known_hooks | 15:46 |
| mgz | installs a hook point and triggers a hook callback | 15:47 |
| mgz | ...some name cleanup really would help | 15:47 |
| jam | mgz: I use the terms HookPoint and callback | 15:47 |
| mgz | then the outer case triggers the hook again, the theory being that the hook callback should then *not* be called | 15:47 |
| jam | I think the code is a bit confused as well. | 15:47 |
| mgz | anyway, I'd like this isolation code to just be test.overrideAttr(_mod_hooks, "_dict_where_all_hook_callbacks_live", {}) | 15:49 |
| mgz | but life isn't that simple. | 15:49 |
| jam | mgz: so are your tests not failing? or failing too much? | 15:52 |
| mgz | yup, both. | 15:52 |
| mgz | the lazy one using the lock hooks doesn't fail | 15:52 |
| mgz | and the new hook point that doesn't get into known_hooks fails by, | 15:53 |
| mgz | never triggering the callback for lazy installation | 15:53 |
| mgz | and always triggering the callback for eager installation (ie, doesn't get cleaned up) | 15:54 |
| mgz | ...I think I have those two the right way round | 15:54 |
| mgz | so, "hooks not in known_hooks are broken" is a fine answer for those two | 15:54 |
| mgz | ...would be nice if the code actually asserted that | 15:55 |
| mgz | anyway, I think I don't want to rewrite the hooks code, so may just delete the bogus tests and the redundant cleanup and see if anything else breaks | 15:59 |
| mgz | okay, I'm off. | 16:04 |
| jam | mgz: have a good evening | 16:09 |
| vila | argh, the new SSD arrived too late :-( The old one died in flames... | 16:33 |
| maxb | literal flames? | 16:35 |
| maxb | :-) | 16:35 |
| fullermd | Probably. Somebody sent it too many nasty emails, and it committed suicide. | 16:39 |
| gour | am i right that qbzr is more advanced than bzr-gtk and therefore recommended to be used withing explorer? | 16:56 |
| gour | i'm familiar with cli using freebsd (and before that linux), but would like to know to recommend right tool for (potential) contributors who are GUI-fans | 16:58 |
| jelmer | gour: yeah, qbzr is definitely more advanced and better integrated into bzr-explorer | 16:59 |
| gour | jelmer: thank you | 17:00 |
| === beuno is now known as beuno-lunch | ||
| gour | cool, it's possible to convert branch into colbranch :-) | 17:33 |
| === deryck is now known as deryck[lunch] | ||
| vila | sigh, lots of lossage, all restored except for babune which I will need to restore from a 3 weeks old backup (of course) and some bits I managed to get back from the ashes | 17:56 |
| vila | now to turn the bits into files... | 17:57 |
| fullermd | So, that counts as a test failure, right? 8-} | 18:00 |
| vila | hehe, thanks, I will end on that, couldn't have dream better ending :) | 18:00 |
| vila | bye folks, have fun ! | 18:00 |
| fullermd | Better hope it's transient, and not repeatable :p | 18:00 |
| === sidnei_ is now known as sidnei | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === zyga is now known as zyga-afk | ||
| === cbz_ is now known as cbz | ||
| === Ursinha is now known as Ursinha-afk | ||
| === yofel_ is now known as yofel | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-nom | ||
| === Ursinha-nom is now known as Ursinha | ||
| EM03 | how is performance now of the system? | 22:54 |
| lifeless | good | 22:55 |
| EM03 | i remember it used to be not to good lifeless | 22:56 |
| lifeless | EM03: sure, it used to be slowed | 23:04 |
| poolie | hi all | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!