Makyo | 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:49 |
---|---|---|
hatch | i'll take it | 00:50 |
gary_poster | thank you. also looking at it but won't have time for review | 00:50 |
hatch | heh this diff is very confusing | 00:51 |
hatch | hmm Makyo very intersting | 00:52 |
gary_poster | 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:05 |
Makyo | gary_poster, not seeing any pauses, here.. | 01:07 |
gary_poster | Makyo, ack. :-/ I looked at app/views/viewlets/service-overview.js and saw changes you have in the diff | 01:08 |
gary_poster | so I do have your changes | 01:08 |
gary_poster | I can try make clean | 01:08 |
gary_poster | nope, no change | 01:10 |
Makyo | Takes 10s for 2000 units to render on comingsoon for me, 1.5s locally. No delays scrolling in either, though. | 01:11 |
gary_poster | ah, weirdness: filesystem says one code, but browser says another | 01:12 |
gary_poster | trying something | 01:12 |
gary_poster | no | 01:13 |
gary_poster | weird! Makyo good news is that it's something on my system :-/ | 01:14 |
gary_poster | 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:17 |
gary_poster | I need to grok the branch tomorrow so I can see what you mean by your comments | 01:18 |
Makyo | Oh! Cool :) | 01:19 |
Makyo | Yeah, np | 01:19 |
gary_poster | 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:31 |
Makyo | Definitely. Will make a card with notes for myself. | 01:32 |
gary_poster | thank you | 01:32 |
gary_poster | made card. please feel free to take over :-) | 01:33 |
gary_poster | running away. have a good night! | 01:33 |
=== gary_poster is now known as gary_poster|away | ||
bac | hi frankban | 12:31 |
frankban | morning bac | 12:31 |
bac | frankban: since you are the world's expert on using Mock and MagicMock could you give me a hand with mocking 'open'? | 12:32 |
frankban | :-) | 12:33 |
bac | 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:33 |
bac | 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 |
frankban | bac: does it work using '__builtin__.open'? | 12:34 |
bac | i've tried using michael's instructions here: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_10_02.shtml#e1188 | 12:34 |
bac | i've not tried builtin. good idea | 12:34 |
=== gary_poster|away is now known as gary_poster | ||
gary_poster | frankban, fwiw I am reviewing your branch | 13:04 |
frankban | gary_poster: thank you!, Brad will start the second review in minutes | 13:05 |
* frankban lunches | 13:05 | |
dimitern | gary_poster, hatch, hey guys | 13:45 |
gary_poster | hey dimitern . thanks for work on charm upload: looking cool | 13:45 |
dimitern | gary_poster, hatch, we had a bit of discussion about the charm upload implementation | 13:46 |
* gary_poster listens | 13:46 | |
gary_poster | hatch is probably still sleeping in his timezone | 13:46 |
gary_poster | or at least not started yet | 13:46 |
dimitern | 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:46 |
gary_poster | so this POST vs PUT? | 13:47 |
dimitern | no matter, at leas he'll be pinged and see the conversation later if i include him :) | 13:47 |
gary_poster | :-) cool | 13:47 |
dimitern | so, encoding a sub-10MB charm inside a multipart form is not a big deal (some 25% increase in size) | 13:48 |
rogpeppe | 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 |
dimitern | but I'm told we expect much bigger charms | 13:48 |
dimitern | i.e. a binary, non-encoded body | 13:48 |
dimitern | ^ re rogpeppe's question | 13:48 |
dimitern | 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 |
gary_poster | dimitern, rogpeppe needs research. trying to do it quickly. | 13:50 |
dimitern | 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 |
rick_h__ | compressing client side will be tough | 13:51 |
dimitern | rick_h__, I thought we already have the zip packaged before the upload? | 13:51 |
gary_poster | rick_h__, this is about octet | 13:52 |
rick_h__ | gary_poster: oh, ok nvm. | 13:52 |
gary_poster | rick_h__, we will be provided zip *and* there appears to be nice JS zip lib for converting floders to zips | 13:52 |
gary_poster | rick_h__, http://stuk.github.io/jszip/ | 13:52 |
dimitern | 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:53 |
dimitern | otherwise we'll bump it to the highest in state +1 | 13:54 |
dimitern | the bumping also occurs if the revision in the charm is lower than the highest in state for the same charm | 13:54 |
gary_poster | 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 |
dimitern | 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 |
dimitern | brb doorbell | 13:55 |
rogpeppe | gary_poster: yes, the return from the POST is the charm url which includes the new revision number | 13:56 |
gary_poster | great | 13:56 |
dimitern | yes | 13:56 |
gary_poster | 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 |
gary_poster | t? | 14:00 |
rogpeppe | gary_poster: it would be nicer if we could avoid the multipart stuff entirely | 14:01 |
gary_poster | rogpeppe, of course | 14:01 |
gary_poster | 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:02 |
rogpeppe | 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:03 |
gary_poster | ack | 14:04 |
dimitern | gary_poster, great | 14:05 |
gary_poster | cool thanks for update dimitern and rogpeppe. talk to you soon | 14:05 |
dimitern | gary_poster, so, just that you know - I changed the specs to reflect the final version which will be implemented | 14:05 |
gary_poster | dimitern, I saw, and also shared it with rest of gui team | 14:05 |
dimitern | 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 |
gary_poster | ack | 14:06 |
dimitern | gary_poster, cheers | 14:06 |
gary_poster | :-) | 14:06 |
hatch | morning | 14:07 |
gary_poster | hey hatch. read backlog for me and I bet you can figure out what I'd like you to answer/research ;-) | 14:12 |
hatch | on it! | 14:15 |
gary_poster | thanks hatch | 14:17 |
hatch | gary_poster so the question is, can we upload uses an octect-stream? | 14:19 |
hatch | answer is yes | 14:19 |
gary_poster | hatch, on POST as well? | 14:19 |
hatch | yep | 14:20 |
gary_poster | hatch, great. includes Safari? | 14:21 |
hatch | just confirming safari | 14:21 |
gary_poster | cool | 14:21 |
gary_poster | hatch also do you want a review of the sticky headers thing? looks like huwshimi gave you an unofficial +1 | 14:22 |
hatch | sure, somehow I ended up with over 100 emails lastnight, still going through them | 14:22 |
gary_poster | :-) k. and are you in the middle of a review of Matt's performance branch, or should I take that too? | 14:22 |
hatch | going through it | 14:23 |
hatch | another bug with someone using the autocomplete as search results | 14:24 |
hatch | heh | 14:24 |
hatch | man there is like 0 documentation on safari | 14:26 |
bac | 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:26 |
rick_h__ | hatch: yea, at least we've got a plan on that one, just not done it yet | 14:27 |
gary_poster | bac, cool | 14:27 |
bac | gary_poster: and i did use a smiley, which covers many sins. | 14:27 |
gary_poster | bac :-) <- sins covered | 14:27 |
frankban | bac, gary_poster: the reports of me rewriting zope have been greatly exaggerated | 14:28 |
gary_poster | lol | 14:28 |
bac | :) | 14:28 |
bac | frankban: it did seem to come from an unlikely corner | 14:28 |
hatch | 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 |
gary_poster | hatch +1 please thank you | 14:32 |
gary_poster | hatch, for my own knowledge, where did you confirm octet-stream for chrome et al? | 14:33 |
hatch | I just read a few stackoverflow posts where people were having issues with it | 14:33 |
gary_poster | heh ok | 14:35 |
gary_poster | my google fu was merely insufficient :-) | 14:35 |
hatch | it's ok, it happens :D | 14:35 |
gary_poster | 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:37 |
frankban | 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 |
frankban | as, and to a variety of other python libraries (django.form, wtform etc.) | 14:38 |
hatch | I think that should work | 14:38 |
hatch | there is also a very odd bug that huw found | 14:38 |
hatch | I'll work on those, did you want to take Makyo 's branch? :) | 14:38 |
gary_poster | hatch, sure :-) | 14:38 |
bac | frankban: sure, thanks for the explanation | 14:39 |
gary_poster | hatch lots of comments and suggestions, but +1. happy to re-review if desired, | 15:07 |
gary_poster | but not necessary. | 15:07 |
hatch | thanks | 15:09 |
hatch | I fixed the flash in chrome | 15:09 |
gary_poster | awesome | 15:12 |
hatch | I think that this sticky header code nowhas more lines of comments than code | 15:12 |
hatch | hah | 15:12 |
gary_poster | +1 :-) | 15:13 |
hatch | so much for self documenting code lol | 15:13 |
gary_poster | maybe my scrollOffset comment was too much. <shrug> | 15:13 |
hatch | thats only 1 line | 15:16 |
hatch | haha | 15:16 |
hatch | the comment that broke the developers back? | 15:17 |
gary_poster | :-P | 15:17 |
frankban | gary_poster: what do you think about required=False, readonly=False, and then required must be explicitly passed when creating fields? | 15:23 |
gary_poster | frankban, I like it. | 15:23 |
frankban | 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:25 |
gary_poster | cool | 15:26 |
hatch | 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:28 |
benji | rick_h__: is the staging charmworld supposed to ingest regularly? http://staging.jujucharms.com/heartbeat shows that it hasn't since the 8th | 15:40 |
rick_h__ | 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 |
benji | k | 15:41 |
Makyo | hatch, it sounds like gary_poster ran into a cache issue, was better after clearing. | 15:45 |
hatch | ohh ok | 15:46 |
gary_poster | 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 |
gary_poster | now | 15:46 |
hatch | awesomer! | 15:46 |
gary_poster | on the order of a fraction of a second, and barely noticeable | 15:46 |
gary_poster | yeah definitely | 15:46 |
hatch | little bummed that I don't get to write a new implementation | 15:46 |
Makyo | :T | 15:46 |
hatch | but maybe we'll have to support 10,000 at some point | 15:46 |
hatch | :P | 15:46 |
gary_poster | :-P | 15:47 |
* gary_poster kinda loves seeing pr tests and $$merge$$ work | 15:49 | |
hatch | yeah I just wish $$merge$$ wasn't so ugly to look at lol | 15:49 |
Makyo | jujugui call in 10 | 15:50 |
gary_poster | ty | 15:50 |
gary_poster | hatch, heh, yeah, I suspect patches welcome if we all agree on something | 15:50 |
hatch | I'd even go for ::merge:: tbh | 15:50 |
hatch | :D | 15:50 |
gary_poster | <shrug> not huge imporovement to my eyes, but fine with it if team wants | 15:51 |
* gary_poster wishes he remembered ins and outs of Y.merge better | 15:52 | |
hatch | merge is the easy one, it's mix() that's the impossible one :) | 15:53 |
hatch | Y.merge(object[,object]) | 15:53 |
gary_poster | ah right | 15:53 |
hatch | Y.mix(who-the-heck-knows) | 15:53 |
gary_poster | in merge, which wins? | 15:53 |
hatch | last in the line wins | 15:54 |
gary_poster | right | 15:54 |
gary_poster | thx | 15:54 |
hatch | nooooo problem | 15:54 |
rick_h__ | gary_poster: hatch it's a .ini config key + a doc change. Just say what you want it to be. | 15:58 |
gary_poster | :poo: | 15:58 |
hatch | +1 | 15:58 |
Makyo | jujugui call in 2 | 15:58 |
Makyo | +1 | 15:58 |
gary_poster | ty | 15:58 |
Makyo | I'm glad github comments support both :shipit: and :shit: | 15:59 |
Makyo | benji, starting | 16:02 |
benji | coming | 16:02 |
gary_poster | frankban, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 | 16:32 |
gary_poster | benji rick_h__ https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 ? | 16:44 |
benji | yep | 16:45 |
hatch | hey benji, why chiropractor and not massage? | 16:50 |
Makyo | 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 |
Makyo | In other news, our Jenkins install has an Esperanto translation :P | 17:04 |
hatch | haha oh Esperanto | 17:05 |
hatch | I remember the Esperanto bug | 17:05 |
Makyo | gary_poster, hatch okay with one review/qa, or should I request another? | 17:31 |
hatch | I can do another if you need but the code looked good to me with gary's suggestions | 17:31 |
hatch | another qa that is | 17:31 |
Makyo | hatch, I'd appreciate it. | 17:40 |
hatch | ok on it | 17:40 |
Makyo | Sorry, was doing canonicaladmin stuff | 17:41 |
hatch | best UX ever in that app | 17:42 |
Makyo | Hope I did the end-of-year closure thing right. | 17:42 |
Makyo | Hah | 17:42 |
hatch | lgtm'd | 17:43 |
Makyo | Thanks. | 17:44 |
hatch | gary_poster octet is supported across all of our browsers | 18:02 |
hatch | on post | 18:02 |
gary_poster | awesome, thank you | 18:02 |
gary_poster | hatch, I will send a note to dimiter and rogpeppe cc'ing you | 18:03 |
hatch | sure thanks, I'll upload the repo so anyone can test if they like | 18:03 |
rogpeppe | gary_poster: cool | 18:03 |
rogpeppe | hatch: so it's not a problem to upload a zip file as an octet stream with content-type of application/zip ? | 18:04 |
hatch | well we can set whatever as a content type | 18:05 |
hatch | I just tried streaming a file via post from all of our supported browsers | 18:05 |
hatch | I used application/octet-stream | 18:05 |
hatch | looks good here with application/zip | 18:06 |
hatch | I'll push this repo up so you can see | 18:07 |
hatch | https://github.com/hatched/octot-test rogpeppe gary_poster | 18:12 |
gary_poster | octot? | 18:12 |
* rogpeppe likes "octot" | 18:12 | |
gary_poster | :-) | 18:12 |
gary_poster | thanks hatch | 18:12 |
hatch | lol typo and I didn't care to change it haha | 18:12 |
gary_poster | hatch, reply to my mail with link pls? | 18:13 |
hatch | will do | 18:13 |
gary_poster | ty | 18:14 |
Makyo | Hahah | 18:17 |
Makyo | I'm keeping octot. It's perfect. | 18:17 |
hatch | lol perfect for what? | 18:18 |
Makyo | I dunno, but it beats out octet at whatever it is. | 18:18 |
Makyo | Probably perfect for GitHub, actually. | 18:18 |
hatch | haha | 18:18 |
Makyo | Octotcat. | 18:18 |
hatch | Github no longer restricts repo names | 18:19 |
hatch | they are namespaced now | 18:19 |
hatch | so multiple people can have the same repo name | 18:19 |
Makyo | It's been that way since I started using it, at least. | 18:20 |
hatch | ohh, maybe I'm remembering some very legacy stuff | 18:20 |
hatch | and it just stuck | 18:20 |
hatch | ok now what to do....what to do.... *closes eyes and spins around* | 18:21 |
hatch | looks like I'm removing more full browser | 18:21 |
rick_h__ | hatch: there's the search bug | 18:21 |
hatch | search bug? | 18:26 |
hatch | you mean that it doens't work like anyone expects it to? | 18:26 |
hatch | lol | 18:26 |
rick_h__ | hatch: yea, quicksearch filting to only showing one result per charm name with importance weighed in like search results | 18:26 |
hatch | was that triaged as higher priority than the browser stuff? | 18:27 |
rick_h__ | hatch: well, at first I thought you were asking | 18:27 |
rick_h__ | hatch: and it bugs me so if you fix it I get to :) | 18:27 |
hatch | haha | 18:28 |
hatch | well I should probably continue on my path of browser stuff | 18:28 |
hatch | gary_poster in the hangout, whenever you're ready | 19:00 |
bac | oh, yay, the charmworld charm is all bash. | 19:31 |
bac | 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 |
benji | bac: sure, let me try | 20:32 |
bac | ty | 20:32 |
benji | bac: "source orangify" is generating an exception for me | 20:34 |
benji | and I have to go to an appointement, like 5 minutes ago :) | 20:34 |
benji | sorry I couldn't help | 20:34 |
bac | np | 20:35 |
hatch | holy so much code removal | 21:02 |
hatch | and only 3 test failures | 21:08 |
hatch | w00t | 21:08 |
hatch | rick_h__ hey are you around? | 21:27 |
hatch | jujugui looking for two reviews and qas on the fullscreen code removal branch (1242ln diff) | 21:28 |
hatch | 99% removals | 21:29 |
Makyo | hatch, on it \o/ | 21:29 |
hatch | thank yas! | 21:29 |
Makyo | Have a PR? | 21:29 |
hatch | oops | 21:29 |
hatch | https://github.com/juju/juju-gui/pull/15 | 21:29 |
hatch | :) | 21:29 |
hatch | forgot to paste | 21:29 |
gary_poster | will look soon after bug triage, if no one else has taken | 21:30 |
gary_poster | hatch, still triaging, but 1,173 deletions: awesome :-) | 21:39 |
hatch | yeah, that was a lot of code haha | 21:39 |
hatch | the paths are still overly complex but we can now work on simplifying them | 21:39 |
gary_poster | cool | 21:40 |
gary_poster | Makyo, in a shocking move, I accepted your Christmas holiday vacation request | 21:40 |
hatch | lol | 21:41 |
gary_poster | thanks for filing :-) | 21:41 |
Makyo | !!! | 21:41 |
Makyo | Thanks :_ | 21:41 |
Makyo | :) | 21:41 |
hatch | what we get Christmas holidays? | 21:41 |
hatch | NO WAY! | 21:41 |
Makyo | I needed to see how many days would roll over for the convention trip in January. | 21:41 |
hatch | oh what convention? | 21:41 |
rick_h__ | hatch: howdy | 21:42 |
Makyo | Sci-fi/furry :P Giving a talk on data collection and visualization. | 21:42 |
hatch | http://www.scififur.net/forum/forum.php ? | 21:43 |
Makyo | http://www.furtherconfusion.org/2014/ | 21:43 |
hatch | coolio, are you dressing up? | 21:44 |
Makyo | At some point, sure, but not during the talk. Too much to deal with. | 21:45 |
Makyo | 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 |
hatch | haha - I buy ramen in dry plastic wrapped cubes | 21:47 |
hatch | aka ichiban! | 21:47 |
hatch | lol | 21:47 |
Makyo | Pff! I do too, but after going to a few real ramen places out there, I'm hooked on that. | 21:48 |
hatch | 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:48 |
Makyo | 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:49 |
hatch | that's...odd...heh | 21:50 |
hatch | you can tell the best asian restaurants here really easily | 21:56 |
hatch | if they are full of white people, it's probably not very good :D | 21:56 |
hatch | it's like "ohh this is WESTERN Chinese food" | 21:56 |
hatch | haha | 21:56 |
Makyo | There's a place here that helps with work visas for people, so their food is amazing. | 21:58 |
Makyo | It's pretty cool, from what I've heard. They help a family with work visas, find housing, and so on. | 21:59 |
rick_h__ | man hatch you're killing me. Realizing just how much code and tests went into making fullscreen happen. | 22:01 |
hatch | rick_h__ yeah only like 1200 lines worth :P | 22:01 |
rick_h__ | is that what the diff is? ugh | 22:01 |
rick_h__ | I'm happy to see it go, but painful as well | 22:02 |
hatch | haha yeah, sorry :) but I must admit, it was was easy to remove | 22:02 |
hatch | so you did a good job modularizing everything | 22:02 |
rick_h__ | :) | 22:02 |
gary_poster | 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. <juju-gui:Triaged> <https://launchpad.net/bugs/1259704> | 22:02 |
rick_h__ | gary_poster: rgr | 22:02 |
gary_poster | rick_h__, thank you (tomorrow is great!) | 22:02 |
gary_poster | hatch, I won't be reviewing; have to go | 22:02 |
gary_poster | bye all | 22:03 |
=== gary_poster is now known as gary_poster|away | ||
rick_h__ | have fun | 22:03 |
hatch | gary_poster no problem, cya | 22:03 |
Makyo | hatch, code's good, going to walk dogs then QA | 22:05 |
hatch | great thanks | 22:05 |
=== _mup__ is now known as _mup_ | ||
hatch | morning huw | 22:12 |
huwshimi | Mornign | 22:12 |
huwshimi | *Morning | 22:12 |
rick_h__ | hatch: the reroute or something is breaking onboarding | 22:33 |
hatch | rick_h__ repro steps? | 22:34 |
rick_h__ | hatch: clear your localStorage, go to / | 22:34 |
rick_h__ | hatch: to see it work, clear your localStorage go to /sidebar | 22:34 |
rick_h__ | hatch: this is in trunk, not your branch atm | 22:34 |
hatch | ohh ok | 22:34 |
hatch | so a separate card then | 22:34 |
rick_h__ | hatch: I'm guessing it's part of the redirect/etc work | 22:34 |
hatch | nice catch though, I never thought of checking that | 22:35 |
rick_h__ | hatch: can you duplicate? I was going to check comingsoon but that's not updating off of git trunk atm | 22:35 |
hatch | checking | 22:35 |
hatch | rick_h__ what was the chrome command to clear localstorage? | 22:37 |
hatch | I just always did localStorage.clear() | 22:37 |
hatch | but I want to make sure it's out of the list | 22:37 |
hatch | but my google fu is failing me | 22:37 |
hatch | rick_h__ I can confirm | 22:38 |
hatch | definitely a bug | 22:38 |
rick_h__ | hatch: oh sorry, I go to the resources tab in dev tools and look at the list | 22:38 |
rick_h__ | then click/delete the itmes | 22:38 |
hatch | yup it's definitely broken | 22:39 |
hatch | localStorage.clear() does work too, which is pretty cool :) | 22:39 |
rick_h__ | hatch: k, I'll file a bug/add a card for it | 22:40 |
rick_h__ | hatch: posted QA issues | 22:49 |
rick_h__ | hatch: some of them might be related so will hold off on more QA until tomorrow and will go through it again | 22:49 |
hatch | rick_h__ do you think these happen on trunk too | 22:49 |
hatch | as part of the redirect not the code removal? | 22:50 |
rick_h__ | hatch: no, some are pure fullscreen | 22:50 |
rick_h__ | the sidebar issue might, not sure. | 22:50 |
hatch | well I mean there is no /fullscreen as far as the code is concerned | 22:50 |
hatch | it gets redirected | 22:50 |
hatch | and never touches the other code | 22:50 |
rick_h__ | hatch: right, but it's not redirecting cleanly | 22:50 |
hatch | right, so these issues should happen on trunk? | 22:50 |
rick_h__ | some of the urls are possible user bookmarked urls that need to map cleanly | 22:50 |
rick_h__ | hatch: ah, ic | 22:51 |
hatch | the search results one is interesting though | 22:51 |
hatch | will look into that | 22:51 |
rick_h__ | heh, they're worse on trunk as you don't even get a sidebar at all | 22:51 |
rick_h__ | you just get the canvas sans-browser | 22:52 |
hatch | eek | 22:52 |
rick_h__ | 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:52 |
hatch | I can reproduce your sidebar issue, so I'll take a deeper look into that | 22:53 |
hatch | and maybe at the same time try and fix the redirect stuff | 22:53 |
rick_h__ | the sidebar issue is on trunk as well | 22:53 |
hatch | oh? hmm | 22:53 |
hatch | maybe land as is then and roll another branch? | 22:53 |
rick_h__ | hatch: so maybe that's fallout from sticky headers? | 22:53 |
rick_h__ | 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 |
hatch | my guess is it's fallout from the browse/build removal stuff | 22:54 |
rick_h__ | 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 |
hatch | yeah that's true | 22:54 |
hatch | ok I'll look into it | 22:54 |
rick_h__ | thanks | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!