[00:00] <huwshimi> Hey bac!
[00:01] <hatch> I gota run for an hour or so but huwshimi  when I get back I can answer any q's
[00:01] <huwshimi> sure
[01:42] <hatch> huwshimi hey back, so any other ideas on implementation or do you just want to land it as is?
[02:13] <huwshimi> hatch: Apologies I was eating lunch
[02:13] <huwshimi> Oh
[02:28]  * benji wonders how often huwshimi eats sashimi.
[02:29] <huwshimi> Mmm... sashimi
[11:06] <rick_h_> frankban: demo went off awesome. I've had several people pull me aside to say it was awesome/impressive including Mark S
[11:06] <frankban> rick_h_: \o/
[11:06] <rick_h_> so big case of Gui rocks!
[11:06] <rick_h_> :)
[11:07] <frankban> rick_h_: very cool, so this was the local charms, right?
[11:07] <rick_h_> local charms, and then while that deployed I used quickstart -i to choose a non-default environment, and deploy the mongodb cluser bundle 
[11:08] <rick_h_> so hit both together and blew them away
[11:08] <frankban> rick_h_: great
[12:19] <bac> hey rick_h_
[12:41] <dimitern> rick_h_, awesome! so no issues with local charm uploads?
[12:42] <rick_h_> dimitern: nope was awesome. we've got some polish to do, but great demo.
[12:44] <dimitern> rick_h_, perfect! is there a deployed gui with local charms support? staging or something?
[12:48] <bac> he benji you around?
[12:48] <bac> rick_h_: ping
[12:49] <benji> bac: yep; what's up?
[12:49] <bac> benji: i've got a bundle inheritance question.  you up on that?
[12:49] <bac> benji: looky here:  http://bazaar.launchpad.net/~bac/charms/bundles/charmworld-demo/bundle/view/head:/bundles.yaml
[12:51] <benji> I haven't done anything with bundle inheritance, but I'm looking at it :)
[12:52] <bac> benji: ok, i thought you had.  quickstart hates it.  i'll figure it out
[12:53] <benji> bac: I don't know for sure, but I think the charmworld-production is missing the "services" key.
[12:53] <benji> elasticsearch and mongodb should be under a "services" key
[12:54] <bac> ah, right
[12:54] <rick_h_> bac: pong
[12:55] <bac> rick_h_: hey i got a modified version of that charmworld bundle deployed in lxc.  the only tweak required was to change charmworld_import_limit to -1
[12:56] <bac> charm ships with 110, so you were seeing 110 bundles + back versions
[12:56] <rick_h_> bac: oh!
[12:56] <rick_h_> doh
[12:56]  * rick_h_ is so tired, but should have seen that
[13:07] <gary_poster> hey rick_h_, glad the demo went so well. :-)
[13:10] <rick_h_>  gary_poster woot
[13:38] <bac> jujugui: anyone ever use 'juju destroy-environment --force'? does it clear out stale 'provider-state' and other files that make juju think it is bootstrapped when it isn't?  (i just did i manually before discovering --force)
[13:39]  * gary_poster has never used
[13:48] <bac> jujugui: the lcy02 maintenance a few days ago knocked the charmworld CI off-line and it went unnoticed.  it is alive again.
[13:50] <benji> I wonder if there is a simple and effective dead man's switch we could implement for that.
[13:59] <rick_h_> jujugui added a customer bug to the kanban in urgent. It's an odd one. Customer has a workaround but if anyone gets a chance to poke at it appreciate it
[14:00] <rick_h_> I've told them we'd not have a fix until next week, so no one ruin their friday/weekend on it, but want to make sure we're responsive to them. 
[14:01] <gary_poster> rick_h_: that may well be something specific to that charm.  Do you know the OpenStack charm guy?  He's probably there.
[14:01]  * gary_poster tries to remember name
[14:02]  * gary_poster has face...
[14:02] <rick_h_> gary_poster: ah, james?
[14:02] <gary_poster> no
[14:02] <gary_poster> he might know anyway
[14:03] <rick_h_> k, everyone is running for the hills so will see what I can find out
[14:03] <gary_poster> rick_h_: adam gandelman
[14:04] <gary_poster> though, yeah, james has more commits than I expected https://code.launchpad.net/~charmers/charms/precise/nova-compute/trunk
[14:07] <hatch> lol has face
[14:07] <gary_poster> :-P
[14:08] <rick_h_> ok, going afk until probably sunday when I get back to the US. have fun all!
[14:08]  * rick_h_ ran out of mifi data 2gb in one week :/
[14:08] <gary_poster> bye rick_h_, safe travels
[14:09] <bac> frankban: do you know why quickstart/deployer would reject root-disk as an invalid constraint?
[14:10] <hatch> cya rick_h_  have a safe trip
[14:10] <gary_poster> bac, don't we whitelist constraints?
[14:11] <gary_poster> and I don't recall root-disk as a standard one
[14:11] <bac> gary_poster: is this wrong: https://juju.ubuntu.com/docs/reference-constraints.html
[14:11] <gary_poster> bac, unlikely, but it may well be *new*
[14:11] <bac> ah
[14:12] <bac> gary_poster: perhaps, but it has been part of the manual charmworld deploy, presumably for a while
[14:12] <frankban> bac: the first whitelist I see in the stack is ALLOWED_CONSTRAINTS in guiserver/bundles/utils.py
[14:12] <frankban> ALLOWED_CONSTRAINTS = ('arch', 'cpu-cores', 'cpu-power', 'mem')
[14:13] <frankban> bac: we should update that list if core introduces new constraints
[14:13] <frankban> and I am not sure about deployer's own validation, but it's worth looking there too
[14:14] <bac> frankban: agreed.  and proof should match too.  annoying to get a false positive from the cheap test of proof only to have it fail later.
[14:18] <bac> frankban: as shown here https://juju.ubuntu.com/docs/charms-constraints.html, the constraints list is space-separated for the command-line.  guiserver forces comma-separated.
[14:18] <bac> frankban: should we support both?
[14:19] <frankban> bac: we need to support what is supported by the deployer
[14:19] <gary_poster> (and only that)
[14:19] <frankban> bac: which can be different by how things are spelled in the juju-core cli
[14:20] <frankban> bac: what we ideally need is a shared/simple/complete/tested bundle validation Python library that can be used by proof/quickstart/guiserver/deployer...
[14:21] <bac> preach!
[14:21] <frankban> :-)
[14:21] <gary_poster> :-)
[14:21] <bac> frankban: and when we do, it would be nice if it matched what the juju-core CLI and documentation expects
[14:26] <gary_poster> crazy talk\
[14:26] <gary_poster> we part ways there
[14:32] <bac> gary_poster: you being funny, no?
[14:32] <gary_poster> bac, I am hilarity incarnate
[14:32] <bac> which is proven by folks having to ask.  :)
[14:33] <gary_poster> exactly :-)
[14:33] <bac> i understand.  my humor goes unappreciated here.
[14:33] <bac> here = my house
[14:33] <gary_poster> heh
[14:37] <bac> abentley: the charmworld ci process seems to be partially dead.  could you give me some pointers?  chat?
[14:37] <abentley> bac: sure, but opt right now.
[14:37] <abentley> OTP
[14:37] <bac> abentley: np.  eta?
[14:38] <abentley> 10
[14:38] <bac> thanks
[14:50] <abentley> bac: Okay, how can I help?
[14:51] <bac> abentley: let me invite you to a hangout
[15:03] <frankban> guihelp: what do I need to do in the GUI to add an external js lib (except for adding that in the assets and loading it in index)?
[15:04]  * gary_poster seems to recall docs in this direction.  looking
[15:04] <hatch> frankban see merge-files
[15:05] <hatch> it's in bin/
[15:05] <gary_poster> (and lib)
[15:06] <hatch> the one in lib is just the script, the one in bin is the one which has the 'extras' list
[15:06] <hatch> which I've kind of always found odd
[15:06] <hatch> heh
[15:06] <frankban> hatch: so I have to push new libs in that filesToLoad.js, correct? anything else in the Makefile?
[15:07] <gary_poster> hatch are you looking at huw's branch to make it landable per your qa, or should I or someone else?  https://github.com/juju/juju-gui/pull/113
[15:07] <gary_poster> frankban: other thing: add a section to hacking doc describing what you did :-)
[15:07] <hatch> frankban that's it, nothing else required in the makefile
[15:07] <frankban> gary_poster: yeah I was thinking about that :-)
[15:08] <hatch> gary_poster yeah I think I'm going to pull it down and make some small changes and then re-push
[15:13] <gary_poster> ok thanks
[15:14] <hatch> gary_poster I'm also going to be working on adding view support to the viewlet manager
[15:14] <hatch> did you have anything else in the pipe you would like ahead of that?
[15:17] <hatch> in other news I was finally able to get my afp:// mount working
[15:23] <gary_poster> making notes, will be with you in a sec
[15:25] <hatch> *barf* this new coffee is horrid 
[15:26] <hatch> benji any updates on the investigation? Boards still have it in starting
[15:26] <benji> hatch: I need to update the board.  I'll do that now.  The current situation is that I'm fighting with the testing infrastructure.
[15:27] <hatch> want to pair on it? Or is it just something you need to slog through?
[15:27] <gary_poster> hatch, viewlet -> view is good.
[15:28] <hatch> sounds good
[15:28] <benji> I'm not interested in pairing just yet.
[15:28] <hatch> benji ok np lemme know if you do
[15:29] <hatch> itunes is stuck playing a single song.....oh boy stable 14.04 can't come soon enough
[15:34] <abentley> bac: Oh, and since I didn't spell it out in voice chat, a swift or s3 container that's configured for public access is just an http URL, so it works with most tools.
[15:35] <bac> abentley: right
[15:43] <abentley> bac: I don't think you successfully installed tarmac into /usr/local/lib. https://pastebin.canonical.com/104462/
[15:44] <bac> abentley: just did.  had to clean out /usr/local/lib.../tarmac.  the new version wasn't getting written
[15:46] <abentley> bac: Woot!  It worked.
[15:46] <bac> cool
[15:49] <hatch> gary_poster huw's branch is landing with trivials from his code
[15:49] <hatch> odly enough I rebased my fix into his and it showed as him doing the work
[15:49] <hatch> so it must take the first commit as the 'owner' ? 
[15:51] <gary_poster> dunno, but good all around
[15:52] <gary_poster> jujugui call in 8
[15:52] <hatch> yupyup
[15:55] <gary_poster> hatch, if rick is not back Monday and you are looking for something to do, maybe investigate DnD charm upgrade?  first cut UX would be to drag a charm on an existing service to trigger upgrade dialog, maybe?
[15:55] <gary_poster> and the viewlet -> view thing is not done
[15:55] <hatch> does core support it yet?
[15:55] <gary_poster> viewlet -> view more important
[15:56] <gary_poster> sure, same story: upload charm then can simply tell service to switch to new charm id that juju tells you
[15:56] <hatch> ahh right 
[15:56] <hatch> I'll create a card in Project 1
[15:57] <hatch> gary_poster do we want to allow the drop on the inspector as well?
[15:57] <gary_poster> hatch. I considered it.  If you like it, try it. :-)
[15:58] <hatch> ok I made a card which will be split out into a few I think
[15:58] <gary_poster> cool
[15:58] <gary_poster> jujugui call in 2
[16:01] <gary_poster> Makyo ping
[16:01] <Makyo> Keep getting "this party is over but you can start a new one"
[16:01] <Makyo> Trying other comp.
[16:01] <gary_poster> weird
[16:52] <bac> gary_poster: two leave requests added to canonicaladmin for your reviewing pleasure
[16:52] <gary_poster> btw, another remote collaborative tool worth following: http://screenhero.com/ .  Current killer for us is no Linux support, but supposedly in process/coming: http://feedback.screenhero.com/forums/192060-feature-requests/suggestions/3941833-make-screenhero-for-linux
[16:52] <gary_poster> ack bac, I eagerly await clicking buttons...will report back in a amoment
[16:53] <bac> gary_poster: and 1 day is rollover, so i just need to email sarah when approved, correct?
[16:53] <gary_poster> bac, yes, and cc me
[16:55] <gary_poster> bac, all approved .  Would you like me to write email to Sarah about using 2013 day?  I've done so in the past and am happy to.
[16:55] <gary_poster> will cc you
[16:56] <gary_poster> bac, actually you did it already.  following up.
[17:00] <benji> another thought on stateless components: instead of the top level dealing with a mutable bag of user state I wonder if we would be better served by passing in immutable state and getting back a sequence of changes to be enacted, that way we wouldn't have to infer changes from a state delta
[17:01] <benji> e.g.: pass in {sidebar: {minimized: false}} and if the user clicked on the sidebar show button we would get back actions = {sidebar: "un-minimize"}
[17:02] <gary_poster> benji, fwiw, that's my pattern for rendering actually: the factories return instructions on what to draw, rather than drawing themselves.  I was more direct for the event handlers, since I didn't want to have to come up with a vocabulary for the much larger (and yet-to-be-discovered) possible set of actions
[17:02] <hatch> benji you're basically taking the event system and bringing it down to the functional level with that
[17:03] <hatch> which is fine, it removes the async nature of it, (which might be a good thing)
[17:03] <benji> could be; hopefully with the benefits of events plus the benefits of a functional approach
[17:04] <gary_poster> I considered having generic data mutation actions, but I was using immutable data that had a _replace method on it to generate a new version, so it kind of felt like that already, for cheaper cost
[18:44] <Makyo> Boo  My solution doesn't work for some relations.
[18:45] <hatch> :(
[18:46] <Makyo> Was blithely checking relation hook failures, but some relations have multiple endpoints that connect to the same interface, like db and db-slave
[18:46] <frankban> guihelp: I need two reviews for https://github.com/juju/juju-gui/pull/115 . Anyone available? thanks! I'll try to make the changes and eventually land it in the we.
[18:47] <gary_poster> frankban: on it
[18:47] <hatch> sure I'll take it
[18:48] <frankban> benji: ^^^ I already have two reviewers, so, just FYI, that branch introduces the zip library and also adds a zip-utils module where to store helper functions for working with zip archives
[18:48] <frankban> gary_poster, hatch: thank you!
[18:49] <gary_poster> frankban: thanks np.  have a great weekend!  should we try to land it for you if we can?
[18:50] <benji> frankban: sounds good
[18:50] <frankban> gary_poster: sure! hopefully I will be able to do that in the we, but if not, please anyone feel free to take it
[18:51] <gary_poster> cool frankban.  ttyl
[18:51] <frankban> have a great weekend!
[18:52] <gary_poster> thanks :-)
[18:53] <gary_poster> hatch are you going to comment on modules-debug/modules-prod instead of the script tag, or shall I?
[18:54] <gary_poster> :-)
[18:54] <hatch> haha, I'm on lunch
[18:54] <hatch> go ahead
[18:54] <gary_poster> ok cool
[18:55] <hatch> I kind of wish we used the loader of some sort so that we didn't have to ship all of that js to the client all the time
[18:57] <gary_poster> but...we are building an app that needs all of it?
[18:57] <gary_poster> maybe I'm missing something
[18:57] <hatch> well it's just that you don't need it at all unless you're doing the local charm stuff
[18:57] <marcoceppi> so. quickstart kind of went a little wonky during the charm school today
[18:57] <hatch> so it has to be shipped for the 90% of the time that's unused
[18:58] <gary_poster> tell us more marcoceppi?
[18:58] <marcoceppi> gary_poster: oh, it's been recorded to youtube for prosperity, but basically it wasn't able to connect to the juju-gui websocket
[18:59] <marcoceppi> posterity, even
[18:59] <marcoceppi> let me find you the link where I start to panic
[19:00] <gary_poster> oh! weird, and I'm sorry.  was there anything unusual about the circumstances?  A bug report--or anything written--giving details would be fantastic
[19:00] <marcoceppi> juju quickstart -i ~/production.yaml was what I ran
[19:00] <gary_poster> we'll make one if you don't, of course, but it would be better to have you give us the details (and easier :-P)
[19:00] <gary_poster> marcoceppi, local env? ec2?
[19:00] <marcoceppi> gary_poster: I didn't really take time to debug, just kind of swept under the run and moved on
[19:00] <marcoceppi> hpcloud
[19:00] <gary_poster> sure of course
[19:01] <marcoceppi> I'll attempt it again now to see if I can repro
[19:01] <marcoceppi> is there a verbose flag or someting I can use?
[19:01] <gary_poster> I bet we haven't done much hpcloud ourselves.  Thank you!
[19:01] <gary_poster> marcoceppi: --debug
[19:02] <marcoceppi> cool, will give that a go now
[19:02] <gary_poster> thank you much
[19:14] <hatch> gary_poster I don't get an email from linked-in for over a year, I log in thanks to you and now I get about 1 a day lol
[19:14] <gary_poster> hatch, heh, sorry ;-)
[19:15] <bac> gary_poster: looking at the deployer code i see that it parses the constraints only as space-separated key=value pairs.  looks like guiserver using comma-separated is an outlier.
[19:48] <bac> jujugui: if you attempt to apploy a bundle via quickstart or the juju-gui, juju-core api requires that referenced charm urls have revisions in them.  if you don't you get an error message back like "Error": "charm url must include revision"
[19:49] <bac> the juju-deployer doesn't use the api and juju-core CLI doesn't have that restriction
[19:49] <bac> anyone know the rational?
[19:49] <bac> s/apploy/deploy/
[19:51] <bac> marcoceppi:  ^^^ that's what led to the bug i filed yesterday
[19:52] <benji> bac: I don't know of any reason we would include that constraint.  frankban would be a good person to ask.
[19:52] <marcoceppi> bac: thanks for the clarification
[19:52] <bac> benji: it isn't us.  it is juju-core
[19:52] <marcoceppi> couldn't you just do revision expansion?
[19:53] <marcoceppi> so charm: "mysql" would expand to cs:precise/mysql-33
[19:53] <marcoceppi> or are we of the idea that charms should be explicit? and if so that's something the remote proof will have to include, charm-tools proof only does a few things
[19:53] <marcoceppi> charm url validation occurs on the API side
[19:54] <benji> ahh, in that case I would suspect it is an accident of implementation (and an organizational anti-pattern: all clients should use the same API)
[19:54] <marcoceppi> in the case of proofing, the API I'm referring to is the charmworld api
[19:56] <marcoceppi> bac: https://manage.jujucharms.com/api/3/bundle/proof is where that should be fixed, not charm-tools
[19:57] <bac> marcoceppi: it would be better to find out if it is a false restriction and realign the juju-core api with the cli.
[19:57] <marcoceppi> true
[19:57] <marcoceppi> fwiw, the cli exapnds it prior to sending the charm url over
[19:58] <marcoceppi> so either we replicate that within juju-gui or just expose the more strict nature of the api and say you must have a version
[19:58] <marcoceppi> juju-gui server/quickstart
[20:00] <bac> i think from the perspective of a bundle specifying a particular revision is desirable, which guarantees this collection of charms works together.  with no revision you get the latest and that group of charms may have incompatabilities.
[20:01] <bac> i think i just argued with myself, again.
[20:04] <hatch> yes that's a definite requirement else you get issues like we have with npm dependencies 
[20:21] <gary_poster> jorge wants the loose approach too
[20:21] <gary_poster> He thinks he does, anyway :-)
[20:28] <hatch> well I could see that it would be ok
[20:29] <hatch> but that's kind of the cowboy approach and not for 'approved' charms
[20:29] <hatch> er bundles
[20:29] <hatch> at least IN MY MOST HUMBLE OF OPPINIONS
[20:29] <hatch> IMMHOO
[20:31] <gary_poster> hatch is calling out to the Canadian moose in Saskatoon
[20:32] <gary_poster> (and I agree)
[20:38] <marcoceppi> gary_poster: bac hatch I think jorge and I are in the same boat
[20:38] <marcoceppi> Give you enough rope to hang yourself
[20:38] <gary_poster> :-) k
[20:38] <bac> marcoceppi: can you clarify that boat
[20:38] <gary_poster> he wants to be able to have bundles that do not specify versions
[20:38] <marcoceppi> with regards to specifying versions in charms. I think we can talk about promulgated bundles being locked
[20:38] <gary_poster> cool
[20:39] <marcoceppi> but I should be able to strap on spurs and a 10 Gal hat with my own bundle namespace
[20:39] <gary_poster> I'd agree with that, and I think that's what we had intended for some time now
[20:39] <gary_poster> heh, sure
[20:39] <bac> so are we advocating for a change to guiserver to accept revision-less charm urls, look up the latest, and hand it to the juju-core API?
[20:39] <gary_poster> it's a deployer thing
[20:39] <marcoceppi> IMMHOO, yes
[20:39] <gary_poster> and I think it already does it there
[20:39] <gary_poster> heh
[20:39] <bac> NO
[20:39] <bac> well, deployer uses the CLI
[20:39] <hatch> marcoceppi so, approved bundles would require versions?
[20:39] <bac> and the CLI does it
[20:39] <gary_poster> ah right
[20:40] <marcoceppi> well promulgated bundles, if that ever exists, yes
[20:40] <gary_poster> though the deployer should be able to change for 1.18
[20:40] <bac> so, as marcoceppi said earlier, we'd have to have guiserver do the lookup before calling the api
[20:40]  * gary_poster suggests we wait for 1.18
[20:40] <gary_poster> and then have the deployer do the righth thing with the API
[20:40] <bac> i'm confused
[20:40] <gary_poster> and then use that
[20:40] <bac> the deployer does what jorge wants
[20:40] <gary_poster> the POWAA!
[20:41] <hatch> ugh who chose promulgated to be the word.....SERIOUSLY
[20:41] <hatch> was 'promoted' too easy?
[20:41] <hatch> :P
[20:41] <gary_poster> bac what do you mean?
[20:41] <marcoceppi> haha, you would get along with jorge swimingly
[20:41] <hatch> lol
[20:41] <bac> the deployer uses the CLI and does what jorge wants, revisionless charm urls
[20:41] <bac> currently
[20:42] <bac> juju-quickstart and juju-gui use the API and must have revisions
[20:42] <bac> so....
[20:42] <gary_poster> bac, in 1.18 the CLI uses the API
[20:42] <marcoceppi> gary_poster: for juju deploy? I thought it already did since 1.16
[20:43] <bac> gary_poster: ok, then in 1.18 jorge will be sad in all cases
[20:43] <gary_poster> marcoceppi: mebbe so.  I know that the API work is still ongoing
[20:43] <bac> who would like to have a quick hangout?
[20:43] <gary_poster> bac, no, my hope is that the API does the looking up on the server side now
[20:43] <marcoceppi> gary_poster: the CLI does the charm url conversion for by doing a look up against store.juju.ubuntu.com

[20:43] <bac> or shall we continue this whoseonfirst routine?
[20:43] <gary_poster> marcoceppi: and then talks to the API?
[20:44] <marcoceppi> when I run juju deploy mysql in 1.17.X it resolves the charm url then, I believe, uses api to do the deploy
[20:44]  * marcoceppi runs --debug
[20:44] <gary_poster> seems a shame that the charm url conversion is not done on the server side
[20:44] <marcoceppi> gary_poster: networking concerns
[20:44] <bac> marcoceppi, gary_poster: please to be joining me.  https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso
[20:44] <marcoceppi> though, the same exists for the desktop I guess
[21:08] <Makyo> gary_poster, hatch Current impl of relation is in error.  Appears to work, but may be worth a second set of eyes, if either of you have time. http://pastebin.ubuntu.com/6893602/
[21:08] <bac> gary_poster: bug 1277696
[21:08] <_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:New> <https://launchpad.net/bugs/1277696>
[21:09] <gary_poster> hatch finished https://github.com/juju/juju-gui/pull/115 ; ready for you
[21:09] <gary_poster> thank you bac
[21:09] <gary_poster> will mess with it in a sec
[21:09] <gary_poster> looking Makyo
[21:09] <bac> gary_poster: feel free to correct the description if muddy or wrong
[21:09] <gary_poster> cool thanks
[21:11] <gary_poster> Makyo: trivial but maybe worth clarification: "...side of the relation are in a relation error state..." -> "...side of the relation are in an error state for this relation..." or something like that?  awkward.  do what you will.  still reading
[21:11] <Makyo> Oh, right, didn't get to the comment yet.  Will do.
[21:13] <hatch> gary_poster ok thanks I'll get to it once I get out of viewlet manager mode
[21:13] <gary_poster> ack thanks hatch
[21:13]  * bac -> dog walk
[21:15] <hatch> Makyo looks good just maybe some inline comments explaining what the code does so future us doesn't have to actually read the code :D and just FYI arrays have a native some() in all of our supported browsers
[21:15] <Makyo> hatch, cool, thanks.  Will ensure 'some', but yeah, comments on the way.
[21:16] <hatch> this viewlets and views code is a headache
[21:16] <hatch> from now on, I want the final app spec before I start any code :P
[21:17] <hatch> enterprise baby!!!
[21:17] <gary_poster> Makyo, looks good to me.  I have a couple of minor niggles for you to take or leave.  (1) the `indexOf(sourceEndpoint[1].name + ...) !== -1 seems potentially problematic (if I have a name "bar" and another name "foobar", for instance).  Can't we use `...[21:17] <gary_poster> hatch :-P good luck :-)
[21:17] <hatch> lol
[21:17] <Makyo> gary_poster, oh, okay, yeah.  Will take a look.
[21:19] <gary_poster> Makyo: thanks, cool.  (2) I love me some functional programming, but I wonder if the sourceEndpoint & targetEndpoint assignment would be clearer (and as short or shorter) with conditionals
[21:20] <Makyo> gary_poster, oh, so sourceEndpoint = endpoints[0][0] [21:20] <gary_poster> if (this.endpoints[0][0] [21:20] <gary_poster> or whatever
[21:20] <gary_poster> yeah what you said is good direction too
[21:21] <Makyo> Can you expand arrays like that?
[21:21] <Makyo> That'd be neat.
[21:21] <gary_poster> no
[21:21] <Makyo> Boo! >:/
[21:21] <gary_poster> too much language exploration
[21:21] <gary_poster> sorry :-)
[21:21] <Makyo> Haha, I wish
[21:22] <hatch> apparently some iteration of ES6 has the multi assignment stuff added
[21:22] <gary_poster> yay
[21:23] <gary_poster> bac, moved "[suggestion] quickstart cmdline option for which juju to use" card to slack.  putting your new bug in its place.  AOK?
[21:24] <gary_poster> bac, uh, confused.  So we should close bug 1277188, replaced by bug 1277696; and open a new bug about the comma/space difference in constraints parsing?
[21:24] <_mup_> Bug #1277188: charm-proof should warn on revision-less charm URLs <charmworld:Triaged> <https://launchpad.net/bugs/1277188>
[21:24] <_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:New> <https://launchpad.net/bugs/1277696>
[21:25] <gary_poster> OIC
[21:25] <gary_poster> no, we want all three. :-/ k
[21:44] <Makyo> gary_poster, hatch http://pastebin.ubuntu.com/6893754/ ?
[21:44] <gary_poster> looking
[21:44] <hatch> oo pretty green
[21:45] <gary_poster> Makyo: looking good.  Only additional thought, that hatch can probably answer, is whether this is the right logic for peer relations
[21:45] <gary_poster> Is it?  Or is that not even pertinent?
[21:46] <Makyo> gary_poster, hatch not pertinent; peer relations are filtered out in the drawing process.  Logic will have to change if it goes down into handler level code.
[21:46] <gary_poster> Maybe not pertinent because it would not participate in a relation menu
[21:46] <gary_poster> cool
[21:46] <hatch> Makyo isn't this.source.units is not already an array? Isn't it a LML? Or is toArray() just a passthrough in that case?
[21:47] <Makyo> hatch, passthrough, I think. source.units is definitely not an array.
[21:47] <hatch> gotchaz 
[21:47] <hatch> +1
[21:47] <hatch> looks good here
[21:47] <gary_poster> Makyo: cool, looks good.  For future: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_(Merge_into_own_page.2Fsection) :-)
[21:48] <Makyo> Whew, okay.  Glad I caught the weird dual relations case.  Good test is mediawiki with two mysqls.  The interfaces are different on mediawiki, but the same on each mysql.
[21:49] <Makyo> Bonus :D
[21:49] <hatch> :) yay
[21:50] <hatch> yay go future javascript
[21:50] <hatch> which we can't use if we ever don't support the latest browsers
[21:50] <gary_poster> heh, open the inspector when you go to that page and look at console.  Maybe this is only new to me
[21:51]  * hatch hands gary a fancy hat and whistle.... "Welcome to the internet!!!"
[21:51] <gary_poster> :-P
[21:51] <hatch> lol
[22:01]  * Makyo dogwalk, then tests.
[22:01] <hatch> the viewlet manager now accepts viewlets AND views
[22:01] <hatch> unfortunately all the css is broken with views
[22:01] <hatch> yay
[22:02] <hatch> probably a rather simple specificity fix though so that's good
[22:05] <hatch> OO 168 test failures
[22:06] <hatch> there are so many test failures that the scrollback in my terminal doesn't go that far
[22:06] <hatch> haha oops
[22:17] <gary_poster> heh
[22:18]  * gary_poster running
[22:18] <gary_poster> have a great weekend and next week!