frankban | hi rogpeppe: when you have time, I need another approval for https://codereview.appspot.com/7947043/ | 11:34 |
---|---|---|
rogpeppe | frankban: looking | 11:35 |
frankban | rogpeppe: thanks | 11:35 |
rogpeppe | frankban: there was one little thought i had last night, and it seems i lost the comment somewhere | 11:37 |
rogpeppe | frankban: in annotator.insertOps, if you reverse the order of the operations, the code could become a little simpler looking | 11:38 |
rogpeppe | frankban: like this: http://paste.ubuntu.com/5649143/ | 11:40 |
frankban | rogpeppe: I see. ok | 11:41 |
frankban | rogpeppe: I'll make this change and then land the branch, sounds good? | 11:48 |
rogpeppe | frankban: i've just made one other final suggestion in the review | 11:48 |
rogpeppe | frankban: LGTM with both those changes made, thanks! | 11:49 |
frankban | rogpeppe: cool, thanks | 11:49 |
gary_poster | frankban, hi. are you available for a quick consultation on some CI/shelltoolbox topics? | 12:15 |
frankban | gary_poster: sure | 12:16 |
gary_poster | thanks frankban. no rush, guichat when you are available | 12:16 |
rogpeppe | gary_poster: hiya | 12:25 |
rogpeppe | gary_poster: do you know if anyone is currently working on adding more fields to the various allwatcher info types? | 12:26 |
gary_poster | rogpeppe, benji if anyone | 12:26 |
gary_poster | he will be the person to do it | 12:26 |
benji | rogpeppe: not at the moment, but soon | 12:27 |
rogpeppe | benji: ah - i've had a request from green for public address and status in unit info. if you're about to do it, i'll leave it to you though. | 12:27 |
benji | rogpeppe: I can do that, if gary_poster doesn't have any immediate plans for other things for me to work on | 12:28 |
gary_poster | benji, I would take advantage of rogpeppe being willing to do some of the work we need :-) | 12:29 |
rogpeppe | lol | 12:29 |
benji | heh | 12:29 |
rogpeppe | benji: i'd be happy to do it. i could do all the other fields at the same time if you like - let me know what you need | 12:30 |
benji | we need what is used in the GUI, let me see if there is an easy to extract list | 12:30 |
gary_poster | benji, my guess was in app/store/env/sandbox.js in _deltaWhitelist | 12:32 |
gary_poster | it is at least a reasonable start | 12:32 |
benji | cool, looking | 12:32 |
benji | rogpeppe: here is a pretty good list of attributes: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/store/env/sandbox.js#L213 | 12:35 |
rogpeppe | benji: thanks. the only immediate issue i see is machine.instance_state and machine.public_address | 12:40 |
rogpeppe | benji: because we don't currently have those available. | 12:41 |
rogpeppe | benji: except by talking directly to the environment | 12:41 |
benji | we'll take what we can get, for the time being :) | 12:41 |
gary_poster | rogpeppe, agreed with benji, but I suspect we need to figure out how to get at least one of those. I'll do a quick search... | 12:42 |
rogpeppe | gary_poster: i have two possible solutions in mind | 12:42 |
gary_poster | we definitely use public_address... | 12:43 |
gary_poster | looknig for other | 12:43 |
gary_poster | yup, we use instance_state too | 12:43 |
rogpeppe | gary_poster: could you use the public address from the units instead? | 12:43 |
gary_poster | rogpeppe, if they are functionally equivalent then absolutely | 12:44 |
rogpeppe | gary_poster: yes, i think the PublicAddress in a unit is just what would be provided by the machine | 12:44 |
gary_poster | rogpeppe that's perfect then | 12:44 |
rogpeppe | gary_poster: the instance state is a little harder, as it's something that needs to be polled from the provider | 12:45 |
gary_poster | benji ^^ PublicAddress on units will require some tweaks. Could you note somewhere, publicly (card) or privately (personal task) | 12:45 |
rogpeppe | gary_poster: one solution involves putting the information in the state, and adding a jujud worker that polls for information from the provider. the other involves adding an API call to retrieve the info explicitly | 12:45 |
benji | gary_poster: dure | 12:45 |
gary_poster | :-) | 12:45 |
benji | or "sure" even | 12:45 |
rogpeppe | gary_poster: i'm inclined towards the latter currently. something like MachineInfo(id string) struct{PublicAddress string; InstanceState string} | 12:46 |
gary_poster | rogpeppe, that sounds workable. We only show that on one very deep detail page | 12:46 |
gary_poster | rogpeppe, what would you expect the usual turn-around time on a response to that query to be? or is that a fair question? | 12:47 |
rogpeppe | gary_poster: that seems good then. and it's something that can be changed deliberately by an admin, so having manual control of refresh might be a good thing | 12:47 |
benji | gary_poster: card added | 12:47 |
gary_poster | thank you benji | 12:48 |
rogpeppe | gary_poster: 680ms | 12:48 |
benji | np | 12:48 |
rogpeppe | gary_poster: more or less :-) | 12:48 |
gary_poster | rogpeppe, lol ok UI'll take it | 12:48 |
hatch | mornin | 13:52 |
teknico | rogpeppe, hi :-) I need some more help with one last reset() function in api_test.go | 14:00 |
rogpeppe | teknico: i've got a call right now. will be with you in a short while. | 14:01 |
teknico | rogpeppe, great, thanks | 14:01 |
=== Makyo|out is now known as Makyo | ||
teknico | I'll start writing as an attempt to optimize the pipeline :-) | 14:01 |
teknico | I rewrote opClientServiceDestroy to attempt destroying a non-existent service, as you mentioned yesterday: http://pastebin.ubuntu.com/5649448/ | 14:02 |
teknico | it works because TestOperationPerm ends up matching the error with "permission denied" (not sure how much the test is meaningful though) | 14:03 |
teknico | however, I still have a problem with opClientDestroyRelation: opClientDestroyRelation | 14:03 |
teknico | ehm, http://pastebin.ubuntu.com/5649442/ | 14:03 |
hatch | benji: doing a review on your branch right now | 14:03 |
benji | cool, thanks hatch | 14:04 |
teknico | as you can see, it has the usual problem of trying to destroy the relation that still exists | 14:04 |
teknico | sorry, it tries to *add the relation that has not been destroyed yet | 14:05 |
teknico | I tried rewriting it in the same guise as opClientServiceDestroy, attempting to destroy a non-existent relation | 14:05 |
teknico | but the result is not as good: it works for some machines but not for others in the loop | 14:05 |
teknico | that's the last reset() function you asked me to add, then I'll be able to propose this branch and go back to what I was working on originally | 14:07 |
hatch | gary_poster: after the morning chat can you bring me up to speed on the CI stuff? | 14:12 |
gary_poster | sure thing hatch | 14:12 |
gary_poster | thanks | 14:12 |
hatch | benji: review done - just trivial stuff but I think you might agree :) | 14:14 |
benji | cool, I'll take a look | 14:14 |
rogpeppe | teknico: out of call | 14:25 |
rogpeppe | teknico: looking at your paste | 14:25 |
rogpeppe | teknico: how about just DestroyRelation("foo", "bar") ? | 14:25 |
teknico | rogpeppe, you asked for it: :-) http://pastebin.ubuntu.com/5649498/ | 14:26 |
rogpeppe | lol | 14:26 |
benji | hatch: thanks for the review, I've responded, most interestingly to the asynchonicity issue | 14:26 |
rogpeppe | teknico: interrrresting... | 14:27 |
hatch | benji: so wrt the done() - I meant to put the done() in the event callback | 14:28 |
gary_poster | jujugui call in 2 | 14:28 |
rogpeppe | teknico: that doesn't look like it's related to the DestroyRelation. it may be a genuine, honest to goodness bug. :-) | 14:29 |
hatch | right now "potentially" the conn.msg() call could fire, and before the callback is run it could run the assert | 14:29 |
teknico | rogpeppe, nice | 14:29 |
rogpeppe | teknico: could you paste me a branch url please? | 14:29 |
hatch | this is a huge MAYBE - but one that would be damn near impossible to track down :) | 14:29 |
teknico | rogpeppe, https://code.launchpad.net/~teknico/juju-core/fix-cleanup-in-api-tests | 14:29 |
teknico | rogpeppe, and now it's my turn to have a call | 14:29 |
benji | I'm torn between putting in a done() to be pragmatic and resisting voodoo. | 14:30 |
rogpeppe | teknico: ok, that'll keep me busy for a bit... | 14:30 |
teknico | rogpeppe, what if I just leave that last one out for now? | 14:30 |
rogpeppe | teknico: let me try to get to the bottom of the issue first | 14:31 |
teknico | rogpeppe, ok | 14:31 |
rogpeppe | teknico: it *should* work, i think | 14:31 |
hatch | benji: yeah - I can see it never being an issue but I would like to err on the side of caution :) | 14:42 |
hatch | rick_h_ possible to get that review? | 14:45 |
teknico | rogpeppe, out of call, shoot when ready | 14:45 |
Makyo | Some morning humor: https://github.com/joho/7XX-rfc | 14:45 |
rick_h_ | hatch: ah, yea. link me again please? It doesn't show in my codereview since i didn't participate yet | 14:46 |
hatch | https://codereview.appspot.com/7815047/ | 14:46 |
teknico | Makyo, ha! that's nicely comprehensive, except for one glaring omission: no mention of mysql | 14:47 |
Makyo | teknico, Hah! | 14:47 |
rogpeppe | teknico: try this: lp:~rogpeppe/juju-core/tekniko-fix-cleanup-in-api-tests | 14:47 |
teknico | Makyo, otoh, it having to be on *github* is slightly unnerving, do they plan that many revisions? | 14:48 |
Makyo | RFPR - Request For Pull Requests? | 14:48 |
teknico | rogpepbe, I will, I mean rogpeppe ;-) | 14:49 |
teknico | rogpeppe, while tests run, did that last failure actually expose a bug or not? | 14:54 |
rogpeppe | teknico: no, it didn't | 14:54 |
rogpeppe | teknico: i'd missed the assertion failure higher up the log | 14:54 |
rogpeppe | teknico: i *think* that branch should give you most of what you need | 14:54 |
teknico | rogpeppe, good | 14:54 |
rogpeppe | teknico: you can look at the diffs to see what i did to solve the problem | 14:55 |
teknico | rogpeppe, I did, and I may even have understood the approach :-) | 14:56 |
rogpeppe | teknico: :-) | 14:56 |
teknico | rogpeppe, the TestOperationPerm tests pass, great job, thanks! | 14:57 |
teknico | rogpeppe, now running all apiserver tests, and then the whole thing | 14:57 |
rogpeppe | teknico: cool | 14:57 |
bac | hi bcsaller, free to chat? | 15:00 |
bcsaller | bac: winding down call, maybe 5 minutes | 15:00 |
bac | bcsaller: great | 15:00 |
rick_h_ | hatch: heads up, I got a conflict merging your branch into a fresh trunk copy in app/views/topology/service.js so an quick pull from trunk should make landing easier | 15:15 |
bcsaller | bac: still on call, I'll ping you soon | 15:19 |
bac | ok | 15:19 |
rick_h_ | hatch: ping | 15:21 |
hatch | hey sorry in call | 15:21 |
rick_h_ | hatch: ah, np. got ? for you when you get off in QA here | 15:21 |
hatch | sure | 15:21 |
hatch | rick_h_ guichat? | 15:30 |
rick_h_ | hatch: sure can, sec | 15:30 |
bcsaller | bac: ok, off call | 15:30 |
bac | bcsaller: ok. so you want to hangout now or in a few minutes? | 15:31 |
frankban | benji: LGTM with a few questions | 15:31 |
benji | cool, thanks | 15:31 |
benji | I'll be done with your review in a minute. | 15:31 |
bcsaller | bac: we can do it now but I think normal chat room is taken | 15:31 |
bac | bcsaller: i'll make one | 15:32 |
teknico | uhm, I wonder why compiz is a bit crashy lately | 15:35 |
Makyo | teknico, has been for me, too. | 15:37 |
Makyo | Dash, too. | 15:37 |
Makyo | Blacklisting my work directory helped, so that it wouldn't search through branches. | 15:37 |
teknico | Makyo, oh, nice, if it speeds it up it's definitely worth it, how do I do that? | 15:38 |
Makyo | teknico, System Settings - Privacy - Files - Don't record activity in the following folders. | 15:39 |
Makyo | Makes a big difference, even with "Record activity" set to off. | 15:39 |
teknico | Makyo, why do I have no Privacy icon in system settings? | 15:40 |
Makyo | teknico, 12.10? | 15:41 |
teknico | Makyo, yep, are you on raring? | 15:41 |
Makyo | teknico, Not yet. | 15:41 |
teknico | uhm | 15:41 |
Makyo | Another that helped, if you have ccsm, is to go to the Unity Plugin, Experimental tab, and set Dash Blur to No Blur. | 15:42 |
teknico | Makyo, found that one, thanks, but now the dash is a bit too transparent | 15:44 |
teknico | Static Blur seems a nice compromise, whatever that means :-) | 15:44 |
hatch | oh man my internet is so slow right now | 15:48 |
teknico | rogpeppe, it's finally there: https://codereview.appspot.com/7873046 | 16:03 |
rogpeppe | teknico: thanks! looking... | 16:03 |
hatch | rick_h_ FYI I have been using tmux for my ubuntu ssh and it's workign really well although it triggers a lot of 'changed' events causing my terminal tab to flash when nothing has changed | 16:06 |
hatch | I don't know if you have run into the same thing before? | 16:06 |
rick_h_droid | hatch cool. yea any activity in the Window will activate things. | 16:06 |
hatch | but there is no activity - does it maybe poll which triggers activity? | 16:07 |
rick_h_droid | hmm I use it for irc and it has a clock that updates and join/part messages | 16:08 |
rick_h_droid | so it's always updating | 16:08 |
hatch | ahh ok no problem I was just curious really | 16:08 |
hatch | rick_h_droid I pushed the new merge - it all worked properly here | 16:11 |
hatch | try a fresh checkout | 16:11 |
hatch | I'm just about to run the tests in IE | 16:12 |
rick_h_droid | ok will do | 16:13 |
hatch | but first I better let these updates finish - updating a vm and tryign to use it at the same time is....well damn near impossible lol | 16:13 |
hatch | gary_poster: it's looking like travis can do bzr | 16:20 |
gary_poster | hatch, really! interesting | 16:20 |
gary_poster | I thought it was github specific | 16:20 |
hatch | yeah - i'm trying to load more details but my internet is VERY slow | 16:20 |
hatch | will link in a sec | 16:20 |
hatch | :) | 16:20 |
gary_poster | hatch, I looked before and stopped reading after this sentence, actually: "As a free community service, Travis CI limits build duration to about 20 minutes" | 16:22 |
gary_poster | unfortunately | 16:22 |
gary_poster | that's not us | 16:22 |
rogpeppe | teknico: reviewed | 16:22 |
hatch | gary_poster: they have a 'pro' version in beta and it's also OSS so we could run it ourselves (if we wanted) | 16:23 |
gary_poster | no reason to run YA CI system AFAIK. :-/ | 16:24 |
gary_poster | the hosting part is the good part | 16:24 |
gary_poster | hatch, going to go get some lunch. biab | 16:24 |
teknico | rogpeppe, thanks but... oh no! latestUnit! I don't want to lose it! | 16:24 |
hatch | sure - I agree | 16:24 |
hatch | just letting you know :) | 16:24 |
gary_poster | cool :-) | 16:25 |
teknico | rogpeppe, :-) can it be useful somewhere else? | 16:25 |
rogpeppe | teknico: you'll just have to treasure it in your memory (and bzr history) :-) | 16:25 |
hatch | rick_h_droid the lock-zoom branch passes the tests in IE as well so as long as you can confirm you don't get those errors with this merge then I'll submit | 16:25 |
rogpeppe | teknico: nothing is lost :-) | 16:25 |
rick_h_ | hatch: so I'm still seeing the error/issue when I go to all notifications, then click 'view details' on the first one | 16:25 |
rick_h_ | hatch: and the same issue on the N10 with the view details, but working on the N7 | 16:26 |
hatch | well what the... | 16:26 |
hatch | I can't even reproduce in IE | 16:26 |
hatch | haha | 16:26 |
hatch | this is on a fresh checkout? | 16:27 |
rick_h_ | I get it in both stable chrome and the beta chrome on the N10 | 16:27 |
rick_h_ | hatch: yes, all merged with trunk, pulled your latest updates, make clean-all, make, make devel | 16:27 |
hatch | ahah! | 16:27 |
rick_h_ | hmm, /me goes to try the test-server on the machine | 16:27 |
hatch | I was able to reproduce it | 16:27 |
hatch | :D | 16:28 |
rick_h_ | which one? | 16:28 |
hatch | Uncaught TypeError: Cannot read property 'parentNode' of null | 16:28 |
rick_h_ | ah cool | 16:28 |
hatch | damn I'll have to write a test for this now | 16:28 |
hatch | lol | 16:28 |
rick_h_ | wow, crazy to see how tests run in 17.8s on desktop chrome, passing 50s on the N10 | 16:30 |
hatch | rick_h_ that error is on trunk | 16:31 |
hatch | so I'm going to merge this then create a ticket for it | 16:31 |
hatch | are you ok with that? | 16:31 |
hatch | that's why I couldn't reproduce it :D | 16:31 |
rick_h_ | hatch: sure thing. So my QA is that N7 looks ok, N10 has issues we don't know about yet | 16:31 |
hatch | ok, although not ideal, I don't have a N10 to test with | 16:32 |
rick_h_ | though after 159s :( all tests do pass on the N10 | 16:32 |
rick_h_ | hatch: yea, I can try to help at some point but really under the gun. | 16:32 |
hatch | yeah - when I was starting with the N7 - I could simulate the needed events but manually they woudln't work | 16:32 |
hatch | so the tests would pass but it woudln't work hah | 16:32 |
hatch | anyone know what ports I need for juju communication? | 16:59 |
hatch | just 22? | 16:59 |
hatch | so far I have 22, 80, 443 | 17:01 |
gary_poster | hatch juju communication from the GUI? to what? | 17:05 |
hatch | I was just thinking what ports things like 'juju bootstrap' communicates through | 17:05 |
gary_poster | hatch, ah. not sure. would have guessed 22. bcsaller, you happen to know? | 17:07 |
hatch | that's entirely possible - I'm just spinning up the instance now | 17:07 |
hatch | so I haven't gotten that far | 17:07 |
gary_poster | oh ok | 17:07 |
hatch | sorry I googled tarmac and realized I had no idea what was going on so took the EC2 setup side | 17:08 |
hatch | s/going/doing | 17:08 |
hatch | :) | 17:08 |
gary_poster | hatch, cool. I may need to do ec2 also. was about to in fact | 17:08 |
gary_poster | jenkins has been waiting for an m1.small for almost an hour now | 17:09 |
gary_poster | on canonistack | 17:09 |
hatch | oh that's what it was doing | 17:09 |
hatch | I was wondering | 17:09 |
gary_poster | yup | 17:09 |
gary_poster | for the bootstrap node | 17:09 |
gary_poster | fun | 17:09 |
hatch | oh geeze - then it will definitely fail because it won't be able to provision any more :) | 17:10 |
gary_poster | unless it waits forever for that. | 17:10 |
hatch | guichat to run over what I am to do with this micro instance? | 17:11 |
gary_poster | y | 17:11 |
teknico | rogpeppe, all tests pass, landed, fingers crossed :-) | 17:29 |
rogpeppe | teknico: cool, thanks! | 17:30 |
hatch | doing this CI I wish we were in an office so I could do this http://imgs.xkcd.com/comics/compiling.png | 17:32 |
hatch | :D | 17:32 |
hatch | gary_poster: Unexpected initial authentication state: [True, None] | 17:46 |
hatch | have you seen that one? IE test_staging_services error | 17:46 |
gary_poster | hatch that's a diagnostic I added for that test. The good news is that I never actually got the diagnostic before because of a problem I apparently fixed in the previous revision :-) | 17:47 |
gary_poster | lemme remind myself... | 17:47 |
gary_poster | hatch, that should just be info--how did the test itself fail? | 17:48 |
hatch | I'm not sure I'll have to review the video | 17:48 |
hatch | oh wait | 17:48 |
hatch | it didn't fail | 17:48 |
gary_poster | hatch pastebin the output for me pls? | 17:48 |
gary_poster | yay! | 17:48 |
gary_poster | good that makes sense | 17:48 |
hatch | man do these tests fly now :) | 17:49 |
gary_poster | heh, good | 17:49 |
hatch | chrome and firefox both say " unable to complete test run." ERROR | 17:50 |
hatch | they are alsmost all done then I"ll link you the output | 17:50 |
gary_poster | hatch so let's go to guichat | 17:55 |
=== hatch_ is now known as hatch | ||
hatch | 3x-5x speed increase for Y.Base coming in the next YUI | 18:09 |
hatch | OOoOOOooooo | 18:09 |
rick_h_ | yay | 18:11 |
hatch | that's HUGE considering that base is in everything | 18:12 |
hatch | haha | 18:12 |
benji | gary_poster: my telepathy tells me that now is a good time for you to talk about my next task | 18:12 |
gary_poster | benji :-) ok to the guichat | 18:13 |
hatch | ok it takes ~16:30 to start the tests | 18:24 |
hatch | gary_poster: firefox exhibits the same 'caching issue' that IE does | 18:37 |
hatch | that's why the GUI tests are failing | 18:38 |
gary_poster | hatch, ugh | 18:39 |
gary_poster | hatch, btw on IE I have a new opinion about the Javascript Error thing and whether we should retry. It's not cut and dry IMO. We can have that conversation later | 18:40 |
hatch | chrome finishes the unit tests then hangs | 18:40 |
gary_poster | hatch, should timeout eventually | 18:40 |
gary_poster | then we can see why the numbers are wrong | 18:41 |
rick_h_ | hatch: got a sec to sanity check this build issue? http://paste.mitechie.com/show/914/ | 19:09 |
rick_h_ | jcsackett: maybe you know, did you deal with something like this ^^ | 19:10 |
rick_h_ | it looks like it's trying to load the module from YUI vs the gui src | 19:10 |
jcsackett | rick_h_: no, never saw that. has tabview been modified since i checked it in? | 19:14 |
rick_h_ | jcsackett: no, I did move it because I wondered if it was a path issue. It was originally just widgets/tabview | 19:15 |
jcsackett | rick_h_: but you got this error with it as widgets/tabview too? | 19:15 |
rick_h_ | jcsackett: yea, hmmm, you konw it was working. I have a running make devel that was working ok. I wonder if something went batty. make clean_all time | 19:16 |
rick_h_ | I end up with a app.js.map laying around. /me goes through bin/merge-files | 19:17 |
rick_h_ | if I don't require the tabview in my view code it works | 19:18 |
rick_h_ | so I had a working setup, added the tabview, but didn't restart the make devel and it kept working. Once I stopped to lint/push it blows up | 19:19 |
jcsackett | bizarre. | 19:22 |
rick_h_ | yea, grrr at this build stuff sometimes | 19:22 |
* jcsackett nods | 19:22 | |
hatch | ok back | 19:41 |
hatch | rick_h_ hae you solved the issue? | 19:42 |
rick_h_ | hatch: no, I'm tracing through how this merge-files gets it's list of files to merge/build but it's tedious | 19:43 |
rick_h_ | hatch: some how the script thinks yui should have a node_modules/yui/browser-tabview/browser-tabview module | 19:43 |
rick_h_ | hatch: but we've got browser-tabview listed in our modules-debug and it's in the list and picked up as far as I can tell so far | 19:44 |
hatch | that will happen if the module name is not specified | 19:45 |
rick_h_ | 'module name is not specified' where? | 19:45 |
hatch | well if the module name isn't registered it'll try to load it from where yui.js was loaded | 19:46 |
rick_h_ | hatch: ok, getting closer. The if (details && details.requires) { | 19:47 |
rick_h_ | check is failing for the tabview module | 19:47 |
rick_h_ | looking into wtf dteails/details.requires is | 19:47 |
rick_h_ | oh hell...tabview module was a YUI().add instead of YUI.add | 19:50 |
rick_h_ | so it broke out of all the hacks in the build system to replace YUI.add and such I guess | 19:50 |
rick_h_ | thanks hatch jcsackett, all good now | 19:51 |
jcsackett | rick_h_: well damn, sorry for that crap. | 19:51 |
rick_h_ | jcsackett: heh, all good. Simple error. Just hard to debug. Looking at the end of the files in the requires part vs the top of the file. | 19:52 |
hatch | rick_h_: haha oh I hate that - I've done that so many times | 19:52 |
rick_h_ | jcsackett: helped me also realize that the namespaces on the browser-tabview were reversed juju.browser.widgets vs juju.widgets.browser like elsewhere | 19:52 |
rick_h_ | hatch: hah! well lesson learned. Next time I see it it'll jump out at me more | 19:52 |
rick_h_ | and I figured out how to pdb up a node script as well | 19:53 |
hatch | pdb? | 19:57 |
hatch | oooo that namespace thing should probably be fixed....no? | 19:57 |
jcsackett | hatch: pdb is the python debugger; i'm guessing rick_h_ means he has figured out use of the node equivalent? | 19:58 |
rick_h_ | hatch: yea, I've got it correcting here | 19:58 |
rick_h_ | jcsackett: right, basically node debug xxxx allows you to do debugger; in a script | 19:58 |
rick_h_ | but it's fugly ... /me misses pdb | 19:58 |
jcsackett | rick_h_: our tests are run via node when run in the command line, right? so we could potentially command line debug failures? | 19:59 |
hatch | ohh ok :) I was like "pdb? new node debugger??" h | 19:59 |
hatch | aha | 19:59 |
rick_h_ | curses!!!!! now extend failed, verify dependencies in tests. /me pulls plug | 20:01 |
jcsackett | rick_h_: did you add any extends? | 20:05 |
rick_h_ | jcsackett: no, didn't think so. looking over diff | 20:07 |
rick_h_ | hmm, Y.TabView is undefined | 20:12 |
rick_h_ | but it's manually defined in merge-files | 20:13 |
jcsackett | that's...bizarre. | 20:14 |
jcsackett | rick_h_: you're hitting all the fun issues with this one, aren't you? | 20:14 |
rick_h_ | jcsackett: heh, well the dippy things works from the app. It's just getting build/test happy so I can submit some work | 20:15 |
* jcsackett nods. | 20:17 | |
jcsackett | that *is* where the fun goes. | 20:17 |
benji | hmm, that's odd: the units in an error state are grey (like running instances); I would have expected them to be red | 20:18 |
jcsackett | rick_h_: do we think the charm-small widget will change size depending on where its used, or can we assume constant width? i'm thinking it should have a "width" attribute for purposes of placement in the category container. (and the slider, probs). | 20:19 |
rick_h_ | jcsackett: so for now I'm thinking it'll be constant and determined via css. Why a ATTR? | 20:20 |
jcsackett | rick_h_: the charm container wants to be some multiple of the charm small width. and that will vary based on the "max" it shows before being expanded. | 20:21 |
jcsackett | so it would be good if it could get the width from small and set its own width correspondingly, right? | 20:21 |
rick_h_ | jcsackett: so I'm thinking that what we'll do is to have the number to show be an ATTR on the container and let the charm-smalls just be block levels and will float/resize dynamically based on space via css | 20:22 |
rick_h_ | jcsackett: might attach it with the grids framework later on | 20:22 |
jcsackett | rick_h_: ah, yeah, that works. | 20:23 |
jcsackett | and means less work for me, so i'm down with that. | 20:23 |
rick_h_ | so I'd just default to say '5' in the container and we'll work the rest out from that | 20:23 |
rick_h_ | oh man this fixes it but damn is it evil | 20:23 |
jcsackett | ? | 20:25 |
rick_h_ | https://code.launchpad.net/~rharding/juju-gui/fullscreen_charmview/+merge/155595 L466 | 20:28 |
rick_h_ | jcsackett: ^ | 20:28 |
jcsackett | rick_h_: that's bizarre. | 20:29 |
jcsackett | but if it works, it works. | 20:29 |
jcsackett | (apparently bizarre is my new favorite word today) | 20:29 |
rick_h_ | hatch: I'm going to try to get this ready for review here in a sec. It's not complete. I'm coming up on a big diff at this point and will spend tomorrow refactoring, but it 'works' so want to close up a loop. | 20:39 |
hatch | sure | 20:40 |
hatch | fyi - did you look into node-inspector? | 20:40 |
rick_h_ | hatch: no, didn't look at node-inspector | 20:40 |
hatch | ok it's just another option for debugging node | 20:40 |
rick_h_ | ah bah...needed a -edit on there. One more ride... | 20:40 |
rick_h_ | cool, will keep that in mind | 20:40 |
jcsackett | rick_h_: isn't this way late a day for you? | 20:50 |
rick_h_ | jcsackett: yea, well gotta get stuff done. Trying to go late from now until launch. Have a call in an hour anyway so meh | 20:51 |
rick_h_ | go lbox go... | 20:51 |
hatch | rick_h_ ok I'm ready | 20:55 |
hatch | just needed to fire off a potential working CI | 20:55 |
hatch | very potential | 20:55 |
hatch | lol | 20:55 |
gary_poster | hatch, another crazy idea: see what versions of chrome saucelabs offers on different platforms and try switching our chrome to other platforms/versions to see what happens | 20:56 |
hatch | sure thing | 20:56 |
hatch | I'm hoping it's a bug in the after | 20:56 |
hatch | I had to push to my own branch - it woudln't let me push to yours | 20:56 |
gary_poster | hatch, yeah, makes sense | 20:57 |
gary_poster | we can only share in ~juju-gui branches | 20:57 |
gary_poster | (or other teams we both are members of) | 20:57 |
hatch | ohh ok | 20:57 |
hatch | gary_poster: very simple change this time http://bazaar.launchpad.net/~hatch/juju-gui/ci/revision/467 | 20:58 |
hatch | and it still works locally | 20:58 |
gary_poster | cool hatch | 20:58 |
hatch | so as long as that wait_for_script() works as advertised it should work | 20:58 |
gary_poster | :-) | 20:58 |
hatch | hah | 20:59 |
hatch | famous last words - I might as well quit now | 20:59 |
hatch | lol | 20:59 |
hatch | rick_h_ are we going to get a codereview url? | 21:01 |
hatch | or is it just hung up in internet land | 21:01 |
rick_h_ | hatch: sorry, battery died at the coffee shop...lbox take 3 | 21:11 |
hatch | lol | 21:11 |
rick_h_ | yea, fail submit for this one...fighting me every step of the way | 21:12 |
hatch | for some reason I am getting a ton of visits to my blog to invalid php urls | 21:13 |
rick_h_ | hatch: jcsackett https://codereview.appspot.com/7581045 there we go | 21:15 |
hatch | awesome | 21:15 |
rick_h_ | so it's incomplete but it 'works' so I'd like to get it in and on staging for UX to play with while I spend tomorrow refacoring/solid'ing it up | 21:16 |
hatch | review done | 21:33 |
hatch | benji: your propose won't let me actually view any diffs | 21:34 |
hatch | could you try proposing again? | 21:34 |
hatch | everything looks ok as far as the merge goes | 21:36 |
hatch | gary_poster: are you still around? | 21:45 |
=== OutOfControl is now known as benonsoftware | ||
gary_poster | hatch, no :-) | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!