[01:05] <wallyworld_> StevenK: is only workaround to downgrade convoy? ImportError: No module named convoy.meta
[01:06] <wgrant> sudo apt-get install convoy/precise
[01:06] <wgrant> should do it
[01:06] <wallyworld_> so pkg has been updated in repos?
[01:06] <wgrant> No, downgraded.
[01:06] <wgrant> That should still downgrade it
[01:07] <wallyworld_> ok,will try thanks
[01:07] <wallyworld_> all good
[01:16] <StevenK> wallyworld_: I'm working on it.
[01:20] <wallyworld_> np. i downgraded to the previous version
[01:35] <StevenK> wgrant: I don't think I need Provides: convoy, right?
[01:35] <wgrant> StevenK: Hopefully only launchpad-developer-dependencies depends on it, indeed.
[01:35] <wgrant> So just C/R
[01:45] <wgrant> sinzui: I see your progressive-enhancement-ftw branch touches the inline-picker.pt, which has a div inside a span, which is illegal. Any chance you could look at fixing that?
[01:46] <wgrant> Not sure what it's doing there, but it's probably simple to eliminate.
[01:46] <wgrant> I hope.
[03:02] <StevenK> Woo
[03:02]  * StevenK rips out five self.assertEquals() and replaces it with MatchesStructure()
[03:05] <wallyworld_> wgrant: is it preferred to use a CTE or subsquery to force a distinct to be evaluated before a sort?
[03:07] <lifeless> wallyworld_: trick question, there's no point evaluating distinct right before a sort
[03:07] <lifeless> wallyworld_: as doing distinct requires sorted data
[03:07] <wgrant> You also have to be careful about doing that with resultsets, as Storm will apply the limit to the outside.
[03:08] <wgrant> You need to play around to see what performs well.
[03:08] <lifeless> wallyworld_: whats the big picture ?
[03:08] <wallyworld_> such an optimisation was done for a query on the accesspolocygrantflat table already though
[03:09] <wallyworld_> lifeless: i am looking at a query which returns a number of rows which when distinct is applied will be far less
[03:09] <wallyworld_> and i need the result to be ordered on one of the columns which distinct will operate with
[03:09] <wgrant> Need to know specifics.
[03:11] <wallyworld_> lifeless: wgrant: https://pastebin.canonical.com/64992/
[03:11] <wallyworld_> i'm experimenting atm with a couple of approaches
[03:12] <wallyworld_> a single query and a bit of python to loop over the result set vs 2 queries
[03:12] <lifeless> https://pastebin.canonical.com/64993/
[03:12] <wallyworld_> the sql pasted would be for the single query approach. the will be many rows with SOME and these need to be reduced down to 1 per grantee
[03:13] <lifeless> your current query conflats distinct columns and calculate results
[03:13] <wallyworld_> yes it does, i hadn't finished it yet, just threw up something quickly cause you asked :-)
[03:14] <lifeless> indeed, so the thing is you asked about forcing an operaiton order; but that sort of optimisation always happens after you can express what you want basically :)
[03:14] <wallyworld_> so, without the distinct, the result set might be largish. and order by is done first right?
[03:14] <lifeless> no
[03:14] <lifeless> order by is done depending on the plan
[03:14] <lifeless> it may use an index
[03:15] <lifeless> it may sort in memory
[03:16] <wallyworld_> ok. there was a bit of sql already refactored and the comment was that we wanted to force the distinct to be done first since the sort by time dominated the query time
[03:16] <lifeless> it may be different on each execution depending on the params
[03:16] <wallyworld_> so a sub query was used
[03:16] <wgrant> You need to test with both Ubuntu and Launchpad.
[03:16] <wgrant> as targets
[03:16] <lifeless> wallyworld_: for this case or another case? Tuning is a vicious cycle of iteration and experimentation
[03:16] <wallyworld_> lifeless: another case
[03:16] <lifeless> in which case, ignore it. Optimise this separately.
[03:17] <wallyworld_> ok. i wasn't sure if we were dealing with a postgres quirk or not
[03:17] <wallyworld_> s/quirk/generalisation
[03:17] <wgrant> postgres quirks are completely situation-dependent.
[03:17] <wgrant> You have to test.
[03:17] <lifeless> I have a couple of thoughts
[03:18] <lifeless> what do you want to show when both an artifact and  non-artifact grant are present ?
[03:18] <lifeless> or do we prevent that ?
[03:18] <wallyworld_> we show ALL
[03:18] <wallyworld_> but i now need to know of there are SOME also
[03:18] <wallyworld_> whereas before we didn't need to know that
[03:20] <wallyworld_> so previously the query i pasted used MIN(COALESCE(artifact, 0)) and a group by
[03:20] <wallyworld_> if i keep that i need a second query
[03:21] <wallyworld_> or i remove the MIN and have one query with a distinct and order by and a bit of python logic
[03:24] <wallyworld_> lifeless: actually, i take it back. i don't need the 'distinct on', just plain old distinct.
[03:25] <wallyworld_> for my use case
[03:26] <wgrant> You also don't care about order there, do you?
[03:27] <wallyworld_> wgrant: it makes the post processing easier but is not strictly necessary. if the distinct is run first, the order by is trivial
[03:27] <lifeless> what about https://pastebin.canonical.com/64994/
[03:27] <wallyworld_> hence my wanting to run distinct first
[03:28] <lifeless> you'll get up to two rows for any grantee,policy pair
[03:28] <lifeless> one with the min null and True
[03:28] <lifeless> one with a min value and False
[03:29] <wallyworld_> it's missing the group by but perhaps
[03:29] <lifeless> why would it need one ?
[03:30] <wgrant> We need to know (person, person, artifact grant?, policy grant?)
[03:30] <wgrant> s/person, person/person, policy/
[03:30] <lifeless> well, this gives you that but not folded into one row
[03:31] <lifeless> if you are paginating, you might need the fold
[03:31] <lifeless> but if you are paginating, you might want to avoid entire-context processing, which group by will need
[03:31] <wgrant> This is post-pagination
[03:31] <wallyworld_> lifeless: the group by is needed because there's a min() in the select
[03:31] <lifeless> wallyworld_: oh duh, of course.
[03:32] <wallyworld_> my original query works. wgrant, could you possibly run https://pastebin.canonical.com/64992/ on dogfood, adjusting ids for ubuntu?
[03:34] <wgrant> 90ms for me + ubuntu-crashes-universe
[03:34] <wgrant> So very slow
[03:35] <lifeless> wgrant: how does mine run ?
[03:35] <wgrant> Buggily
[03:35] <lifeless> wgrant: with an appropriate group by
[03:36] <wallyworld_> wgrant: perhaps https://pastebin.canonical.com/64995/
[03:36] <lifeless> wgrant: does qas have appropriate data ?
[03:36] <wgrant> qas has appropriate data
[03:36] <wgrant> lifeless: Your thing has no chance of running without a rewrite
[03:36] <wgrant> It uses artifact in both an aggregate and a non-aggregate.
[03:37] <lifeless> what are the right constants for you + u-c-u ?
[03:37] <wgrant> wallyworld_: 120ms
[03:37] <wallyworld_> so even worse :-(
[03:37] <wgrant> lifeless: SELECT id FROM accesspolicy WHERE distribution = 1
[03:38] <wgrant> And (21997, 1324721)
[03:38] <wallyworld_> wgrant: maybe a subselect?
[03:38] <wgrant> Well
[03:38] <lifeless> 72ms
[03:39] <lifeless> wgrant: all specific grants atm right ?
[03:39] <wgrant> For those constraints, yes.
[03:39] <wgrant> Ah
[03:39] <lifeless> SELECT DISTINCT grantee, policy, min(artifact), artifact is NULL FROM AccessPolicyGrantFlat
[03:39] <lifeless> WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (65,66)
[03:39] <wgrant> The old query is 80ms for the same data on DF, so the 90ms before wasn't too bad.
[03:39] <lifeless> GROUP BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, artifact is NULL
[03:40] <lifeless> ORDER BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy;
[03:41] <wallyworld_> so what's the concensus?
[03:42] <wallyworld_> one was run on dogfood, the other qas so can't really compare
[03:43] <wgrant> SELECT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, NOT bool_and(artifact IS NOT NULL), bool_or(artifact IS NOT NULL)
[03:43] <wgrant> FROM AccessPolicyGrantFlat WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (130423, 130464) GROUP BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy
[03:44] <wgrant> SELECT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, bool_or(artifact IS NULL), bool_or(artifact IS NOT NULL)
[03:44] <wgrant> FROM AccessPolicyGrantFlat WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (130423, 130464) GROUP BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy
[03:44] <wgrant> better
[03:44] <wgrant> 78ms on DF
[03:44] <wallyworld_> i haven't seen bool_or before
[03:45] <wgrant> I've never had cause to use it before, either.
[03:45] <wgrant> But I think it fits well here.
[03:45] <wallyworld_> what's it do?
[03:45] <wgrant> It's an aggregate function that computes the boolean OR.
[03:45] <wallyworld_> ah right, nice
[03:45] <wgrant> Which is, I think, exactly what we want here.
[03:46] <wallyworld_> well, before the queru produced column values 'ALL' or 'SOME' not true or false
[03:46] <wgrant> Yeah
[03:46] <wgrant> But that doesn't really make sense any more
[03:46] <wallyworld_> so i could CASE it
[03:46] <wgrant> Since we may need to return both.
[03:46] <wallyworld_> sure
[03:47] <wallyworld_> wgrant: so there's so order by there. that would make post processing easier
[03:47] <wallyworld_> but if it adds too much overhead
[03:48] <wgrant> You can just stick an ORDER BY on the end
[03:48] <wgrant> Doesn't affect performance in this case.
[03:48] <wgrant> Since it has to do the hashagg first.
[03:48] <wallyworld_> rightio
[03:49] <wallyworld_> wgrant: seems to work ok locally too. thanks. updating code now....
[03:50] <wgrant> Great.
[04:01] <wgrant> Hm
[04:02] <wgrant> So it looks like tag searching becomes much faster if I remove all the INTERSECT crap
[04:02] <lifeless> wgrant: the bool_or is redundant there
[04:02] <wgrant> lifeless: How?
[04:03] <lifeless> foo is null is boolean already
[04:03] <lifeless> ditto is not null
[04:03] <wgrant> I use them for the aggregateness
[04:03] <wgrant> Not the boolness
[04:04] <wgrant> Hm. I guess since we paginate before this, we could possibly just get DISTINCT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, artifact IS NULL.
[04:04] <wgrant> Since we don't need a single row per person
[04:04] <lifeless> wgrant: huh, please enlarge
[04:04] <lifeless> (on the aggregateness)
[04:05] <wgrant> lifeless: I want the aggregate
[04:05] <wgrant> Directly requesting a non-distinct bool is not an aggregate.
[04:05] <lifeless> oh right, I see
[04:05] <lifeless> handy
[04:05] <wgrant> But a distinct bool is probably sufficient here, since we don't care about pagination in this query
[04:06] <wgrant> EXPLAIN ANALYZE SELECT DISTINCT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, artifact IS NULL
[04:06] <wgrant> FROM AccessPolicyGrantFlat WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (130423, 130464) ORDER BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy;
[04:06] <wgrant> is pretty much the same speed and less ugly, but will return up to two rows per person
[04:06] <wgrant> And is sort of the obvious way to go.
[04:06] <wgrant> wallyworld_: ^^
[04:06] <lifeless> indeed
[04:06] <lifeless> its roughly, except cleaner, what I originally suggested.
[04:07] <wgrant> And working :)
[04:07] <wgrant> lifeless: Have you reworked the tag searching stuff at all?
[04:07] <lifeless> no
[04:07] <wallyworld_> wgrant: i really want one row per person. the query with bool_or is better
[04:07] <wgrant> k
[04:07] <wgrant> plans are identical
[04:07] <wgrant> So just query prettiness, really
[04:08] <wallyworld_> wgrant: and the order by is done outside this bit by the batching stuff i realised
[04:08] <wgrant> Well, yeah, (person.id, policy.id) is hardly going to be a user-friendly sort. I assumed it simplified your code somehow.
[04:09] <wallyworld_> it would have but now we have one row per person so it doesn't matter
[04:09] <wallyworld_> ah never mind, forget my comment about batching - different query
[04:10] <wgrant> lifeless: https://pastebin.canonical.com/64996/ is what ALL tag search queries look like now
[04:10] <wgrant> lifeless: Replacing the EXISTS ( ... INTERSECT ... ) with EXISTS ( ... ) AND EXISTS ( ... ) is about 30 times faster.
[04:10] <wgrant> I guess it plans better from the tag counts.
[04:11] <wgrant> I guess I'll do it behind a flag and see what happens.
[04:11] <wgrant> Because it, like, makes Ubuntu multi-tag searches not take 10s.
[04:11] <wgrant> (although it was 20s in the old schema)
[04:20] <lifeless> wgrant: I tweaked it for the old schema at one point
[04:20] <lifeless> wgrant: I'm glad you can get it better
[04:26] <lifeless> wgrant: did you end up making an array for tags ?
[04:26] <wgrant> lifeless: Not in this round.
[07:07] <adeuring> good mornin
[07:42] <stub> Grrr... lifeless stole my namespace with lazr.postgresql.
[07:45] <stub> What do we have besides lazr? Need to package a Python library containing PG helpers.
[07:45] <wgrant> lazr.postgresql, maybe? :)
[07:46] <stub> :-P
[07:48] <stub> Lot of renaming to move that db patch buildout application
[07:59] <lifeless> stub: huh, shove your stuff in there.
[07:59] <lifeless> stub: its what its there for
[07:59] <stub> And the obvious name for lazr.postgresql application has now been taken - might be interesting. http://pypi.python.org/pypi/pgmigrate2/1.2.2
[08:00] <lifeless> hah
[08:00] <lifeless> stub: so seriously, put your helpers in lazr.postgresql; theres plenty of namespace within that
[08:00] <lifeless> stub: I just hadn't bothered moving stuff it didn't need.
[08:00] <lifeless> (into it)
[08:00] <stub> lifeless: Merging the buildout driven application and my helper library looks like a packaging mess
[08:00] <lifeless> stub: how so?
[08:01] <lifeless> stub: which helper library ?
[08:01] <stub> One I'm going to assemble so I can get common CLI, helpers like ConnectionString etc. available for our various scripts (backups, database report) without pulling in a Launchpad tree or cargo culting.
[08:02] <stub> Been cargo culting so far and finally got sick of it.
[08:02] <lifeless> stub: great; buildout should be fine for that.
[08:02] <lifeless> stub: its got a very small dep footprint
[08:02] <lifeless> stub: and will play nice with e.g. pip or virtualenv (which btw we probably want to do a mass migration to)
[08:03] <stub> I'm thinking a .deb
[08:03] <lifeless> stub: still no problem, I wanted lazr.postgresql to end up deb'd too with a primarily CLI interface.
[08:04] <stub> Python packages into .deb seem not hard if you are using setup tools. Buildout?
[08:04] <lifeless> stub: its still setuptools
[08:04] <lifeless> stub: don't overthink it :>
[08:04] <lifeless> stub: buildout is for local dev mode; you can totally ignore it as far as delivery of debs is concerned.
[08:04] <stub> I'm used to using buildout assembing a tree
[08:04] <lifeless> separate problems.
[08:04] <lifeless> buildout will give you the dev environment.
[08:04] <lifeless> The deb stuff will be a separate packaging tree anyhow.
[08:05] <stub> Yer, just as long as I can get 'python setup.py install' to install mystuff my limited packaging skills should suffice.
[08:06] <lifeless> which buildout doesn't affect ;)
[08:06] <lifeless> also you might like to use pkgme for deb stuff
[08:07] <lifeless> stub: all that said, the -ops are good at getting buildout trees onto machines via deploymgr, so you might be good to go just as-is, with no packaging effort.
[08:08] <stub> It will end up being used by stuff like lp:losa-db-scripts. Getting helpers on the standard PYTHONPATH seems best to me.
[08:08] <wgrant> While you're here, I think there is an issue with your assignees-must-have-visibility policy.
[08:08] <wgrant> lifeless: ^^
[08:08] <lifeless> stub: sure
[08:08] <lifeless> wgrant: whats issue ?
[08:08] <wgrant> lifeless: I've fixed lots of bugs in my company's private project.
[08:08] <lifeless> stub: we should do a catchup; after wgrant grills me ?
[08:08] <wgrant> lifeless: But I've just left the company :(
[08:08] <stub> And the extracted database report, which is what I actually want to be working on.
[08:09] <stub> lifeless: Sure, or tomorrow if it is late for you.
[08:09] <lifeless> wgrant: clearly none of the bugs are your responsibility any more
[08:09] <wgrant> lifeless: Now all these historical bugs have to be molested, since I no longer have accss.
[08:09] <lifeless> stub: it is late, but today is better.
[08:09] <stub> k
[08:10] <wgrant> lifeless: That argument might apply to an In Progress bug.
[08:10] <lifeless> wgrant: I don't see a conceptual problem: open bugs *should* be updated. Closed bugs the assignee is just vanity, and its in the changelog for the bug.
[08:10] <wgrant> But it probably doesn't apply to a Fix Released one.
[08:10] <lifeless> if you consider assignee a next-actor field its clearly irrelevant for F-R bugs
[08:11] <lifeless> arguably it should not permit being set there anyhow.
[08:11] <wgrant> That's not how the field is defined at present.
[08:11] <wgrant> And it has never been used that way.
[08:11] <lifeless> (not something we could do today, but if we were starting from scratch...)
[08:11] <lifeless> wgrant: actually, it has been used that way.
[08:11] <wgrant> Some Ubuntu process bugs use it that way.
[08:11] <wgrant> use/used
[08:11] <wgrant> But nothing widespread.
[08:12] <lifeless> wgrant: I forget which team, but there is/was one that religiously updates it that way.
[08:16] <lifeless> wgrant: so I admit its a little awkward, but it is, I think, the best of a bunch of bad options.
[08:19] <lifeless> wgrant: allowing data that is inconsistent means we have to have safeguards and doublechecks throughout the system; having assignee imply notification means having it imply visibility (by definition)
[08:19] <lifeless> wgrant: if we take any one piece out, the system gets harder to explain and use.
[08:20] <lifeless> wgrant: I find it implausible that users will be functionally affected if the assignee is cleared when someone leaves; consider the following identical cases:
[08:20] <lifeless>  - the user deletes their LP account
[08:20] <lifeless>  - the user merges their LP account
[08:22] <lifeless> wgrant: another way of thinking about it is that having a single identity for interacting with multiple partitioned visibility areas has an inbuilt tension.
[08:23] <lifeless> wgrant: if you left canonical, for instance, your google docs would be migrated and the account and all its track record nuked.
[08:24] <lifeless> stub: so, skype?
[08:24] <stub> sure
[08:25] <wgrant> lifeless: Assignee doesn't have to imply notification any more than structural subscription does.
[09:26] <StevenK> danhg: O hai!
[09:26] <danhg> hey stevenk
[09:26] <StevenK> danhg: I'd like to get a text review if you have a moment?
[09:26] <danhg> yeah sure
[09:30]  * StevenK stabs gpg for being difficult
[11:16] <jml`> hey
[11:17] <jml> the bug listing page seems to have no favicon
[11:35] <jml> never mind.
[13:04] <deryck> Morning, everyone.
[13:06] <rick_h_> morning
[13:06] <abentley> deryck: morning.
[13:06] <abentley> rick_h_: morning.
[13:06] <StevenK> rick_h_: Did you see I fixed convoy?
[13:06] <rick_h_> StevenK: no, didn't see it. thanks!!!
[13:06] <rick_h_> StevenK: I'll pull/check it out and reply to the -dev email then
[13:07] <StevenK> rick_h_: It's also on asuka at least
[13:07] <rick_h_> StevenK: awesome
[13:07] <StevenK> rick_h_: And we set caching on asuka for +combo
[13:07]  * rick_h_ assumes asuka is a dev server
[13:07] <rick_h_> or something
[13:07] <StevenK> asuka is staging/qastaging's asppserver
[13:07] <rick_h_> cool
[13:07] <StevenK> *appserver
[13:08] <StevenK> rick_h_: We might be in a position to turn on the feature flag on qas and see how much breaks
[13:08] <rick_h_> StevenK: very cool then
[14:13] <awilkins> Is there a statechart of the Launchpad bug statuses ; I have the list of states, but not the transitions. Or is there a particular piece of the source I can look at to work it out?
[15:20] <deryck> awilkins, not sure what you mean by the transitions.
[15:21] <deryck> awilkins, what are you wanting to understand?
[15:21] <awilkins> deryck, Which state leads to which other state : I got an answer in the non-dev channel, apparently you can move to any state if you have the privileges
[15:21] <awilkins> I just want to compare it to Bugzilla, etc
[15:22] <deryck> awilkins, ah, ok.  yeah, there's no set order.
[15:26] <jml> looking at MPs now
[15:55]  * deryck lunches
[16:28] <jml> benji, bac: have replied to MPs. am available for the next hour to chat.
[16:43] <sinzui> rick_h_, jcsackett: do you have time to review https://code.launchpad.net/~sinzui/launchpad/progressive-enhancement-ftw/+merge/103733
[16:44] <rick_h_> sinzui: sure thing
[17:17] <rick_h_> sinzui: ping, ? for you
[17:17] <sinzui> hi rick_h_
[17:17] <rick_h_> sinzui: so you've wrapped the <a> contents with invisible-link css for many cases
[17:18] <rick_h_> in a non-js browser situation then, is there any method for these to show up not hidden?
[17:18] <rick_h_> since this is to replace no-script use cases
[17:18] <sinzui> ah
[17:19] <sinzui> invisible-link exists the Zope testbrowser, not humans
[17:19] <sinzui> the sprite class instead renders an icon instead of text for the human
[17:19] <rick_h_> ok, ic
[17:20] <sinzui> rick_h_, there is a nuance we need to consider
[17:21] <sinzui> linx is non-js and non-graphical, so crucial cases of reporting a bug must work without graphics or script. +filebug is such as case. We really want users to see those extra options. There are not edit icons on them
[17:22] <rick_h_> ah, gotcha
[17:23] <rick_h_> yea, it's the eternal debate of JS flash to hide things vs hiding by default
[17:24] <rick_h_> sinzui: so with my icon fonts I've used this: http://pictos.cc/articles/using-icon-fonts/
[17:24] <rick_h_> which helps make sure if you don't get the font you get the text
[17:24] <rick_h_> I wonder if this could be adapted for a pure css solution
[17:25] <sinzui> ah
[17:25] <sinzui> I tried something like that a few years ago
[17:25] <rick_h_> yea, I think part of this works because it's a font vs a sprite, but haven't tried it out
[17:25] <sinzui> it was rejected as a programmer hack. I think we could get it accepted on the grounds that we care about accessibility.
[17:26] <rick_h_> yea, it works pretty well ime in my side project and if we can praise it for accessability and lack of JS driven flashing UI it's a win
[17:27] <sinzui> Anything that properly sites in the uncode ranges and that we can add beauty too via a web font would be grand
[17:27] <sinzui> s/sites/sits
[17:28] <rick_h_> yea, unfortunately I think most icon fonts aren't sticking to unicode land because of unidoce issues people end up with
[17:34] <abentley> rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/celery-everywhere-9/+merge/103723 ?
[17:36] <rick_h_> abentley: will do
[17:38] <rick_h_> sinzui: ok, commented, also wanted to bring up alt vs title text for these links since again we're really targeting accessability here
[17:39] <sinzui> thank you.
[17:40] <rick_h_> thank you, look forward to noscript dying
[17:49] <sinzui> rick_h_, I already know that we cannot change the broken span in a div markup easilly
[17:49] <sinzui> We tried this 18 months ago :(
[17:49] <rick_h_> sinzui: ok, it looked like it might be a much bigger task, but wanted to note it
[17:49] <sinzui> It is quite complicated. I can be done, but that is not the issue that needs to be solved in this branch
[17:50] <abentley> gary_poster: ISTM that Storm does not maintain a mapping of table names to classes.  Does that seem correct to you?
[17:50] <rick_h_> sinzui: understand
[17:50] <sinzui> rick_h_. we stopped adding inline editing to the project page because th divs did bad things in element that had to be inline
[17:51] <gary_poster> abentley, it's been a long time since I looked at that code, but I believe you are correct.
[17:51] <rick_h_> sinzui: can the reverse happen though, can the spans be turned to divs with inline or inline-block styles?
[17:52] <sinzui> No.
[17:52] <rick_h_> sinzui: ok
[17:52] <sinzui> Lp and HTML in general wants form elements to work in line
[17:52] <abentley> gary_poster: I had always assumed there would be one.  I also thought having two classes with the same table would be impossible.  But if Storm can't tell that there are two classes with the same table, it shouldn't care, either.
[17:52] <gary_poster> heh
[17:52] <sinzui> rick_h_, consider that div can never go in a paragraph
[17:53] <rick_h_> sinzui: ah right ok.
[17:53] <sinzui> rick_h_, you are right about the title, I see I was not consistent
[17:53] <sinzui> I will work on this now
[17:54] <rick_h_> sinzui: np, I'll be around laterish today and can ok any time. Thanks for looking into it.
[17:54] <gary_poster> abentley, it must reliably be able to determine what class to use to instantiate records from the db; looking for a sec; suspect that this is configuration
[17:55] <abentley> gary_poster: There's a complicated derivation dance used in most Jobs classes; but if BranchScanJob, BranchUpgradeJob etc all were ORM objects with the same table, life would be simpler.
[17:55] <abentley> gary_poster: I think that it relies on the caller of Store.fine to specify what class to use, and class specifies table.
[17:56] <abentley> s/Store.fine/Store.find
[17:57] <gary_poster> abentley, yes, I think you are right!  A very interesting idea
[17:58] <gary_poster> Crazy idea abentley: you could maybe even pass a (single) factory, depending on how loose the contract is for the first argument to store.find
[17:59] <gary_poster> if it just has to be a callable with a __storm_table__ ...
[18:00] <gary_poster> you could create different objects depending on one or more columns
[18:00] <gary_poster> May or may not be a horrible hack :-)
[18:01] <gary_poster> __new__ might also lead down interesting, horrible paths
[18:02] <gary_poster> if the contract is tighter than "callable + __storm_table__"
[18:02] <abentley> gary_poster: So, Store.find does appear to defer to the caller: http://pastebin.ubuntu.com/947827/
[18:03] <gary_poster> cool
[18:05] <abentley> gary_poster: Unfortunately, my current work kinda assumed that I could serialize an IRunnableJob by writing out its table and id.
[18:05] <gary_poster> ah
[18:31] <deryck> jcsackett or rick_h_ -- I've got a branch killing doctests for review.
[18:31] <rick_h_> deryck: cool, almost done with abentley's stuff and I can get right onto that
[18:32] <deryck> rick_h_, cool, thanks!  It's at: https://code.launchpad.net/~deryck/launchpad/refactor-editemail-doctest-363916/+merge/103718
[18:35] <rick_h_> deryck: ok, loading up now. Man, where's that achievement system from jono. I want a reviews badge for today lol
[18:35] <deryck> heh
[18:55] <rick_h_> deryck: #2 is just for my own curiosity as searching for doc gets me a ton of stuff
[18:57] <deryck> rick_h_, so #1 -- I can underbar the create methods. I only did the assert one differently, so it wouldn't be mistaken for any self.assertXXX methods provided by the test case classes....
[18:58] <deryck> rick_h_, #2 is due to the error message being an instance in one case, and unicode in all the others.
[18:58] <deryck> rick_h_, #2 cont. I think some of the form magic calls doc on the widget to get the error string.
[18:58]  * deryck is re-reading #3 now :)
[18:59] <rick_h_> deryck: ok yea wasn't sure what .doc came from that seemed to imply it converted the input to unicode
[18:59] <rick_h_> deryck: I've been confused on #1 before as usually personally I'd _private things that weren't tests but were used but then again things like setUp/tearDown and all that aren't as well so I guess it goes either way
[19:00] <rick_h_> deryck: #3 just says that each unit test should start with a comment about what's being tested according to the testing style guidelines
[19:00] <lifeless> tearDown shouldn't be used :)
[19:00] <deryck> rick_h_, yeah, that's why I don't normally underbar something unless I need to signal it is somehow different.
[19:00] <rick_h_> and wasn't in this case for the record, just comparing the names of non test_methods
[19:00] <deryck> rick_h_, but if you want me to change either for consistency, I don't mind.
[19:01] <deryck> hi lifeless  :)
[19:01] <rick_h_> right, this only struct me because it did both, I see your point though now deryck. Up to you there
[19:01] <lifeless> deryck: o/
[19:02] <deryck> rick_h_, so can you point me at a line in that wiki your referring to. We're inconsistent about comments in unit tests, and I followed the example of the other tests in that file.
[19:03] <rick_h_> deryck: under "Python test cases" #3
[19:03] <deryck> rick_h_, ah, see it now thanks.  I can update the other tests in this file then too.
[19:04] <deryck> rick_h_, and you know you're a new reviewer. ;)  That's a lot of wiki doc to read thoroughly. :)
[19:04] <lifeless> I think that line is too proscriptive; 'test intent should be understandable' is a much better rule
[19:04] <rick_h_> deryck: so jcsackett says I'm going to be set free for tues
[19:04] <rick_h_> lifeless: come on, I'm a fan of the comment string for a nice readable line in the error reporting :P
[19:04] <rick_h_> don't rain on my parade
[19:05] <lifeless> rick_h_: in the runner output? All my runners disable that as an antifeature
[19:05] <rick_h_> lifeless: yea
[19:05] <deryck> I feel like we should have something akin to "You might be a redneck" jokes sometimes....
[19:05] <deryck> "You might have a crazy test system if...."
[19:05] <rick_h_> hah
[19:06] <deryck> it requires multiple huge wiki docs to explain how to write good tests.
[19:06] <deryck> :)
[19:06] <rick_h_> well test names can be a bit shorter if you have a nice sentence on wtf just blew up in that first comment line. I like that as someone that blows up other peoples testes a lot lol
[19:06] <deryck> I really don't mind adding a comment.  Just kidding around.
[19:08] <rick_h_> I'm just sticking up for my anti features :)
[19:28] <sinzui> rick_h_,  I replied and pushed a change to verify that widget-position-ext is not needed: https://code.launchpad.net/~sinzui/launchpad/progressive-enhancement-ftw/+merge/103733
[19:29] <rick_h_> sinzui: saw that, so the two items are the alt tags and the hidden by default text of the links right?
[19:29] <rick_h_> did you want to worry about the hidden text bits as a seperate branch/item?
[19:29] <rick_h_> and I can approve it as is with the understanding the alt text can get added in?
[19:30] <sinzui> rick_h_, I updated my reply. alt tags never EVER worked on anchors
[19:32] <sinzui> rick_h_, title is universal and the only true mechanism to use in the 2000's
[19:34] <rick_h_> sinzui: ah ok, sorry I was looking at examples at the start wich are tests anyway
[19:35] <sinzui> :) That is my trick
[19:35] <rick_h_> sinzui: thanks for the updated comment. Marked ok
[19:35] <sinzui> fab.
[19:36]  * sinzui reports bug to remove widget-position-ext source-dep
[20:10] <sinzui> rick_h_, the http://pictos.cc/font/ is really great. I want to build something with it
[20:28] <abentley> jcsackett: Could you please review https://code.launchpad.net/~abentley/launchpad/efficient-universal-source/+merge/103768 ?
[20:28] <jcsackett> abentley: it's in my queue. might be a bit, it's not a short queue. :-)
[20:29] <abentley> jcsackett: That's a second one.
[20:29] <jcsackett> abentley: got it, just letting you know i'll get to it asap.
[20:29] <abentley> jcsackett: Cool.
[20:33] <rick_h_> sinzui: so I changed over to an open source version: http://fortawesome.github.com/Font-Awesome/
[20:34] <rick_h_> sinzui: I paid for pictos though
[20:36] <sinzui> That is nice too
[20:37] <rick_h_> yea, only reason I switched was license, but yea it's nice to use the font idea like that
[21:24] <jcsackett> abentley: r=me on that branch, in case you missed the email.
[22:02] <abentley> jcsackett: thanks.
[23:15] <StevenK> -            'text': '** Visibility changed to: Public',
[23:15] <StevenK> +            'text': '** Information type changed from User Data to Public.',