[00:07] rick_h_ curious, did you ever create that upstream bug for the kernel? [00:08] hatch: no, honestly it's like 10th on my list of stuff atm [00:08] :-) no problem just didn't see a link so was going to track it if it was [00:08] though did make my appt to get my snow tires off and get some new tires on the summre wheels :) [00:08] ooooo nice :) I gota do the same [00:08] maybe this weekend [00:09] I swap them myself....unfortunately [00:09] hatch: heh, I'm sitting here trying to get a local env to bootstrap to test out working with local charms [00:09] hatch: yea, I don't have storage space and such so I use their valet service [00:09] you've seen the emails from hazmat and I/ [00:09] they store them and just swap them off since their diff wheel sizes [00:09] hatch: yea, I want to verify what you CAN do [00:09] hatch: I want to deploy a local charm, see if we can deploy another instance with a new name via cli [00:09] if we can, the code is there, it's wiring it [00:10] kapil's email seemed to focus on deploying a local charm that's not yet uploaded [00:10] but there's note on the auto incrementing revision [00:10] I couldn't figure out a syntax to deploy a local charm via the CLI but I'm hoping I was wrong [00:10] that's the biggest limitation atm [00:10] hatch: yea, maybe it's not there. [00:10] I'll bug someone on -core maybe [00:11] I learnt something about python today which I felt was a little dumb....you can call functions without () so it looks like a property but it's actually a function [00:11] right [00:12] call help on it that way [00:12] it's a little cool....but not good for discoverability imho [00:12] help(str.something) [00:12] well you'll notice the type [00:12] I mean it's the same in JS [00:12] right but when you're reading the code of some passed in value you just assume it's a property [00:12] functions are objects [00:12] ah, heh that's functional for you :) [00:13] but again, same as JS. pass in a callback/etc [00:13] charm.charm_url <---- this is actually a function....but charm._charm_url is a property [00:13] so unless you're familiar with the code base, you don't know that [00:14] yea, that's a bit of bad form as methods should be named something methody, get_charm_url [00:14] I came across it in a log `log.debug("xxx %s", charm.charm_url) [00:14] and it was throwing an error [00:15] so it caught me off guard that a fn was being called [00:15] heh [00:15] yea [00:16] bah, lxc env is broken again it seems [00:16] but I suppose you're right, callbacks and the like in js are similar [00:16] they just release 17.7 [00:16] yea, but not in trusty atm [00:16] maybe it's fixed in there? [00:16] ohh [00:16] it'll take time, but yea, we'll see. [00:16] my envs are a mess [00:16] haha [00:17] I've had so many broken envs that I think my configs/existing envs are in trouble [00:17] working on my desktop, yay for more than one machine lol [00:17] haha [00:18] well even though my task was not completed/possible I learnt a lot of pythony bits so I'm considering this a success :) [00:18] heh cool [00:23] hatch: so I can do this [00:24] ah bah nvm [00:25] :-) [00:25] yea, make sure to cd before you think it did work lol [00:25] well, add it to the GUI feature work list we want to do [00:26] * rick_h_ grumbled he could have sworn being told it was possible [00:28] it IS possible if the charms are on the users file system [00:28] then the deployer can deploy from the local file system [00:30] ok, good to know. I'll have to work on some wording and emails tomorrow [00:33] yeah - it's unfortunately a ton of work to do what we want to do [00:35] I don't know it's more than stuff like local charm support to begin with :) [00:35] but it's another feature [00:37] yeah - I'm wondering if we 'need' this feature [00:37] it's a pretty rare usecase which will be handled by ___ [00:38] so....maybe the best reply would be how to do it via the CLI [00:38] it's not ideal but 'should' work [00:38] (we should probably test it first) [00:39] hatch: yea, pretty much. [00:40] would you like me to look into that in the AM or are you trying that now? [00:40] the CLI only approach [00:40] no, I think we'll put this away and write up a nice "here's the temp path" email [00:42] ok I'll slide the card into daily [00:50] * hatch flicks the no-more-work-today switch [02:24] evening kadams54 [02:24] evening [02:24] it's EOD, go to bed you guys :P [02:25] rick_h_ lol I've been debuggin a python script! [02:25] https://github.com/SublimeText/Origami/issues/59 [02:25] I want vim style PANE management [02:25] :P [02:30] also did this https://plus.google.com/118445028821328031751/posts/PLZrunniCC4 [02:33] Heh [02:34] rick_h_: your evil plans for state refactoring have run afoul of YUI. We'll have to talk more tomorrow :-) [02:36] lol [02:37] kadams54 are you going to push the state into a state array so that state[state.length-1] is the current state and state[state.lenth-2] was the previous state? [02:37] that's one approach I was thinking of [02:37] kind of a persistent data store style [02:37] Haven't gotten that far yet [02:37] Right now I'm just trying to hide current and previous state objects behind the API [02:38] So that clients of state don't know or care about how they're implemented [02:39] http://pastie.org/private/mbzgddvoyee0svattwa [02:39] Calling set() would set the field in the current state, and setPrevious() would set the field in the previous state. [02:40] But YUI tries to call set('destroyed') as part of destroy() [02:40] I think usually the states are set as complex objects [02:40] ohh yeah you're overloading set [02:40] Yeah [02:40] can't do that [02:40] Not really overloading [02:40] So much as colliding :-) [02:40] Or smashing [02:40] not on a Y.Base derived class (which is, like, all of them :) ) [02:41] So we'll need to figure out new names [02:41] haha yeah [02:41] state.save({...}) [02:42] It's not really a save [02:42] You're updating one field within the state object [02:42] update() already exists [02:42] well... [02:42] State objects are really simple right now - they're basically just (to use the python term) dictionaries… [02:43] save could push the current state into previous, then merge this object over the old one to create the new state [02:43] this._previous = { [02:43] charmID: null, [02:43] querystring: null, [02:43] hash: null, [02:43] search: null, [02:43] viewmode: null [02:43] }; [02:43] So if you want to update 'charmID' in the this._current state object, you'd call state.set('charmID', 'foo') [02:43] so instead of needing to 'set' you would state.save({charmID: 1234}) [02:44] Yeah… [02:44] and it would merge the two, giving you the value you need [02:44] save has conntations for me [02:44] It implies a wholesale change of the object [02:44] save or me means "update and dispatch" [02:44] Thinking about the way the mongo API uses it [02:44] I'd rather do something like "patch" or "update" [02:44] so update would also dispatch? [02:45] and then figure out a better name for the update method [02:45] Not sure what you mean by dispatch [02:45] after updating the state 'something' needs to dispatch the changes to update the DOM [02:45] else you're just changing a object [02:46] Or you're "just" changing a object [02:46] So that it's in the proper state for when a 'navigateView' event fires [02:46] And then it can generate the right URL [02:46] Which results in the proper parts of the DOM being updated [02:46] So nothing is necessarily being dispatched when the various state bits are being updated [02:47] ohh ok I was thinking of ditching the navigate view business and having state fire a 'dispatch' event which could the trigger the changes on all the listeners [02:47] because some changes aren't going to be routable [02:47] like showing the ghost inspector for example [02:48] * kadams54 sticks fingers in ears and says "la la la" [02:48] That's not my concern at the moment :-) [02:49] haha - I have a problem with thinking too far ahead [02:50] anyways in YUI there is a convention for providing a single and multiple setter methods [02:50] I'm pretty sure rick_h_ explained how non-routable changes were handled, but I forget what he told me [02:50] I remember "non-navigable" or something similar being written on the whiteboard [02:50] setStyle('foo', 'bar') vs setStyles({...}) you may want to do something similar [02:51] setState() setStates() [02:51] Yeah [02:51] That would be nice [02:51] Although state.setStates() is a bit awkward [02:52] We really need a better name for the bits that make up a state [02:52] how do you mean? [02:52] if you think of each view as having a 'state' it makes sense [02:52] It reads as redundant to me [02:52] so State is a state manager [02:52] in a sense [02:52] Yeah, it really is [02:52] And was called that at one point [02:53] But browser.state is shorter that browser.stateManager [02:53] meh [02:53] :) [02:53] The python developer in me wanted to make it browser.sm [02:53] you should write go [02:53] then it could be b.am [02:53] lol [02:53] lol [02:54] we're gona be stuck with this api for a while so might as well do it 'right' :) [02:54] There's a convention in SQLAlchemy to have your model's manager object accessible from an m attribute, so Foobar.m.find(...) [02:54] whatever that means in this sense haha [02:54] Yeah [02:54] I think we'll get there… [02:55] rick_h_ and I were talking about how you have to balance small, bite-sized tasks with big picture thinking [02:56] yup [02:56] There needs to be a sense of where things are going (thinking ahead) so that your code is well-ordered [02:56] But at some point you have to zoom in again in order to start getting stuff done [02:56] setState and setStates could fire a 'stateUpdated' method on the stateManager which view/viewManagers could listen for and react to [02:57] that's probably the cleanest approach and provides a ton of flexibility [02:57] I'm not sure how to distinguish between routable and non-routable state changes [02:58] Yeah, there's one "clean up these views" method in browser.js that needs to be called after the update() [02:58] but that's probably for another day ) [02:58] yeah I don't like that [02:58] well....not that I don't like it [02:58] I'd prefer a more detached approach [02:58] Right now we just explicitly call it, e.g: [02:58] this.state.update() [02:58] this._cleanOldViews() [02:58] But we've talked about that needing to switch to an event-based approach on down the road [02:59] yeah it would be nice if the state module was a self contained ball which you pushed things into and it told it's listeners when something interesting happened [02:59] We've also talked about events in the other direction [02:59] That State would subscribe to other events [02:59] And then know when it needs to update or save based on those events [02:59] Then you wouldn't need to call update() or save() explicitly anywhere [03:00] hmm that feels like an inversion of responsibility on the face of it... [03:02] YUI's event system would allow it [03:02] but my head is stuck on a stateManager being a database of sorts [03:03] stateManager.listenFor('inspector:showUnit'); // pseudo code [03:03] nah that's from outside [03:03] it would have to be [03:04] this.listenFor('inspector:showUnit') [03:04] which means the stateManager would have to be updated whenever we added a new interaction to the app..... [03:04] sorry I'm just thinking about this outloud [03:04] :) [03:35] np [03:36] Sometimes you just need a sounding board [03:36] Though I'm heading to bed now :-) [13:14] * frankban lunches [13:53] rick_h_: morning, can we have a call when you have a minute? [13:54] frankban: sure thing [13:55] frankban: https://plus.google.com/hangouts/_/7ecpjl135481h8o5058gu7643s [14:06] rick_h_ when you're done with frankban I need some guidance on the card I should be working on - I think all the Ready To Code's are blocked [14:06] hatch: k, shoot me a url please [14:07] just reuse ^ one [14:07] :) they stay active for a bit...not sure how long without anyone in them [14:10] rick_h_: cards created [14:14] frankban: thank you much [14:16] lol [14:16] * hatch waves [14:16] oops [14:16] sorry about that, on the mac and bad tap on the trackpad [14:16] yeah it happens [14:16] apparently the new air's will not have a clicky trackpad [14:16] anyway, does that help then? [14:16] I think that's a horrible idea [14:16] yup [14:17] thx [14:17] I'll create a card [14:17] lol cool [14:23] Whew, plumber has plans that don't involve digging up the foundation. [14:23] Makyo: always a good thing :) [14:23] yay [14:24] I had an issue like that - the pipe between the floor (our water comes in in the basement floor) and the shut off was leaking but the pipe was so short I thought they may need to smash up the floor [14:40] Yeah. Ours is this polybutylene piping that's not been used in years for good reason. No clue where the fracture is, but at least there's a fix. [14:40] yeah smashing concrete is not cheap - or fun if you're doing it yourself :) [14:42] yea, had to do that when our sump died [14:43] we had some funky non hole in the ground sump setup with a pump/piping through the floor [14:43] uh oh....jumpy d3's [14:43] they had to bang out the floor to put in a more usualy sump [14:44] when I did my basement bathroom I had to smash in a shower drain....and carry out all the broken concrete [14:45] hatch, QA on my branch, or trunk? [14:45] hatch, also, what do you think about my assets vs utils comment [14:45] ? [14:46] I don't feel very strongly about it [14:46] oh, there are the replies, nevermind [14:46] :) [14:47] :-) [14:50] jujugui call in 10 [14:50] jujugui call in 10, kanban please [14:50] curses [14:51] Hah! [15:00] jujugui call now ish [15:10] Makyo: branch? [15:10] frankban, https://github.com/juju/juju-gui/pull/208 [15:45] so that hangout used up 66% of my battery lol [15:46] wow [15:46] hatch: yea, killed me here about 50% [15:46] multi HD video is hard, let's go shopping [15:46] yeah there is a bandwidth scaler but there should really be a quality one too [15:47] unless the CPU load doesn't change much [15:47] video card load [15:49] yeah and I have the discrete card too so that can't be easy on the battery [15:49] this 'moom' looks like it has a nice featureset [15:50] was kind of hoping for keyboard available scaling though [15:50] like window resizing in vim [15:50] pane resizing [16:01] If only Mac had vim [16:01] ;-) [16:04] haha - I was looking for one for Sublime, I found it but there is a pretty big bug in it [16:06] https://github.com/SublimeText/Origami/issues/59 [16:07] Which reminds me… time to give Atom a whirl [16:08] I've seen reviews that it's slower than sublime, it kind of lags, but it is still alpha.....after 6 years [16:08] lol [16:25] rick_h_ posted a good link about vim to G+ which makes an excellent case for 'modes' - too bad vim is so non-user friendly to set up and get started with [16:26] it has the core - someone just needs to write a good UI for it [16:26] yea, learning curve required [16:26] well even after the learning curve it's not very user friendly [16:26] package management, trying to find keybindings, etc etc etc [16:27] I think gvim was maybe trying to do that but didn't go far enough [16:27] part of the learning curve :) [16:27] lol [16:34] and the board fills back up wheee [16:35] here comes round 3! [16:35] any idea how we are doing on estimation vs completion? [16:35] hatch: we're doing really well [16:35] noice [16:36] hatch: so first cycle the math says 2 points per day per dev we did 79/86 points. This time we did 102/100 [16:36] so the team is rocking it [16:36] those both include cards w/o counts too right? [16:37] guihelp PR for State API cleanup has landed: https://github.com/juju/juju-gui/pull/209 [16:37] kadams54 on it [16:37] hatch: no, that's just cards with counts. That includes the unsched tag which I get points to [16:37] hatch: thanks! [16:37] so it's scheduled and unscheduled work, but not counting cards like "do release" [16:37] rick_h_ ahh cool [16:37] awesome [16:37] so first cycle we did 20 points of unsched work, 12 this cycle [16:37] sounds like we are right where we need to be [16:37] but those go into the 79/102 completion numbers [16:38] hatch: yea, definitely all good and great work from the team [16:38] hatch: on vim, use janus: https://github.com/carlhuda/janus [16:38] I'm completely happy to put all this down for mramm [16:38] Janus is the Ubuntu of vim - lets you get up and running with a good set of plugins and config [16:38] except don't, I'll argue with kadams54 about it over lunch now [16:39] speaking of which, afk for lunch biab [16:39] rick_h_is crazy, but I guess we have a lunch conversation topic :-) [16:39] lol! [16:39] kadams54 I'll look at this janus at lunch later thx === hatch__ is now known as hatch [17:12] oo this Amethyst pane manager looks really nice rick_h_ [17:16] hmm saving the db is not going to work [17:16] deltas or commands might be the best way [17:17] well it would work [17:17] but it's a lot of work [17:19] ehhhh maybe [17:29] https://twitter.com/FromAnEgg/status/449598755239497728 anyone? [17:37] hatch: can you not just json.dumps(complex) ? [17:37] hatch: JSON.stringify(window.location) [17:38] then copy/pate? [17:38] paste? [17:38] yeah I was hoping for a plugin or a script or something [17:38] so that we could generate these outputs easily for demo purposes and the like [17:38] stick some dev utils on app? [17:39] app.dev.dumpDB() [17:39] ? [17:39] yeah I just don't want to write it myself [17:39] it feels like something that should exist [17:39] JSON.stringify exists? You just need a few lines in a function to walk the data you want to output [17:40] I feel like I'm missing something that makes this larger/harder than it seems [17:40] I want to pass a complex object the output from a db parse method to a json stringify which will then save that output to a text file on disk [17:41] I'd like it to not have to rely on the user to have to open the console and do manual work [17:42] it's probably easy to do via the File API but I'm asking the hivemind before i put any time on it :)' [17:42] hatch: but this is for 5 devs, and we'll cache the 'suggested base' [17:42] they always ask for more demo materials lol [17:42] but I suppose [17:42] * hatch scales back [17:45] hatch: yea this is a helper for us to get through the next few weeks of dev [17:45] not a published feature for 'users' [17:45] so scale back to 'I can debug easier than now' [17:45] type levels [17:45] please :) [17:45] Oh Kay [17:45] btw you should take a look at Amethyst it looked like it was more along the lines of the requirements [17:46] for the pane manager [17:47] hatch: very cool then will try that one as well [17:47] back on linux now with a proper tiling WM :) [17:49] hah yeah - I think I'll install Amethyst tonight and give it a go - window management has been a big gripe of mine for osx [17:51] interestingly enough there is a max length for a console output heh [17:51] darn [18:21] hmm interesting, apparently we rely on more than just the db [18:21] :) [18:25] ok pushing into the db is not going to work [18:25] going to have to rely on deltas like we do with real envs [18:26] but first....lunch [19:08] jujugui I'm running out a bit early today. Thanks for the great cycle and have a good weekend! It'll be a fun next cycle. [19:08] Cheers, hav ea good weekend [19:12] kadams54 I'm not sure YUIDoc has a crosslink syntax like you had used there [19:13] kinda too bad really [19:13] http://yui.github.io/yuidoc/syntax/index.html [19:13] oh it does [19:13] look at that [19:13] craaaazy [19:13] learn something new every day [19:15] Hah, yeah. Was just going to paste this: http://yui.github.io/yuidoc/syntax/index.html#cross-referencing-modules-and-classes [19:15] But then you spoiled my big "booyah" moment [19:18] lol [19:18] that must be newish [19:18] I haven't seen any of this hbs stuff before [19:24] hatch: FYI, just finished incorporating all of your feedback into PR209 [19:25] cool - I see I was outvoted with the api calls [19:25] current is now getCurrent, parseRequest is loadRequest [19:25] * hatch crys [19:25] :P [19:25] I'll live with getCurrent [19:25] It's a compromise, and you know what that means… [19:25] Nobody is happy :-) [19:26] rofl! [19:32] hatch: wondering if this is the Safari Selenium bug? http://ci.jujugui.org:8080/job/juju-gui/640/console [19:32] F(*@&#_)@)($)(*@$)&%*(#(# [19:32] yes [19:32] Wait… it seems to be in Firefox [19:33] JUJU_GUI_TEST_BROWSER="firefox" make test-browser-mocha [19:33] oh interesting [19:33] hmmmm [19:33] did rick_h_ get you a login for jenkins yet? [19:34] no [19:34] looks like it's running again [19:34] odd... [19:34] guess we'll see [19:34] Yeah, the second build started right up after the first… was also puzzled by that. [19:34] must have been queued up from a change [19:34] Fingers crossed. [19:35] I wonder if we are using an old version of anything [19:35] where an upgrade may fix this [19:36] yeah looks like we are running an older version of selenium [19:36] one version back mind you [19:36] but might be worth an upgrade [19:40] Same error second time around. Grrr… [19:41] hatch: you OK with me doing a :shipit: on the PR? [19:41] yup let'r rip [19:43] kadams54 looks like it's not passing [19:44] in firefox now [19:44] lemme take a look at the failure [19:44] lol [19:45] https://github.com/juju/juju-gui/blob/develop/test/browser.py#L205-L209 [19:45] *sigh* [19:46] It doesn't look like the CI is picking up my :shipit: comment… [19:47]