| poolie_ | lifeless, well, on a happier note, can i get a kind of architecture review on markdown? | 00:02 |
|---|---|---|
| lifeless | sure | 00:02 |
| === poolie_ is now known as poolie | ||
| poolie | so | 00:03 |
| poolie | it will be behind a flag | 00:03 |
| poolie | istm it might be good to make the rendering be a timeline action? | 00:04 |
| poolie | or would that be redundant with just profiling it | 00:04 |
| lifeless | if its really 200ms per text | 00:04 |
| poolie | it could possibly go in memcached but perhaps that could be done later | 00:04 |
| lifeless | I think we'll have issues | 00:04 |
| lifeless | ugh no, memcached is very much not the right hammer here | 00:04 |
| lifeless | so structurally whats going on is that you're generating html out of some content, which is exactly what the template engine does | 00:05 |
| === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugtasks: 292 | ||
| lifeless | we're then embedding that result literally in the larger template | 00:05 |
| wgrant | Hmm? memcached would be reasonable here, I think. | 00:05 |
| poolie | the caching could be done in the template | 00:06 |
| poolie | s//controlled by | 00:06 |
| poolie | if it really is 200ms that's almost infeasible | 00:06 |
| lifeless | wgrant: one word: bug comments | 00:06 |
| wgrant | lifeless: Myes? | 00:06 |
| poolie | ow | 00:06 |
| lifeless | wgrant: a situation where we timed out *because* we used memcache | 00:07 |
| lifeless | wgrant: and a place where markdown is [eventually] desired | 00:07 |
| wgrant | Right, but it was timing out because the pages sucked, and there was absolutely minimal benefit to using memcache there. | 00:07 |
| wgrant | It would need testing, but I think it could be useful if implemented properly. | 00:08 |
| lifeless | so we want to use memcache on things that are both expensive to generate and able to be generated once for all viewers | 00:08 |
| wgrant | And if the page didn't suck already. | 00:08 |
| lifeless | but more so we want the first hit to be fast | 00:08 |
| poolie | wgrant, tangentially, re your email bug, i will add a test that forces an email.Header into it and check its handled correctly | 00:08 |
| lifeless | so we either want preloading (with change updates) or we want rendering to be so fast that memcache communication overhead is slower. | 00:08 |
| lifeless | poolie: you could timeline it yes; if there are questions over its performance thats a great way to ensure we have data. | 00:09 |
| poolie | so if it's really that slow | 00:09 |
| poolie | that might be a problem for applying it to all bug comments | 00:09 |
| lifeless | poolie: as there seem to be questions around it, perhaps you want to pull on that thread a little first | 00:09 |
| poolie | there is python-markdown2 which claims to be an unspecified amount faster | 00:09 |
| lifeless | poolie: so that we don't have markdown for home pages and then get stuck on bug comments | 00:09 |
| poolie | exactly | 00:09 |
| lifeless | poolie: I'm fine with landing with a restrictive feature flag to find out early adopter issues | 00:10 |
| poolie | right | 00:10 |
| poolie | performance to some extent we can test offline | 00:10 |
| poolie | there is also this thing that api clients will now see markdown in the results | 00:11 |
| poolie | i think that's ok | 00:11 |
| poolie | it's close enough to text | 00:11 |
| poolie | if they eventually want to start rendering it, they can | 00:11 |
| lifeless | so will folk not behind the feature flag | 00:11 |
| poolie | right | 00:11 |
| poolie | so people probably don't want to go too crazy til it's widespread | 00:11 |
| lifeless | I think timelining it for now is a good idea | 00:12 |
| lifeless | till the issues/concerns are put to rest | 00:12 |
| poolie | oh hang on | 00:12 |
| poolie | rvb's measurement is actually that it's 240µs. | 00:13 |
| poolie | isn't it? | 00:14 |
| poolie | yep | 00:16 |
| poolie | that's not so bad then | 00:16 |
| poolie | but, worth testing | 00:16 |
| lifeless | no, its not | 00:16 |
| lifeless | the timeit CLI reports time per loop | 00:16 |
| lifeless | the timeit python API reports total time | 00:17 |
| poolie | but each iteration of the loop formats it 1000 times | 00:17 |
| lifeless | ah | 00:17 |
| lifeless | let me have a play | 00:17 |
| poolie | ./bin/py -m timeit -vv -s 's="a *b*\n" ; import markdown; md = markdown.Markdown(safe_mode="escape",extensions=[ "tables",])' 'md.convert(s);' | 00:17 |
| poolie | 1000 loops, best of 3: 231.1 usec per loop | 00:17 |
| poolie | ./bin/py -m timeit -vv -s 's="a *b*\n" *100; import markdown; md = markdown.Markdown(safe_mode="escape",extensions=[ "tables",])' 'md.convert(s);' | 00:17 |
| poolie | 100 loops, best of 3: 7.816 msec per loop | 00:18 |
| lifeless | btw, choosing the packaged version is irrelevant to LP: we need things on lucid, and eggs are much more reliable than debian packages (because of version migration) | 00:18 |
| poolie | yep | 00:18 |
| poolie | i have it as an egg | 00:18 |
| poolie | was just using 'packaged' as a very rough metric for 'supported/popular/worthwhile' | 00:18 |
| poolie | also kind of handy for things like this | 00:18 |
| lifeless | ok, yes, <1 ms is good | 00:19 |
| lifeless | don't timeline it | 00:19 |
| lifeless | poolie: you know about bin/py ? | 00:19 |
| lifeless | bin/py -m timeit ... | 00:19 |
| poolie | see the lines i pasted? | 00:20 |
| lifeless | heh, I do know | 00:20 |
| lifeless | *now* | 00:20 |
| * lifeless slaps his fingers | 00:20 | |
| poolie | :) is ok | 00:20 |
| lifeless | the scaling on longer strings is a little worrying | 00:20 |
| lifeless | we would have trouble at 8ms per bug comment, for instance | 00:21 |
| poolie | ok so if we say a large comment has about 100 lines of text, it's about 28.69ms to convert it | 00:21 |
| poolie | hm, with no actual markdown in it, 100 lines, 1.798ms | 00:21 |
| lifeless | so 100 comments is 2.8 seconds, which is 50% of the budget for an entire load | 00:21 |
| lifeless | anyhow, no Big Red Flags | 00:22 |
| poolie | one 100 line code block, 0.4ms | 00:22 |
| poolie | strangely | 00:22 |
| lifeless | it needs some love I guess | 00:22 |
| poolie | arguably typical 10 line comment, 0.3ms | 00:22 |
| lifeless | it might have some pathological cases that can DOS us | 00:22 |
| poolie | yeah | 00:22 |
| lifeless | OTOH one laptop can DOS us, so not goig to worry about this yet | 00:22 |
| poolie | especially because the parsing is regexps | 00:23 |
| poolie | <lifeless> wgrant: one word: bug comments | 00:23 |
| poolie | can i buy another word? | 00:23 |
| lifeless | timeouts :) | 00:23 |
| poolie | oh i see | 00:23 |
| mwhudson | yeah | 00:23 |
| mwhudson | was going to say that, i think | 00:23 |
| poolie | this is the "you eventually fall off a cliff" case? | 00:23 |
| lifeless | ⸘that⸘ | 00:24 |
| mwhudson | github run pygments but clearly limit the highlighting of any segment to say 2s | 00:24 |
| mwhudson | would be nice to have that sort of thing | 00:24 |
| mwhudson | (also for pygments...) | 00:24 |
| lifeless | poolie: no, it was that we spent more time in memcache chatter than in rendering the comments; we also retrieved them from the DB no matter what | 00:24 |
| poolie | yes, that can hook in | 00:24 |
| poolie | huh | 00:24 |
| lifeless | poolie: very poor interactions between late evaluation and a chatty protocol | 00:24 |
| poolie | so, the other approach is to do it on the client side | 00:24 |
| lifeless | poolie: nowadays memcache is just turned off, and things are much faster. | 00:25 |
| poolie | which possibly makes rendering the page actually easier on the server, if we can reliably detect to just send json not html | 00:25 |
| wgrant | Someone want to review https://code.launchpad.net/~wgrant/launchpad/observer-merging/+merge/82952? | 00:41 |
| StevenK | wgrant: Line 68 of the diff -- why do you bother pulling in store? | 00:42 |
| wgrant | StevenK: Because I forgot to remove that line when I replaced the check just now. | 00:43 |
| StevenK | Haha | 00:43 |
| StevenK | wgrant: That's my only niggle, r=me | 00:43 |
| wgrant | IAPGS.get only came into existence late last night. | 00:43 |
| wgrant | So I previously queried directly. | 00:43 |
| wgrant | Thanks. | 00:43 |
| lifeless | is http://appbuntu.com a legit site or a spammer ? | 00:43 |
| StevenK | lifeless: NXDOMAIN ? | 00:44 |
| wgrant | WFM | 00:45 |
| lifeless | StevenK: get a better DNS resolver ? | 00:45 |
| StevenK | Oh, *buntu*, not *ubuntu* | 00:45 |
| StevenK | Transcribe error | 00:45 |
| lifeless | UI fail :P | 00:45 |
| StevenK | Well, I didn't click the link, I typed it out from memory so I could whois it | 00:46 |
| StevenK | And my memory fails | 00:46 |
| StevenK | Often | 00:46 |
| * StevenK waits for lifeless to say "Frequently" | 00:46 | |
| lifeless | there is a link to http://appbuntu.com/2011/04/mengapa-ubuntu-menggunakan-launchpad/ in the blog, marked as spam but it doesn't look like spam to me | 00:47 |
| lifeless | trying to determine if it is / isn't | 00:47 |
| lifeless | StevenK: I did but you've clearly forgotten :P | 00:47 |
| StevenK | I was about to suggest wgrant, but I suspect wgrant is too young for Gilbert & Sullivan | 00:47 |
| lifeless | there was also an andi comment, but francis has address that separately, so I just deleted it | 00:48 |
| poolie | lifeless, memcached is just off across the board? | 01:21 |
| poolie | in a flag i think? | 01:21 |
| lifeless | more or less | 01:22 |
| lifeless | I need to go through and rip out the inappropriate uses of it | 01:22 |
| poolie | hm | 01:22 |
| poolie | the rules ui could do with some love too | 01:22 |
| lifeless | any new use needs rather deep thought about what its actually saving | 01:23 |
| lifeless | there is currently one reasonable use of memcache in LP - the front page blog contents | 01:23 |
| lifeless | the rest have deep flaws (due to the interaction between views, eager loading and late evaluation), as well as various cachability rule interactions | 01:23 |
| poolie | do you have a rule of thumb for how long it takes to query it? | 01:24 |
| lifeless | between 1 and 5ms | 01:24 |
| lifeless | sometimes up to 12ms | 01:24 |
| StevenK | lifeless: TBH, since we aren't using it, I feel we should cache the blog contents differently and rip it out | 01:27 |
| lifeless | StevenK: I'm open to that. | 01:27 |
| lifeless | StevenK: OTOH it is a reasonable cache engine and I wouldn't want to reinvent a cache just because we haven't got much use for it | 01:27 |
| poolie | possibly comments could do it reasonably well | 01:29 |
| poolie | i mean, markdown could use it | 01:29 |
| poolie | if the rendering was independent of the request (including the user)\ | 01:29 |
| poolie | and keyed off the place the text comes from, eg comment N on bug M | 01:29 |
| poolie | anyhow, later | 01:30 |
| mwhudson | one of the problems with the tal:cache stuff (it seems to me) is that it doesn't let you use multi_get at all | 02:06 |
| wgrant | mwhudson: I've been assuming that's the entire performance problem we saw, yes. | 02:09 |
| wgrant | Making a thousand round-trips is not cheap, just like with postgres. | 02:10 |
| poolie | mwhudson, meaning one api call that gets many results? | 02:10 |
| poolie | s/api/network | 02:10 |
| mwhudson | poolie: yes | 02:10 |
| mwhudson | the usual 'don't do potato programming' sort of thing | 02:11 |
| poolie | sure | 02:11 |
| poolie | it seems like in theory that could be hooked in to tal | 02:11 |
| poolie | depending on what it exposes | 02:11 |
| wgrant | It would be nice if we could do multi-stage renders :/ | 02:12 |
| mwhudson | you'd have to defer rendering parts of the template, or walk the template twice or something wouldn't you? | 02:12 |
| wgrant | But TAL doesn't make that easy. | 02:12 |
| wgrant | So we would probably have to do something like the current preloading. | 02:13 |
| wgrant | Where we work out what we need beforehand, and poke it all into the caches. | 02:13 |
| huwshimi | poolie: Not sure if you saw my note about adding a test for the tag ordering (I had to rush offf shortly afterwards). Just wanted to check if it looked ok (line 59 onwards: https://code.launchpad.net/~huwshimi/launchpad/tag-cloud-removal-709009/+merge/81689) | 02:14 |
| poolie | hi huw | 02:14 |
| wgrant | Rather than the probably more sensible setup of partially rendering the template, finding all the markdown that needs to be rendered, pulling stuff out of the cache, rendering what's left, filling in the template. | 02:14 |
| huwshimi | poolie: Hey | 02:14 |
| poolie | huwshimi, can you look at / think about the markdown branch too | 02:15 |
| poolie | i don't know if it especially needs anything from you | 02:15 |
| huwshimi | poolie: No problems | 02:15 |
| poolie | is that screenshot up to date? | 02:15 |
| mwhudson | wgrant: do you know a template engine that lets you do that sort of thing? | 02:16 |
| wgrant | mwhudson: No | 02:16 |
| huwshimi | poolie: That screenshot is up to date, yes | 02:17 |
| huwshimi | poolie: This is the branch: lp:~mbp/launchpad/391780-markdown ? | 02:17 |
| poolie | yep | 02:17 |
| poolie | the test looks good to me | 02:17 |
| poolie | mm | 02:17 |
| poolie | you could add a comment specling out the meaning | 02:18 |
| poolie | ie that the most popular tags come firstn | 02:18 |
| poolie | perhaps it's obvious | 02:18 |
| huwshimi | poolie: No, you're right | 02:18 |
| huwshimi | poolie: Thanks | 02:18 |
| rick_h_ | poolie: thanks for the link and update in the bug. That's a different place than I was looking.working with. | 02:19 |
| rick_h_ | I had been looking at https://bugs.launchpad.net/launchpad/+bug/814696 and the link "Diff: 45 lines..." | 02:20 |
| _mup_ | Bug #814696: Link to show inline diffs in merge proposals should be green <qa-ok> <trivial> <ui> <Launchpad itself:Fix Committed by rharding> < https://launchpad.net/bugs/814696 > | 02:20 |
| lifeless | mwhudson: wgrant: poolie: also that we don't want to do DB lookups for stuff we're then going to get from memcache. | 02:20 |
| lifeless | mwhudson: wgrant: poolie: the whole template-view interaction is brittle here | 02:20 |
| mwhudson | yeah | 02:20 |
| wgrant | Yeah. | 02:20 |
| wgrant | Particularly since the BugMessages are actually subviews. | 02:20 |
| mwhudson | i've been very suspicious of passing anything other than dumb data to templates | 02:20 |
| wgrant | Doing a pipelined render would be much nicer, but no :( | 02:20 |
| mwhudson | s/been/become/ | 02:21 |
| poolie | ok | 02:21 |
| poolie | we can worry about it later | 02:21 |
| poolie | or not | 02:21 |
| poolie | :) | 02:21 |
| poolie | huwshimi, i'm not a very reliable reviewer for the js stuff | 02:21 |
| huwshimi | poolie: No problems. I spent quite a bit of time chatting to wallyworld about that anyway | 02:22 |
| poolie | aside from that it looks good | 02:22 |
| poolie | i'm keen to see the results live | 02:22 |
| poolie | good on you for deleting those horrible doctests | 02:22 |
| poolie | have a badge :) | 02:22 |
| poolie | what is the actual rule, if any, for tal indentation? | 02:23 |
| wgrant | Nothing special for TAL. You mean XML/HTML? | 02:23 |
| poolie | yes | 02:24 |
| rick_h_ | huwshimi: any reason not to make the taglist stuff a module with ATTR, initialize, etc? | 02:25 |
| wgrant | huwshimi: CSS is somewhat broken. | 02:25 |
| wgrant | huwshimi: https://bugs.qastaging.launchpad.net/launchpad/+bug/1234 | 02:25 |
| _mup_ | Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 > | 02:25 |
| wgrant | huwshimi: status/importance are blue | 02:25 |
| poolie | huwshimi, can i see your current theme things some time? | 02:26 |
| huwshimi | rick_h_: I'm not quite sure what you mean, care to elaborate? | 02:27 |
| huwshimi | wgrant: ick! | 02:27 |
| huwshimi | poolie: Sure, I haven't had a chance to work on it recently, but I'll try and push out a first stage to show people soon | 02:28 |
| rick_h_ | huwshimi: ok so you declared a namespace, but normally we seem to be using YUI modules, extending base or some decendent of that. For instance, see lp/app/javascript/picker/picker.js | 02:28 |
| lifeless | mwhudson: excellent, the meme is spreading | 02:28 |
| rick_h_ | see http://yuilibrary.com/yui/docs/base/ for the YUI docs of the pattern | 02:28 |
| rick_h_ | so you'd end up with more var tagcloud = new TagCloud({any: settings}); | 02:29 |
| rick_h_ | it allows for others to extend and customize later, more OOP version of things | 02:30 |
| huwshimi | rick_h_: No reason other than ignorance | 02:30 |
| rick_h_ | huwshimi: ok, sorry, a bit new. But if you wanted review I'd definetely say to head down that route. | 02:30 |
| rick_h_ | overlay for instance is a good example | 02:31 |
| rick_h_ | there's a base, and several extentions that are used | 02:31 |
| rick_h_ | extensions that is | 02:31 |
| wgrant | huwshimi: Ah, the stylesheets are combined in the wrong order | 02:31 |
| huwshimi | rick_h_: Thanks I'll take a look. This was mostly me pulling the code out of a template and adding a few things/getting it working again, so I didn't really put enough thought into what I was doing :) | 02:32 |
| rick_h_ | huwshimi: totally understand, been there done that | 02:32 |
| wgrant | typography.css is included later, and it sets link colours that override colours.css | 02:32 |
| huwshimi | rick_h_: But, I'll take another look | 02:32 |
| wgrant | huwshimi: Should I roll this back? | 02:32 |
| wgrant | Or do you want to fix quickly? | 02:32 |
| rick_h_ | awesome, let me know if you need a hand with anything and I'll be happy to help in the morning | 02:32 |
| huwshimi | wgrant: I can fix quickly | 02:32 |
| huwshimi | rick_h_: Thankyou | 02:32 |
| * rick_h_ is heading towards bed here | 02:33 | |
| wgrant | huwshimi: Needs to be landed in the next three hours, so not completely urgent. | 02:33 |
| huwshimi | wgrant: That's ok, I'm on it | 02:33 |
| wgrant | Thanks. | 02:34 |
| huwshimi | wgrant: What should I do with these changes? Commit to the same branch and lp-land? | 02:43 |
| wgrant | huwshimi: Ideally customising the commit message in lp-land to something sensible, but yeah, that sounds reasonable. | 02:44 |
| huwshimi | oh breakages | 02:47 |
| wallyworld___ | huwshimi: rick_h_: with the yui module vs namespace thing, what is used depend on the heritage of the code. if it came from lazr-js, then it tends to extend the yui component framework. if it was originally lp code, then it tended to be more procedural and just use functions scoped using namespaces | 02:47 |
| poolie | lifeless, is there a timeline matcher? | 02:47 |
| lifeless | poolie: not really | 02:48 |
| huwshimi | wallyworld___, rick_h_: in this case, I guess I would need to make it a little more generic, ie, not have a hardcoded url etc. right? | 02:48 |
| lifeless | poolie: closest is the underlying matcher of BrowsesWithQueryCount which doesn't use the timeline, it uses a custom storm filter instead | 02:48 |
| wallyworld___ | huwshimi: rick_h_: so the preference moving forward is to use more of the yui component and widget framework for new stuff | 02:48 |
| huwshimi | wallyworld___: Is the component still appropriate for this? | 02:48 |
| wallyworld___ | but for simple refactoring, it think "whatever works" is fine | 02:48 |
| wallyworld___ | huwshimi: so, we are talking about the bug tags stuff? | 02:49 |
| huwshimi | wallyworld___: Yeah | 02:49 |
| wgrant | -p 5432 | 02:49 |
| wgrant | Blah | 02:49 |
| wallyworld___ | huwshimi: personally, i think the way it was done was fine - it was refactoring what was there already and was a very simple bit of code | 02:50 |
| huwshimi | wallyworld___: If you say that I'm not going to fix it :) | 02:51 |
| huwshimi | Mostly cause I would like to finish with this bracnh | 02:52 |
| huwshimi | but very happy to fix it if it means doing it right | 02:52 |
| wallyworld___ | huwshimi: i'm not sure what value it would add for the effort involved. but as a learning exercise.... | 02:53 |
| huwshimi | wallyworld___: Maybe I'll consider it a lesson learned for next time :) | 02:55 |
| wallyworld___ | huwshimi: sure. fwiw, as i said, i would have done it the same way, since it was refactoring existing code and was a simple change | 02:56 |
| rick_h_ | wallyworld___: thanks for the info | 02:57 |
| rick_h_ | the stuff I've been doing and seen most of is the YUI module stuff | 02:57 |
| rick_h_ | so it just struck me as odd when I peeked at it | 02:58 |
| wallyworld___ | rick_h_: yes, i suspect you've been exposed to either the new distro pages or the former standalone lazr-js library that we sucked into the lp code base | 02:59 |
| wallyworld___ | rick_h_: then there's all the other lp javascript, which is mainly the procedural stuff | 03:00 |
| wallyworld___ | rick_h_: it's a bit of a mess, but we do want to evolve to use the yui component and widget framework for significant new stuff | 03:00 |
| rick_h_ | yea, overlay, inline editor, etc. | 03:00 |
| rick_h_ | yea, I had heard that, which I +1 :) | 03:01 |
| rick_h_ | I'm a bit of a YUI fanboi so happy to be working with this stuff | 03:01 |
| wallyworld___ | rick_h_: yep, that's all the lazr-js stuff which was written to be a reusable js lib and formerly packaged separate to lp | 03:01 |
| wallyworld___ | rick_h_: then no-one else was using lazr-js and it was too hard to use separately so we just sucked in all the source code | 03:02 |
| wallyworld___ | into the lp tree | 03:02 |
| rick_h_ | ah, yea I saw some bzr log stuff for "merge in lazr" | 03:02 |
| rick_h_ | when I tried to chase some older history items for it | 03:02 |
| wallyworld___ | yeah, we did that at the last epic, in july | 03:03 |
| huwshimi | 'bzr lp-land' errors with this: http://paste.ubuntu.com/745525/ any thoughts? | 03:03 |
| wallyworld___ | rick_h_: i'm having "fun" today trying to upgrade to yui 3.4.1, but there's errors thrown by the yui.js code. i may perhaps ping to tomorrow about it. very frustrating | 03:04 |
| wallyworld___ | huwshimi: haven't seen that before | 03:04 |
| huwshimi | grrr | 03:04 |
| lifeless | your gnome session isn't | 03:05 |
| rick_h_ | wallyworld___: yuck, devel is currently on .0 then? | 03:05 |
| wallyworld___ | rick_h_: use currently are using 3.3 | 03:05 |
| lifeless | I really regret not making a fuss about the desktop integration thing | 03:05 |
| lifeless | we've had -lots- of fallout | 03:05 |
| wallyworld___ | s/use/we | 03:05 |
| rick_h_ | oh, that's right, deryck mentioned skipped 3.4 to jump to 3.5 1st qrt | 03:05 |
| rick_h_ | qtr that is | 03:06 |
| wallyworld___ | rick_h_: oh, i didn't know that. in that case i may drop it and stick with 3.3 till then | 03:06 |
| rick_h_ | yea, there's a release schedule for 3.5 and deryck mentioned that would be the migration target | 03:06 |
| lifeless | huwshimi: are you logged into gnome? | 03:06 |
| huwshimi | lifeless: That's strange, I'm not running this from ssh or anything | 03:06 |
| wallyworld___ | rick_h_: there's been a fairly major re-packaging in 3.3 -> 3.4 | 03:06 |
| rick_h_ | so I'd not kill yourself on it | 03:06 |
| lifeless | huwshimi: or ssh'd into the machine ? | 03:06 |
| huwshimi | lifeless: Yeah | 03:06 |
| lifeless | huh | 03:06 |
| rick_h_ | wallyworld___: yea, I was checking out their MVC stuff which moved a few things around | 03:06 |
| lifeless | that is odd | 03:06 |
| lifeless | did unity crash on you or something ? | 03:07 |
| wallyworld___ | rick_h_: the reason for doing it is that i wanted to start looking to use the mvc stuff | 03:07 |
| huwshimi | lifeless: Things have been a bit weird today, maybe a reboot is in order | 03:07 |
| rick_h_ | wallyworld___: yea, I'm porting backbone to the YUI MVC on my bookmark app on the side | 03:07 |
| wallyworld___ | rick_h_: since we are embarking on a major new piece of development (the managing disclosure ui) and i wanted to look at using that | 03:07 |
| huwshimi | brb | 03:08 |
| rick_h_ | wallyworld___: ah, yea it's definitely something to plan from the start from | 03:08 |
| wallyworld___ | rick_h_: so i'm still tempted to try to get 3.4.1 working | 03:08 |
| rick_h_ | to catch the new way of doing the events and such | 03:08 |
| wallyworld___ | yep | 03:08 |
| wallyworld___ | rick_h_: so you used 3.4.1? | 03:09 |
| rick_h_ | well, let me know how it goes. I'd be curious to see it | 03:09 |
| rick_h_ | wallyworld___: yea, 3.4.1 | 03:10 |
| rick_h_ | but I started out with that, so not sure what the migration points are from 3.3, I've been porting from jquery + backbone + historyjs | 03:10 |
| wallyworld___ | rick_h_: we have a "unique" way of packaging yui which may be part of the issue, not sure | 03:11 |
| rick_h_ | yea, I've not gotten my head all the way around all of that yet | 03:11 |
| rick_h_ | references and use of LEP() or something vs YUI() | 03:11 |
| wallyworld___ | rick_h_: we basically cat selected yui js files to a big launchpad.js file | 03:11 |
| rick_h_ | yea, I've gotten that part and added some things to that | 03:12 |
| rick_h_ | hopefully have my auto resizing textarea widget done tomorrow and in there soon :) | 03:13 |
| wallyworld___ | rick_h_: so 3.4.1 has split stuff out and re-done the options for seeding yui etc. a trivial change to yui-deps.py to pull in all the new files seems to generate a reasonable launchpad.js but there's an error inside yui when pages load :-( | 03:14 |
| huwshimi | lifeless: It worked, then I discovered that I hadn't pushed my change but now can't run lp-land again. | 03:14 |
| huwshimi | (it worked, after a restart | 03:14 |
| huwshimi | ) | 03:14 |
| lifeless | huwshimi: same error? | 03:14 |
| huwshimi | lifeless: Sorry, yes | 03:14 |
| wallyworld___ | rick_h_: cool about the text area widget. great to have that fixed | 03:15 |
| huwshimi | lifeless: Can I restart my keyring or something? | 03:15 |
| rick_h_ | wallyworld___: hmm, I can't find that file | 03:15 |
| rick_h_ | but makes sense | 03:15 |
| lifeless | huwshimi: possibly, might be listnening on dbus | 03:15 |
| wallyworld___ | rick_h_: utilities/yui-deps.py | 03:15 |
| lifeless | huwshimi: have alook for a .*keyring.* process | 03:15 |
| wallyworld___ | rick_h_: it's run by make | 03:16 |
| rick_h_ | bah, helps if I tell it to do it recursively | 03:16 |
| huwshimi | lifeless: gnome-keyring-daemon? | 03:16 |
| lifeless | sounds like it | 03:16 |
| lifeless | if its dbus activated, killing it should be pretty transparent | 03:17 |
| lifeless | I don't know if it is | 03:17 |
| wallyworld___ | rick_h_: it print out all the js files we want to use and these are cat'ed to launchpad.js | 03:17 |
| huwshimi | lifeless: I'll give it a try | 03:17 |
| rick_h_ | wallyworld___: gotcha, yea not peeked at that. | 03:17 |
| rick_h_ | http://yuilibrary.com/forum/viewtopic.php?p=27897 | 03:18 |
| huwshimi | lifeless: Ah, that seems to have worked. Thanks :) | 03:18 |
| rick_h_ | that seems sucky, but maybe? | 03:19 |
| rick_h_ | lol "should be fixed in 3.5.0" | 03:19 |
| wallyworld___ | rick_h_: so you would think that being conservative and grabbing everything and yui-base and using that would work but sadly not. it fails inside YArray.hash :-( | 03:19 |
| rick_h_ | wallyworld___: well I'd hand modify the file and start small | 03:19 |
| rick_h_ | just try to get yui concat'd to launchpad.js and get it to load on some url | 03:20 |
| rick_h_ | and then start adding a module/two at a time | 03:20 |
| huwshimi | oh failure | 03:21 |
| wgrant | Failure? | 03:21 |
| wallyworld_ | rick_h_: yeah, i was hoping not to have to resort to doing stuff like that. i may just leave it as i've got lots of other stuff to get done :-( | 03:21 |
| rick_h_ | wallyworld_: yea, sorry. There's so much to the build of this stuff I think the only sane way is to break it down step by step | 03:22 |
| huwshimi | wgrant: Still trying to get my keyring stuff happening | 03:22 |
| huwshimi | so I can lp-land that change | 03:22 |
| rick_h_ | might at least try a JS test file, .html | 03:22 |
| wgrant | huwshimi: :( | 03:22 |
| rick_h_ | and see if you can just make the few files in one of those work with yui 3.4.1 | 03:22 |
| rick_h_ | just load it into the html from the cdn | 03:22 |
| rick_h_ | and see if there's anything in the modules we're writing that's harmful (like the forum post on using requires: ...) | 03:23 |
| wallyworld_ | rick_h_: i'll see what i can do in the time i have left. | 03:23 |
| rick_h_ | yea, have fun! off to bed for real this time. | 03:24 |
| wallyworld_ | rick_h_: thanks. ttyl | 03:24 |
| wgrant | Night rick_h_. | 03:24 |
| huwshimi | wgrant: Ok, done, that change is running through pqm now | 03:26 |
| wgrant | huwshimi: Thanks. | 03:28 |
| huwshimi | wgrant: No problems | 03:29 |
| huwshimi | I don't know how but I appear to have completely broken my ssh/keyring on my computer | 03:39 |
| StevenK | huwshimi: What's the issue? | 03:43 |
| huwshimi | StevenK: Well, now when I try and ec2 land I get "ec2: ERROR: You must have an ssh agent running with keys installed that will allow the script to access Launchpad and get your branch." | 03:44 |
| StevenK | What does ssh-add -l say? | 03:44 |
| huwshimi | StevenK: "Could not open a connection to your authentication agent." | 03:45 |
| StevenK | ssh-agent should be started on login | 03:45 |
| huwshimi | StevenK: ssh-agent gives me output | 03:46 |
| StevenK | It will | 03:46 |
| huwshimi | what I assume to be normal looking output anyway | 03:46 |
| StevenK | No matter if it is running or not | 03:46 |
| huwshimi | StevenK: oh, right, that's helpful | 03:47 |
| huwshimi | StevenK: How do I get it to run then? | 03:47 |
| StevenK | huwshimi: So you can logout and back in and then see if ssh-add -l behaves or you can fix it for one terminal | 03:47 |
| huwshimi | StevenK: I'll try the log out first | 03:48 |
| huwshimi | brb | 03:48 |
| huwshimi | StevenK: Ok, that fixed it this time. Thankyou! | 03:50 |
| huwshimi | I restarted a few minutes ago, but that didn't work | 03:50 |
| huwshimi | maybe it needed a logout rather than a restart | 03:50 |
| StevenK | wgrant: Can haz review? https://code.launchpad.net/~stevenk/launchpad/use-userHasPriviledges/+merge/82967 | 04:00 |
| wgrant | StevenK: You can't spell privileged. | 04:01 |
| wgrant | Not "privileges" | 04:02 |
| wgrant | s/Not/Nor/ | 04:02 |
| wgrant | StevenK: Why isn't userHasPrivileges implemented in terms of userHasPrivilegesContext? | 04:03 |
| StevenK | wgrant: Because I couldn't think of a clean way to do it. Suggestions welcome. | 04:04 |
| wgrant | StevenK: Make isOneOfDrivers work on distroseries/productseries if it doesn't already. | 04:05 |
| wgrant | Then call isOneOfDrivers(context) instead of isOneOfDrivers(pillar) | 04:06 |
| wgrant | Mm, it would also need to work for SP and DSP, I suppose. | 04:06 |
| wgrant | But it's doable somehow and better than duplication. | 04:06 |
| StevenK | And make userHasPrivileges a class method? | 04:06 |
| wgrant | No. | 04:07 |
| wgrant | It's still an instance method. | 04:07 |
| wgrant | It just calls the underlying class method with the instance's context. | 04:07 |
| StevenK | You've lost me somewhere, sorry. | 04:07 |
| wgrant | userHasPrivileges does basically the same thing as userHasPrivilegesContext | 04:08 |
| wgrant | The logic should not be duplicated. userHasPrivileges should call into userHasPrivilegesContext | 04:08 |
| StevenK | Oh | 04:08 |
| StevenK | Right | 04:08 |
| nigelb | Does launchpad do something like keyword search? | 04:15 |
| lifeless | statik: lol, you haven't deleted all lp mail... lists.launchpad.net :P | 04:19 |
| lifeless | nigelb: we don't treat some words differently, no | 04:19 |
| nigelb | lifeless: Are there plans for something like that? Or can I just building with the API. | 04:20 |
| lifeless | nigelb: no, why would there be? | 04:20 |
| nigelb | I like how for bugzilla, I can do "bug product:Firefox" in my firefox awesome bar and see all the bugs for that product. | 04:20 |
| nigelb | I think most modern browsers have that feature. | 04:21 |
| lifeless | Ah, thats totally different to keyword search :) | 04:22 |
| lifeless | thats a search grammar - and there are plans for that | 04:22 |
| lifeless | however, I think for awesome bar stuff you should implement it in the bar | 04:22 |
| nigelb | Ah, right. I couldn't figure out what's the right term for it :) | 04:22 |
| nigelb | All the awesome bar stuff wants is a search box into which you can put specific words for specific things. | 04:22 |
| poolie | lifeless, can i use fixtures as contextmanagers? | 04:29 |
| poolie | ah nm | 04:30 |
| lifeless | poolie: yes | 04:30 |
| poolie | so it's not setUp/tearDown but setUp/cleanUp? | 04:31 |
| poolie | more decoy code! | 04:31 |
| poolie | lifeless, so is the tearDown method of ZopeViewReplacementFixture wrong? | 04:32 |
| poolie | it looks like it will never run | 04:32 |
| lifeless | yes, thats buggy | 04:33 |
| lifeless | it should just use self.addCleanup | 04:33 |
| lifeless | self.addCleanup(undefineChecker, self.replacement) | 04:34 |
| poolie | yes | 04:34 |
| poolie | very deceptive | 04:34 |
| lifeless | self.addCleanup(self.gsm.adapter.register, ... | 04:34 |
| poolie | they're run fifo? | 04:34 |
| lifeless | same as the testtools one you are familiar with | 04:34 |
| lifeless | they all execute, fifo, errors are collected and raised at the end | 04:34 |
| poolie | sure | 04:35 |
| poolie | i thought it would be tearDown to be consistent with unittest and the code already in that file reinforced that misconcetpion | 04:35 |
| poolie | it's fine now | 04:35 |
| lifeless | care to fix that bad example while you are thre ? | 04:36 |
| poolie | of course | 04:36 |
| lifeless | thanks! | 04:36 |
| poolie | yakkety yak | 04:37 |
| lifeless | don't test back? | 04:40 |
| nigelb | poolie: Whats the fun if you don't shave a couple of yaks ;) | 04:41 |
| StevenK | wgrant: Diff updated, can you have another look? | 05:16 |
| StevenK | wgrant: And I can rename the branch if the name offends you | 05:16 |
| poolie | wgrant, btw raw_sendmail is tested now | 05:24 |
| poolie | down to the point it would normally call into zope | 05:24 |
| wgrant | poolie: Nice | 05:25 |
| wgrant | StevenK: Let me see. | 05:26 |
| poolie | wgrant, did you have any luck working out where an email.Header is being passed to raw_sendmail? | 05:33 |
| poolie | paranoid_email_content_validatino seems to trap it | 05:34 |
| poolie | oh | 05:34 |
| wgrant | I can probably dig up a pageid if you haven't solved it yet. | 05:35 |
| poolie | two different ways to send mail, of course | 05:35 |
| wgrant | Yes | 05:35 |
| wgrant | At least | 05:35 |
| poolie | maybe i should stop worrying and just flatten the mail | 05:35 |
| poolie | *value | 05:35 |
| poolie | then we can see if it still fails | 05:35 |
| lifeless | wgrant: you hjad lxc puking on resolv.conf not existing ? (due to /var/run/resolvconf being awol) ? | 05:36 |
| wgrant | lifeless: don't think so | 05:37 |
| wgrant | Not in months, at least. | 05:37 |
| wgrant | But not at all that I can recall. | 05:37 |
| jtv | wgrant: did you just move bug 887078 back from Fix Released to In Progress? | 05:38 |
| _mup_ | Bug #887078: Builder:+history timeout <qa-ok> <timeout> <ui> <Launchpad itself:In Progress by rvb> < https://launchpad.net/bugs/887078 > | 05:38 |
| lifeless | wgrant: its not making /var/run/resolvconf automatically, or something | 05:39 |
| wgrant | jtv: From Fix Committed to In Progress. It's not done yet, AFAICT. | 05:40 |
| wgrant | jtv: The pages are still slow and time out. | 05:40 |
| lifeless | erm, not the the literal packag,e whatever makes resolve.conf on lucid by default | 05:40 |
| jtv | wgrant: I see. Thanks. | 05:41 |
| poolie | is there a new request, and a new timeline, for each test? | 05:49 |
| StevenK | wgrant: Did you get distracted? | 05:49 |
| wgrant | StevenK: builddisasters tend to do that. | 05:49 |
| lifeless | poolie: there is no strong correlation between tests and timelines | 05:49 |
| wgrant | Relooking now. | 05:49 |
| lifeless | poolie: tests may make requests | 05:49 |
| lifeless | poolie: if they do, the request gets its own timeline | 05:50 |
| poolie | so | 05:50 |
| poolie | i should clear the timeline if i want to observe it later? | 05:50 |
| lifeless | the request will d that | 05:50 |
| poolie | mm | 05:50 |
| poolie | this is the sendmail code | 05:50 |
| poolie | i don't know if there is a request | 05:50 |
| poolie | do i need to make one? | 05:50 |
| lifeless | so, for that, you want to manually setup a timeline - probably easiest to call adapter.set_request_started() and its matching thing later | 05:51 |
| wgrant | StevenK: I am confuse. | 05:51 |
| wgrant | StevenK: Why not pass the context into userHasPrivilegesContext? | 05:51 |
| wgrant | StevenK: bugtask.target | 05:51 |
| poolie | ok thanks | 05:52 |
| StevenK | wgrant: From IBugTask.userHasPrivileges? | 05:53 |
| wgrant | StevenK: Yes | 05:53 |
| wgrant | You currently specialcase IBugTask in userHasPrivilegesContext | 05:54 |
| wgrant | Why not specialcase series? | 05:54 |
| wgrant | So you are actually passing the context in there. | 05:54 |
| wgrant | Not a task. | 05:54 |
| StevenK | wgrant: IE, if IProductSeries.providedby() ? | 05:54 |
| wgrant | role.isOwner(context.pillar) or role.isOneOfDrivers(context) or role.isBugSupervisor(context.pillar) | 05:55 |
| wgrant | probably | 05:56 |
| wgrant | Remove the Assuming that isOneOfDrivers works on SP/DSP | 05:56 |
| wgrant | Which it might not. | 05:56 |
| StevenK | I can test this quickly, given wallyworld__'s bitching. | 05:57 |
| StevenK | Hey look, he has two underscores. | 05:57 |
| StevenK | wgrant: Seems to work fine. | 05:59 |
| StevenK | wgrant: Anything else jump out at you? | 06:00 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | Really? It shouldn't work, AFAICT. | 06:00 |
| StevenK | wgrant: TestBugTaskUserHasPriviliges works fine | 06:01 |
| wgrant | Even for DSP and SP targets? | 06:01 |
| wgrant | Note that we don't want the pillar. | 06:02 |
| StevenK | wgrant: DSP/SP don't have drivers ... | 06:09 |
| wgrant | StevenK: No, which is why it probably won't work. | 06:10 |
| wgrant | StevenK: They need to use the series/pillar drivers. | 06:10 |
| wgrant | StevenK: It's probably better to make them have drivers. | 06:10 |
| wgrant | By adding a drivers property. | 06:10 |
| poolie | wgrant, ok https://code.launchpad.net/~mbp/launchpad/885972-sendmail-timeline/+merge/82963 should fix your timeline thing | 06:10 |
| poolie | afaict | 06:10 |
| wgrant | poolie: It's safely unicodable? | 06:10 |
| StevenK | wgrant: And check distribution for DSP and both distribution and series for SP? | 06:11 |
| poolie | one line of actual fix, ~300 lines of diff to make it testable | 06:11 |
| wgrant | StevenK: SP should be able to just check distroseries | 06:11 |
| StevenK | poolie: Welcome to Launchpad. | 06:11 |
| poolie | wgrant, i think so: it provides a __unicode__ method that tries to take header encoding into account | 06:11 |
| wgrant | StevenK: since distroseries should inherit distribution | 06:11 |
| poolie | for fairly low values of 'safe' | 06:11 |
| StevenK | wgrant: You'd think. | 06:11 |
| wgrant | poolie: Ah, missed the not isinstance. | 06:11 |
| wgrant | Was worried it could be a shittily encoded bytestring. | 06:11 |
| wgrant | But that indeed looks reasonable. | 06:11 |
| poolie | yeah i thought of that too | 06:12 |
| wgrant | poolie: (un)registerUtility behaves sensibly if there's already one? | 06:23 |
| poolie | yeah apparently it stacks them internally | 06:23 |
| === al-maisan is now known as almaisan-away | ||
| poolie | it is not very well documented | 06:23 |
| wgrant | Aha, handy. | 06:24 |
| poolie | :/ | 06:24 |
| poolie | to some extent i'm going to leave that for whoever uses it next | 06:25 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| nigelb | I may be imagining things, but did Karl Fogel work on Launchpad at some point? | 07:39 |
| nigelb | His name and nickname seem somewhat familiar. | 07:40 |
| lifeless | yes he did | 07:40 |
| lifeless | community/communication mgr | 07:40 |
| lifeless | well know for svn | 07:41 |
| nigelb | Aha | 07:41 |
| nigelb | Yeah, that and the book that he wrote. | 07:41 |
| nigelb | Gerv from Mozilla keeps posting excerpts from his book to Mozilla Planet and I keep thinking "Why am I familiar with this name" | 07:41 |
| poolie | hi nigelb | 07:46 |
| * wgrant glares threateningly at yuixhr | 07:48 | |
| * wgrant prepares to disable. | 07:48 | |
| nigelb | Hey poolie | 07:54 |
| nigelb | wgrant: It didn't disable itself with the glaring :) | 07:54 |
| mrevell | Hello | 09:11 |
| nigelb | Morning mrevell | 09:12 |
| lifeless | rvba: hi | 09:18 |
| lifeless | rvba: I got your query | 09:18 |
| rvba | lifeless: hi | 09:18 |
| lifeless | rvba: cachedproperty injection is the general answer to this sort of thing | 09:18 |
| lifeless | rvba: see BranchCollection for some of the more complex examples that are around | 09:19 |
| rvba | lifeless: yeah, but as soon as I materialize the object, the query gets executed so unless I remove the reference, cachedproperty won't help. | 09:19 |
| lifeless | got a backtrace of that query being triggered ? | 09:20 |
| rvba | No… but I can work out an example for you if you want. | 09:21 |
| lifeless | run your test with LP_DEBUG_SQL_EXTRA=1 | 09:21 |
| lifeless | or visit a page with ++oops++ | 09:21 |
| lifeless | the test is probably easiest | 09:21 |
| rvba | Oh, you mean you simply want the query itself. | 09:21 |
| lifeless | no | 09:21 |
| rvba | Ok, hold on a sec. | 09:21 |
| lifeless | the _EXTRA makes it spit out backtraces | 09:22 |
| rvba | k | 09:22 |
| === almaisan-away is now known as al-maisan | ||
| rvba | lifeless: https://pastebin.canonical.com/56131/ | 09:27 |
| rvba | lifeless: btw, I wanted to say that having backtraces on oops is a real nice addition to try to find what object should be eager loaded. They are not very easy to read but still really useful. | 09:28 |
| lifeless | rvba: cool, thanks | 09:29 |
| lifeless | rvba: so, that backtrace tells me a lot | 09:30 |
| lifeless | rvba: what do you get from it ? | 09:30 |
| rvba | The problem is the backreference from preview_diff to bmp. When the previewdiff is created it has to look up the related bmp object. | 09:31 |
| lifeless | nope | 09:32 |
| lifeless | thats not what happens ;) | 09:32 |
| rvba | ah? | 09:32 |
| lifeless | the quest is triggered at line 166 of the pastebin | 09:32 |
| lifeless | bah | 09:32 |
| lifeless | query, line 165 | 09:32 |
| lifeless | diff_lines_count is accessed at line 156 of the backtrace | 09:34 |
| rvba | Hum, security check… | 09:34 |
| lifeless | bingo | 09:34 |
| lifeless | the security check is triggering the backref | 09:34 |
| lifeless | __init__ or _storm_loaded are not | 09:35 |
| lifeless | rvba: now, if you are loading the bmp as part of the eager loading | 09:35 |
| lifeless | you can solve this by injecting the bmp into the object | 09:36 |
| lifeless | this involves | 09:36 |
| lifeless | replace the storm reference with a cached property | 09:36 |
| lifeless | and set it | 09:36 |
| lifeless | (or you could poke under the storm hood, but so far we haven't done that) | 09:36 |
| lifeless | for instance | 09:36 |
| rvba | This reference is also used else were and cachedproperty cannot be 'set', right, only populated so to speak. | 09:38 |
| lifeless | rvba: http://pastebin.com/vbiezhwF | 09:38 |
| lifeless | rvba: it can be with gavins patch | 09:38 |
| lifeless | rvba: or you can update the other call sites, which is arguably better | 09:38 |
| rvba | Right, I think updating the other call sites sounds better to me. | 09:39 |
| lifeless | rvba: does this help? | 09:40 |
| rvba | lifeless: it does, thanks! | 09:40 |
| lifeless | rvba: backtraces ftw :) | 09:40 |
| rvba | Indeed! | 09:40 |
| rvba | lifeless: btw, by gavins patch you mean ~allenap/launchpad/cached-property-bug-893074? | 09:42 |
| lifeless | yeah | 09:42 |
| rvba | This will just prevent one from setting a cachedproperty and thinking it's all good right? | 09:43 |
| lifeless | actually yes :) | 09:43 |
| allenap | There was a *lot* of test fallout from that patch :-/ | 09:43 |
| lifeless | so update the callers | 09:43 |
| lifeless | allenap: win :) | 09:43 |
| rvba | Okay, just checking ;) | 09:43 |
| rvba | lifeless: I could also have the cachedreference be called _branch_merge_proposal and only change the callsite in security.py. | 09:46 |
| lifeless | rvba: indeed | 09:54 |
| lifeless | rvba: however that would then make semi-invisible skew | 09:54 |
| lifeless | rvba: better I think for all callsites to use the one attribute | 09:54 |
| rvba | lifeless: Good point. | 09:55 |
| rvba | lifeless: on second thought, this means that all the call sites wanting to access the property will use branch_merge_proposal but those setting the property will use _branch_merge_proposal. Or the other way around if I make _branch_merge_proposal be the cachedreference. | 10:12 |
| rvba | I think it's cleaner if branch_merge_proposal is the reference that you can get/set without trouble. | 10:13 |
| jtv | Anyone know what's up with staging? | 10:13 |
| jtv | It's been saying “code update in progress” for a suspicious length of time. | 10:13 |
| wgrant | jtv: staging or qastaging? | 10:14 |
| jtv | staging | 10:14 |
| wgrant | Hmm. | 10:14 |
| wgrant | That shouldn't be down, AFAIK | 10:14 |
| wgrant | qastaging is down for a DB upgrade. | 10:14 |
| * wgrant checks. | 10:14 | |
| wgrant | 2011-11-22 09:10:51 CRITICAL lpmain_staging_slave has transaction by postgres open 0:02:01.180763 | 10:15 |
| wgrant | 2011-11-22 09:10:51 INFO No fragile systems connected to the cluster (publish_ftpmaster, publish_distro, process_accepted, buildd_manager, process_upload) | 10:15 |
| wgrant | Get a LOSA to retry the update. | 10:15 |
| wgrant | Tue Nov 22 09:10:51 UTC 2011 ERROR: Failed to run full-update.py | 10:15 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | rvba: mmm | 10:20 |
| lifeless | rvba: do you agree that all the sites accessing it should use one attribute name | 10:21 |
| lifeless | rvba: the overhead of the (very few) sites that set it doing it differently seems inconsequential to me | 10:21 |
| rvba | lifeless: but AFAIUI it's not possible, we want the sites getting the prop to use the cachedproperty and the sites setting the property to use the reference. | 10:22 |
| lifeless | yes | 10:22 |
| lifeless | one to write one to read | 10:22 |
| rvba | So your argument is that it gets read much more often than set right? | 10:23 |
| lifeless | one hopes | 10:23 |
| rvba | My argument is this: setting the cachedproperty leads to silent data fuck up ;). But Gavin's patch will fix this. | 10:23 |
| lifeless | indeed :> | 10:24 |
| lifeless | rvba: also, you can tell zope to not let writes to that attribute, if you want to | 10:24 |
| wgrant | Interesting things also happen when a cachedproperty is used in a Storm query. | 10:24 |
| lifeless | rvba: or you can set a set for it | 10:24 |
| rvba | lifeless: right, that would be a good solution. | 10:25 |
| lifeless | rvba: as wgrant notes, you need to use the storm reference in queries (though you shouldn't do that anyhow- should be using the _id | 10:25 |
| wgrant | lifeless: Mm, that's a matter of opinion. | 10:26 |
| lifeless | wgrant: perhaps, but I've yet to see a compelling argument for using the reference itself | 10:26 |
| wgrant | It's type-safe and I've yet to see a compelling argument for using the ID. | 10:27 |
| wgrant | Except that using the reference fails in a couple of cases, which are bugs. | 10:27 |
| lifeless | using the reference is discouraged by storm upstream; it fails in some cases and is ambiguous at best in others. | 10:28 |
| rvba | Too we can't explicitly define a setter for a cachedproperty à la cachedproperty(_get_branch_merge_proposal, _set_branch_merge_proposal) | 10:32 |
| rvba | s/Too/Too bad/ | 10:34 |
| jtv | wgrant: I seem to be back for the time being. Any news on staging? | 10:36 |
| rvba | number of (storm references in queries + places where the field is set) > number (places where the field is read) | 10:41 |
| rvba | This is in favor of having the cachedproperty named _branch_merge_proposal. | 10:43 |
| === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 292 | ||
| wgrant | jtv: | 10:46 |
| wgrant | 21:14:57 * wgrant checks. | 10:46 |
| wgrant | 21:15:40 < wgrant> 2011-11-22 09:10:51 CRITICAL lpmain_staging_slave has transaction by postgres open 0:02:01.180763 | 10:46 |
| wgrant | 21:15:40 < wgrant> 2011-11-22 09:10:51 INFO No fragile systems connected to the cluster (publish_ftpmaster, publish_distro, process_accepted, buildd_manager, process_upload) | 10:46 |
| wgrant | 21:15:41 < wgrant> Tue Nov 22 09:10:51 UTC 2011 ERROR: Failed to run full-update.py | 10:46 |
| wgrant | 21:15:46 < wgrant> Get a LOSA to retry the update. | 10:46 |
| jtv | Thanks. | 10:46 |
| jtv | Not much luck with the retry though, evidently. :( | 10:46 |
| wgrant | I didn't ask for a retry. | 10:51 |
| wgrant | Because gnuoy was busy with other stuff. | 10:51 |
| gnuoy | jtv, just kicking it off again now | 10:52 |
| jtv | great, thanks | 10:52 |
| stub | Do we need an option to increase the long running transaction threshold? We have reasons to keep it low on production, but staging is another kettle of fish. | 10:58 |
| === matsubara-afk is now known as matsubara | ||
| lifeless | rvba: the other cases we have have the cachedproperty be branch_merge_proposal | 11:15 |
| lifeless | rvba: I humbly suggest that the difference isn't big enough to outweight consistency | 11:15 |
| rvba | lifeless: okay then ;) … I hope the test suite will catch it if the cached property is used in a query. | 11:16 |
| lifeless | rvba: I suggest grepping | 11:17 |
| rvba | Of course I'll do that. | 11:17 |
| lifeless | :) | 11:17 |
| rvba | :) | 11:17 |
| rick_h_ | morning | 11:48 |
| nigelb | Morning rick_h_ | 11:51 |
| rvba | Hey rick_h_. | 11:52 |
| jml | lifeless: btw, came across this. I haven't read it yet. It's called "The Vietnam of Computer Science" and it's about ORM. Thought you might be interested: http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx | 11:53 |
| rick_h_ | uh oh, ORM debates this early? | 11:54 |
| nigelb | heh | 11:54 |
| nigelb | Early is all about perspective. | 11:55 |
| rick_h_ | so true | 11:55 |
| rick_h_ | woot! changes landed and are live! | 11:55 |
| * rick_h_ does a little happy dance | 11:55 | |
| rick_h_ | meh, I think before people write ORM articles they need to use SqlAlchemy for a big project first | 12:04 |
| lifeless | rick_h_: 0100 :P | 12:04 |
| rick_h_ | too many bad ones cause people to write this stuff | 12:04 |
| rick_h_ | and lose the idea that ORM == "no need to know SQL" | 12:04 |
| lifeless | a terrible idea to be sure | 12:06 |
| nigelb | rick_h_: Dear god. SqlAlchemy is scar-inducing :) | 12:13 |
| nigelb | I sometimes prefer writing pure SQL to SqlAlchemy :) | 12:14 |
| rick_h_ | lol, what? How so? | 12:14 |
| rick_h_ | oh man, when I first tinkered with Python I put SA is one of the top 5 reasons to use Python | 12:14 |
| nigelb | Its awesome, etc. | 12:14 |
| gary_poster | Hey StevenK. I was going to try and increase JS timeouts yet again for my new yuixhr tests, but I was unable to build. versions.cfg says Twisted 11.1.0, but our dist directory has 11.1.0pre1 | 12:14 |
| nigelb | Just that it takes a while to settle in. | 12:15 |
| rick_h_ | yea, that's true | 12:15 |
| rick_h_ | but all the good frameworks do | 12:15 |
| gary_poster | StevenK Making a custom Twisted release requires changing files | 12:15 |
| StevenK | gary_poster: Hm, lemme check. | 12:15 |
| gary_poster | IIRC | 12:15 |
| rick_h_ | I find if it's too easy to start, you'll grow out of it before the end of the project | 12:15 |
| StevenK | gary_poster: But 11.1.0 is a REAL release! | 12:15 |
| gary_poster | StevenK, then maybe you did not push up the changes? | 12:16 |
| gary_poster | to the download-cache | 12:16 |
| StevenK | gary_poster: But it passed ec2! | 12:16 |
| gary_poster | StevenK... | 12:16 |
| nigelb | rick_h_: heh, agreed. | 12:16 |
| nigelb | StevenK: Maybe you didn't test for it? :D | 12:16 |
| gary_poster | lemme look at my download-cache again | 12:16 |
| StevenK | nigelb: The download-cache is not seeded on ec2 instances, if buildout works and the tests pass, the upgrade is good. | 12:17 |
| StevenK | nigelb: That is, "troll failed" | 12:17 |
| nigelb | StevenK: Damn. I'll blame travel exhaustion for it. | 12:17 |
| StevenK | gary_poster: It's here in my download-cache | 12:17 |
| nigelb | StevenK: I was "closer" to you for a weekend :) | 12:18 |
| StevenK | gary_poster: r401 | 12:18 |
| gary_poster | StevenK, sorry, bizarre system confusion. From emacs term, bzr up in my download cache said there wasn't anything to get, and from a normal terminal in updated, getting Twisted. I have no idea what is going on over here, but it isn't your fault :-P | 12:18 |
| gary_poster | Thanks StevenK | 12:18 |
| StevenK | That's what you get for using emacs to do your dirty work. | 12:19 |
| gary_poster | :-P | 12:19 |
| nigelb | s/to do your dirty work//g | 12:19 |
| StevenK | nigelb: Oh? | 12:19 |
| nigelb | :D | 12:19 |
| nigelb | StevenK: Kuala Lumpur! | 12:19 |
| rick_h_ | lol, from ORM flames to emacs...on fire today | 12:19 |
| nigelb | Amazing weekend with Mozilla people for Mozcamp Asia. | 12:20 |
| StevenK | nigelb: Pfft, like Australia was that much further ... | 12:23 |
| nigelb | StevenK: Well... it made sense to keep an Asia event *in* Asia... ;) | 12:23 |
| nigelb | How far is Australia from KL? | 12:24 |
| * nigelb checks | 12:24 | |
| nigelb | Interesting. Not too far. | 12:26 |
| jml | rick_h_: have you read the article? | 12:28 |
| nigelb | jml: It was an interesting comparison. | 12:28 |
| nigelb | I bookmarked to finish reading later. | 12:28 |
| rick_h_ | jml, I gave it a run through skimming | 12:28 |
| jml | nigelb: yeah, it's on my readitlater list | 12:28 |
| rick_h_ | basically seems to make the general argument people start using and ORM and refuse to lose and give it up | 12:28 |
| rick_h_ | thus enduring more pain and suffering | 12:29 |
| jml | rick_h_: so are you saying that if only he'd used Python & SQLAlchemy instead of whatever other technologies he's using, he'd not have a problem with ORMs at all? | 12:30 |
| rick_h_ | no, I'm saying that people get fussy over ORMs, but what ORM you use can great change your outlook | 12:31 |
| rick_h_ | having used several ORM in PHP land and Python land | 12:31 |
| rick_h_ | things like the verbosity stuff he talks about is better in python | 12:31 |
| rick_h_ | along with things like the ability of Python to add/modify objects at will make it more flexible for a lot of ORM tricks | 12:32 |
| rick_h_ | and SA improves a lot because it's two layers, the expression layer makes crazy things possible | 12:32 |
| rick_h_ | while the ORM layer makes typical things pretty and easy | 12:32 |
| rick_h_ | but most ORM solutions don't break down nicely like that | 12:32 |
| rick_h_ | but SA has its own pain points for sure | 12:33 |
| nigelb | I've always thought it was a compromise of the lesser of the two evils. | 12:33 |
| nigelb | And that depends on the situation. | 12:34 |
| rick_h_ | it makes you have to learn more, there's two solid layers to understand, and it expects you to actually write your own layer above it | 12:34 |
| rick_h_ | which I think is very important | 12:34 |
| nigelb | Oh. | 12:34 |
| nigelb | SA excepts developers to abstract SA out of their operations? | 12:35 |
| rick_h_ | well, I argue that you write an API layer that your app accesses and you wrap all your SA | 12:35 |
| rick_h_ | that way you can swap out the back end/what SA is doing without breaking your app | 12:35 |
| rick_h_ | http://python.mirocommunity.org/video/4392/pyohio-2011-sqlalchemy-tutoria | 12:36 |
| nigelb | Hrm. Fair. | 12:36 |
| rick_h_ | for thoughts on it :) | 12:36 |
| nigelb | I have seen projects doing exactly that. | 12:36 |
| nigelb | https://crash-stats.mozilla.org/ for one does that. | 12:36 |
| nigelb | Backend is something python-ish and SA. | 12:36 |
| rick_h_ | yea, I think that's the only way to go and really solves a lot of problems with DRY and such | 12:36 |
| rick_h_ | and makes the breaking down to SQL and such less icky | 12:37 |
| nigelb | This changes my POV for a few things. Now I need to go back and think things through :) | 12:37 |
| gary_poster | nigelb, rick_h_, I think ORMs are evil, from experience, and even pure object databases seem easier than they are. However, a good alternative is tricky. I am interested in the pure data + SQL composability for functions that is being explored in Clojure-land with projects like Korma. http://sqlkorma.com/ . It allows abstractions while being much closer to what the database actually manipulates. | 13:03 |
| gary_poster | http://nathanmarz.com/blog/clojure-or-how-i-learned-to-stop-worrying-and-love-the-paren.html has a related argument. | 13:03 |
| * gary_poster retreats back into cave, with a madman hair wig on | 13:04 | |
| jml | gary_poster: I think Haskell has similar stuff | 13:04 |
| jml | gary_poster: incidentally, thanks for the Clojure conference write-up. Was a good read. | 13:05 |
| * jml has had the "simple vs easy" talk flagged for watching for a couple of weeks now. Surprisingly hard to find an uninterrupted 1hr+ of time to watch things. | 13:05 | |
| rick_h_ | jml: heh, yea. I wanted to watch some YUIConf videos so scheduled it as group viewing at CHC this week | 13:06 |
| rick_h_ | make everyone else suffer my wishes! bwuhahaha | 13:06 |
| jml | CHC? | 13:06 |
| rick_h_ | sorry, CoffeeHouseCoders, weekly meetup I run locally for devs | 13:06 |
| rick_h_ | http://coffeehousecode.appspot.com/ | 13:06 |
| rick_h_ | detroit branch | 13:06 |
| rick_h_ | gary_poster: yea, that second link is a lot of stuff I'd do with SA | 13:07 |
| rick_h_ | creating almost little sql "widgets" and then using them into larger queries and such later on | 13:07 |
| jml | rick_h_: you can do that in storm, fwiw | 13:08 |
| rick_h_ | yea, I look forward to getting into some storm stuff later on. | 13:08 |
| rick_h_ | I know I gave it a look when it first came out and really didn't follow it afterwards | 13:08 |
| rick_h_ | well, first went OSS public I guess vs "first came out" | 13:08 |
| rick_h_ | I'm still floored people suffer through the django orm though ugh | 13:09 |
| gary_poster | jml, cool, glad you liked write-up. Yeah, not surprised Haskell has similar stuff. And yeah, understood about the hour. I put it on one weekend while I was supposed to be cleaning a room. Cleaning the room was pretty slow, but hey, I saw the video! :-) | 13:09 |
| rick_h_ | gary_poster: I like though that this clojure stuff keeps things sql'y. Keep people from getting away from that idea | 13:09 |
| jml | gary_poster: :D | 13:09 |
| gary_poster | right | 13:09 |
| rick_h_ | ah, imapfilter running now. This ought to help with all these lists | 13:10 |
| jml | gary_poster: yeah, I've got to disassemble a whiteboard this weekend, might have this in the bg then :) | 13:10 |
| gary_poster | sounds perfect jml :-) | 13:10 |
| bac | sinzui: ping | 14:08 |
| sinzui | hi bac | 14:08 |
| rick_h_ | do we have a sprite with a spinner not on a white background? like transparent? | 14:08 |
| deryck | rick_h_, no, I don't think we do. We only have spinner.gif or whatever it's called, that is over white. | 14:10 |
| rick_h_ | yea, ugh. Ok | 14:10 |
| dobey | deryck, rick_h_: just do one in CSS | 14:18 |
| rick_h_ | dobey: http://fgnass.github.com/spin.js/ import this? :) | 14:19 |
| rick_h_ | dobey: when I tried to do a css3 spinner it had cross browser issues | 14:19 |
| rick_h_ | and a TON of vendor prefixing fun | 14:19 |
| dobey | eh :) | 14:20 |
| deryck | yeah, css 3 spinners are just showing off. And painful. We can get a new image if you need. | 14:20 |
| rick_h_ | actually, I use it on my bookie plugin, but the animation freezes while the ajax request takes place | 14:21 |
| rick_h_ | yea, I figured I'd check on the stand up the best way to move forward on it | 14:21 |
| rick_h_ | I need a spinner on a grey background and not sure if a fresh bug or something else it the right way to move it forward | 14:21 |
| === matsubara is now known as matsubara-lunch | ||
| rick_h_ | http://www.yuiblog.com/blog/2011/11/15/yui-3-5-0-roadmap-and-timelines/ | 14:40 |
| rick_h_ | deryck: ^ | 14:40 |
| abentley | deryck: lp:~abentley/launchpad/history-model | 14:45 |
| deryck | abentley, ok, will take a look now. | 14:46 |
| abentley | qastaging looks unhappy. Known issue? | 14:48 |
| deryck | abentley, not to me. Not sure if others know. | 14:49 |
| rvba | abentley: deryck The update failed this morning at 09:10:51 UTC | 14:50 |
| rvba | gnuoy has kicked it off again after that. | 14:50 |
| abentley | rvba: Cool, thanks. | 14:50 |
| rvba | s/has/ | 14:50 |
| rvba | Not sure were we're at now… gnuoy? | 14:51 |
| gnuoy | rvba, hi | 14:51 |
| === abentley changed the topic of #launchpad-dev to: qastaging is down, but being worked on. |https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 292 | ||
| rvba | gnuoy: hey, can you tell us where we're at with qastaging's update? | 14:52 |
| gnuoy | hmm, it hasn't logged anything for the past few hours | 14:52 |
| deryck | abentley, a ha! | 15:01 |
| deryck | abentley, the event name has changed since it's a new object. It's now: buglisting-model:fields-changed | 15:01 |
| abentley | deryck: I don't follow. The event is still being constructed using this.constructor.NAME + ':fields-changed' where NAME is buglisting-config-util | 15:03 |
| deryck | abentley, no, because NAME is the buglisting model object. the event is fired from the new object, not buglisting config util objects. | 15:04 |
| abentley | deryck: Ah, so this is a keyword-this trap. | 15:05 |
| deryck | abentley, right, in YUI's event handling "this" always gets bound back to the object firing the event. | 15:06 |
| gary_poster | sinzui, the "project group report" we talked about is the +milestones page for project groups, right? | 15:06 |
| deryck | abentley, or rather to the host object, since the event is the ATTR change event. | 15:06 |
| abentley | deryck: Okay, adding "this" to the end of .after() fixed it. | 15:07 |
| abentley | deryck: thanks! | 15:08 |
| deryck | abentley, yup. Long term, I think the addListeners stuff should move up to the model object, since it's really after that object updates that we're interested in. And then the tests updated. | 15:08 |
| deryck | abentley, np! | 15:08 |
| sinzui | gary_poster, yes, you can see an example of the report that is being used: https://launchpad.net/landscape-project/+milestone/11.11.2 | 15:17 |
| gary_poster | thanks sinzui | 15:17 |
| rick_h_ | gmb: if you get a quick second: https://code.launchpad.net/~rharding/launchpad/bug_814697_missing_spinner/+merge/83034 | 15:28 |
| abentley | deryck: btw, the trick of setting a global, e.g. "debug_me=true" and doing if(debug_me){debugger;} works pretty well. | 15:32 |
| === matsubara-lunch is now known as matsubara | ||
| deryck | abentley, ok, nice. I'll have to remember that. | 15:34 |
| deryck | gmb, I also have a branch that needs review, if you're not too overloaded. | 15:36 |
| gmb | rick_h_, Sure | 15:36 |
| gmb | deryck, I'm not. I'll take a look after rick_h_'s | 15:36 |
| deryck | gmb, awesome, thanks! https://code.launchpad.net/~deryck/launchpad/field-visibility-persistence-891780/+merge/83037 | 15:37 |
| gmb | sinzui, Any particular reason you assigned bug 867593 to me? | 15:37 |
| _mup_ | Bug #867593: Displayed number of comments hidden is sometimes +1 to the actual value <bugs> <comments> <regression> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/867593 > | 15:37 |
| deryck | abentley, bug 890745 is fixed release, right? I think it's another case of tagger not handling pre-reqs right. | 15:37 |
| _mup_ | Bug #890745: dynamic bug listings don't handle next and prev correctly on first and last batch <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/890745 > | 15:37 |
| sinzui | gmb, lifeless assigned a bug regarding comment numbering to you, tagged it as regression, then raised it to critical. He wanted your opinion... | 15:37 |
| abentley | deryck: that's right. | 15:38 |
| deryck | abentley, ok, thanks. | 15:38 |
| gmb | rick_h_, approved. | 15:38 |
| sinzui | But that bug was a dupe of an older bug. I made you the assignee of the master, and also a related bug that I think a numbering fix will also fix | 15:38 |
| rick_h_ | gmb ty | 15:38 |
| sinzui | gmb, so I am channeling lifeless and asking for you opinion of all bugs assigned to you tagged with "comments" | 15:39 |
| gmb | sinzui, Uhm, okay. I'm slightly confused as I don't know which bug it was that lifeless assigned to me. But I think for the sake of sanity we should unassign those bugs. I'm up to my eyes in bug 881019 at the moment so it makes more sense for someone else to take them if they have the time. | 15:41 |
| _mup_ | Bug #881019: Lp login is broken after account merge <merge-deactivate> <openid> <regression> <users> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/881019 > | 15:41 |
| sinzui | gmb, This is the bug I saw 45 minutes ago https://bugs.launchpad.net/launchpad/+bug/893375 | 15:43 |
| _mup_ | Bug #893375: Comment order wrong and not all comments shown <comments> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/893375 > | 15:43 |
| * gmb looks | 15:44 | |
| sinzui | gmb: you have my sympathies with that bug. I suspect the issues will not really be fixed until this feature is implemented with ISD: bug 770107 | 15:44 |
| _mup_ | Bug #770107: launchpad relies on login.ubuntu.com but does not sync email addresses <email> <feature> <openid> <Launchpad itself:Triaged> < https://launchpad.net/bugs/770107 > | 15:44 |
| gmb | sinzui, That may well be the case. Okay, now that I have a better idea what's going on, I'm happy enough to be assigned to those bugs. | 15:46 |
| gmb | Thanks for the clarification. | 15:47 |
| gmb | (I think the fencepost error is a result of the fact that the BugComment code basically consists of all the Aale of which bigjools's Luftkissenfahrzeug is always voll. | 15:49 |
| sinzui | gmb: really do not know what is going on. the openididentifier -> account <-person <- emailaddress -> account relationship seems to permit different answers on how you join... | 15:49 |
| gmb | sinzui, Yeah. It's a pain. At the moment I'm working on removing Person.account to see if that causes any fewer problems. Unfortunately, lots of things have now broken. | 15:50 |
| sinzui | gmb ... So the code that might try to setup or fix user data may get an different set of linked object when logging the userin or showing a list of object | 15:50 |
| sinzui | gmb so email is the link between person and account? | 15:50 |
| gmb | sinzui, That's the plan (you suggested it here https://bugs.launchpad.net/launchpad/+bug/881019/comments/1, which is where I got the idea from). | 15:54 |
| _mup_ | Bug #881019: Lp login is broken after account merge <merge-deactivate> <openid> <regression> <users> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/881019 > | 15:54 |
| abentley | deryck: the only place we should be using field_visibility_defaults is when the user asks us to reset to the default. In other places, we should be using field_visibility. | 15:54 |
| gmb | Unfortunately, it _might_ be too inefficient. Not sure yet because I haven't got the test suite passing. | 15:54 |
| deryck | abentley, agreed. Did I not do this somewhere? | 15:55 |
| abentley | deryck: Yes, in the getter and setter for BugListingConfigUtil.field_visibility | 15:55 |
| sinzui | gmb: Yes, I was not certain it would scale. | 15:57 |
| deryck | abentley, do you mean the valueFn? | 15:57 |
| abentley | deryck: yes, the valueFn and the setter. | 15:57 |
| deryck | abentley, so the valueFn only returns default values. it will never be used in most cases, where you pass in a config. if nothing was defined, I think we should use field_visibility_defaults there.... | 15:58 |
| abentley | deryck: If nothing was defined, I think we should use LP.cache.field_visibility. | 15:59 |
| deryck | abentley, I guess that's fine. | 16:00 |
| abentley | deryck: Those are the setting that were used to render the initial view. | 16:00 |
| abentley | i.e. server-side. | 16:00 |
| deryck | abentley, sure. That's probably better. I initially liked be explicit with a config, which is why I didn't sniff the cache for it.... | 16:01 |
| deryck | abentley, but that will fix the issue of the bar not being in sync with the page, and we can drop the explicit config on object creation. | 16:02 |
| deryck | abentley, as for the setter, I'm trying to recall why I merged with the defaults there. I had some reason that escapes me, but hopefully the tests will reveal that if you change it to merge with field_visibility. | 16:03 |
| abentley | deryck: But you do sniff the cache, implicitly, by using get('field_visibility_defaults'), which hits the cache. | 16:03 |
| abentley | deryck: So it's a question of which cache value you hit, and if field_visibility_defaults is defined field_visibility is also defined and better. | 16:05 |
| deryck | abentley, right, I'm fine to change it to sniff for field_visibility. Was just trying to explain my reasoning, i.e how the code go to where it is. | 16:05 |
| abentley | deryck: okay. It wasn't clear to me that the valueFn was intended to be a fallback. | 16:07 |
| deryck | abentley, yeah, that's all I was trying to say, in that the common case, and in current template usage, it's never hit. | 16:07 |
| deryck | abentley, but if we make that change to sniff for field_visibility, we can drop the explict config for field_visibility from the template and fix a bug. | 16:08 |
| sinzui | Does anyone know of a way query users to know if someone was former canonical employee? | 16:09 |
| sinzui | Ah, I had to type that to remember I can check the TeamMembership deactivated status | 16:09 |
| abentley | deryck: I'd rather make field_visibility and field_visibility_defaults mandatory. We can just pass the LP.cache in as the config object. | 16:10 |
| deryck | abentley, as the config or as part of the config? | 16:13 |
| abentley | deryck: I meant as the config, but we could pass it in as part of the config instead. | 16:14 |
| deryck | abentley, if we do, let's make it part, so we don't have to append srcNode type configs to the cache, or our reference of it..... | 16:14 |
| deryck | abentley, but what is the advantage of passing it in, versus sniffing for it? We only need it in a couple places. | 16:14 |
| abentley | deryck: I don't know what a "srcNode type config" is. | 16:15 |
| abentley | deryck: decoupling and explicitness. | 16:15 |
| deryck | abentley, I meant srcNode type of things that go in the config. i.e. we have to specify things that are in ATTRS plus srcNode beyond just field_visibility. | 16:16 |
| abentley | deryck: I don't know what srcNode is. | 16:16 |
| deryck | abentley, srcNode is what the widget framework uses to know where on the page to stick the widget you're rendering. | 16:17 |
| deryck | srcNode: Y.one('#mydiv-for-this-widget') | 16:17 |
| deryck | that ^^ goes in config usually, beyond any custom attrs. | 16:17 |
| abentley | deryck: Okay but that's needed for the BugListingConfigUtil, not the model. Right now, the model just needs field_visibility and field_visibility_defaults. | 16:18 |
| deryck | abentley, right. | 16:18 |
| deryck | abentley, also, can we just pass around values in the config, rather than the whole cache. and maybe that's what you meant. | 16:18 |
| deryck | so field_visibility: LP.cache.field_visibility rather than config.cache = LP.cache. | 16:19 |
| deryck | abentley, hmmm, well I guess for the model object the cache actually does make sense as the config.... | 16:20 |
| deryck | abentley, sorry, I'm stuck thinking about BLCU. | 16:20 |
| abentley | deryck: so we certainly can do new BugListingModel({field_visibility: LP.cache.field_visibility, field_visiblity_defaults: LP.cache.field_visibility_defaults}), but it just seems verbose at this point. | 16:20 |
| deryck | abentley, if you only needs those two bits from the cache, I prefer that. But I'm not going to be a jerk about it. :) | 16:21 |
| deryck | abentley, but if you need more from the cache, using it as the config is fine. | 16:21 |
| gmb | deryck, approved, with comments. | 16:33 |
| deryck | gmb, thanks! Good suggestions all the way around. | 16:35 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| === salgado is now known as salgado-lunch | ||
| === gmb changed the topic of #launchpad-dev to: qastaging is down, but being worked on. |https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 292 | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === salgado-lunch is now known as salgado | ||
| james_w | if I've got one of the new hash-style oops that should still be findable via lp-oops shouldn't it? | 18:21 |
| rick_h_ | abentley deryck either of you guys have a sec to help me figure out what I'm missing from getting yui simulate to help me test my events? | 18:22 |
| lifeless | yes, if it has synced to devpad | 18:22 |
| lifeless | production doesn't have the rabbit config toggled on yet (liam is still getting the glitches out of monitoring) | 18:22 |
| james_w | yep, just wanted to make sure I wasn't sat here hitting refresh for nothing | 18:22 |
| deryck | rick_h_, did you include node-event-simulate in the requires line for the test module? | 18:23 |
| rick_h_ | yea | 18:23 |
| rick_h_ | and if I manually interact with the html on the page the event fires | 18:23 |
| rick_h_ | so everything seems "hooked up" | 18:23 |
| rick_h_ | but running node.simulate('keyup') or 'valueChange' isn't doing me any good for automated testing | 18:23 |
| deryck | rick_h_, so everything in the basic example here matches what you're doing? http://yuilibrary.com/yui/docs/event/index.html#simulate | 18:25 |
| rick_h_ | deryck: yea, loggerhead is hating me, but the relevent bits: http://paste.ubuntu.com/746203/ | 18:27 |
| rick_h_ | oh, nvm | 18:30 |
| rick_h_ | I had to do it right, can't simulate valueChange and when simulating keyup, you need the value code and the keydown to go with it | 18:32 |
| rick_h_ | http://paste.ubuntu.com/746211/ changing to that works | 18:33 |
| deryck | rick_h_, alrighty then. there you go. :) | 18:34 |
| rick_h_ | am I missing an easy way to check assertion counts in YUI test? I see Y.assert has a count and _getCount() but nothing public I'm seeing | 18:50 |
| deryck | rick_h_, what are you wanting to count? how many assertions you make? | 18:52 |
| rick_h_ | yea, sanity check because I've got to do some timeout waiting | 18:52 |
| rick_h_ | so want to verify that there were 3 assertions in this test kind of thing | 18:53 |
| === jcsackett_ is now known as jcsackett | ||
| deryck | rick_h_, do you know about "waits"? Are you using that, or actual setTimeouts? | 18:54 |
| rick_h_ | yea, I'm using a setTimeout right now. I guess if I go to wait/resume it'd "catch" the case I'm looking for | 18:55 |
| rick_h_ | nvm then, I'll try to find out later on. Seems like there's some stuff there for it, but my searches are coming up empty | 18:56 |
| deryck | rick_h_, yeah, I think it would be better to use waits then count the assertions. | 18:59 |
| rick_h_ | gotcha, thanks | 18:59 |
| === jcsackett_ is now known as jcsackett | ||
| rick_h_ | deryck: for this plugin, is there a good place to document it at? | 19:46 |
| rick_h_ | the doc directories all seem really just doctests | 19:46 |
| deryck | rick_h_, the dev wiki is where we tend to put pure documentation. | 19:47 |
| deryck | rick_h_, and we usually do a launchpad-dev email to say "hey I did this, it's available, and docs are at $LINK" :) | 19:47 |
| rick_h_ | ah ok, was looking for things like usage examples and such for the lazr stuff in the code | 19:48 |
| rick_h_ | deryck: ok, phew...let my first big MP get a thrashing! https://code.launchpad.net/~rharding/launchpad/bugfix_891735/+merge/83068 | 20:19 |
| deryck | rick_h_, that's a nice size change. :) | 20:20 |
| deryck | rick_h_, can you hunt around for another reviewer. Trying to get stuff landed I'm behind on. | 20:21 |
| rick_h_ | little better than one liners so far? | 20:21 |
| rick_h_ | sure thing | 20:21 |
| deryck | rick_h_, but if no one else can do it, I will, certainly. | 20:21 |
| rick_h_ | understand, was an FYI | 20:21 |
| rick_h_ | come out reviewers come out wherever you are please | 20:21 |
| rick_h_ | fresh meat to hack up on | 20:21 |
| rick_h_ | jcsackett abentley or should I ping anyone else in particular? no rush on things | 20:22 |
| abentley | rick_h_: I'm happy to look at it. | 20:22 |
| rick_h_ | awesome, thanks! | 20:24 |
| abentley | rick_h_: Could you add a screenshot, please? | 20:24 |
| rick_h_ | abentley: I guess, it just looks like a textarea | 20:25 |
| rick_h_ | I don't dress anything up at all | 20:25 |
| rick_h_ | a movie perhaps? | 20:25 |
| rick_h_ | or would that be a bit much | 20:25 |
| abentley | rick_h_: We usually request screenshots for UI changes, but if there's nothing to see, that's okay. | 20:25 |
| rick_h_ | yea, it's invisible until you use it | 20:26 |
| abentley | rick_h_: lifeless has a good point. We already have auto-sizing behaviour for bug descriptions, just not on bug creation. | 20:31 |
| rick_h_ | right, I noted that in my MP. It definitely does, and it's built around multiple elements, only on edits, and the whole toolbar/save event workflow | 20:33 |
| abentley | rick_h_: I thought you were referring to the bug title. | 20:33 |
| rick_h_ | in discussion it was thought this was light enough and different enough to be useful since the inlineedit isn't easily pulled out atm to use for this | 20:33 |
| rick_h_ | no, in the pre-impl note? | 20:34 |
| abentley | rick_h_: It seems pretty unfortunate to have different widgest for creating text fields vs editing them, don't you think? | 20:35 |
| rick_h_ | yes, definitelty, but the original goal here was that if this gets tested and is ok, we could enable this across all textareas on the site as part of the global ui | 20:36 |
| rick_h_ | which is a bit hard to do with the inlineedit module | 20:36 |
| rick_h_ | out of this I've got a couple of bugs to push against the inline edit to help it's resizing, and then as a larger scope can look to see if somehow that can use this plugin for handling textareas | 20:36 |
| rick_h_ | but it's very tied in currently | 20:37 |
| abentley | rick_h_: I really don't get it. Bad enough to have an inconsistent one-off field, far worse to have many inconsistent fields. | 20:39 |
| rick_h_ | inconsistent how? | 20:39 |
| rick_h_ | I admit that just adding to this one place in the bug report isn't great, but that's where the bug/idea came out of and it needed a home to start at | 20:40 |
| abentley | rick_h_: you'd have a better idea than me, but generally when there are two implementations of something, they are never quite consistent. | 20:40 |
| rick_h_ | I didn't want to make it global without getting it in front of more people/eyes | 20:40 |
| rick_h_ | abentley: yes, true. but this is only resizing, while the other is an implmentation that includes some resizing logic | 20:41 |
| rick_h_ | but really deals with a lot more | 20:41 |
| rick_h_ | some parts are definitely something to add to the inlineedit, support for min/max heights and such | 20:41 |
| rick_h_ | but it's really a lot more than just a resizing widget | 20:42 |
| rick_h_ | and stripping that logic out to make it global was deemed more work than it's worth at the moment | 20:42 |
| abentley | rick_h_: By doing this, you'd be adding tech debt. Bug #723417 doesn't seem to justify adding tech tebt-- it could just be solved by changing a CSS class or something. | 20:47 |
| _mup_ | Bug #723417: Further information input area shrunk making it difficult to input and review details <bugs> <qa-ok> <regression> <ui> <Launchpad itself:Fix Released by rharding> < https://launchpad.net/bugs/723417 > | 20:47 |
| flacoste | rick_h_: wouldn't be possible to implement this as YUI plugin? | 20:47 |
| flacoste | that could be used standalone like here | 20:47 |
| abentley | flacoste: he has. | 20:47 |
| rick_h_ | yes, that's how it's implemented | 20:48 |
| flacoste | and used on the textarea editor | 20:48 |
| deryck | I chatted with him about the inline editor. | 20:48 |
| flacoste | then couldn't use this plugin in the textarea inline editor? | 20:48 |
| rick_h_ | long term it's possible. Right now there isn't clear separation of that in the inline editor | 20:48 |
| flacoste | right | 20:48 |
| rick_h_ | so it needs some updates to be able to use this plugin as a base for multiline | 20:48 |
| flacoste | that's well possible | 20:48 |
| deryck | abentley, flacoste -- the inline editor tightly couples the single line and multi-line editor to the same widget. | 20:48 |
| rick_h_ | right | 20:48 |
| deryck | that's the tech debt, really. | 20:49 |
| deryck | it's not like he can just plug the text area, which is what I also suggested. | 20:49 |
| flacoste | right | 20:49 |
| flacoste | the inline editor needs some love | 20:49 |
| deryck | it's a lot of work to make the inline editor clean first. | 20:49 |
| deryck | right | 20:49 |
| deryck | once the inline editor is cleaned up, then yes, it would be trivial to plug the text area for resize. | 20:50 |
| flacoste | so we are all in agreement then! | 20:50 |
| flacoste | this approach is sane | 20:50 |
| rick_h_ | agreed, would love to hack on it some. This was kind of a chance for my first "large" work through the JS code and the process | 20:50 |
| flacoste | once we clean the inline editor mess | 20:50 |
| deryck | yeah. | 20:50 |
| flacoste | we can use this new clean plugin to remove the coupled functionality in the editor | 20:50 |
| deryck | yup | 20:50 |
| abentley | deryck: there can be multiple pieces of tech debt. | 20:50 |
| deryck | abentley, sure. But I don't think this is creating debt. | 20:51 |
| deryck | abentley, it's saying "here's the one true way to do resizing text areas." | 20:51 |
| deryck | abentley, the debt already exists in that the inline editor was poorly factored to start with. and can't make use of this one true way. | 20:51 |
| abentley | deryck: To me, duplicating functionality is tech debt pretty categorically. | 20:51 |
| deryck | abentley, we're not really duplicating. There is no generic way to resize text areas. The inline editor resizes as one of a million things that it does. ;) | 20:52 |
| deryck | bear in mind, I have no issues with rick_h_ continuing work on this in a follow up branch to clean up the inline editor. | 20:53 |
| abentley | deryck: I understand that there is no generic way to resize text areas. | 20:54 |
| deryck | abentley, so do you think he shouldn't land this? | 20:54 |
| abentley | deryck: I still see it as functionality duplication. | 20:54 |
| deryck | abentley, so are you suggesting he shouldn't land it? Or that he shouldn't land it without also fixing the inline editor? | 20:55 |
| abentley | deryck: I am not happy either saying he shouldn't land it or that he should. | 20:56 |
| deryck | heh | 20:56 |
| deryck | come on, commit! :) | 20:56 |
| abentley | deryck: This is a case where code review is covering pre-implementation material. | 20:57 |
| rick_h_ | hah, I knew my first code would get a tearing into! | 20:57 |
| abentley | deryck: and that always sucks. | 20:57 |
| deryck | abentley, yeah, it does. but he and I did discuss that in a pre-imp. it's a lot of work to rip that stuff out of the editor and add this. and I saw value in him getting this widget first and then turning to the editor. | 20:58 |
| deryck | abentley, would you have suggested something different? | 20:58 |
| abentley | deryck: Yes, I would have said if we don't want to work on the in-line editor, we should delay working on a generic resizable textarea until we are ready to work on it. | 20:59 |
| === almaisan-away is now known as al-maisan | ||
| deryck | abentley, well, I never said we don't want to work on the inline editor. But also, I do see value in this by itself. How can someone clean up the editor if they don't have this to replace the current stuff that's bad? | 21:00 |
| deryck | I definitely think doing both in the same branch is too much. | 21:00 |
| abentley | deryck: They can clean up the editor by extracting its resizing functionality and making it modular. | 21:02 |
| abentley | deryck: And then making it pluggable. | 21:02 |
| rick_h_ | so what if I were to remove the one place it's currently used, and just try to land as "added a plugin" for now based on code/tests | 21:03 |
| rick_h_ | and then work on the inline edit using this plugin as a next step before it gets used anywhere | 21:03 |
| deryck | abentley, no, you can't extract it. you need to first convert the single inline editor widget into two widgets, one for text inputs and one for text areas. | 21:04 |
| abentley | deryck: I haven't looked at that code. Maybe that's true in this case. | 21:06 |
| deryck | abentley, it is, I promise. I'm not trying to be a dick. I'm just telling you it is a lot of work to fix. | 21:07 |
| deryck | and it's really not worth pulling out; it's poorly written, using an updateSize thing that is called after so many different events. | 21:07 |
| === matsubara is now known as matsubara-afk | ||
| abentley | rick_h_: I would rather not commit unused code. If you're actually committing to fixing the tech debt by fixing the inlineeditor, that is enough for me. | 21:08 |
| deryck | abentley, FWIW, I'm fine with rick_h_ committing to doing the follow up work. | 21:13 |
| deryck | i.e. I don't have anything else he has to do instead of that. | 21:13 |
| abentley | deryck: You should also understand that I'm on my third day of de-duplicating functionality, and so I'm perhaps more sensitive to these issues than normal. | 21:14 |
| deryck | abentley, yeah, fair enough. :) | 21:14 |
| rick_h_ | well I have to run here in a sec. What should I do from here? | 21:15 |
| abentley | rick_h_: I see you're setting skip_animations true, so why do we need to wait "a slight sec"? | 21:16 |
| deryck | rick_h_, if you're leaving, let's just take up the issues in the standup, if abentley doesn't mind. | 21:16 |
| deryck | standup tomorrow, I mean. | 21:17 |
| abentley | rick_h_: we can pick up tomorrow. I'm the on-call-reviewer anyway, tomorrow. | 21:17 |
| rick_h_ | abentley: because in testing, chrome was too fast that if I checked right away it still grabbed the orig sizing values | 21:17 |
| rick_h_ | and the 100ms there seemed to slow it down just enough for chrome to finish the ui redraw | 21:17 |
| rick_h_ | abentley: ok, sounds good to me | 21:17 |
| rick_h_ | thanks and sorry for the trouble | 21:18 |
| deryck | abentley, while I have you, too :) Does mustache have a syntax for negative conditions? I assume there's no "else" block, but is there an "if this value is None" kind of expression? | 21:18 |
| abentley | rick_h_: np | 21:18 |
| abentley | deryck: Yes. | 21:18 |
| abentley | deryck: e.g. {{^repo}}{{/repo}} | 21:19 |
| deryck | abentley, ah, thanks! I would have never guessed the ^. And I couldn't find it in docs. | 21:20 |
| deryck | abentley, now searching docs for "^" I do ;) | 21:20 |
| abentley | deryck: :-) | 21:20 |
| deryck | it was also something hard to google for. I got lots of "Are mustaches hot or not" hits. | 21:24 |
| === jcsackett_ is now known as jcsackett | ||
| === al-maisan is now known as almaisan-away | ||
| poolie | hi all | 22:23 |
| flacoste | hi poolie | 22:24 |
| flacoste | poolie: what's happening with https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408? | 22:24 |
| flacoste | do we have anybody on the hook to integrate this? | 22:24 |
| poolie | no | 22:24 |
| poolie | i think there should be | 22:24 |
| poolie | :( | 22:24 |
| poolie | it is a real shame it has been neglected for so long | 22:25 |
| poolie | so | 22:26 |
| poolie | perhaps i am well placed to shepherd it in | 22:27 |
| flacoste | poolie: thanks! | 22:27 |
| flacoste | i think it only requires a merge to loggerhead, updating the version in LP and then QA? | 22:28 |
| poolie | probably a ton of qa | 22:29 |
| poolie | i think that's the main real commitment | 22:30 |
| huwshimi | "17045 tests run in 4:54:26.362705, 1 failures, 303 errors" hah! | 23:00 |
| wgrant | Heh | 23:04 |
| wgrant | Which branch was that? | 23:04 |
| StevenK | wgrant: Opinions on http://pastebin.ubuntu.com/746479/ ? | 23:06 |
| wgrant | I guess. | 23:07 |
| StevenK | wgrant: I'm still working on the branch, so if you'd prefer a loop or something, say something. :-P | 23:07 |
| huwshimi | wgrant: Oh, the branch was to do with the tag cloud, the errors were all because "ImportError: No module named lpbuildd" | 23:12 |
| wgrant | huwshimi: Ah, merge devel. | 23:12 |
| huwshimi | wgrant: Yeah, I figured that might fix it | 23:12 |
| mwhudson | should make it about an hour quicker too... | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!