[00:49] Rebase hates me. Anyway. jujugui lf review/qa (sandbox, 2000 units, watch the inspector for delays) https://github.com/juju/juju-gui/pull/14 [00:50] i'll take it [00:50] thank you. also looking at it but won't have time for review [00:51] heh this diff is very confusing [00:52] hmm Makyo very intersting [01:05] Makyo, hatch, I'm seeing maybe a half second shaved off of the pauses as I scroll with 2000 units if I compare local repo with comingsoon. Is that what I should expect to see, or do you expect the change to be more dramatic? Maybe I did something wrong [01:07] gary_poster, not seeing any pauses, here.. [01:08] Makyo, ack. :-/ I looked at app/views/viewlets/service-overview.js and saw changes you have in the diff [01:08] so I do have your changes [01:08] I can try make clean [01:10] nope, no change [01:11] Takes 10s for 2000 units to render on comingsoon for me, 1.5s locally. No delays scrolling in either, though. [01:12] ah, weirdness: filesystem says one code, but browser says another [01:12] trying something [01:13] no [01:14] weird! Makyo good news is that it's something on my system :-/ [01:17] Makyo, awesome! weird cache issue on my side; has not happened in a long while. had to clear cache. Sorry for false alarm. Looks great! [01:18] I need to grok the branch tomorrow so I can see what you mean by your comments [01:19] Oh! Cool :) [01:19] Yeah, np [01:31] Makyo would you mind explaining what you did to the team on the Friday call, as a way of giving us all d3 insight? [01:32] Definitely. Will make a card with notes for myself. [01:32] thank you [01:33] made card. please feel free to take over :-) [01:33] running away. have a good night! === gary_poster is now known as gary_poster|away [12:31] hi frankban [12:31] morning bac [12:32] frankban: since you are the world's expert on using Mock and MagicMock could you give me a hand with mocking 'open'? [12:33] :-) [12:33] frankban: i've got this test: http://paste.ubuntu.com/6555806/ -- the MagicMock that is returned by the mocked open is not being called. [12:34] if i step into the function, the fd returned from the mocked open is a MagicMock and it is being called, but the object accessible in the calling context is not. [12:34] bac: does it work using '__builtin__.open'? [12:34] i've tried using michael's instructions here: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_10_02.shtml#e1188 [12:34] i've not tried builtin. good idea === gary_poster|away is now known as gary_poster [13:04] frankban, fwiw I am reviewing your branch [13:05] gary_poster: thank you!, Brad will start the second review in minutes [13:05] * frankban lunches [13:45] gary_poster, hatch, hey guys [13:45] hey dimitern . thanks for work on charm upload: looking cool [13:46] gary_poster, hatch, we had a bit of discussion about the charm upload implementation [13:46] * gary_poster listens [13:46] hatch is probably still sleeping in his timezone [13:46] or at least not started yet [13:46] gary_poster, hatch, and some concerns were raised that using multipart/form-data, while being more standard-based is less efficient for bandwidth due to the encoding required [13:47] so this POST vs PUT? [13:47] no matter, at leas he'll be pinged and see the conversation later if i include him :) [13:47] :-) cool [13:48] so, encoding a sub-10MB charm inside a multipart form is not a big deal (some 25% increase in size) [13:48] gary_poster: the question is: is it hard for you to generate a POST with an application/octet-stream body containing the zip file? [13:48] but I'm told we expect much bigger charms [13:48] i.e. a binary, non-encoded body [13:48] ^ re rogpeppe's question [13:50] gary_poster, the content-type is not a big deal, but 'd prefer it to be application/zip, so we can bail out earlier with a nicer message [13:50] dimitern, rogpeppe needs research. trying to do it quickly. [13:51] gary_poster, otherwise we're still extracting the archive and reporting any errors, but in a more generic fashion (i.e. "invalid charm format: zip: no header found" or something like it) [13:51] compressing client side will be tough [13:51] rick_h__, I thought we already have the zip packaged before the upload? [13:52] rick_h__, this is about octet [13:52] gary_poster: oh, ok nvm. [13:52] rick_h__, we will be provided zip *and* there appears to be nice JS zip lib for converting floders to zips [13:52] rick_h__, http://stuk.github.io/jszip/ [13:53] also one thing to keep in mind is that we'll be respecting the revision specified in the charm, if possible - i.e. non-conflicting with another charm in state [13:54] otherwise we'll bump it to the highest in state +1 [13:54] the bumping also occurs if the revision in the charm is lower than the highest in state for the same charm [13:55] I like that bit dimitern; I assume the API will give us feedback as to what revision was actually used, so we can report back [13:55] gary_poster, yes, if you look at the specs https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit#heading=h.t7svtxl846ha [13:55] brb doorbell [13:56] gary_poster: yes, the return from the POST is the charm url which includes the new revision number [13:56] great [13:56] yes [14:00] dimitern, rogpeppe I *think* we can do application/zip and application/octet-stream. We will need to test it on supported browsers, I think, because I don't find a clear cut answer in my searches. Worst case, though, would be that you have two or three mini-paths, one for zip, one for form-data, and maybe one for octet-stream. That doesn't sound too bad? We can give you concrete answer be EoD today as to the res [14:00] t? [14:01] gary_poster: it would be nicer if we could avoid the multipart stuff entirely [14:01] rogpeppe, of course [14:02] rogpeppe, dimitern, so, we will research and give you concrete answers first investigating application/zip (your pref); and then application/octet-stream if we run into trouble with the first. We will report back today. Sound good? [14:03] gary_poster: sounds good to me. personally, i'd be more than happy with just application/octet-stream - i can't really see much added benefit from checking the content type, as filesystems don't usually store that. [14:04] ack [14:05] gary_poster, great [14:05] cool thanks for update dimitern and rogpeppe. talk to you soon [14:05] gary_poster, so, just that you know - I changed the specs to reflect the final version which will be implemented [14:05] dimitern, I saw, and also shared it with rest of gui team [14:06] gary_poster, the most important change is that the body needs to be binary, the Content-Type is not crucial, pending your verification [14:06] ack [14:06] gary_poster, cheers [14:06] :-) [14:07] morning [14:12] hey hatch. read backlog for me and I bet you can figure out what I'd like you to answer/research ;-) [14:15] on it! [14:17] thanks hatch [14:19] gary_poster so the question is, can we upload uses an octect-stream? [14:19] answer is yes [14:19] hatch, on POST as well? [14:20] yep [14:21] hatch, great. includes Safari? [14:21] just confirming safari [14:21] cool [14:22] hatch also do you want a review of the sticky headers thing? looks like huwshimi gave you an unofficial +1 [14:22] sure, somehow I ended up with over 100 emails lastnight, still going through them [14:22] :-) k. and are you in the middle of a review of Matt's performance branch, or should I take that too? [14:23] going through it [14:24] another bug with someone using the autocomplete as search results [14:24] heh [14:26] man there is like 0 documentation on safari [14:26] gary_poster, frankban: sorry for the vague zope reference, i was thinking instead of the auto-ui generation aspect. that said, my lack of understanding of the roadmap shouldn't reflect negatively on the work. [14:27] hatch: yea, at least we've got a plan on that one, just not done it yet [14:27] bac, cool [14:27] gary_poster: and i did use a smiley, which covers many sins. [14:27] bac :-) <- sins covered [14:28] bac, gary_poster: the reports of me rewriting zope have been greatly exaggerated [14:28] lol [14:28] :) [14:28] frankban: it did seem to come from an unlikely corner [14:32] gary_poster so I can't find anything to confirm/deny the support for octect-stream in safari post - I can hack together a quick node script to test today if you would like [14:32] hatch +1 please thank you [14:33] hatch, for my own knowledge, where did you confirm octet-stream for chrome et al? [14:33] I just read a few stackoverflow posts where people were having issues with it [14:35] heh ok [14:35] my google fu was merely insufficient :-) [14:35] it's ok, it happens :D [14:37] hatch qa of sticky headers is good. one idea: the only mildly annoying flickers I see on Ubuntu are chrome, for the top header. Can we apply the sticky CSS to the top header as soon as the box is drawn? [14:38] bac: yeah, no. the goal is to have a something to describe fields: gary_poster is right we could do that without classes (a namedtuple seems a good candidate). in this case classes seemed to me more natural: they provide a namespace and a factory (__init__). re auto-ui generation: yes those fields will be eventually used to render/validate the urwid env edit form. AFAIK this can be considered similar to zope schem [14:38] as, and to a variety of other python libraries (django.form, wtform etc.) [14:38] I think that should work [14:38] there is also a very odd bug that huw found [14:38] I'll work on those, did you want to take Makyo 's branch? :) [14:38] hatch, sure :-) [14:39] frankban: sure, thanks for the explanation [15:07] hatch lots of comments and suggestions, but +1. happy to re-review if desired, [15:07] but not necessary. [15:09] thanks [15:09] I fixed the flash in chrome [15:12] awesome [15:12] I think that this sticky header code nowhas more lines of comments than code [15:12] hah [15:13] +1 :-) [15:13] so much for self documenting code lol [15:13] maybe my scrollOffset comment was too much. [15:16] thats only 1 line [15:16] haha [15:17] the comment that broke the developers back? [15:17] :-P [15:23] gary_poster: what do you think about required=False, readonly=False, and then required must be explicitly passed when creating fields? [15:23] frankban, I like it. [15:25] gary_poster: the validation is not completely duplicated between the Int and the base fields: the base would complain about 0, but I see your point [15:26] cool [15:28] gary_poster when qa'ing Makyo's branch you said that you didn't feel it was more performant? If you want something to compare it to, my branch removes the filters entirely - albeit it has bugs but it'll give you something to compare to. [15:40] rick_h__: is the staging charmworld supposed to ingest regularly? http://staging.jujucharms.com/heartbeat shows that it hasn't since the 8th [15:41] benji: hmm, yes I believe so. I'ts using the same cron from the charm as production unless someone turned off the cron job. [15:41] k [15:45] hatch, it sounds like gary_poster ran into a cache issue, was better after clearing. [15:46] ohh ok [15:46] hatch, thank you. it turned out to be a caching issue in my browser. not sure why it triggered. once I cleared out cache, the code really had a huge & impressive speed increase. Seems like only slowdown is in simulator [15:46] now [15:46] awesomer! [15:46] on the order of a fraction of a second, and barely noticeable [15:46] yeah definitely [15:46] little bummed that I don't get to write a new implementation [15:46] :T [15:46] but maybe we'll have to support 10,000 at some point [15:46] :P [15:47] :-P [15:49] * gary_poster kinda loves seeing pr tests and $$merge$$ work [15:49] yeah I just wish $$merge$$ wasn't so ugly to look at lol [15:50] jujugui call in 10 [15:50] ty [15:50] hatch, heh, yeah, I suspect patches welcome if we all agree on something [15:50] I'd even go for ::merge:: tbh [15:50] :D [15:51] not huge imporovement to my eyes, but fine with it if team wants [15:52] * gary_poster wishes he remembered ins and outs of Y.merge better [15:53] merge is the easy one, it's mix() that's the impossible one :) [15:53] Y.merge(object[,object]) [15:53] ah right [15:53] Y.mix(who-the-heck-knows) [15:53] in merge, which wins? [15:54] last in the line wins [15:54] right [15:54] thx [15:54] nooooo problem [15:58] gary_poster: hatch it's a .ini config key + a doc change. Just say what you want it to be. [15:58] :poo: [15:58] +1 [15:58] jujugui call in 2 [15:58] +1 [15:58] ty [15:59] I'm glad github comments support both :shipit: and :shit: [16:02] benji, starting [16:02] coming [16:32] frankban, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 [16:44] benji rick_h__ https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 ? [16:45] yep [16:50] hey benji, why chiropractor and not massage? [17:04] It's rare enough that a webpage has an Esperanto translation that I'm always surprised by it, and remember that Chrome thinks that's my language for some reason. [17:04] In other news, our Jenkins install has an Esperanto translation :P [17:05] haha oh Esperanto [17:05] I remember the Esperanto bug [17:31] gary_poster, hatch okay with one review/qa, or should I request another? [17:31] I can do another if you need but the code looked good to me with gary's suggestions [17:31] another qa that is [17:40] hatch, I'd appreciate it. [17:40] ok on it [17:41] Sorry, was doing canonicaladmin stuff [17:42] best UX ever in that app [17:42] Hope I did the end-of-year closure thing right. [17:42] Hah [17:43] lgtm'd [17:44] Thanks. [18:02] gary_poster octet is supported across all of our browsers [18:02] on post [18:02] awesome, thank you [18:03] hatch, I will send a note to dimiter and rogpeppe cc'ing you [18:03] sure thanks, I'll upload the repo so anyone can test if they like [18:03] gary_poster: cool [18:04] hatch: so it's not a problem to upload a zip file as an octet stream with content-type of application/zip ? [18:05] well we can set whatever as a content type [18:05] I just tried streaming a file via post from all of our supported browsers [18:05] I used application/octet-stream [18:06] looks good here with application/zip [18:07] I'll push this repo up so you can see [18:12] https://github.com/hatched/octot-test rogpeppe gary_poster [18:12] octot? [18:12] * rogpeppe likes "octot" [18:12] :-) [18:12] thanks hatch [18:12] lol typo and I didn't care to change it haha [18:13] hatch, reply to my mail with link pls? [18:13] will do [18:14] ty [18:17] Hahah [18:17] I'm keeping octot. It's perfect. [18:18] lol perfect for what? [18:18] I dunno, but it beats out octet at whatever it is. [18:18] Probably perfect for GitHub, actually. [18:18] haha [18:18] Octotcat. [18:19] Github no longer restricts repo names [18:19] they are namespaced now [18:19] so multiple people can have the same repo name [18:20] It's been that way since I started using it, at least. [18:20] ohh, maybe I'm remembering some very legacy stuff [18:20] and it just stuck [18:21] ok now what to do....what to do.... *closes eyes and spins around* [18:21] looks like I'm removing more full browser [18:21] hatch: there's the search bug [18:26] search bug? [18:26] you mean that it doens't work like anyone expects it to? [18:26] lol [18:26] hatch: yea, quicksearch filting to only showing one result per charm name with importance weighed in like search results [18:27] was that triaged as higher priority than the browser stuff? [18:27] hatch: well, at first I thought you were asking [18:27] hatch: and it bugs me so if you fix it I get to :) [18:28] haha [18:28] well I should probably continue on my path of browser stuff [19:00] gary_poster in the hangout, whenever you're ready [19:31] oh, yay, the charmworld charm is all bash. [20:32] hey benji, if you have a moment could you see if you can successfully 'juju status' to staging.jujucharms.com after 'source orangify'? i'm getting TLS handshake errors. [20:32] bac: sure, let me try [20:32] ty [20:34] bac: "source orangify" is generating an exception for me [20:34] and I have to go to an appointement, like 5 minutes ago :) [20:34] sorry I couldn't help [20:35] np [21:02] holy so much code removal [21:08] and only 3 test failures [21:08] w00t [21:27] rick_h__ hey are you around? [21:28] jujugui looking for two reviews and qas on the fullscreen code removal branch (1242ln diff) [21:29] 99% removals [21:29] hatch, on it \o/ [21:29] thank yas! [21:29] Have a PR? [21:29] oops [21:29] https://github.com/juju/juju-gui/pull/15 [21:29] :) [21:29] forgot to paste [21:30] will look soon after bug triage, if no one else has taken [21:39] hatch, still triaging, but 1,173 deletions: awesome :-) [21:39] yeah, that was a lot of code haha [21:39] the paths are still overly complex but we can now work on simplifying them [21:40] cool [21:40] Makyo, in a shocking move, I accepted your Christmas holiday vacation request [21:41] lol [21:41] thanks for filing :-) [21:41] !!! [21:41] Thanks :_ [21:41] :) [21:41] what we get Christmas holidays? [21:41] NO WAY! [21:41] I needed to see how many days would roll over for the convention trip in January. [21:41] oh what convention? [21:42] hatch: howdy [21:42] Sci-fi/furry :P Giving a talk on data collection and visualization. [21:43] http://www.scififur.net/forum/forum.php ? [21:43] http://www.furtherconfusion.org/2014/ [21:44] coolio, are you dressing up? [21:45] At some point, sure, but not during the talk. Too much to deal with. [21:47] Want to tool around the bay area a bit, too, eat at all the neat places we don't have here in town. I know it's basically fast food there, but we don't have any ramen shops here :T [21:47] haha - I buy ramen in dry plastic wrapped cubes [21:47] aka ichiban! [21:47] lol [21:48] Pff! I do too, but after going to a few real ramen places out there, I'm hooked on that. [21:48] we are starting to get a lot of 'foodie' type restaurants here but none really have the level of quality i've come to expect from places on my travels which is unfortunate [21:49] Yeah, for sure. There are a few cropping up in town, thankfully, but some stuff is underrepresented. Korean food, notably: we have a pretty big Korean population, but the restaurant that's owned by a Korean family mostly just serves sushi. [21:50] that's...odd...heh [21:56] you can tell the best asian restaurants here really easily [21:56] if they are full of white people, it's probably not very good :D [21:56] it's like "ohh this is WESTERN Chinese food" [21:56] haha [21:58] There's a place here that helps with work visas for people, so their food is amazing. [21:59] It's pretty cool, from what I've heard. They help a family with work visas, find housing, and so on. [22:01] man hatch you're killing me. Realizing just how much code and tests went into making fullscreen happen. [22:01] rick_h__ yeah only like 1200 lines worth :P [22:01] is that what the diff is? ugh [22:02] I'm happy to see it go, but painful as well [22:02] haha yeah, sorry :) but I must admit, it was was easy to remove [22:02] so you did a good job modularizing everything [22:02] :) [22:02] rick_h__, when you get a chance, could you comment as to whether you think https://bugs.launchpad.net/juju-gui/+bug/1259704 should be addressed in charmworld or gui? If gui, would like to ask huw to fix it quickly. [22:02] <_mup_> Bug #1259704: Bundle branch command incorrect. [22:02] gary_poster: rgr [22:02] rick_h__, thank you (tomorrow is great!) [22:02] hatch, I won't be reviewing; have to go [22:03] bye all === gary_poster is now known as gary_poster|away [22:03] have fun [22:03] gary_poster no problem, cya [22:05] hatch, code's good, going to walk dogs then QA [22:05] great thanks === _mup__ is now known as _mup_ [22:12] morning huw [22:12] Mornign [22:12] *Morning [22:33] hatch: the reroute or something is breaking onboarding [22:34] rick_h__ repro steps? [22:34] hatch: clear your localStorage, go to / [22:34] hatch: to see it work, clear your localStorage go to /sidebar [22:34] hatch: this is in trunk, not your branch atm [22:34] ohh ok [22:34] so a separate card then [22:34] hatch: I'm guessing it's part of the redirect/etc work [22:35] nice catch though, I never thought of checking that [22:35] hatch: can you duplicate? I was going to check comingsoon but that's not updating off of git trunk atm [22:35] checking [22:37] rick_h__ what was the chrome command to clear localstorage? [22:37] I just always did localStorage.clear() [22:37] but I want to make sure it's out of the list [22:37] but my google fu is failing me [22:38] rick_h__ I can confirm [22:38] definitely a bug [22:38] hatch: oh sorry, I go to the resources tab in dev tools and look at the list [22:38] then click/delete the itmes [22:39] yup it's definitely broken [22:39] localStorage.clear() does work too, which is pretty cool :) [22:40] hatch: k, I'll file a bug/add a card for it [22:49] hatch: posted QA issues [22:49] hatch: some of them might be related so will hold off on more QA until tomorrow and will go through it again [22:49] rick_h__ do you think these happen on trunk too [22:50] as part of the redirect not the code removal? [22:50] hatch: no, some are pure fullscreen [22:50] the sidebar issue might, not sure. [22:50] well I mean there is no /fullscreen as far as the code is concerned [22:50] it gets redirected [22:50] and never touches the other code [22:50] hatch: right, but it's not redirecting cleanly [22:50] right, so these issues should happen on trunk? [22:50] some of the urls are possible user bookmarked urls that need to map cleanly [22:51] hatch: ah, ic [22:51] the search results one is interesting though [22:51] will look into that [22:51] heh, they're worse on trunk as you don't even get a sidebar at all [22:52] you just get the canvas sans-browser [22:52] eek [22:52] hatch: yea, I think the redirect should detect the requested viewmode and rather than just navigate, change the viewmode and do a browser viewNavigate so that the rest of the viewstate is kept in place [22:53] I can reproduce your sidebar issue, so I'll take a deeper look into that [22:53] and maybe at the same time try and fix the redirect stuff [22:53] the sidebar issue is on trunk as well [22:53] oh? hmm [22:53] maybe land as is then and roll another branch? [22:53] hatch: so maybe that's fallout from sticky headers? [22:54] well, I think it kind of sucks to keep going removing fullscreen (and hints on what's changed) with the broken url/search/state stuff [22:54] my guess is it's fallout from the browse/build removal stuff [22:54] I know your branch isn't 100% at fault, but it's related and think those urls should 'work' as part of removing this stuff [22:54] yeah that's true [22:54] ok I'll look into it [22:54] thanks