| hatch | any vim users here? I'm trying to find out what the equivalent of 'x' is but instead of delete, backspace | 03:12 |
|---|---|---|
| hatch | ahh upper case x | 03:14 |
| hatch | X | 03:14 |
| hatch | hmm which doesn't work | 03:14 |
| hatch | kadams54: you use vim? | 03:14 |
| kadams54 | Yes. | 03:14 |
| hatch | what is 'backspace' ? | 03:15 |
| hatch | x = delete | 03:15 |
| hatch | I found online that says X = backspace | 03:15 |
| hatch | but that doesn't work | 03:15 |
| hatch | oh crap now it is | 03:15 |
| hatch | :/ | 03:15 |
| hatch | hah | 03:15 |
| hatch | it's a little clumsy though I suppose | 03:15 |
| kadams54 | hm | 03:17 |
| kadams54 | I can't say I've ever seen it function as backspace | 03:17 |
| kadams54 | Usually just delete | 03:17 |
| kadams54 | But given the various navigation shortcuts, I've never really needed backspace | 03:18 |
| hatch | yeah I'm slowly learning vim heh | 03:20 |
| hatch | very slowly | 03:20 |
| hatch | probably just in time for some other editor to come out that's superior | 03:20 |
| hatch | :P | 03:20 |
| hatch | kadams54: do you also use jj as your escape? | 03:21 |
| kadams54 | no | 03:21 |
| kadams54 | I use escape as my escape | 03:21 |
| kadams54 | I do have my leader key mapped to comma | 03:22 |
| kadams54 | http://walking-without-crutches.heroku.com/image/images/vi-vim-cheat-sheet.png | 03:25 |
| hatch | leader key? | 03:25 |
| kadams54 | Yeah, it's important when you start talking about vim plugins | 03:25 |
| hatch | so you reach all the way up to escape every time you have to exit from insert mode? | 03:26 |
| kadams54 | For example, there's one called NERDTree that adds a file browser on the left side, similar to what you see in a lot of the editors. | 03:26 |
| kadams54 | You access that by hitting <leader>+n | 03:26 |
| kadams54 | And yes, I reach all the way up | 03:26 |
| hatch | ugh, yeah definitely couldn't do that :) | 03:26 |
| kadams54 | I've done it enough times that it doesn't feel awkward. | 03:26 |
| hatch | even the vim website has jj as the example for remapping haha | 03:26 |
| hatch | my escape key is so far away I have to actually move my hands off of the keyboard :) | 03:27 |
| kadams54 | Based on that shortcut, it looks like Shift+x is backspace | 03:27 |
| hatch | yeah, I figured it out, I kept hitting caps (which is remapped to ctrl) | 03:27 |
| kadams54 | I knew someone who mapped caps to escape | 03:27 |
| kadams54 | https://github.com/carlhuda/janus | 03:28 |
| kadams54 | Even if you don't use Janus, there are some really good links for learning Vim in the readme | 03:29 |
| hatch | I need caps as ctrl for tmux | 03:30 |
| hatch | well, and everything else that uses ctrl :) | 03:30 |
| kadams54 | Alright, I'm heading to bed. | 03:33 |
| kadams54 | Have fun learning how to be a real programmer ;-) | 03:33 |
| hatch | lol | 03:36 |
| hatch | night | 03:36 |
| === urulama-afk is now known as urulama | ||
| urulama | jujugui: https://github.com/juju/charmstore/pull/82 | 07:43 |
| urulama | jujugui: revision-info was not under the implemented endpoints | 07:43 |
| urulama | jujugui: i just merged it as it was just api reordering | 07:51 |
| urulama | frankban: good point, will do. | 08:07 |
| frankban | urulama: great thanks | 08:07 |
| frankban | rogpeppe1: could you please also take a look at https://github.com/juju/charmstore/pull/81 when you have time? | 08:08 |
| urulama | frankban: added card for weekly discussion | 08:09 |
| frankban | urulama: cool | 08:10 |
| urulama | frankban: one more thing from the QA test ... we did not define what happens to the revision numbers when uploading the same archive. Currently, rev.num. is increased with every POST. I would suggest that it is only changed if SHA is different. | 08:30 |
| frankban | thinking | 08:32 |
| frankban | urulama: that sounds reasonable. so, for series/charm-name, if a previous revision exists and has the same hash, publish is basically a no-op. | 08:38 |
| frankban | rogpeppe1: ^^^ | 08:38 |
| urulama | frankban: i would say so, yes. no upload. no rev inc. | 08:38 |
| rogpeppe1 | urulama: i'm not sure | 08:38 |
| urulama | rogpeppe1: heya, morning ... any counterexamples why we would want to inc the revision? | 08:39 |
| rogpeppe1 | urulama: it just seems like a reasonable invariant that if i do an upload, i get a new revision | 08:39 |
| rogpeppe1 | urulama: (changing this will also break current test logic, but i guess that's by the by) | 08:39 |
| urulama | rogpeppe1: on the other hand, if i double click the link in the gui (making a mistake), i get 2 versions | 08:40 |
| urulama | rogpeppe1: breaking test logic would be ok in this case :) | 08:40 |
| frankban | rogpeppe1: FWIW a nice side effect of this change is that the ingestion logic can be simplified | 08:40 |
| rogpeppe1 | frankban: only if the zip archives are deterministically made from the VCS info, i guess | 08:41 |
| urulama | rogpeppe1: that is a good point | 08:42 |
| rogpeppe1 | urulama: i'm wondering about situations where we *want* a new revision, regardless of the content | 08:43 |
| urulama | rogpeppe1: i tried to find one, but couldn't | 08:43 |
| rogpeppe1 | for example, we might want to associate some revision-info with the new revision, in extra-info | 08:43 |
| urulama | rogpeppe1: except that it is really easy to test everything :) | 08:43 |
| rogpeppe1 | urulama: i don't quite get why it makes it easier to test | 08:44 |
| urulama | rogpeppe1: you just upload 10 same zips and can get expand-id, revision-info, charm-related, bundles-containing showing more than one ... and deleting one still returns results | 08:45 |
| rogpeppe1 | urulama: how is that different from current? | 08:46 |
| urulama | rogpeppe1: no, no, current implementation is easier for testing. | 08:46 |
| rogpeppe1 | urulama: ah yes | 08:46 |
| urulama | rogpeppe1, frankban: I've just made a mark in the doc about the revisions increase. And let's leave it as it is, as it is easier to understand what's happening with each POST. In case it turns out that we want a NOP POST, we can change later. | 08:48 |
| rogpeppe1 | urulama: sgtm | 08:48 |
| frankban | rogpeppe1: with that change, it would be harder the case when you need different revisions of the same charm in tests. Tests requiring different charms would still work reusing the same charm implementation. for the former case, it should not be hard to implement a factory that just increases the revision number before returning the archive impl. urulama: sounds good | 08:49 |
| urulama | rogpeppe1: could you take a look at this "investigate how juju-core pings for upgrades" for the next task? The aim of this is that we'd like to have a number of live charms (deployed and used) in some recent time frame. | 08:50 |
| rogpeppe1 | frankban: yeah, it wouldn't be too hard. but i don't really see that it's that important. the important place to do this logic is at the client side (we need to make the hash of the archive available to clients, if we don't already) | 08:50 |
| rogpeppe1 | urulama: sure | 08:50 |
| frankban | rogpeppe1: sure, I mentioned that just to understand if I see the possible problems | 08:51 |
| frankban | urulama: re the card "store: Update bundles to support multiple revisions and make available over api v4": it seems you confirmed this already works in your QA, I guess we can move the card to done | 08:52 |
| urulama | frankban: i was looking at this already, guess Rick added it ... yes, this can be removed. done. | 08:54 |
| frankban | cool thanks | 08:54 |
| * urulama likes when things get resolved without extra effort :) | 08:54 | |
| frankban | :-) | 08:56 |
| * frankban bbiab | 08:56 | |
| urulama | frankban: after PR 81, we only support https? (because conf.validate will fail if user and pwd are not set) | 09:23 |
| * urulama lunches | 09:53 | |
| frankban | urulama: no, we still support http, but we require auth for POST/DELETE archive | 10:39 |
| frankban | urulama: so I guess we'll need to add to options to the charm | 10:40 |
| urulama | frankban: to options to the charm? | 10:51 |
| frankban | urulama: sorry, two options to the charm | 10:51 |
| frankban | urulama: like superuser-name/superuser-password or something like that, so that the charm can generate the cnfiguration file for charmd with the proper options | 10:52 |
| urulama | frankban: do we need this? | 10:53 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| jcastro | rick_h_, I'd like to feature a bundle | 13:04 |
| jcastro | but it appears like I can't self feature like I can with charms | 13:04 |
| urulama | jcastro: rick_h_ is on well deserved holidays | 13:05 |
| jcastro | oh boo! :) | 13:05 |
| jcastro | can any of you guys feature a bundle? | 13:05 |
| urulama | jcastro: not sure if such functionality is possible right now | 13:07 |
| jcastro | well, we have featured bundles already, so it exists | 13:07 |
| urulama | jujugui: anyone with access to do featured bundles? | 13:08 |
| jcastro | BradCrittenden, this sounds like something you would know | 13:08 |
| BradCrittenden | urulama: yes i should be able to. anyone in, what ~charmers, shoule be able | 13:19 |
| === BradCrittenden is now known as bac | ||
| bac | urulama: what bundles? | 13:19 |
| urulama | bac: something jcastro needs ... jcastro what bundles? | 13:20 |
| jcastro | elasticsearch please! | 13:20 |
| jcastro | bac, ^ | 13:20 |
| jcastro | brand new and shiny! | 13:20 |
| urulama | bac: speaking of ES :D :D | 13:20 |
| bac | jcastro: this one: http://manage.jujucharms.com/bundle/~charmers/elasticsearch/cluster | 13:22 |
| bac | jcastro: if you login, and visit that page do you not see a "Feature" link? | 13:22 |
| * bac teaches fishing | 13:22 | |
| * bac done | 13:29 | |
| bac | jcastro: if you visit that link now you should see an 'unfeature'. urulama you might try it as well to see if you're in the correct groups. | 13:29 |
| urulama | bac: i am not :) | 13:31 |
| urulama | bac: just kidding, yes, i see unfeature link | 13:32 |
| bac | oh, good | 13:32 |
| jcastro | I was at that page, I just totally missed the link! | 13:32 |
| jcastro | ah nuts, on my screen, the featured bundles collapses, so you can't really see it on the list. :-/ | 13:33 |
| jcastro | there's no way to change the order of the featured bundles is there? | 13:33 |
| jcastro | I'll just unfeature mongo for a bit | 13:34 |
| urulama | jujugui: taking the kinds to visit my parents ... be back in 20min | 13:42 |
| === urulama is now known as urulama-afk | ||
| hatch | jujugui there are a ton of branches from huw from last night - I'll do one review for them all, I'll need one more, any volunteers ? | 14:01 |
| === uru_ is now known as urulama | ||
| lazyPower | hey hatch, i'm getting some weird artifacting on the gui using Chrome Version 36.0.1985.143 - http://i.imgur.com/a4HCoEX.png | 14:24 |
| lazyPower | this persists through a page refresh | 14:24 |
| hatch | lazyPower: yeah.... | 14:25 |
| hatch | this appears to be a chrome bug | 14:25 |
| lazyPower | ok i haven't filed a bug or looked for one to contribute to - i was more confirming its known behavior | 14:25 |
| hatch | it only happens on some icons though | 14:25 |
| hatch | so we may be able to fix it by fixing some icons | 14:25 |
| lazyPower | strange that they were working fine before - any clue as to what's stemming the icon issue? | 14:26 |
| lazyPower | older svg spec? | 14:26 |
| hatch | lazyPower: honestly I have no idea, it displays fine in all other browsers | 14:26 |
| hatch | I spent a couple hours trying to track it down before but no luck | 14:26 |
| hatch | if you come accross something let me know....the bug is... | 14:27 |
| hatch | https://bugs.launchpad.net/juju-gui/+bug/1358671 | 14:27 |
| mup | Bug #1358671: Charm icons not rendering properly <juju-gui:Triaged> <https://launchpad.net/bugs/1358671> | 14:27 |
| hatch | maybe if you could add that image to the bug | 14:27 |
| hatch | ya know - more people, higher priority :) | 14:27 |
| lazyPower | already done :) | 14:30 |
| hatch | great - but you'll see that it's only certain ones - primairly the wordpress and mysql ones | 14:30 |
| lazyPower | i've seen it happen to the category icons as well - but its random | 14:31 |
| lazyPower | it doesn't always rear it's head, and its not always on the same icons | 14:31 |
| lazyPower | it typically happens when i'm zoomed out and zoom back in | 14:31 |
| hatch | hmm | 14:32 |
| lazyPower | also, moving the charm squircle appears to make it re-render the svg properly | 14:32 |
| hatch | yeah...odd | 14:33 |
| hatch | since nothing changes in the gui | 14:33 |
| hatch | the markup is identical when you drag | 14:33 |
| hatch | so it's definitely a chrome bug | 14:33 |
| hatch | just not sure how to workaround it | 14:33 |
| lazyPower | throw more javascript at it | 14:34 |
| lazyPower | :P | 14:34 |
| hatch | haha | 14:35 |
| hatch | Makyo: jcsackett your branches ready to land now? | 14:39 |
| jcsackett | hatch: doing the rebase to cleanup this very moment. | 14:39 |
| hatch | coolio | 14:40 |
| Makyo | Was hoping for another +1, but can land whenever. | 14:40 |
| hatch | it's going to be in a queue behind huw's branches heh | 14:40 |
| hatch | Makyo: don' you have 2? | 14:40 |
| Makyo | Didn't last I checked. | 14:40 |
| Makyo | Oh, there it is. | 14:40 |
| Makyo | Sometimes GH streams comments, sometimes not. | 14:40 |
| hatch | yeah i've noticed that | 14:41 |
| hatch | we might be back down to 0 open pr's again today :) | 14:45 |
| hatch | assuming of course CI doesn't totally shit the bed | 14:45 |
| jcsackett | hatch: big assumption. | 14:49 |
| hatch | lol | 14:52 |
| hatch | jujugui call in 2 | 14:58 |
| hatch__ | kadams54: | 15:00 |
| kadams54 | joining | 15:01 |
| kadams54 | Hangouts is telling me to wait :-) | 15:01 |
| bac | jrwren: it is an unwieldy solution | 15:25 |
| === mup_ is now known as mup | ||
| urulama | bac: if you're out next week, and Friday is your product management day, could we spend some time tomorrow on ES schemas for current version and start working towards schema for charmstore v4? | 15:26 |
| urulama | bac: by we, i meant you, jrwren and me | 15:27 |
| bac | urulama: yes i think that's a good idea | 15:27 |
| bac | urulama: and the following week i'll be working in UTC+2, so we can collaborate like crazy! | 15:27 |
| urulama | bac: aaa, i misunderstood that you are offline ... ok, ok, then np, no need to change activities | 15:28 |
| urulama | bac: you'll be French! :D | 15:29 |
| bac | urulama: no you were right. next week i'm out. the following week i'm working from UTC+2 | 15:29 |
| hatch | world traveler! | 15:29 |
| urulama | bac: hehe, ok, then schema it is tomorrow and soon, you'll be French! | 15:29 |
| bac | i will not actually *be* french. i will be in france. | 15:30 |
| bac | i think gillam gets to spend the week working with our host guillaume in a winery, eating baguettes. | 15:31 |
| bac | now that's french | 15:31 |
| frankban | :-) | 15:31 |
| * urulama gets hungry | 15:31 | |
| urulama | bac: but you can enjoy their lunches, where wine is of course big part of it | 15:32 |
| bac | maybe not | 15:33 |
| frankban | jrwren: FYI I think the design team already has some stuff re dominant charm color (IIRC they did something on the client side). I might be worth asking them | 15:33 |
| * frankban now wants escargot + bourgogne wine for dinner | 15:36 | |
| jrwren | frankban: Thanks, I'll ask. Should I just email luca? That design team? | 15:41 |
| frankban | jrwren: yes | 15:42 |
| luca | jrwren: antdillon is the best person to talk to about the colour thing | 15:42 |
| antdillon | jrwren, hi | 15:42 |
| antdillon | jrwren, are you looking for the generic icon stuff? | 15:43 |
| jrwren | Now I want to make baguettes. | 15:45 |
| urulama | antdillon: luca pointed at you about that dominant colour :D | 15:50 |
| hatch | jrwren: need barley for that? haha | 15:50 |
| rogpeppe1 | bac: just had a brief glance at elastigo. looks like it's just a very thin wrapper around normal http methods. doesn't look like it adds enough value to justify it as a 3rd party dep | 15:50 |
| rogpeppe1 | bac: perhaps useful for the struct definitions | 15:50 |
| jrwren | antdillon: I think so, yes. | 15:50 |
| jrwren | antdillon: predominant background color of the svg. | 15:50 |
| rogpeppe1 | bac: but i'd tend towards defining an API that we want to use and defining marshaling types as necessary, with reference to the elastic search API docs | 15:50 |
| rogpeppe1 | s/API/Go API/ | 15:50 |
| antdillon | urulama, oh that colour lol ... what you need jrwren ? | 15:51 |
| jrwren | hatch: I've considered wheat futures too :) | 15:51 |
| urulama | antdillon: just how to get it :D | 15:51 |
| luca | urulama: currently what I think Ant uses is pretty simple and we would like to tweak it once we can see it’s application when running on a proper database | 15:51 |
| luca | antdillon: ^ | 15:51 |
| bac | rogpeppe1: interesting | 15:51 |
| hatch | jrwren: haha | 15:51 |
| antdillon | urulama, jrwren currently I pick the colour of the pixel at 10x10 on the charm icon and apply that colour to the hero row background colour | 15:52 |
| jrwren | antdillon: DONE! :) | 15:53 |
| urulama | rogpeppe1: khm. you sure it's worth it? then we have to track ES development and update that ... | 15:53 |
| urulama | jrwren: NONONONO! :D :D | 15:53 |
| jrwren | 10,10 when the svg is sized to what? | 15:53 |
| rogpeppe1 | urulama: do we really trust the author of elastigo to do that? also, isn't the elastic search API versioned? | 15:53 |
| urulama | luca, antdillon: so the "better" algorithm is not used? surely we must do better than that :D | 15:54 |
| hatch | so I can help ya'll out with this | 15:54 |
| hatch | pretty simple really | 15:54 |
| jrwren | urulama: luca said they would like to tweak it, so maybe we default to this but allow the value to be set via POST? | 15:55 |
| hatch | render the svg to a canvas, then go pixel by pixel reading the colour data | 15:55 |
| antdillon | jrwren, the icons are currently displayed at 45px but when grabbing it with js it can be anysize | 15:55 |
| rogpeppe1 | hatch: that assumes we can render svg... | 15:55 |
| hatch | rogpeppe1: why can't we? | 15:55 |
| hatch | what are we? amatures!!!!! | 15:55 |
| hatch | no but really...why can't we | 15:55 |
| hatch | :) | 15:55 |
| rogpeppe1 | hatch: maybe we can - we'd need a library for doing svg->raster in go | 15:56 |
| antdillon | urulama, we only wanted to select the background colour of the charm icon | 15:56 |
| urulama | jrwren: we have SVG code in go, why not just do something smarther ... but yes. the first implementation can take the colour of 10,10 pixel :D | 15:56 |
| rogpeppe1 | hatch: 'cos i don't really want to write one from scratch | 15:56 |
| antdillon | urulama, I took an average of all colours before but if resulted in some ugly colours | 15:56 |
| hatch | rogpeppe1: right - the proper tool for the job here is to use phantom/casper etc | 15:56 |
| rogpeppe1 | if we've got a bitmap icon, it would be easy to take the majority pixel colour | 15:56 |
| jrwren | I found this: https://github.com/ajstarks/svgo I don't think CC attribution makes for a good software license :( | 15:57 |
| hatch | unless there is a svg to raster go tool | 15:57 |
| urulama | didn't someowne in jujugui write the go code for svg already? | 15:57 |
| urulama | someone even :D | 15:57 |
| hatch | Makyo: wrote a svg renderer yes | 15:57 |
| jrwren | urulama: hatch thanks. | 15:58 |
| frankban | urulama: Makyo did, but generating the svg is different than converting it to a raster in order to do pixel counts | 15:58 |
| rogpeppe1 | hatch: wasn't that something that generated svg to be rendered elsewhere? | 15:58 |
| hatch | ^ that | 15:58 |
| urulama | a, ok, generator ... not renderer. ok. | 15:58 |
| hatch | so anyways, to do this is pretty trivial using phantomjs buuuut that requires phantomjs dependency heh | 16:00 |
| hatch | can I propose having a microservice for this task? | 16:00 |
| rogpeppe1 | i guess this isn't *too* far away http://godoc.org/code.google.com/p/draw2d/draw2d | 16:02 |
| rogpeppe1 | but i suspect that svg is quite involved to parse and render, as every web standard is | 16:03 |
| hatch | http://www.svgopen.org/2011/papers/34-SVGo_a_Go_Library_for_SVG_generation/ | 16:04 |
| jrwren | its *just* xml. :p | 16:04 |
| hatch | lol riiiight | 16:04 |
| hatch | urulama: is a microservice an option? | 16:04 |
| urulama | hatch: i'd like it not to be :D | 16:05 |
| hatch | haha, well it probably 'should' be, they are all the rage now :) | 16:05 |
| hatch | easy to test, upgrade, etc etc :P | 16:05 |
| Makyo | SVGo was less than ideal, but oh well. | 16:06 |
| frankban | rogpeppe1: exec.Command("convert", "input.svg", "output.png") ? ;-) | 16:07 |
| urulama | :D | 16:07 |
| Makyo | That'd work, heh | 16:08 |
| Makyo | ImageMagick's a heavy dependency, but probably already on the system. | 16:08 |
| hatch | think so? | 16:08 |
| Makyo | Maaaybe? | 16:08 |
| frankban | it is if the charm installs it | 16:08 |
| hatch | haha | 16:09 |
| jrwren | hatch: nice paper. I still find the CC attribution license strange. | 16:09 |
| rogpeppe1 | hatch: that doesn't render it | 16:09 |
| rogpeppe1 | hatch: it just produces svg | 16:09 |
| rogpeppe1 | hatch: which can be rendered elsewhere | 16:09 |
| rogpeppe1 | https://groups.google.com/forum/#!topic/golang-nuts/IonhQBFfg7o | 16:09 |
| * rogpeppe1 tries to think of a way we can avoid the problem | 16:09 | |
| === rogpeppe1 is now known as rogpeppe | ||
| urulama | does anyone knows how much "cpu" does rendering of svgs take? | 16:09 |
| rogpeppe | *producing* svg is easy | 16:10 |
| rogpeppe | *consuming* it is hard | 16:10 |
| hatch | jrwren: rogpeppe no idea, I just found it while googling | 16:10 |
| urulama | maybe postprocessing job is not that bad of a solution | 16:11 |
| hatch | :) | 16:11 |
| hatch | I'm not sure if go has a library for parsing png pixel data but you can do it via js and canvas | 16:12 |
| hatch | but that requires phantom or th elik | 16:12 |
| hatch | e | 16:12 |
| hatch | although it sounds like the current winning solution requires imagemagick | 16:13 |
| frankban | hatch: IIRC png handling is in the go stdlib | 16:13 |
| hatch | which also isn't very small | 16:13 |
| urulama | jrwren: just do the get/post methods for the colour for now | 16:13 |
| urulama | jrwren: and luca will be super happy, he'll be able to test and change colours on the fly :D | 16:13 |
| hatch | frankban: ahh yes there is one that returns an Image interface....nice | 16:14 |
| rogpeppe | frankban: yeah, that's an option, i guess | 16:14 |
| rogpeppe | urulama: it's probably not too bad, if you're not running an external command that's reading and writing to the filesystem :-) | 16:14 |
| hatch | so in that case imagemagik + that is probably the best option | 16:14 |
| urulama | rogpeppe: no, no ... no disk involved | 16:15 |
| hatch | why is disk bad? | 16:15 |
| rogpeppe | wow, svg really is huge. http://www.w3.org/TR/SVG/single-page.html | 16:15 |
| rogpeppe | hatch: bitmaps are easy to do in go | 16:15 |
| hatch | rogpeppe: right but you have to get from svg to png | 16:16 |
| hatch | first | 16:16 |
| rogpeppe | hatch: yeah | 16:16 |
| urulama | i guess python has svg rendering lib? | 16:16 |
| jrwren | so huge it took a decade to get browser support | 16:16 |
| hatch | ohhhh kadams54 - how goes the reviews on huws stuff? | 16:16 |
| rogpeppe | hatch: i'm wondering if we could just do it with an external process that processes svgs and adds background colour metadata | 16:16 |
| hatch | rogpeppe: thats what I suggested earlier :P | 16:17 |
| rogpeppe | hatch: the downside of that is that you're not guaranteed a background colour in a timely way | 16:17 |
| urulama | hatch: and that's what it looks will be at least a short term solution ... | 16:17 |
| hatch | rogpeppe: what? 1s too slow? how long do you think it'll take? lol | 16:17 |
| hatch | it'll only need to be done when it's updated | 16:18 |
| urulama | luca: from your perspective, could we have a delay on the charm colour when uploaded? | 16:18 |
| rogpeppe | hatch: i was thinking of something entirely external to the charm store server, that just crawls charms that needs their bg colour updating | 16:18 |
| luca | urulama: I would like a small delay so it has more impact | 16:18 |
| urulama | luca: can we use PNGs instead of SVGs in charms ;) | 16:19 |
| hatch | rogpeppe: oh I was thinking that when a new charm is updated the charmstore would send the svg out for parsing | 16:19 |
| hatch | so it'll only need to be done once per icon update | 16:19 |
| luca | urulama: ooooo, I don’t know. I doubt it. | 16:19 |
| rogpeppe | hatch: yeah, it could do that - that's essentially the "run the convert command" approach | 16:20 |
| hatch | rogpeppe: yeah - imho that's the best way because it's a bunch of code/process that will sit dormant 99% of the time | 16:20 |
| rogpeppe | actually, i do know how we could do it in Go | 16:20 |
| hatch | so might as well separate it out | 16:20 |
| urulama | rogpeppe: with a queue. send an ID in the db, svg-renderer is a charm, related to the CS mongo, it takes the ID, process it ... | 16:21 |
| hatch | ^ that | 16:21 |
| urulama | rogpeppe, hatch: classical batch system ... | 16:21 |
| hatch | yep, and if the svg has this 'major-colour' param then you can skip it | 16:22 |
| hatch | you could put it on a micro then, really | 16:23 |
| rogpeppe | urulama: i'm not sure exactly what you mean by "send an ID in the db" | 16:23 |
| rogpeppe | urulama: ah, perhaps you mean "from the db" ? | 16:23 |
| urulama | that :) | 16:23 |
| rogpeppe | urulama: you'd have to be careful how you find the next id to send | 16:25 |
| urulama | when archive is posted? | 16:25 |
| rogpeppe | urulama: what happens if the charm store goes down just after that? | 16:25 |
| urulama | it's the same as cleaning up the blob/name mess | 16:26 |
| rogpeppe | urulama: i think you'd need some kind of queue in the database, holding all the ids that still need colours | 16:26 |
| hatch | it could just whip through the charms to find ones which are missing the metadata then send those out | 16:26 |
| Makyo | jujugui trivial review/QA https://github.com/juju/juju-gui/pull/518 | 16:26 |
| hatch | even if there are 100,000 charms it'll only take seconds at most to query | 16:26 |
| urulama | rogpeppe: another collection? | 16:26 |
| rogpeppe | urulama: yes, that's what i was thinking | 16:27 |
| rogpeppe | urulama: when a charm is added, you add its id to the "needs external processing" queue | 16:27 |
| rogpeppe | urulama: but then you run into issues trying to make it scalable | 16:28 |
| rogpeppe | urulama: for example, what if you want to have several workers processing requests from the queue concurrently. then you need some kind of a lease system. | 16:28 |
| hatch | rogpeppe: honestly though - how long do you think it'll take that you need to do it like that? :) | 16:29 |
| rogpeppe | jeeze, this is a lot of proposed mechanism to get 3 bytes of data. | 16:29 |
| urulama | rogpeppe: that's why i was first suggesting batch system | 16:29 |
| urulama | rogpeppe: INDEED! | 16:29 |
| urulama | luca: we don't need clours! :D | 16:30 |
| jrwren | yes, I do not like these proposed mechanisms. I'd prefer to write Cgo to librsvg | 16:30 |
| urulama | luca: colours even | 16:30 |
| rogpeppe | jrwren: let's not add cgo as a dependency | 16:30 |
| rogpeppe | jrwren: directly, at any rate | 16:30 |
| rogpeppe | jrwren: we could perhaps have a separate binary | 16:30 |
| jrwren | rogpeppe: why is that? | 16:30 |
| luca | urulama: I disagree :P | 16:30 |
| rogpeppe | jrwren: because cgo is evil :-) | 16:30 |
| urulama | jrwren: I don't like something that is cpu intensive (or might be) to be needed when archive is posted | 16:31 |
| jrwren | urulama: do we know it is cpu intensive? Its like the clock time of the processing task will be far less than time for network xfer of the post. | 16:31 |
| rogpeppe | jrwren: and more concretely, it admits lots of potential C loopholes like buffer overruns etc | 16:31 |
| jrwren | s/like/likely/ | 16:31 |
| urulama | jrwren: /me goes and look for that, have no idea about svg rendering requirements | 16:33 |
| frankban | another possibility is the client (the GUI) to do that the first time using the "print to canvas" approach, then sending the result back to the server to be stored, subsequent requests don't need recalculation, and sooner or later the billions of GUIs out there will cooperatively do the job for us | 16:33 |
| hatch | you're all talking like we are writing some system to manage google scale svg parsing, when atm we have, what, 100? | 16:35 |
| hatch | and at what rate will they be added, max 1 per day? | 16:35 |
| frankban | hatch: 100 * numSeries * numRevisions + the same for private charms | 16:36 |
| hatch | we don't show icons for private charms | 16:36 |
| jrwren | hatch: lets say customer X wants to sping up a new charm store, maybe they have a charmstore per department. Lets say they have these for prod, pre-prod, QA and dev envs. | 16:36 |
| frankban | hatch: oh we do | 16:36 |
| frankban | hatch: local charms | 16:36 |
| hatch | right local charms | 16:37 |
| jrwren | hatch: I share your concern of overengineering. I feel it is not quite as simple as we have just 100. | 16:37 |
| rogpeppe | yeah, i'm thinking along jrwren's lines. when we bootstrap a new charm store, we don't really want to spend a great amount of time rendering svgs for all the charms | 16:37 |
| hatch | ok 100 was an exaggeration | 16:38 |
| rogpeppe | i'm more concerned with the extra dependencies and complexity than the cpu time though, in all honesty | 16:38 |
| hatch | we don't really store and need to parse svg's for all revisions do we? | 16:38 |
| urulama | hatch: yes, but taking some time to find a proper solution is better then just do the wrong one because we can :D | 16:39 |
| hatch | haha true | 16:39 |
| hatch | so maybe the first step is hack something together real quick to see how long it takes to parse | 16:40 |
| hatch | something imagemagik and go | 16:41 |
| hatch | then you'll actually know, this takes X ms to parse | 16:41 |
| hatch | who knows, it could be so darn fast that it doesn't matter :) | 16:41 |
| urulama | hatch: trying to use google for that, but we might have to do that, yes | 16:42 |
| jrwren | time for i in `seq 1 1000 ` ; do rsvg-convert memcached/icon.svg > icon.png ; done | 16:42 |
| jrwren | my stupid quick get an idea for it test ^^^ | 16:42 |
| jrwren | 19s | 16:42 |
| jrwren | on my old slow server | 16:42 |
| hatch | 19s to convert 1000svg's to pngs? | 16:43 |
| jrwren | yes | 16:43 |
| urulama | wow! | 16:43 |
| hatch | that's pretty fast :) | 16:43 |
| jrwren | I know, kinda slow. | 16:43 |
| hatch | lol | 16:43 |
| jrwren | that also spawned 1000 processes, which is not insignificant | 16:43 |
| hatch | jrwren: what's the old slow server? | 16:44 |
| jrwren | E8500 | 16:44 |
| hatch | oh ok, so not really that slow | 16:44 |
| jrwren | That is a 6 year old CPU. | 16:45 |
| hatch | right, but doesn't your script only use a single core? | 16:45 |
| jrwren | but compared to clouds where we run, yes, its lightning fast. | 16:45 |
| jrwren | yes, script is single core. | 16:45 |
| hatch | yeah so a person could multi-thread it | 16:46 |
| urulama | hatch: when you start talking about using cores, you know it's slow ;) | 16:46 |
| hatch | urulama: haha | 16:46 |
| hatch | well if you put it on a quad core it'll cut it by 3/4 :) | 16:46 |
| jrwren | i don't know how rsvg-convert is implemented. | 16:46 |
| rogpeppe | jrwren: i was also looking at rsvg-convert | 16:47 |
| hatch | no idea | 16:47 |
| urulama | jrwren: let's stay with the get/post implementation | 16:47 |
| rogpeppe | it works ok even when the source and destination are pipes too | 16:47 |
| jrwren | urulama: ok. | 16:47 |
| urulama | not saying to stop discussing about the solution | 16:47 |
| urulama | just that we'll start with that | 16:47 |
| hatch | Makyo: I thought that we weren't going to show uncommitted units in the icon status bar? | 16:48 |
| hatch | am I getting my discussions cross? | 16:48 |
| Makyo | Oh, I don't know. Was there a discussion on that? | 16:49 |
| Makyo | I took the path of least resistance, but can go that way, too. | 16:49 |
| jrwren | In general, do we have specific performance requirements? | 16:49 |
| urulama | jrwren: please take a svg from a charm and repeat the test? | 16:50 |
| jrwren | urulama: that was a svg from a charm. | 16:50 |
| * urulama drops a jaw on a floor | 16:50 | |
| urulama | that. is. slow. | 16:50 |
| jrwren | 52/s sure is not fast. | 16:51 |
| hatch | luca: you here? | 16:51 |
| luca | hatch: hi | 16:51 |
| jrwren | urulama: but again, that is a terrible test. | 16:51 |
| hatch | luca: the status bar on service icons, are we supposed to show uncommitted units in there? | 16:51 |
| hatch | or ignore them from the status bar? | 16:51 |
| urulama | jujugui: see you later | 16:52 |
| luca | hatch: ignore them for the time being but that may change, I wanted to see how it worked | 16:52 |
| hatch | cya urulamau | 16:52 |
| kadams54 | urulama: have a good one | 16:52 |
| hatch | luca: I'm just asking because Makyo is working on it atm, and it's easier to show them, vs hide | 16:53 |
| hatch | but from a UX standpoint....does it make sense to show them? | 16:53 |
| Makyo | hatch, luca I can show them with one CSS tweak as uncommitted blue fwiw | 16:53 |
| hatch | yeah | 16:53 |
| jrwren | I guess 52/s isn't THAT bad. 19ms sounds faster. | 16:53 |
| hatch | lol | 16:54 |
| hatch | jrwren: add moar coars | 16:54 |
| Makyo | I kind of like it because then I can see how much I'm going to add in proportion to how much I already have. | 16:54 |
| hatch | Makyo: good point | 16:54 |
| hatch | I'm good with it, just want luca's approval so we don't get another bug report :PPP | 16:54 |
| Makyo | no prob | 16:54 |
| luca | Makyo: you want to show them in the bar? | 16:55 |
| rogpeppe | jrwren: here's the source for rsvg-convert, FWIW: http://paste.ubuntu.com/8160919/ | 16:55 |
| jrwren | rogpeppe: https://git.gnome.org/browse/librsvg/tree/rsvg-convert.c :) | 16:55 |
| rogpeppe | jrwren: :-) | 16:55 |
| Makyo | luca, I do personally, but you're the designer :) | 16:56 |
| hatch | haha | 16:56 |
| rogpeppe | what i don't really get is why we can't implement this logic in the client, that's going to be rendering the svgs anyway | 16:56 |
| Makyo | Let me screenshot | 16:56 |
| luca | Makyo: ok | 16:56 |
| luca | Makyo: I wanted to see how it worked in the GUI, it might be best to play with it there and then remove if necessary | 16:57 |
| jrwren | rogpeppe: its a fair question. Why is meta/color in the spec? | 16:57 |
| luca | Makyo: I wanted the health bar to depict health only | 16:57 |
| rogpeppe | can't the client grab the svg, render it, pick out a pixel as appropriate, and use that | 16:57 |
| rogpeppe | ? | 16:57 |
| Makyo | luca, that makes sense, yeah. | 16:57 |
| jrwren | rogpeppe: exactly. | 16:57 |
| hatch | rogpeppe: jrwren: it's cpu intensive and quite a bit of overhead to do it all the time instead of just showing a provided hexcode | 16:58 |
| luca | Makyo: should we try it with for the time being and then I can see how it feels and works? | 16:58 |
| hatch | many cpu cycles around the world wasted for what? FOR WHAT? | 16:58 |
| Makyo | https://www.dropbox.com/s/e6z5k2betv6xoqy/Screenshot%20from%202014-08-27%2010%3A57%3A30.png?dl=0 | 16:58 |
| Makyo | luca, ^ | 16:58 |
| hatch | ;) | 16:58 |
| Makyo | luca, sure, it's easy to back out. | 16:58 |
| luca | Makyo: cool, will the blue also show in the inspector? | 16:59 |
| Makyo | luca, we don't have the status bar in the inspector anymore, but it does still list uncommitted units with the blue uncommitted indicator. | 16:59 |
| hatch | Makyo: that's because it's broken ;) | 16:59 |
| luca | Makyo: thats a bug, the health bar should be visible in the inspector | 17:00 |
| rogpeppe | hatch: it might be worth trying to see how much time it actually takes when done client-side | 17:00 |
| Makyo | Oh, then yeah, it'll show there. The CSS affects both status bars | 17:00 |
| Makyo | (and I'll see about fixing that) | 17:00 |
| hatch | rogpeppe: it has to load the svg, render it to a canvas, read the pixel data, determine which colour is the predominant one, then set the bg colour - on every page load | 17:01 |
| hatch | vs, set background-color: #xxxxxx | 17:01 |
| jrwren | hatch: ty, that is a good use case. | 17:01 |
| Makyo | hatch, have the clients send the data back to the server to store, call it distributed :D | 17:01 |
| jrwren | hatch: doesn't it load the svg and render it anyway? | 17:01 |
| rogpeppe | hatch: well, on every page load that uses an svg we haven't seen before, i guess. or is it not possible to cache stuff client side? | 17:02 |
| hatch | well no it caches the svgs | 17:02 |
| hatch | but it'll need to render it to a canvas and do the processing every time | 17:02 |
| Makyo | Could dump it in localstorage | 17:02 |
| Makyo | Or whatever the KV pair thing is. | 17:03 |
| jrwren | hatch: doesn't it do that anyway? or does it need this background color for some case where the svg is not rendered? | 17:03 |
| hatch | yeah, but this is all vs setting a hex code as the bg | 17:03 |
| hatch | jrwren: svg is rendered as an image | 17:03 |
| hatch | not into a canvas | 17:03 |
| jrwren | oh! image not... | 17:03 |
| jrwren | hatch: thank you. I see now. | 17:03 |
| hatch | I'm not saying it's not possible - just that it's a lot of overhead for every pageload vs doing it once serverside and setting the bg colour of the container element | 17:04 |
| hatch | code-wise it's also pretty trivial, just cpu intensive (and we only have a single thread) | 17:05 |
| hatch | Makyo: could you take a review of huw's branches? | 17:06 |
| hatch | I'd like to get them landed | 17:06 |
| Makyo | hatch, sure | 17:06 |
| hatch | thanks | 17:06 |
| rogpeppe | another possibility is to make it part of the charm uploader's responsibility | 17:07 |
| hatch | Makyo: thanks for the reviews! | 17:23 |
| hatch | Makyo: so you're leaving it with the uncommitted in the status bar? Just checking so I can +1 if so :) | 17:24 |
| Makyo | hatch, yeah, it's easy enough to remove, and will give luca et al the chance to play with it. | 17:25 |
| hatch | coolio | 17:25 |
| Makyo | Will fix the status bar in the inspector next. | 17:25 |
| hatch | +1'd | 17:25 |
| hatch | awesome | 17:25 |
| luca | Makyo: hatch thanks guys | 17:25 |
| hatch | ugh ci | 18:44 |
| hatch | jcsackett: I don't know what bitch planet is but it sounds interesting..... | 19:28 |
| jcsackett | hatch: scifi comic by kelly sue deconnick. modern reworking of 70s era "prison planet" films. | 19:29 |
| hatch | interesting, guessing it's good? | 19:30 |
| jcsackett | it hasn't actually started yet; launches in december. | 19:32 |
| jcsackett | but everything else she's written has been awesome. | 19:32 |
| jcsackett | she maintains a blog she posts art and stuff to for it, which is where that image came from. | 19:32 |
| hatch | ahhh | 19:33 |
| jcsackett | hatch: also, i am now running my blog on ghost, using the charm. :) | 19:37 |
| hatch | *squeeeeee* | 19:37 |
| hatch | what's your setup like? haproxy? apache? | 19:37 |
| jcsackett | haproxy -> ghost -> mysql | 19:37 |
| jcsackett | haproxy and ghost running on the same machine. | 19:37 |
| hatch | cool, how much is it going to cost you per mo? | 19:38 |
| jcsackett | $20. it's two 1024 linode instances; used manual provider. | 19:38 |
| hatch | ahh cool, you should blog about it :) | 19:38 |
| jcsackett | i did have to clone it and deploy a local version to get it out on trusty. | 19:39 |
| hatch | I need to figure out a way to use the charm to redirect my tumblr urls to their respective ghost ones | 19:39 |
| jcsackett | i intend to. | 19:39 |
| hatch | yeah sorry about no trusty one - I need to write amulet tests before the trusty one will get promoted | 19:39 |
| jcsackett | yeah, that's going to be difficult; i kept my tumblr and use ifttt to repost stuff from my blog to it. | 19:39 |
| hatch | but what about people visiting the tumblr urls? | 19:39 |
| hatch | they need to redirect, no? | 19:39 |
| jcsackett | for me, no. i didn't get enough traffic to the individual urls to worry about redirection issues. | 19:40 |
| hatch | ohh , I get about 5000 uniques per month so I kind of have to | 19:40 |
| jcsackett | wow, nice. | 19:40 |
| hatch | well....I guess :) | 19:41 |
| jcsackett | i ... don't. :p | 19:41 |
| hatch | I have no idea why I get so much traffic tbh | 19:41 |
| hatch | I don't actively promote it or anything | 19:41 |
| jcsackett | weren't you once upon a time a biggish name in YUI community places? | 19:42 |
| hatch | I need to do some url rewriting or something, but I'm not sure if the apache charm supports such a thing, I'm not even sure where to start....maybe fork the apache charm and write my own? | 19:42 |
| hatch | I was, but I only have a couple posts about YUI | 19:43 |
| jcsackett | so, the apache charm takes a jinja template to set the vhost stuff. | 19:43 |
| jcsackett | you could probably get it to then do rewrites that way. | 19:43 |
| jcsackett | i couldn't even get it to work as a front end though, so gave up and did haproxy. | 19:43 |
| hatch | jinja for vhosts? | 19:44 |
| hatch | heh | 19:44 |
| hatch | no? What did it do? | 19:44 |
| hatch | it should 'just work' | 19:44 |
| hatch | haproxy and apache2 both accept the same relation endpoint | 19:44 |
| jcsackett | hatch: it did not "just work" when i related it. :p | 19:44 |
| hatch | hmm, interesting | 19:45 |
| jcsackett | haproxy did, so i didn't bother debugging. | 19:45 |
| hatch | any errors or anything? | 19:45 |
| hatch | oh ok | 19:45 |
| hatch | I'll have to look into that because I don't think haproxy does url rewriting | 19:45 |
| jcsackett | hatch: no juju errors. the hook executed just fine. | 19:45 |
| hatch | I need 'something' to redirect with 301's | 19:45 |
| hatch | ohh maybe it does...... | 19:46 |
| hatch | Makyo: qa'ing | 20:50 |
| hatch | Makyo: qa done, little issues | 20:55 |
| Makyo | hatch, what do you mean 'spacing on the deployed status bar'? | 20:56 |
| hatch | see the photos | 20:56 |
| hatch | the gap on top is much bigger than on the bottom | 20:57 |
| hatch | are the photos not showing up? | 20:57 |
| Makyo | hatch, shit, sorry, privacy badger got them. Will fix that. | 20:57 |
| hatch | ahh different hosts | 20:57 |
| Makyo | Yeah. | 20:58 |
| Makyo | Got it | 20:58 |
| Makyo | Still not quite sure what you mean on spacing\ | 20:58 |
| hatch | ok on the ghost one you see the huge empty space? | 20:59 |
| Makyo | Yeah, I see that. | 20:59 |
| hatch | ok and the deployed one, there is a space above and below the status bar | 21:00 |
| hatch | the space above it is much larger before the divider line than the one below it | 21:00 |
| Makyo | Alright, will see about trimming. | 21:01 |
| hatch | but good work finding the issue :) | 21:01 |
| hatch | that one was a big oops | 21:02 |
| Makyo | Yeah, didn't know about the mv flag in CSSland | 21:02 |
| hatch | kadams54: did you want to pass your branch off for the time you're gone? | 21:56 |
| kadams54 | hatch: I'm going to try to get it finished up tonight. | 22:28 |
| hatch | kadams54: ok cool, if you don't plz push it up and send an email to peeps | 22:31 |
| kadams54 | Will do | 22:31 |
| hatch | man the icon rendering on tokens is real broken heh | 22:31 |
| hatch | been working on it all day tracking down the issues | 22:31 |
| Makyo | hatch, repushed, for whenever | 22:45 |
| hatch | Makyo: thanks, i'll probably look at it tonight, I'm in my own special version of hell right now | 22:48 |
| hatch | :) | 22:48 |
| Makyo | hatch, np, good luck | 22:50 |
| huwshimi | Morning | 22:59 |
| hatch | Makyo: thanks, I 'think' I just got it | 23:02 |
| hatch | sometimes it's the smallest things.....i am beginning to hate javascript | 23:02 |
| hatch | lol | 23:02 |
| hatch | morning huwshimi | 23:02 |
| huwshimi | hatch, Makyo: Thanks for all the reviews! | 23:03 |
| hatch | np :) the damn ci was runnin almost all day haha | 23:03 |
| hatch | gw | 23:03 |
| hatch | thanks for doing all them | 23:04 |
| huwshimi | np | 23:04 |
| hatch | huwshimi: hey I'm heading out for a while, need anything before I take off? | 23:57 |
| huwshimi | hatch: I'm all good. Have a good one | 23:58 |
| hatch | you too, cya | 23:58 |
| huwshimi | bye | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
