| rogpeppe | mornin' all | 07:34 |
|---|---|---|
| frankban | morning rogpeppe: how are you doing? when you have time, could you please take a look at https://github.com/juju/juju/pull/48 ? | 09:08 |
| frankban | rogpeppe1: hi, when you have time, could you please take a look at https://github.com/juju/juju/pull/48 ? | 10:18 |
| rogpeppe1 | frankban: looking | 10:18 |
| frankban | thanks | 10:18 |
| rogpeppe1 | frankban: reviewed | 10:30 |
| frankban | rogpeppe1: thanks | 10:31 |
| frankban | rogpeppe1: so, the rule is to not rebase changes after the review, right? | 10:32 |
| rogpeppe1 | frankban: i think so | 10:33 |
| frankban | rogpeppe1: ok | 10:33 |
| rogpeppe1 | frankban: i don't know what the rules are any more :-) | 10:33 |
| frankban | rogpeppe1: yeah, I am also a bit confused | 10:33 |
| frankban | rogpeppe1: I'll take a look at removing testing dependencies from store | 10:52 |
| rogpeppe1 | frankban: cool | 10:52 |
| frankban | rogpeppe1: didn't you have a branch for moving testing/charms.go to charm/testing? | 11:16 |
| rogpeppe1 | frankban: yeah | 11:17 |
| frankban | rogpeppe1: is it ready to be proposed? | 11:18 |
| rogpeppe1 | frankban: it's already been LGTM'd | 11:18 |
| rogpeppe1 | frankban: i thought it had landed | 11:19 |
| frankban | rogpeppe1: it does not seem so | 11:19 |
| rogpeppe1 | frankban: ah, tests failed | 11:19 |
| frankban | rogpeppe1: could you please get that landed? store depends on testing.Charm right now, I'd like to change that | 11:19 |
| rogpeppe1 | frankban: yeah, just looking now | 11:20 |
| rogpeppe1 | frankban: one of those sporadic test failures. i'll re-merge and re-propose. | 11:20 |
| frankban | cool thanks | 11:21 |
| rogpeppe1 | ok, trying to land again | 11:23 |
| rick_h_ | morning | 11:25 |
| frankban | morning rick_h_ | 11:49 |
| frankban | rogpeppe1: it seems we have to move testing/mgo.go to github/juju/testing. The only internal dep is cert.ParseCert. we can either 1) move cert to its own repo (it does not depend on anything internal) or 2) dupe ParseCert in github.com/juju/testing | 11:51 |
| rogpeppe1 | frankban: hmm, is that for the mongo that the store tests need? | 11:52 |
| frankban | rogpeppe1: yes | 11:52 |
| frankban | rogpeppe1: store_test.go | 11:53 |
| frankban | rogpeppe1: perhaps cert can be moved into utils? | 11:53 |
| frankban | rogpeppe1: it's just a single file and a test file | 11:53 |
| rogpeppe1 | frankban: i'm a bit dubious about that | 11:54 |
| rogpeppe1 | frankban: it's really very juju-specific | 11:54 |
| frankban | rogpeppe1: so github.com/juju/cert? | 11:54 |
| frankban | (option 1) | 11:54 |
| rogpeppe1 | frankban: i'm having to think quite hard abut whether mgo.go should go into github.com/juju/testing | 11:55 |
| rogpeppe1 | frankban: there's quite a lot of logic in there that's there mostly because of the way we do things in juju | 11:55 |
| frankban | rogpeppe1: uhm, is that logic still valid for the future store? | 11:59 |
| rogpeppe1 | frankban: and at the moment, I can't quite see how it's working, given that store calls mgo.Dial directly. Ah, I see, it calls MgoTestPackagSsl with ssl=false | 11:59 |
| rogpeppe1 | frankban: so the charm store doesn't actually use any of the cert stuff | 11:59 |
| rogpeppe1 | frankban: my main concern is that the way mongo is configured in MgoSuite must be an exact mirror of how the state server sets up mongo | 12:00 |
| rogpeppe1 | frankban: so keeping the two in sync, in the same repo, seems like a Good Thing | 12:01 |
| * rogpeppe1 tries to think of a way of factoring out the juju-nonspecific pieces | 12:01 | |
| * frankban bbiab | 12:06 | |
| frankban | rogpeppe1: re juju logic: do you mean the ssl stuff? I am thinking about making MgoTestPackageSsl accept a pem string instead of a ssl bool. That way the ssl logic can still be placed in juju, while the suite itself can be moved | 12:51 |
| frankban | rogpeppe1: istm that, even if we want to decouple MgoSuite from the juju certs, it is still interesting to have a generic MgoSuite that handles tls. in that case, even if, e.g. we change MgoTestPackage so that it receives the certs, we still need the cert stuff to be in an external repo. | 13:11 |
| frankban | rogpeppe1: and I am not sure I fully understand why cert stuff should be considered so specific to core | 13:16 |
| === rogpeppe1 is now known as rogpeppe | ||
| rogpeppe | frankban: the details of the generated certificates are very juju specific | 13:16 |
| frankban | rogpeppe: ^^^ | 13:16 |
| rogpeppe | frankban: for example, look at the CommonName in cert.NewCA | 13:17 |
| rogpeppe | frankban: and the Organisation, etc | 13:17 |
| frankban | rogpeppe: IC, you pass the env name, etc... | 13:17 |
| rogpeppe | frankban: if we change MgoTestPackage so that it receives the certs, we don't necessarily need the cert stuff to be in an external repo | 13:18 |
| rogpeppe | frankban: because you'll generally only want that stuff if you're part of juju | 13:18 |
| frankban | rogpeppe: that's true if we duplicate the code in cert.ParseCert | 13:18 |
| rogpeppe | frankban: ParseCert is a fairly trivial wrapper function | 13:18 |
| rogpeppe | frankban: I don't mind duplicating that code if we need to | 13:19 |
| rogpeppe | frankban: alternatively we might be able to make it take *x509.Certificate and *rsa.PrivateKey as args | 13:19 |
| rogpeppe | frankban: which would probably be just as easy to use | 13:21 |
| frankban | rogpeppe: ok, that seems to work. So we need to decouple testing/mgo.go from the stuff in testing/cert.go, right? | 13:23 |
| rogpeppe | frankban: yeah | 13:23 |
| frankban | rogpeppe: and MgoTestPackage receives *x509.Certificate and *rsa.PrivateKey: if they are both nil tls is disabled | 13:25 |
| rogpeppe | frankban: if the cert is nil, tls is disabled, i think | 13:26 |
| rogpeppe | frankban: if there's a cert and no private key, i think we can panic | 13:26 |
| frankban | rogpeppe: coo, and MgoTestPackageSsl is just a juju shortcut which takes nothing and uses stuff defined in testing/cert.go, right? | 13:27 |
| rogpeppe | frankban: sgtm | 13:27 |
| bac | frankban: update: i got the python-websocket-client backported to precise and saucy in juju-quickstart-beta ppa. doing the final QA on precise. will get it moved to juju-stable ppa soon. then do the release of 1.3.3. | 13:59 |
| frankban | bac: sounds good, was it difficult to change the package name? | 14:00 |
| bac | frankban: it required i do everything by hand. couldn't use the backportpackage tools | 14:01 |
| bac | so, none of it hard, just requires figuring out the six incantations. | 14:01 |
| frankban | bac: :-/ thanks a lot for that, do you have notes about the incantation process? | 14:03 |
| bac | frankban: i do. will clean them up and stick somewhere shortly | 14:03 |
| frankban | bac: great thanks | 14:04 |
| hatch | morning all | 14:10 |
| hatch | I have no internet....yay! | 14:11 |
| rick_h_ | wheee | 14:12 |
| hatch | rick_h_ want to take a look at the new cache stuff while I write the tests https://github.com/juju/juju-gui/pull/372 | 14:17 |
| rick_h_ | hatch: looking | 14:20 |
| rick_h_ | hatch: feedback done | 14:35 |
| hatch | cool looking | 14:35 |
| hatch | I'm also calling around trying to get my internet fixed | 14:35 |
| hatch | ugh, apparently our area is subbed out to a contracting company to get fixed | 14:35 |
| rick_h_ | some sort of community internet? | 14:36 |
| hatch | I think it's that the telco doesn't have enough staff | 14:41 |
| hatch | so they have to sub out jobs sometimes | 14:42 |
| hatch | brb hopping on the phone again | 14:42 |
| makyo_ | jujugui call in 10 | 14:50 |
| hatch | rick_h_ replies made | 14:59 |
| rick_h_ | jujugui call now rogpeppe jcsackett | 15:01 |
| rick_h_ | antdillon: ^ | 15:01 |
| jcsackett | rick_h_: voice plugin crashing, be there soon. | 15:02 |
| rick_h_ | jcsackett: rgr | 15:02 |
| bac | makyo_: don't say PTO</rant> | 15:10 |
| === makyo_ is now known as Makyo | ||
| Makyo | ?? | 15:10 |
| bac | PTO is a movement to steal your sick time and roll it in with vacation. | 15:11 |
| bac | rick_h_: stop saying PTO | 15:11 |
| bac | :) | 15:11 |
| bac | HR has agreed to change the wording | 15:11 |
| hatch | what's wrong with PTO? | 15:14 |
| hatch | too union for ya? lol | 15:14 |
| rick_h_ | bac: oh, sorry. It's my old job everything was PTO | 15:14 |
| hatch | EDO's.....now that's what we need | 15:15 |
| hatch | EDO's | 15:15 |
| hatch | lol | 15:15 |
| bac | PTO means you can never really plan, as you must keep an allotment for the off chance you get sick. | 15:15 |
| rick_h_ | bac: yea, always hated that, but also hated having XX sick days never not using them | 15:15 |
| bac | anyway, the PTO language on the HR site is inherited from salesforce and not a new company policy. | 15:15 |
| bac | rick_h_: but our current sick policy takes into account your previous use. so if you never use it, then when you do have the need you are given allowance. | 15:17 |
| hatch | I actually had no idea there was such a issue with the naming | 15:17 |
| Makyo | rick_h_, requests in | 15:17 |
| bac | hatch: you wouldn't. us of a specific silliness | 15:17 |
| hatch | bac I mean that I didn't know PTO had a certain definition where it specifically lumped things together like that | 15:18 |
| rick_h_ | hatch: replied | 15:18 |
| rick_h_ | hatch: overall seems like a good path. | 15:19 |
| hatch | I STILL can't get a hold of anyone to come fix the internet....ugh | 15:19 |
| hatch | rick_h_ cool thx | 15:19 |
| bac | rick_h_: when i last looked at IPv6 interoperability testing the only tools were a mess of Perl written at a Japanese university. it was terribly painful. | 15:21 |
| bac | hopefully things are better now | 15:21 |
| rogpeppe | frankban: sorry, just saw my branch failed to land again (clashes with other branches which had been pushed in the meantime) | 15:27 |
| rogpeppe | frankban: am trying again | 15:27 |
| frankban | rogpeppe: thanks, no worries | 15:29 |
| hatch | hmm I wish I could put the hotspot on my network.... | 15:31 |
| rick_h_ | hatch: <3 http://www.amazon.com/gp/product/B007GFYHPG/ref=wms_ohs_product?ie=UTF8&psc=1 | 15:31 |
| rogpeppe | frankban: oh, darn it, i think i forgot to commit the relevant changes before merging | 15:32 |
| rick_h_ | hatch: I've used that to share out my mifi network, and think it can run the wifi network through the wired end | 15:32 |
| hatch | rick_h_ so this thing youd plug in place of the modem and connect it to your switch? | 15:32 |
| rick_h_ | hatch: well the mifi would do wireless and you'd plug the wire end into your current router outside | 15:32 |
| rick_h_ | so your existing router would this this thing is the internet | 15:32 |
| rick_h_ | would think that is | 15:32 |
| hatch | ahh yeah that's definitely what I need | 15:33 |
| rick_h_ | I *think* it can work that way. Normally it's for taking a wired connection and sharing it out over wifi (hotel with wired but no wifi signal) or resharing/extending an existing wifi network (5 devices on my mifi my $#@$#@, I'll connect as many as I want) | 15:33 |
| hatch | lol | 15:34 |
| hatch | why does your mifi have a limit? | 15:34 |
| rick_h_ | they do in the US here. Most do 5 or 10 devices | 15:35 |
| rick_h_ | I share with my coffee house coders group so I use that to get aroudn the limits | 15:35 |
| hatch | I'm wondering what the thought is behind that | 15:36 |
| hatch | # of devices does not increase the bandwidth or anything heh | 15:36 |
| rogpeppe | hatch: before i get totally lost in the git log help page again, do you know how to get git log to show the files that have changed in each commit? | 15:37 |
| hatch | git log --name-only or something | 15:37 |
| rick_h_ | rogpeppe: I use lf = log --stat | 15:37 |
| rick_h_ | so git lf | 15:37 |
| hatch | maybe git log --stat would be better | 15:38 |
| rick_h_ | will give me file/diff info | 15:38 |
| hatch | heh you and your aliases :) | 15:38 |
| rick_h_ | ld = log -p | 15:38 |
| lazyPower | rick_h_: do we know if juju-actions are going to be exposed in juju-gui | 15:38 |
| rick_h_ | is good as well, for the diff | 15:38 |
| rogpeppe | hatch: ah, that looks good thanks. line 1139 out of 1850 of the help page. | 15:39 |
| rick_h_ | lazyPower: the hope is to. We've got a guy that's been waiting on stuff to implement it. He's not contract, so not sure how far he'll get | 15:39 |
| rogpeppe | hatch: not surprising i hadn't found it yet | 15:39 |
| lazyPower | ok ty | 15:39 |
| hatch | rogpeppe unlike bzr there is a HUGE amount of information online for "how do I do x" so you don't need to read the man pages | 15:39 |
| rogpeppe | hatch: yeah, i guess. rtfm is a bad habit i need to get out of :-) | 15:39 |
| hatch | haha - well, it's a good habit, but with big communities usually come faster ways to do things :D | 15:40 |
| rogpeppe | hatch: once upon a time, man pages were simple :-) | 15:40 |
| hatch | rogpeppe haha I suppose thought git would have been 100 different commands back then too | 15:41 |
| lazyPower | rick_h_: if that work starts can you ping me? Our big data efforts would benefit from this and asanjar is practically offering me money to give him information on it. | 15:41 |
| rick_h_ | lazyPower: so I sent an email today to him about looking over the documentation that bodie sent out in irc | 15:41 |
| rogpeppe | hatch: it *is* 100 different commands :-) | 15:42 |
| lazyPower | thats excellent.w e want to be early adopters :) | 15:42 |
| rick_h_ | lazyPower: and I've asked him to start looking at the front end and meet in the middle with the back end as the api finalized | 15:42 |
| hatch | rogpeppe lol!! | 15:42 |
| rick_h_ | lazyPower: so I guess it's "kind of" in progress | 15:42 |
| lazyPower | excellent. as soon as we have a branch / etc to look at I'm game to get my hands dirty | 15:42 |
| rogpeppe | hatch: actually, 146 different commands... | 15:42 |
| rick_h_ | lazyPower: definitely. Because he's not paid/contractor I'm not sure how it'll go, he has another job, but we're trying to enable him to be involved and move things forward from the GUI end. | 15:43 |
| rick_h_ | lazyPower: but we'll definitely be reaching out to you guys as things firm up because actions need to go through charm proof, we'll need to get those ingested/part of the charmworld api, etc | 15:43 |
| lazyPower | marcoceppi: ^ | 15:44 |
| lazyPower | pinging you preemptively so you're aware of whats coming at us | 15:44 |
| rick_h_ | lazyPower: marcoceppi make sure you see https://github.com/johnweldon/juju-docs/commit/cb7a4709e9a5fed5c885cd3e5e2ecc1cd34da181#commitcomment-6594689 and respond | 15:44 |
| marcoceppi | lazyPower: cool, I told the core guys to let me know when it lands in trunk too so we can start playing with it | 15:45 |
| * rick_h_ goes to get lunchables | 15:46 | |
| hatch | rick_h_ I replied to one of your comments about the bundle/charm path id url stuffs | 15:54 |
| rick_h_ | hatch: looking | 15:57 |
| rick_h_ | hatch: why can we not use the permanent/url? | 15:58 |
| hatch | rick_h_ the data I have is in the first paragraph the perm url requires that I parse the username out of the entityId to reconstruct it | 15:59 |
| hatch | so it's the least amount of work to do what I did | 16:00 |
| hatch | we could maybe create a entityId > charmUrl method | 16:00 |
| rick_h_ | hatch: call? I'm having a slow monday and not following | 16:00 |
| hatch | sure one sec just grabbing my coffee | 16:00 |
| hatch | be in standup | 16:00 |
| rick_h_ | rgr | 16:00 |
| bac | hey frankban, my qa of 1.3.3 is good. i'm going to copy the packages over to juju/stable now and do the pypi release after i eat lunch. any objections? | 16:09 |
| rick_h_ | woot! | 16:09 |
| frankban | bac: please go ahead and thanks! | 16:09 |
| bac | np | 16:10 |
| frankban | rogpeppe: review done | 16:28 |
| rogpeppe | frankban: thanks! | 16:28 |
| rick_h_ | rogpeppe: https://plus.google.com/hangouts/_/canonical.com/jaas-work?authuser=1 | 16:36 |
| Makyo | rick_h_, hatch I figured out where the call stack is on the profiler. Looks like it's all in YUI land on a few calls from the token widget (setHTML and _setBox, both of which parse the string they're given as HTML). Not sure of next steps - any ideas? | 16:54 |
| hatch | Makyo ok that's where I got too as well, glad we're in the same place :) | 16:55 |
| hatch | now as far as ideas.....that's also as far as I got | 16:55 |
| * hatch thinks | 16:55 | |
| Makyo | Best I could think of is to deal with it only as strings until the last step and only parse it once, but I think that goes against the Widget Way™ | 16:55 |
| hatch | Makyo yeah....but why didn't we have this problem before with the old code? | 16:56 |
| Makyo | hatch, we did, but it was hidden by the long load times. | 16:56 |
| hatch | but we don't on jujucharms.com | 16:56 |
| Makyo | Checked on an old checkout. | 16:56 |
| hatch | on jujucharms.com going from a search back to curated is instant | 16:57 |
| Makyo | I get exactly the same profile on jujucharms.com | 16:58 |
| hatch | really....interesting | 16:59 |
| hatch | hmm ok then | 17:00 |
| hatch | that settles that debate haha | 17:00 |
| hatch | Makyo what if....after each 'section' is rendered we append it to the dom | 17:00 |
| hatch | instead of all at once | 17:00 |
| hatch | so add the append() into the loop isntead of out of it | 17:00 |
| hatch | maybe we can start showing 'something' sooner | 17:00 |
| Makyo | Hmm, let me play around with that. | 17:00 |
| hatch | this of course being an alternative to re-writing it | 17:02 |
| hatch | I mean.... | 17:02 |
| hatch | :) | 17:02 |
| * Makyo gets out the squirt bottle. | 17:03 | |
| Makyo | Works on the dogs... | 17:03 |
| hatch | haha | 17:03 |
| * rick_h_ runs errand biab | 17:28 | |
| hatch | alllright, I finally talked to someone who MAY be able to fix my internet | 17:28 |
| hatch | lol | 17:28 |
| hatch | so much fail today | 17:29 |
| hatch | yay! It's getting fixed this afternoon | 17:33 |
| * rogpeppe has reached eod | 17:34 | |
| rogpeppe | frankban: that branch finally landed, BTW | 17:34 |
| frankban | rogpeppe: \o/ looking at your cp branch | 17:34 |
| hatch | I'm going to run grab a bite before the tech gets here to fix this net | 17:47 |
| frankban | rogpeppe: done | 17:50 |
| hatch__ | oh great the internet started working again before the tech got here.... | 18:51 |
| rick_h_ | lol | 18:51 |
| rick_h_ | now you've done it | 18:51 |
| hatch__ | yeah now this thing is never getting fixedx | 18:52 |
| === hatch__ is now known as hatch | ||
| Makyo | hatch, That change doubled the FPS (read: halved the amount of time blocking on render) from ~7fps to ~15fps. | 18:53 |
| Makyo | Still takes the same amount of time, ofc. | 18:53 |
| Makyo | Which would help with the spinner. | 18:53 |
| hatch | Makyo ok so that's likely why we didn't notice it before | 18:53 |
| hatch | alright then | 18:54 |
| rick_h_ | yea, with the spinner and less time | 18:54 |
| rick_h_ | blocked up taht is | 18:54 |
| rick_h_ | I did notice the spinner hang some, but not enough that it felt broken | 18:54 |
| hatch | Makyo with a spinner would it now be acceptable? | 18:54 |
| Makyo | I think so | 18:54 |
| Makyo | It would feel better, at least. | 18:54 |
| rick_h_ | yay | 18:54 |
| hatch | and we can put off the conversion to a view for some time later | 18:55 |
| rick_h_ | +1 | 18:55 |
| Makyo | +1 | 18:55 |
| rick_h_ | thank you Makyo for chasing that down and testing it out | 18:56 |
| hatch | it's interesting just how much slower widgets truly are | 18:57 |
| Makyo | I wonder if the views would have much in the way of improvement, since the slowness shows up in some of the base node manip stuff, like setHTML. | 18:58 |
| rick_h_ | yea, I guess I wonder how much is parents vs just widgets/etc | 18:58 |
| Makyo | But yeah, I'm still learning the whole widget thing. | 18:58 |
| hatch | well we dump considerably more dom nodes into tho dom with the inspector unit list on a big environment | 19:00 |
| hatch | that uses append() | 19:00 |
| hatch | so I'm guessing that it has to do with some html parsing or something that's being done with the widgets | 19:00 |
| hatch | because there is some progressive enhancement stuff tha'ts built in | 19:00 |
| hatch | maybe we are hitting that | 19:00 |
| hatch | this is totally speculation though | 19:00 |
| Makyo | Okay, yeah, that makes sense. I think it's come to bite us more recently because of the addition of bundles, too, which have more elements in the dom (some of which are SVGs, which chrome is parsing) | 19:01 |
| hatch | ahhh | 19:02 |
| hatch | darn svg's | 19:02 |
| hatch | I noticed that we request the same svg a lot | 19:02 |
| hatch | even though it has the same request path | 19:02 |
| Makyo | That is how img elements, work, yes :) | 19:03 |
| Makyo | Ditto svg image elements. | 19:03 |
| hatch__ | I never thought i'd be happy that the internet broke again....lol | 19:04 |
| === hatch__ is now known as hatch | ||
| bac | hey rick_h_, got a sec for a chat? | 19:27 |
| rick_h_ | bac: 2min? | 19:28 |
| bac | sure | 19:28 |
| rick_h_ | bac: k, standup hangout? | 19:29 |
| bac | k | 19:29 |
| hatch | tech is here, bbiab | 19:39 |
| rick_h_ | good luck | 19:39 |
| hatch | heh it's not looking good | 19:48 |
| hatch | rick_h_ btw doing the id bits in the bundle model was pretty small loc's | 19:48 |
| hatch | so i'll leave it in | 19:48 |
| rick_h_ | hatch: woot | 19:48 |
| rick_h_ | had hoped so | 19:48 |
| hatch | rick_h_ so regarding the search caching.....I don't think it's going to be an issue because modellists don't add multiple models with the same id's | 20:14 |
| hatch | so the charm models won't grow exponentially, only linearly | 20:14 |
| rick_h_ | hatch: ok, but QA it with a bundle: and charm: and "" search | 20:15 |
| hatch | right now when I do a bundle: search I only get a single bundle | 20:15 |
| rick_h_ | if it qa's ok and not deadly with the large basis then cool | 20:15 |
| hatch | is charmworld broken that it only returns 1? | 20:15 |
| rick_h_ | hmm, maybe not | 20:15 |
| hatch | i'll try jujucharms | 20:16 |
| hatch | yeah only one.... | 20:16 |
| hatch | odd...I was sure that returned a massive json | 20:16 |
| rick_h_ | ok, then yea oh well | 20:16 |
| rick_h_ | we fixed a lot of that | 20:16 |
| hatch | but broke bundle: ? :) | 20:16 |
| rick_h_ | heh, well not sure that was supposed to work | 20:17 |
| rick_h_ | bundle:apache should | 20:17 |
| hatch | checking | 20:17 |
| rick_h_ | hmm, yea bundle: was supposed to work for all bundles | 20:17 |
| rick_h_ | how about just bundle | 20:17 |
| rick_h_ | w/o the : | 20:17 |
| hatch | bundle:apache doesn't | 20:17 |
| hatch | trying without the : for bundle | 20:17 |
| hatch | yeah it's hanging | 20:17 |
| hatch | that must be it | 20:17 |
| rick_h_ | heh there you go | 20:17 |
| hatch | hmm it only returned 52 bundles | 20:18 |
| hatch | but took fo eva! | 20:18 |
| rick_h_ | hah, well bundles take a while to build since htey include charm info | 20:18 |
| hatch | but ok cool I'll check that out with the caching | 20:18 |
| hatch | ohhhh right | 20:18 |
| hatch | looks good even with a big data set | 20:21 |
| rick_h_ | woot | 20:21 |
| hatch | memory footprint of course goes up according to the size of the huge dataset | 20:21 |
| hatch | so we should still see what we can do about reducing the data sent at some point | 20:21 |
| rick_h_ | yep yep | 20:21 |
| rick_h_ | but that's on the api end side to do | 20:21 |
| hatch | right now our box for the gui should say "requires a minimum of 200MB of ram" ;) | 20:22 |
| rick_h_ | :P | 20:22 |
| Makyo | hatch, mind taking a look? Trying to figure out how to test. https://github.com/juju/juju-gui/pull/373 | 20:34 |
| hatch | sure | 20:34 |
| hatch | heh hmm | 20:34 |
| hatch | Makyo maybe adding some comments around the render() call for future devs and for the tests make sure it's called with the proper string in the tests using a stub | 20:35 |
| Makyo | Hmm, alright. | 20:36 |
| hatch | I'm also not sure container is used any longer | 20:36 |
| Makyo | This is gonna be finnicky. | 20:36 |
| Makyo | charmList = container.one... | 20:36 |
| hatch | oh duh | 20:36 |
| hatch | heh | 20:36 |
| Makyo | It's basically the same exact functionality, just in a slightly different order. | 20:36 |
| rick_h_ | Makyo: yea, I think you can do that with a big QA and comments around that | 20:37 |
| hatch | well render is being called with a different string | 20:37 |
| hatch | er elements | 20:37 |
| hatch | I know it's pretty basic but that's all I can see here without doing any selenium stuff | 20:38 |
| rick_h_ | hatch: yea, true | 20:38 |
| rick_h_ | but even selenium stuff is hard to catch | 20:38 |
| hatch | oh yeah for sure - I've been doing some research on performance testing in CI | 20:38 |
| hatch | would be pretty cool if we could somehow get a more stable CI machine | 20:39 |
| hatch | stable being performance wise | 20:40 |
| hatch | uh oh internet is looking like it's going to be a bit | 20:53 |
| hatch | the lines going into the house are bad | 20:55 |
| hatch | rick_h_ did you see someone picked up the a Review Board charm | 21:31 |
| rick_h_ | hatch: yea, saw that. I can't seem to find a good way to work reviewboard into the workflow though to be honest | 21:36 |
| rick_h_ | everything I find really doesn't even try to work with the pull request system in github. A lot of it is pre-pull request review style stuff | 21:36 |
| rick_h_ | all diff based, which doesn't help our lander/etc systems | 21:36 |
| hatch | that was my reviewing as well - I was hoping to get some time more time this week to dig in and see if we could write a hook or something | 21:37 |
| hatch | s/hook/plugin | 21:37 |
| hatch | although tbh I think that GH is working pretty well for us | 21:37 |
| hatch | it has some warts, but what doesn't heh | 21:37 |
| rick_h_ | yea, but it definitely has some scale issues imo. The side by side review plugin is :( compared to a real side by side tool | 21:38 |
| hatch | right - but since I've been doing the inline stuff I miss side-by-side less and less | 21:38 |
| hatch | maybe it's just the type of work I've been doing | 21:38 |
| rick_h_ | yea, maybe it won't work out, but had high hopes for it | 21:39 |
| hatch | I think with GH not showing the whitespace changes like reitveld did, side-by-side isn't as important because diffs are typically less than 20 lines | 21:40 |
| hatch | per block | 21:40 |
| hatch | more than enough that can fit on the screen | 21:40 |
| hatch | yes, side-by-side IS better, but inline isn't horrible imho | 21:40 |
| rick_h_ | yea, I mean there's the email flood, the lack of diff's in rebased stuff, etc. | 21:41 |
| rick_h_ | more to it I guess, but yea, if it can't fit into the workflow in a sane way I don't want to write another app to do it | 21:41 |
| hatch | yeah the email is crazy but if you use the email threads or whatever you can easily delete the whole thread | 21:42 |
| hatch | the lack of diffs in rebased kind-of sucks....but I can't think of once where I actually needed it since we switched over | 21:42 |
| rick_h_ | "if you use" :P | 21:42 |
| hatch | well use a real client :P | 21:42 |
| rick_h_ | you're getting very much into your use vs the team as a whole tbh | 21:42 |
| hatch | wait, even mutt does threads | 21:43 |
| rick_h_ | yes it does | 21:43 |
| rick_h_ | just mean that you're projecting "it's not an issue if you do XXX" is not the best argument for stuff like this | 21:44 |
| rick_h_ | as you fall deep into assumptions | 21:44 |
| hatch | oh right - well got to adapt to the tools sometimes unfortunately | 21:45 |
| hatch | good thing we all got into web dev, nothing ever changes here :P | 21:45 |
| rick_h_ | :) | 21:47 |
| hatch | installing that tree file system plugin for GH has saved so much time | 21:48 |
| hatch | that sort of stuff should be installed by default hah | 21:48 |
| hatch | well looks like I might be going to pick up one of those things you mentioned rick_h_ because if they need to run a new line it might be a bit before I get internet again :/ | 21:59 |
| hatch | see everyone tomorrow | 22:56 |
| huwshimi | Morning | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!