| wallyworld_ | StevenK: is only workaround to downgrade convoy? ImportError: No module named convoy.meta | 01:05 |
|---|---|---|
| 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:06 |
| wallyworld_ | ok,will try thanks | 01:07 |
| wallyworld_ | all good | 01:07 |
| StevenK | wallyworld_: I'm working on it. | 01:16 |
| wallyworld_ | np. i downgraded to the previous version | 01:20 |
| 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:35 |
| 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:45 |
| wgrant | Not sure what it's doing there, but it's probably simple to eliminate. | 01:46 |
| wgrant | I hope. | 01:46 |
| StevenK | Woo | 03:02 |
| * StevenK rips out five self.assertEquals() and replaces it with MatchesStructure() | 03:02 | |
| wallyworld_ | wgrant: is it preferred to use a CTE or subsquery to force a distinct to be evaluated before a sort? | 03:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| wallyworld_ | lifeless: wgrant: https://pastebin.canonical.com/64992/ | 03:11 |
| wallyworld_ | i'm experimenting atm with a couple of approaches | 03:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| lifeless | it may sort in memory | 03:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:20 |
| wallyworld_ | or i remove the MIN and have one query with a distinct and order by and a bit of python logic | 03:21 |
| wallyworld_ | lifeless: actually, i take it back. i don't need the 'distinct on', just plain old distinct. | 03:24 |
| wallyworld_ | for my use case | 03:25 |
| wgrant | You also don't care about order there, do you? | 03:26 |
| 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:27 |
| 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:28 |
| wallyworld_ | it's missing the group by but perhaps | 03:29 |
| lifeless | why would it need one ? | 03:29 |
| 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:30 |
| 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:31 |
| wallyworld_ | my original query works. wgrant, could you possibly run https://pastebin.canonical.com/64992/ on dogfood, adjusting ids for ubuntu? | 03:32 |
| wgrant | 90ms for me + ubuntu-crashes-universe | 03:34 |
| wgrant | So very slow | 03:34 |
| lifeless | wgrant: how does mine run ? | 03:35 |
| wgrant | Buggily | 03:35 |
| lifeless | wgrant: with an appropriate group by | 03:35 |
| 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:36 |
| 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:37 |
| wgrant | And (21997, 1324721) | 03:38 |
| wallyworld_ | wgrant: maybe a subselect? | 03:38 |
| wgrant | Well | 03:38 |
| lifeless | 72ms | 03:38 |
| 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:39 |
| lifeless | ORDER BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy; | 03:40 |
| wallyworld_ | so what's the concensus? | 03:41 |
| wallyworld_ | one was run on dogfood, the other qas so can't really compare | 03:42 |
| 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:43 |
| === jtv1 is now known as jtv | ||
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| wallyworld_ | wgrant: seems to work ok locally too. thanks. updating code now.... | 03:49 |
| wgrant | Great. | 03:50 |
| wgrant | Hm | 04:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:20 |
| lifeless | wgrant: did you end up making an array for tags ? | 04:26 |
| wgrant | lifeless: Not in this round. | 04:26 |
| adeuring | good mornin | 07:07 |
| stub | Grrr... lifeless stole my namespace with lazr.postgresql. | 07:42 |
| stub | What do we have besides lazr? Need to package a Python library containing PG helpers. | 07:45 |
| wgrant | lazr.postgresql, maybe? :) | 07:45 |
| stub | :-P | 07:46 |
| stub | Lot of renaming to move that db patch buildout application | 07:48 |
| 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 | 07:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| stub | Yer, just as long as I can get 'python setup.py install' to install mystuff my limited packaging skills should suffice. | 08:05 |
| lifeless | which buildout doesn't affect ;) | 08:06 |
| lifeless | also you might like to use pkgme for deb stuff | 08:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| lifeless | wgrant: I forget which team, but there is/was one that religiously updates it that way. | 08:12 |
| lifeless | wgrant: so I admit its a little awkward, but it is, I think, the best of a bunch of bad options. | 08:16 |
| 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:19 |
| 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:20 |
| 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:22 |
| lifeless | wgrant: if you left canonical, for instance, your google docs would be migrated and the account and all its track record nuked. | 08:23 |
| lifeless | stub: so, skype? | 08:24 |
| stub | sure | 08:24 |
| wgrant | lifeless: Assignee doesn't have to imply notification any more than structural subscription does. | 08:25 |
| 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:26 |
| * StevenK stabs gpg for being difficult | 09:30 | |
| jml` | hey | 11:16 |
| === jml` is now known as jml | ||
| jml | the bug listing page seems to have no favicon | 11:17 |
| jml | never mind. | 11:35 |
| deryck | Morning, everyone. | 13:04 |
| 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:06 |
| 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:07 |
| 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 | 13:08 |
| === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett, rick_h* | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| === sagaci_ is now known as sagaci | ||
| 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? | 14:13 |
| deryck | awilkins, not sure what you mean by the transitions. | 15:20 |
| 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:21 |
| deryck | awilkins, ah, ok. yeah, there's no set order. | 15:22 |
| jml | looking at MPs now | 15:26 |
| * deryck lunches | 15:55 | |
| === salgado is now known as salgado-lunch | ||
| jml | benji, bac: have replied to MPs. am available for the next hour to chat. | 16:28 |
| === salgado-lunch is now known as salgado | ||
| sinzui | rick_h_, jcsackett: do you have time to review https://code.launchpad.net/~sinzui/launchpad/progressive-enhancement-ftw/+merge/103733 | 16:43 |
| rick_h_ | sinzui: sure thing | 16:44 |
| 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:17 |
| 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:18 |
| 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:19 |
| sinzui | rick_h_, there is a nuance we need to consider | 17:20 |
| 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:21 |
| rick_h_ | ah, gotcha | 17:22 |
| rick_h_ | yea, it's the eternal debate of JS flash to hide things vs hiding by default | 17:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| rick_h_ | yea, unfortunately I think most icon fonts aren't sticking to unicode land because of unidoce issues people end up with | 17:28 |
| abentley | rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/celery-everywhere-9/+merge/103723 ? | 17:34 |
| rick_h_ | abentley: will do | 17:36 |
| 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:38 |
| sinzui | thank you. | 17:39 |
| rick_h_ | thank you, look forward to noscript dying | 17:40 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| abentley | s/Store.fine/Store.find | 17:56 |
| gary_poster | abentley, yes, I think you are right! A very interesting idea | 17:57 |
| 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:58 |
| gary_poster | if it just has to be a callable with a __storm_table__ ... | 17:59 |
| 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:00 |
| gary_poster | __new__ might also lead down interesting, horrible paths | 18:01 |
| 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:02 |
| gary_poster | cool | 18:03 |
| 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:05 |
| 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:31 |
| deryck | rick_h_, cool, thanks! It's at: https://code.launchpad.net/~deryck/launchpad/refactor-editemail-doctest-363916/+merge/103718 | 18:32 |
| 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:35 |
| rick_h_ | deryck: #2 is just for my own curiosity as searching for doc gets me a ton of stuff | 18:55 |
| 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:57 |
| 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:58 | |
| 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 | 18:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| rick_h_ | I'm just sticking up for my anti features :) | 19:08 |
| 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:28 |
| 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:29 |
| sinzui | rick_h_, I updated my reply. alt tags never EVER worked on anchors | 19:30 |
| sinzui | rick_h_, title is universal and the only true mechanism to use in the 2000's | 19:32 |
| rick_h_ | sinzui: ah ok, sorry I was looking at examples at the start wich are tests anyway | 19:34 |
| sinzui | :) That is my trick | 19:35 |
| rick_h_ | sinzui: thanks for the updated comment. Marked ok | 19:35 |
| sinzui | fab. | 19:35 |
| * sinzui reports bug to remove widget-position-ext source-dep | 19:36 | |
| === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| sinzui | rick_h_, the http://pictos.cc/font/ is really great. I want to build something with it | 20:10 |
| 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:28 |
| 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:29 |
| rick_h_ | sinzui: so I changed over to an open source version: http://fortawesome.github.com/Font-Awesome/ | 20:33 |
| rick_h_ | sinzui: I paid for pictos though | 20:34 |
| sinzui | That is nice too | 20:36 |
| rick_h_ | yea, only reason I switched was license, but yea it's nice to use the font idea like that | 20:37 |
| jcsackett | abentley: r=me on that branch, in case you missed the email. | 21:24 |
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| abentley | jcsackett: thanks. | 22:02 |
| === salgado is now known as salgado-afk | ||
| StevenK | - 'text': '** Visibility changed to: Public', | 23:15 |
| StevenK | + 'text': '** Information type changed from User Data to Public.', | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!