| === _mup__ is now known as _mup_ | ||
| frankban | morning rogpeppe: how are you doing? | 08:19 |
|---|---|---|
| rogpeppe | frankban: hiya | 08:19 |
| rogpeppe | frankban: not too bad | 08:19 |
| rogpeppe | frankban: just reading the leader election thread | 08:19 |
| frankban | rogpeppe: are you migrating filetesting? | 08:20 |
| rogpeppe | frankban: yes, i have a LGTM and can merge it | 08:20 |
| rogpeppe | frankban: i'll do that now | 08:20 |
| frankban | rogpeppe: ok I moved the card in coding and assigned to you, please put it in daily accomp. when done. | 08:21 |
| frankban | rogpeppe: do you have notes on the migration steps? | 08:22 |
| rogpeppe | frankban: hmm, i thought i had a card | 08:22 |
| rogpeppe | frankban: i haven't made the notes yet, but i've got all the shell history :-) | 08:22 |
| frankban | rogpeppe: cool, could you please share it? you have a card for utils, I believe you switched to filetesting because some packages in utils depend on it, correct? | 08:23 |
| rogpeppe | frankban: yup | 08:23 |
| rogpeppe | frankban: zip/zip_test.go | 08:24 |
| rogpeppe | frankban: that seems to be the only one | 08:24 |
| frankban | rogpeppe: cool, I guess I am going to migrate schema | 08:26 |
| rogpeppe | frankban: that should probably go inside utils, i think | 08:27 |
| rogpeppe | frankban: i don't really think it justifies its own repo | 08:27 |
| rogpeppe | frankban: then again, i don't mind much | 08:28 |
| rogpeppe | frankban: if you think otherwise | 08:28 |
| frankban | rogpeppe: I proposed the same last week and David said: "Yes to migrating it, no to renaming it. Schema is useful as a top | 08:29 |
| frankban | level project, rather than buried in an amorphous utils repo." | 08:29 |
| rogpeppe | frankban: ok, fair enough | 08:30 |
| frankban | rogpeppe: ugm. it seems I don't have permission to create a repo in juju :-/ | 08:34 |
| frankban | rogpeppe: when you can, could you please 1) create a juju/schema repo (I don't have permission) and 2) send me the commands you used to split filetesting? | 08:42 |
| rogpeppe | frankban: 1) is now done | 08:45 |
| rogpeppe | frankban: for 2) you won't need the more complex commands that i used | 08:45 |
| rogpeppe | frankban: because you're not merging into an existing repo | 08:46 |
| rogpeppe | frankban: and you don't need to rewrite pathjs | 08:46 |
| frankban | rogpeppe: 1) thanks | 09:01 |
| frankban | rogpeppe: github says https://github.com/juju/schema is empty and I cannot fork it | 09:01 |
| rogpeppe | frankban: utils is now factored out; here's a trivial PR that adds README.md and LICENSE: https://github.com/juju/utils/pull/1 | 09:02 |
| rogpeppe | frankban: you'll need to push directly to it initially | 09:02 |
| frankban | rogpeppe: ah, so initial push with an empty repo or with the actual repo generated by "git filter-branch"? | 09:05 |
| frankban | rogpeppe: LGTM | 09:05 |
| rogpeppe | frankban: the latter | 09:06 |
| frankban | rogpeppe: ERROR: Permission to juju/schema.git denied to frankban. | 09:18 |
| frankban | rogpeppe: any idea? | 09:40 |
| rogpeppe | frankban: sorry, missed your earlier comment | 09:41 |
| rogpeppe | frankban: looking | 09:41 |
| frankban | thanks | 09:41 |
| rogpeppe | frankban: what command did you use? | 09:42 |
| frankban | git remote add upstream git@github.com:juju/schema.git | 09:42 |
| frankban | git push upstream master | 09:43 |
| frankban | rogpeppe: ^^ | 09:43 |
| frankban | rogpeppe: in https://github.com/juju/schema I only see: | 09:44 |
| frankban | This repository is empty. | 09:44 |
| frankban | Care to check out the GitHub Channel on YouTube while you wait? | 09:44 |
| rogpeppe | frankban: does it behave differently if you do: git remote remove upstream; git remote add upstream https://github.com/juju/schema.git ? | 09:44 |
| frankban | rogpeppe: it asks for user and password and then exits with: fatal: unable to access 'https://github.com/juju/schema.git/': The requested URL returned error: 403 | 09:45 |
| rogpeppe | frankban: hmm, weird | 09:46 |
| rogpeppe | frankban: i'll try pushing a branch to it | 09:46 |
| frankban | rogpeppe: https://github.com/juju/schema/settings/collaboration ? | 09:48 |
| frankban | rogpeppe: now I see your branch but I cannot fork | 09:49 |
| rogpeppe | frankban: ah, i hadn't seen the collaboration settings | 09:49 |
| rogpeppe | frankban: you should be able to push now | 09:49 |
| frankban | rogpeppe: done, could you please remove the testing branch? | 09:50 |
| rogpeppe | frankban: yeah, just trying to work out how to do that | 09:50 |
| rogpeppe | frankban: hmm, it's not obvious... | 09:52 |
| frankban | rogpeppe: I did it | 09:53 |
| frankban | rogpeppe: git push upstream :testing | 09:53 |
| rogpeppe | frankban: ah yes, i'd forgotten that idiom | 09:53 |
| frankban | rogpeppe: https://github.com/juju/schema/pull/1 | 09:57 |
| rogpeppe | frankban: LGTM | 09:58 |
| frankban | thanks | 09:59 |
| frankban | rogpeppe: could you please create a juju/names repo and give me write permission? | 10:28 |
| rogpeppe | frankban: yup | 10:28 |
| frankban | thanks | 10:31 |
| rogpeppe | frankban: done | 10:34 |
| frankban | rogpeppe: thanks | 10:37 |
| frankban | rogpeppe: could you please review https://github.com/juju/juju/pull/25 ? | 10:37 |
| rogpeppe | frankban: LGTM | 10:38 |
| frankban | rogpeppe: do you know if in the new git world dependencies.tsv changes are handled by the bot? | 10:38 |
| rogpeppe | frankban: i don't - best ask on #juju-dev | 10:39 |
| frankban | rogpeppe: yeah, already done | 10:39 |
| frankban | rogpeppe: thanks for the review, I guess I'll try to $$merge$$ it | 10:39 |
| rogpeppe | frankban: good plan | 10:41 |
| frankban | rogpeppe: and now names | 10:42 |
| frankban | rogpeppe: FWIW, these are the notes I've taken while migrating schema: http://pastebin.ubuntu.com/7593938/ | 10:42 |
| rogpeppe | frankban: BTW your "fix import paths" step can be done automatically by running "govers -m github.com/juju/juju/schema github.com/juju/schema" in the schema directory | 10:45 |
| rogpeppe | frankban: what's the difference between an https remote and a git@github remote? | 10:46 |
| frankban | rogpeppe: https vs ssh | 10:46 |
| rogpeppe | frankban: is one preferred over the other? | 10:47 |
| frankban | rogpeppe: not sure, I prefer ssh because https asks me credentials | 10:47 |
| frankban | rogpeppe: ssh uses the ssh key | 10:48 |
| rogpeppe | frankban: hmm, i guess i can tell github about my ssh key | 10:49 |
| frankban | rogpeppe: https://help.github.com/articles/generating-ssh-keys | 10:50 |
| rogpeppe | jeeze my network is stupidly slow today | 11:27 |
| rick_h_ | ssh is faster and uses the key vs password. | 11:47 |
| frankban | rogpeppe: trivial https://github.com/juju/names/pull/1 | 12:08 |
| rogpeppe | frankban: LGTM | 12:09 |
| frankban | rogpeppe: thanks | 12:10 |
| frankban | rogpeppe: could you please take a look at https://github.com/juju/juju/pull/27 ? (mechanical) | 12:50 |
| rogpeppe | frankban: did that previous branch merge ok? | 12:52 |
| frankban | rogpeppe: yes | 12:52 |
| rogpeppe | frankban: or did you have to do something manually to update the deps? | 12:52 |
| frankban | rogpeppe: no it seems they are handled automatically now | 12:53 |
| rogpeppe | frankban: great! | 12:53 |
| frankban | yeah | 12:53 |
| rogpeppe | frankban: LGTM | 12:53 |
| frankban | rogpeppe: great thanks | 12:54 |
| bac | hi rick_h_ -- i got an email from the LocalCharmGuy asking how to ingest local bundles. afaik we've not tried that before but it should be similar. shall i finish my current task and then help him? | 13:03 |
| kadams54 | morning all | 13:06 |
| jcsackett | morning kadams54. | 13:09 |
| kadams54 | rick_h_: you around? | 13:10 |
| redir | morining | 13:12 |
| redir | I have to go get a blood test. | 13:12 |
| redir | bbiab | 13:12 |
| rick_h_ | kadams54: kinda what's up? | 13:21 |
| kadams54 | rick_h_: Just wondering what needs working on next. I could start tackling all the feedback from design or I could move into the cards for MV. Very hesitant to start in on an IL card until hatch is in, to make sure we aren't setting up painful merge conflicts. | 13:23 |
| rick_h_ | kadams54: yea, any MV card, especially that was part of our planning poker for this sprint is good | 13:27 |
| rick_h_ | kadams54: there's some wire cards that might work out | 13:27 |
| rick_h_ | kadams54: did you move all the cards you had created in there? | 13:28 |
| kadams54 | Yeah, going to start in on the one for choosing constraints | 13:28 |
| rick_h_ | ah cool, thanks for moving those to the pool. I think on deck would be good as well | 13:28 |
| kadams54 | rick_h_: I moved them into the Pool for Project 1, per hatch's suggestion yesterday. | 13:28 |
| rick_h_ | but nice to split out back down to our planned work for the sprint | 13:28 |
| rick_h_ | +1 | 13:28 |
| kadams54 | Also setup a metatask card for the design feedback | 13:28 |
| rick_h_ | I'll be doing card gardening today/tomorrow | 13:28 |
| kadams54 | I did real gardening yesterday. | 13:28 |
| kadams54 | I suspect you'll end up with fewer mosquito bites. | 13:29 |
| rick_h_ | awesome, had enough of those to last me a while this week :) | 13:29 |
| kadams54 | Though I suppose that depends on where you're camping :-) | 13:29 |
| kadams54 | I have NEVER seen mosquitos this bad | 13:29 |
| rick_h_ | did you see my pics? | 13:30 |
| kadams54 | No, where at? | 13:30 |
| bac | hey frankban, we've also got to do a quickstart release to get the OS X support...my brew recipe works but it installs 1.3.2 and then promptly fails b/c it doesn't have the new work. i'll be glad to start on the QA, do the release, whatever. | 13:30 |
| bac | rick_h_: your pics were good. liking the new camera? | 13:30 |
| rick_h_ | bac: <3 I upgraded from the kit lense yesterday and got a tripod so looking forward to playing with it some more | 13:31 |
| rick_h_ | kadams54: https://www.flickr.com/photos/7508761@N03/14300218662/ and https://www.flickr.com/photos/7508761@N03/14115492088/ | 13:31 |
| kadams54 | moving up from a kit lens is such a *huge* improvement | 13:31 |
| bac | rick_h_: which tripod? there some cool, lightweight travel ones out now | 13:31 |
| frankban | bac: ok, I'll make the deb packages in quickstart beta, then I'd appreciate your help for QA | 13:32 |
| rick_h_ | bac: mefoto one, the middle one | 13:32 |
| rick_h_ | bac: it'll do a monopod as well which I liked for travel | 13:32 |
| bac | rick_h_: yeah that's one of the ones i was thinking of | 13:32 |
| kadams54 | rick_h_: Yeah, that's about right. The only thing I've ever seen that's even close is the swarm of mosquitoes above the latrine at Minnesota camp sites in the Boundary Waters. | 13:33 |
| bac | frankban: great! | 13:33 |
| rick_h_ | ok, car is ready...out for a bit | 13:33 |
| kadams54 | Have fun! | 13:34 |
| bac | rick_h_: i hope you got the purple | 13:34 |
| frankban | rogpeppe: is juju/utils usable? | 13:38 |
| rogpeppe | frankban: it should be | 13:39 |
| frankban | rogpeppe: ok thanks | 13:39 |
| frankban | rogpeppe: I'll tackle the FakeHomeSuite next | 13:39 |
| rogpeppe | frankban: i'll change charm so that it doesn't use environs/config | 13:40 |
| frankban | rogpeppe: sounds good | 13:40 |
| frankban | rogpeppe: don't we need to remove some packages from utils in core? | 13:41 |
| rogpeppe | frankban: ah yes, and most of utils itself | 13:41 |
| rogpeppe | frankban: i'll do that too | 13:42 |
| rogpeppe | frankban: along with making juju use utils | 13:42 |
| frankban | rogpeppe: yeah thanks, so that you can move your current card to done | 13:42 |
| frankban | rogpeppe: names removal landed in core | 13:43 |
| frankban | bac: quickstart packages pending | 13:53 |
| frankban | bac: https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-daily | 13:53 |
| bac | frankban: so we will qualify the .deb, then release to pypi, and then i can qualify on os x, and try to get the brew formula accepted. sound about right? | 14:06 |
| frankban | bac: sounds good | 14:06 |
| frankban | bac: do you have a saucy vm? | 14:09 |
| * bac looks | 14:09 | |
| bac | frankban: i do. i collect them like baseball cards | 14:10 |
| frankban | bac: heh | 14:10 |
| bac | lucid, quantal, raring, saucy, trusty ... and some from lesser OSes | 14:10 |
| frankban | bac: so QA can be something like: verify lxc envs work, verify ec2, verify idempotence, check bundle deployments work. | 14:12 |
| frankban | bac: the above on trusty and saucy, and that should be enough | 14:12 |
| bac | frankban: how is the idempotence step done? you mean uses existing bootstrapped env? | 14:13 |
| frankban | bac: quickstart must be installed from the PPA, and the machine should not have juju-core installed (so that we can also verify juju installation) | 14:13 |
| frankban | bac: yeah, running on an existing environment, perhaps also running on an existing environment without the GUI deployed | 14:14 |
| rick_h_ | bac: red :P | 14:15 |
| rick_h_ | bac: frankban a doc of qa for a release like that would be useful as things get more complex. I'm not sure how to look into automating test/qa across OS and systems like that now. | 14:19 |
| bac | rick_h_: i'm starting a QA doc. | 14:19 |
| rick_h_ | bac: rock on! | 14:20 |
| bac | will do google doc for now and we can move it to the tree if we want | 14:20 |
| rick_h_ | yea, in tree ftw so it's easy to update it as required as the code changes | 14:20 |
| rick_h_ | and easier to hand off next ccyle | 14:20 |
| rick_h_ | cycle | 14:20 |
| bac | rick_h_: even though you are not here, did you see my question regarding local bundle ingestion? | 14:21 |
| frankban | rick_h_, bac: +1 on a doc that will be merged into HACKING, but I'd really love if quickstart had functional tests which can be run by the juju CI against current and devel juju releases | 14:21 |
| rick_h_ | bac: no, I didn't see it sorry | 14:21 |
| rick_h_ | frankban: yea, definitely +1 on working with QA on that. Not sure how much OSX QA they can setup but maybe there's others around we can ask about these sorts of issues. | 14:22 |
| bac | our friend has local charm ingestion working. he'd now like to do local bundles. i've never tried it so i'd have to get it to work then document. | 14:22 |
| rick_h_ | what is a 'local bundle'? | 14:22 |
| rick_h_ | ah, a bundle with local charms...not going to happen right now. | 14:22 |
| bac | he wants his bundles to show up in the sidebar of juju gui | 14:23 |
| rick_h_ | yea, that's not currently supported. | 14:23 |
| bac | well...if he's running his own charmworld (he is) and has ingested local charms as he has, then ingesting bundles should just work, for some amount of config/poking. | 14:24 |
| bac | unless i'm missing a failure point regarding the charm store or something | 14:24 |
| rick_h_ | well we'll have to walk him through getting those bundles ingested as he doesn't want to submit them to lp charms/bundles | 14:25 |
| rick_h_ | and honestly we've got a really nice chunk of time sunk into this | 14:25 |
| hatch | now that core has switched to GH and is getting an email per comment......holy smokes lots of emails hah! | 14:28 |
| redir | rogpeppe: frankban am I missing something here? http://juju-ci.vapour.ws:8080/job/github-merge-juju/23/console | 14:40 |
| redir | how can there be panics and FAILs and pass? | 14:40 |
| frankban | redir: uhm, it seems tests run a first time and failed, and then a second time successfully | 14:42 |
| redir | mmm yes I missed the + go test -p 2 ./... | 14:43 |
| frankban | redir: so the first time they failed using all the cpu cores. subsequently the lander switches to using 2 cores | 14:44 |
| redir | -p is cores? and not -cpu? | 14:46 |
| redir | jujugui standup in 10 | 14:50 |
| frankban | redir: the number of builds that can be run in parallel | 14:52 |
| frankban | redir: from "go help build" | 14:53 |
| Makyo | hatch, ping | 14:53 |
| hatch | yesm | 14:54 |
| Makyo | Just curious if our branches are going to collide. Is the solution you're working towards the fact that there are two div.left-breakout elements and the fillSlot code is not grabbing the right one? | 14:55 |
| hatch | Makyo yes ish - I'm still trying to determine the right approach | 14:56 |
| hatch | there are left-breakouts which aren't used | 14:57 |
| hatch | then there is the bws-data elements which are | 14:57 |
| hatch | but they are using the wrong ones | 14:57 |
| hatch | this stuff is really borked | 14:57 |
| hatch | chat after the standup? | 14:57 |
| Makyo | hatch, yep, that sums it up nicely. We'll talk then. | 14:57 |
| Makyo | jujugui call in 2 | 14:58 |
| bac | jcsackett: i'll be glad to look at your charmworldlib MP | 15:09 |
| jcsackett | bac: oh, it's coming. but it'll have to be slack. | 15:10 |
| bac | jcsackett: ok. | 15:12 |
| * rogpeppe wishes that you could see the comment that was being replied to in git code review comments. | 15:16 | |
| hatch | rogpeppe you can | 15:23 |
| rogpeppe | hatch: ... by going to the web page, right? | 15:23 |
| hatch | yeah - unless they rebased it away | 15:23 |
| hatch | then it only has the few lines surrounding it | 15:23 |
| hatch | rogpeppe it could be worse, it could be LP which doesn't even give you a link to the repo in it's emails lol | 15:24 |
| redir | change is hard | 15:29 |
| kadams54 | hatch: you available to chat? | 15:43 |
| hatch | just feeding the dogs, 2 mins | 15:43 |
| kadams54 | redir: Yeah, that's why I decided to be a programmer. A nice, comfy career secluded from change. ;-) | 15:44 |
| redir | :) | 15:44 |
| redir | kadams54: at least for several minutes at a time | 15:44 |
| hatch | kadams54 ok - standup room should be empty | 15:46 |
| hatch | blah it dropped | 15:48 |
| hatch | one sec kadams54 | 15:48 |
| kadams54 | maybe I'm not the one with bandwidth/lag issues ;-) | 15:49 |
| frankban | bac: quickstart packages are ready | 16:18 |
| redir | rogpeppe: is there a command to create the juju lxc container templates ? | 16:23 |
| rogpeppe | redir: no AFAIK. i think they should be created automatically by juju. | 16:23 |
| redir | rogpeppe: I mean without deploying something | 16:24 |
| rogpeppe | redir: what are you trying to do? | 16:25 |
| redir | I am trying to get consistent test passage | 16:25 |
| redir | I have 2 machines with lxc containers that have nothing but juju core on them | 16:26 |
| redir | one passes all tests with -p 2 flag and the other fails lxc-test | 16:26 |
| redir | oh well. | 16:28 |
| redir | it works on one, I'll work on that machine:) | 16:28 |
| hatch | kadams54 ok review done - feel free to take a look and lemme know where you want to go from here | 16:28 |
| kadams54 | ok | 16:28 |
| frankban | bac: resulting package is broken, missing "python-websocket-client". I'll try to fix that. | 16:29 |
| frankban | bac: re-building... | 16:36 |
| frankban | bac: packages should be ready in ~30mins. I am not sure about "websocket-client" in saucy and precise (maybe we will need to create backports) BTW if they install correctly feel free to proceed with QAing and release. Releasing involves steps in http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/HACKING.rst#L101 | 17:01 |
| hatch | kadams54 so thoughts on my comments? | 17:22 |
| kadams54 | hatch: oh yeah, sorry, they look good, working on implementing right now | 17:22 |
| hatch | ok great - you'll need to close Huw's and re-PR unfortunately | 17:23 |
| hatch | I wish people could do coop PR's | 17:23 |
| rogpeppe | i'm done for the day | 17:52 |
| rogpeppe | g'night all | 17:52 |
| * bac misses having LP super powers to bump up build farm priority... | 18:04 | |
| hatch | bac haha, I thought you had those up until recently | 18:33 |
| hatch | when did they get taken away? | 18:33 |
| Makyo | YES | 19:27 |
| Makyo | Got it. | 19:27 |
| Makyo | Finally. | 19:27 |
| Makyo | There are so many tiny little parts to the viewlets system. | 19:28 |
| Makyo | It's pretty cool when it works right, though! | 19:30 |
| hatch | Makyo YAY! | 19:39 |
| hatch | Makyo I would be interested in hearing ways to make it easier to follow | 19:39 |
| Makyo | Probably could've used some RTFM on my part :) | 19:39 |
| hatch | lol | 19:39 |
| hatch | I'm also pretty pumped about this cache system | 19:40 |
| hatch | little concerned noone else will be though haha | 19:40 |
| Makyo | I promise I will be sufficiently pumped. | 19:43 |
| rick_h_ | :) why would no one else be pumped hatch? | 19:44 |
| hatch | rick_h_ because it's magical! | 19:44 |
| * rick_h_ raises eyebrows at the word 'magic' in the area of coding | 19:44 | |
| rick_h_ | as long as it's not so magical that only a wizard can figure it out later after years of additional study :P | 19:45 |
| hatch | haha | 19:47 |
| hatch | https://github.com/hatched/juju-gui/blob/caching-charmbrowser/app/utils/cache.js | 19:49 |
| hatch | ^ rick_h_ Makyo | 19:49 |
| Makyo | TWO underscores! That really is magic. | 19:50 |
| kadams54 | That's python-agical. | 19:50 |
| kadams54 | Dunder here we come! | 19:50 |
| hatch | lol - the more underscores is the importance of the dev not using it directly | 19:52 |
| hatch | at two you BETTER know what you're doing :P | 19:52 |
| hatch | three...well three....wow | 19:52 |
| hatch | just no | 19:52 |
| hatch | just FYI that code doesn't run, I had a bug in there :) | 19:55 |
| rick_h_ | huh? one public method, no tests to follow expected working/use :P | 19:56 |
| hatch | I'm writing the rest of the tests now | 19:57 |
| Makyo | JDD - Jeff Driven Development. | 20:03 |
| hatch | lol | 20:07 |
| hatch | WWJD | 20:07 |
| hatch | What Would Jeff Do | 20:07 |
| hatch | <sub>Is probably not what you want to do</sub> | 20:07 |
| hatch | lol | 20:07 |
| hatch | so our linter gets confused by functions in comment blocks | 20:17 |
| hatch | yay.... | 20:17 |
| hatch | lol | 20:17 |
| hatch | jujugui looking for a review of the new cache object https://github.com/juju/juju-gui/pull/368 | 20:20 |
| redir | If I knew JS I would look at it and say __LGTM__, alas the joke falls flat | 20:21 |
| bac | hatch: i'm not sure when my wonder-powers were removed. probably when they noticed all of my PPAs hogging the build farm. :) | 20:22 |
| hatch | redir lol | 20:22 |
| hatch | bac haha | 20:23 |
| hatch | so.......anyone able to do that review? jujugui.......beuler? | 20:47 |
| jcsackett | hatch: sure. | 20:53 |
| redir | hatch: __UNQUALIFIED__ :) | 20:53 |
| hatch | jcsackett sweet thx | 20:54 |
| jcsackett | hatch: no tests? | 20:54 |
| hatch | umm | 20:54 |
| hatch | crap | 20:55 |
| hatch | one sec | 20:55 |
| jcsackett | k. | 20:55 |
| hatch | ok tests :) | 20:55 |
| hatch | man I'm fast at writing tests eh? :P | 20:55 |
| jcsackett | superfast. :p | 21:00 |
| jcsackett | hatch: this is really hard to review absent its use; two things stand out to me: why are we bothering with supplying special setters/getters? is there a use case already? | 21:15 |
| hatch | jcsackett interesting and search | 21:15 |
| hatch | well search*n for each search query | 21:15 |
| hatch | it's a highly generic cache layer which allows you to do with it what you want | 21:15 |
| jcsackett | hatch: yeah, i'm just saying it seems overly generic. but that's not a big deal. | 21:16 |
| hatch | correct it is | 21:16 |
| jcsackett | my bigger question is also a comment in the PR. that whole autogenerating setters/getters thing. | 21:16 |
| jcsackett | i don't see how that's desireable--i would much rather cache.set(key, data) than cache['get'+key](data) if i'm doing caching of arbitrary objects, which seems likely. | 21:17 |
| hatch | sure, replying | 21:18 |
| jcsackett | hatch: ok. wasn't sure if you preferred here or in github, given the long convo in the other channel we had earlier. :) | 21:18 |
| jcsackett | but i guess that was more python questions than code review. | 21:18 |
| hatch | oh haha yeah that was mostly pythony related | 21:19 |
| hatch | ok replied | 21:19 |
| rick_h_ | replied :) | 21:20 |
| jcsackett | he emerges, from the deeps. | 21:20 |
| rick_h_ | builder just got through telling me my $30k screened porch should be a $90k+ addition :/ | 21:21 |
| rick_h_ | so disclaimers and all that | 21:21 |
| * jcsackett laughs | 21:21 | |
| hatch | rick_h_ did you tell them that they can do whatever they want as long as it's $30k? lol | 21:21 |
| rick_h_ | heh | 21:21 |
| jcsackett | hatch: assuming i'm swayed on the custom getter/setter thing, i think i can be convinced this is all lovely if you make the "getnameofthing" functions "_getnameofthing" and give me a get(key, data) function that grabs the goofy name and calls that. | 21:22 |
| jcsackett | but that's a workaround if i'm swayed on the custom bit. | 21:22 |
| hatch | jcsackett if we want it to be super basic we can just use a global object and call it a day | 21:23 |
| hatch | then if you want a custom getter/setter hang it off the object | 21:23 |
| hatch | this was an attempt to formalize access of the cache | 21:24 |
| jcsackett | i mean, i'm pro a uniform cache for everything; and i like a wrapper protecting access to an internal __storage object that deep copies. | 21:25 |
| rick_h_ | hatch: so the requirements are a shared object with a single modellist for all cached charm models + a flexible list of defined/named modellists (interesting, search_term1_term2) or the like? | 21:26 |
| jcsackett | hatch: i'll be back to continue looking at this soon--have to make an emergency run to the store. | 21:26 |
| hatch | rick_h_ replied to your request for the use case | 21:27 |
| rick_h_ | hatch: ty | 21:27 |
| rick_h_ | reviewing more thoroughly now | 21:27 |
| hatch | jcsackett I think I might agree with your get('nameofthing') to _getnameofthing() conversion | 21:30 |
| hatch | thinking through it | 21:30 |
| rick_h_ | hatch: replied and reviewed | 21:31 |
| jcsackett | hatch: cool. | 21:31 |
| hatch | it makes it cleaner to interact with, I see no down side to it | 21:31 |
| hatch | back from the store already? | 21:32 |
| hatch | wow | 21:32 |
| jcsackett | On my phone. It beeped as I was getting in my car. | 21:32 |
| hatch | oh :) | 21:33 |
| jcsackett | Call my name and I shall appear. Assuming my IRC notifications aren't all hacked up. :p | 21:34 |
| rick_h_ | beatlejuice beatlejuice jcsackett | 21:35 |
| * rick_h_ checks if it worked | 21:35 | |
| jcsackett | Oh, to do that it has to be in a mirror in the dark. | 21:36 |
| jcsackett | Hatch: with the change to the customs being _ and a get/set db that looks up the customs, my chief complaint is addressed. | 21:36 |
| jcsackett | rick_h_ clearly has several that I think are valid. | 21:37 |
| hatch | rick_h_ lol!! | 21:37 |
| hatch | rick_h_ replied to the long thread again :) | 21:37 |
| hatch | replying to the rest now | 21:38 |
| rick_h_ | hatch: ok, replied back one more time. I've got to run at the moment sorry. | 21:43 |
| Makyo | jujugui https://github.com/juju/juju-gui/pull/369 databinding for unit details + viewing charm details PR for review and QA | 21:47 |
| hatch | Makyo sure I'll hop on that | 22:01 |
| hatch | Makyo heh it's such a good idea that we didn't work on this at the same time - there was so many conflicts haha | 22:02 |
| Makyo | Right? :P | 22:06 |
| hatch | Makyo your branch also fixes the charm details panel fyi | 22:10 |
| Makyo | hatch, yep, that was the goal. | 22:11 |
| Makyo | Just poorly named. | 22:11 |
| hatch | dun and dun | 22:12 |
| Makyo | Cool, replied and prepping for another push. | 22:13 |
| Makyo | Should be landable, though | 22:13 |
| hatch | rick_h_ jcsackett ok I'm not entirely sure where to take the caching branch - do I remove the functionality and just go for a 'dumb' key/value object store or add the generic get('key') like methods and leave the advanced functionality? | 22:15 |
| rick_h_ | hatch: I think it's worth this discussion. I see your idea about the database, but I feel like that's the wrong place (thus the cache) since the db can be modified by env and such | 22:15 |
| rick_h_ | hatch: the results form charmworld are static, unchanging, pure cache | 22:15 |
| hatch | right - but I am trying to figure out where removing the functionality makes it a better tool | 22:16 |
| rick_h_ | not live models for modifying/etc. They get copied on deploy, and I agree we should not re-request them, but we should be copying them from the cache into the db via that code I think | 22:16 |
| rick_h_ | I'm for a lighter cache to get started and adding complexity as required by use cases. I think that helps keeps this from being that big chunk of work as well for now. | 22:17 |
| rick_h_ | but that's how my head works, interative development | 22:17 |
| hatch | I'm not sure I agree with you on that cache to db stuff :) | 22:17 |
| hatch | right, but it's already written | 22:17 |
| rick_h_ | and I'm just not sold on the bigger picture cases so far. | 22:17 |
| hatch | so removing the functionality is actually more work :) | 22:17 |
| rick_h_ | hatch: yea, but it's overhead. long term maint. overhead | 22:17 |
| rick_h_ | every time someone tries to figure out 'how does this work' overhead | 22:17 |
| rick_h_ | it's 10x the 'let's clear it up now' work levels | 22:18 |
| hatch | ok then all of this is simply WAY to good, might as well just create an instance of Y.Attribute and call it a day | 22:18 |
| rick_h_ | lol | 22:18 |
| rick_h_ | well I think we can chat on the db point, that seems to be the heart of this. You've got a use case I'm not following yet | 22:18 |
| hatch | but really, then it has getters and setters, and it's an object store | 22:19 |
| hatch | the app.js can just go this.cache = new Y.Attribute() and it's done | 22:19 |
| hatch | lol | 22:19 |
| rick_h_ | well I don't even know getter/setters are required. What do they get us? We're not waching/eventing on this | 22:19 |
| rick_h_ | hatch: heh, except we want to pass the object instance around down to views/etc. and I think it might belond on state tbh | 22:20 |
| hatch | so then we don't need a new class at all | 22:20 |
| rick_h_ | kind of like that one bit of state that's out of band already, /me tries to recall it | 22:20 |
| hatch | just create an object | 22:20 |
| rick_h_ | hatch: maybe not, the main goal was to get it out of browser.js | 22:20 |
| rick_h_ | so that it's not so smart and center of the world with stuff so it can be shared better | 22:20 |
| rick_h_ | what use case does an object on state fall apart at? | 22:21 |
| * rick_h_ is trying to think this through | 22:21 | |
| hatch | I wouldn't put it in state because I think it's bringing stuff along with it that is unnecessary, I'd definitely keep it separate | 22:21 |
| rick_h_ | ok | 22:21 |
| hatch | so now the question is....why won't a dumb object work | 22:22 |
| hatch | it's not a very 'clean' approach | 22:22 |
| rick_h_ | so for the use case of charm/bundle models it seems sensible. a dumb object of model lists | 22:22 |
| hatch | impossible to test | 22:23 |
| hatch | there isn't anything 'to' test | 22:23 |
| rick_h_ | ok, so a simple get/set api on top of a dumb object makes it a cleaner api? | 22:23 |
| hatch | it does, because then you can see 'ok here we have a cache' | 22:23 |
| rick_h_ | hatch: well, that's kind of the nice thing. You test things that are cache-enabled. And make sure they read from the cache data without making a new request, or that they update the cache data | 22:24 |
| hatch | right but there is no 'cache' it's just an object | 22:24 |
| rick_h_ | ok, so I can +1 a get/set but without the magic method per cache key | 22:24 |
| hatch | there is no implicit.... I am a cache, hear me roar | 22:24 |
| rick_h_ | hatch: right, but that's what makes it easy to test :) | 22:24 |
| hatch | (i'm just talking it out btw) | 22:24 |
| hatch | get and set without any bonus kind of feels like a waste | 22:25 |
| rick_h_ | so maybe calling it a cache is a bad word? Is there a better way of calling it "hey view, here's some existing useful data to help speed things up for you" | 22:25 |
| hatch | (which is a cache) :P | 22:25 |
| rick_h_ | well you're saying an object is no cache, that it's ugly without an api, so I'm trying to figure out how to do it in a light weight way that provides and api and 'feels' cachy (aside from the name of the argument being cache or modelCache) | 22:26 |
| hatch | an object will work just fine as long as nobody touches it | 22:26 |
| jcsackett | i mean, caches frequently are dumb, so a protected storage thingy with get and set and ensurance that we're deep copying doesn't sound like a waste to me. | 22:26 |
| hatch | when you wrap it inside an instance it's much harder to touch | 22:26 |
| hatch | you have to be explicit about accessing it | 22:27 |
| rick_h_ | hatch: ok, so then the thing to figure out is how to update teh cache | 22:27 |
| rick_h_ | in the old system the Views fired a cacheUpdate event with the new data to cache | 22:27 |
| hatch | I think the cache should be passed in | 22:27 |
| hatch | but then everyone can access the object | 22:27 |
| hatch | without going through a setter/getter | 22:27 |
| hatch | they could accidentally empty it too | 22:28 |
| hatch | so that's the issue with a basic object | 22:28 |
| hatch | no protection at all | 22:28 |
| rick_h_ | well, I think we can unblock ourselves with a simple object for now and move forward towards release. And keep in mind the tools available if a more complex use case presents itself. However, we don't currently have those to drive the decisions on what to implemnt | 22:28 |
| rick_h_ | and if it's simpler now, it's less to update/replace down the road when a real use case does jump out and hit us | 22:28 |
| hatch | ok I'll scrap this branch | 22:29 |
| hatch | the cache will live in the browser though | 22:29 |
| hatch | I don't think this cache needs to be passed from the app | 22:29 |
| hatch | at least for now | 22:30 |
| rick_h_ | why in the browser? How does that work with the inspector and other use cases? | 22:30 |
| hatch | like browser.js | 22:30 |
| rick_h_ | that's been a limitation of the last work. If the inspector loads up a charm details it can add it to the cache | 22:30 |
| hatch | it should be adding that to the db | 22:30 |
| hatch | not to the cache | 22:30 |
| hatch | it's a fully populated model then | 22:31 |
| huwshimi | Morning | 22:31 |
| hatch | that's where grabbing keys for the search/interesting makes more sense | 22:31 |
| rick_h_ | ok, but before it's added to the db is can get an initial default values/etc from the cache | 22:31 |
| hatch | morning huwshimi | 22:31 |
| huwshimi | hatch: Hey | 22:31 |
| hatch | lol I really don't agree | 22:32 |
| rick_h_ | but it needs access to that, I guess the inspector is in the browser at this point but it feels like it's not the right place to keep it out | 22:32 |
| hatch | ok I think I got something | 22:32 |
| hatch | put the cache in the db | 22:32 |
| rick_h_ | hatch: call? | 22:32 |
| hatch | everything has access to the db already | 22:32 |
| hatch | sure | 22:32 |
| hatch | I think it's aus call time too | 22:32 |
| rick_h_ | but the browser never ever touches the db, now all that code needs a db instance passed down which allows it to touch a bunch of stuff it never should need to | 22:32 |
| hatch | im in the aus room | 22:33 |
| rick_h_ | huh? the charmresults has db access currently? | 22:33 |
| hatch | no browser.js does | 22:33 |
| hatch | kadams54 did you end up re-proposing huwshimi branch? | 23:03 |
| hatch | huwshimi so kadams54 took over your branch (the one he closed) to apply the changes from my comments. I don't see anything in his fork about that so maybe you want to take those comments and run with them today? | 23:06 |
| hatch | huwshimi this is the PR in question https://github.com/juju/juju-gui/pull/366 | 23:06 |
| huwshimi | hatch: OK, was there a reason he needed to pick it up (was it blocking something)? | 23:06 |
| hatch | huwshimi he was going to take it, fix the comments, then add the functionality to the container as well | 23:07 |
| huwshimi | Ah I see | 23:07 |
| hatch | so yeah...if you're blocked on that not landing then maybe you can continue on your own branch | 23:07 |
| hatch | sucks to be duplicating work but I'm not sure where it's at | 23:07 |
| huwshimi | hatch: Do you know if he started working on the container constraints? | 23:12 |
| hatch | huwshimi no idea, sorry | 23:12 |
| hatch | huwshimi maybe you can ping kadams54 periodically over the next few hours :P | 23:30 |
| huwshimi | :) | 23:30 |
| kadams54 | actually i'm here now | 23:30 |
| hatch | it worked! | 23:31 |
| kadams54 | for about 5 seconds :-) | 23:31 |
| hatch | :P | 23:31 |
| kadams54 | location change | 23:31 |
| hatch | kadams54 where are you with huwshimi's branch? | 23:31 |
| kadams54 | and then we can talk more | 23:31 |
| hatch | oh ok | 23:31 |
| kadams54 | hatch, huwshimi: back. Here's the update: I'm fixing tests that broke in refactoring. My plan was to push once those tests were fixed. | 23:47 |
| kadams54 | Unfortunately I won't be able to resume work on them for another 45 minutes. So hopefully it's not blocking? | 23:48 |
| huwshimi | kadams54: That's fine, not blocking me! | 23:48 |
| kadams54 | huwshimi: great. | 23:49 |
| kadams54 | huwshimi: your branch implemented about half of the card I picked up, which is how I ended up on it in the first place :-) | 23:49 |
| huwshimi | kadams54: Ah yeah, are planning on re-using that view and using it in the containers column? | 23:50 |
| kadams54 | Yes | 23:50 |
| huwshimi | kadams54: Great, I assume you'll do the container type card at the same time? | 23:51 |
| kadams54 | huwshimi: "wire deployed unit token UI for choosing container type" - that card? | 23:52 |
| kadams54 | I was planning on tackling that next :-) | 23:52 |
| huwshimi | kadams54: Yeah | 23:52 |
| huwshimi | kadams54: Well, it's the step before the constraints are show... | 23:53 |
| huwshimi | *shown | 23:53 |
| huwshimi | kadams54: Might make sense to do them at the same time, or do the container type card first (if it can be broken out) | 23:53 |
| kadams54 | I was going to do it after the constraints work because that was already in progress on your branch. | 23:55 |
| kadams54 | So the plan was to wrap up your branch, get it landed, and then start on container types. | 23:55 |
| kadams54 | That said, we'll see how things go once I get the kids settled in bed ;-) | 23:55 |
| huwshimi | kadams54: OK, well, whichever way make sense, I guess either way you need to do a bit of refactoring. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!