[12:27] <gary_poster> rick_h_, you want any huwshimi second reviews, or are you good to go?
[12:27] <rick_h_> gary_poster: I'm waffling, all of these are trivial few liners
[12:27] <gary_poster> rick_h_, :-) if I can help ping me
[12:27] <rick_h_> gary_poster: so was thinking I'd just land and run, but feels dirty to land 5 branches sans second review :)
[12:28] <gary_poster> lol
[12:29] <gary_poster> rick_h_, I'll try to zoom through them.  Have you qa'd all of them?
[12:29] <rick_h_> gary_poster: no, I haven't. I might build a super branch locally and run through them. 
[12:30] <gary_poster> rick_h_, sounds perfect
[12:30] <rick_h_> pastebin.canonical.com/90338/ for the quick run through list
[12:34] <jcsackett> rick_h_: what's the url for the ec2 version?
[12:34] <rick_h_> tinyurl.com/jujucharms
[12:34] <rick_h_> jcsackett: ^
[12:34] <jcsackett> thanks.
[12:36] <gary_poster> rick_h_, https://codereview.appspot.com/9069043/ is not LGTM but I suggested a possible solution
[12:37] <gary_poster> rick_h_, everything else is LGTM
[12:38] <rick_h_> gary_poster: thanks 
[12:38] <gary_poster> welcome
[12:59] <gary_poster> rick_h_, did you try the z-index of 2 thing?  Do you want me to try it, to get that moving along?
[13:04] <rogpeppe> gary_poster: you might be interested in this: it's an automatically generated description of the API, represented as JSON: http://paste.ubuntu.com/5622552/
[13:05] <rogpeppe> gary_poster: in this particular case it happens to include the read-only client object too, as i'd just been hacking on that.
[13:06] <gary_poster> rogpeppe, very cool!  :-)
[13:07] <gary_poster> rogpeppe, are you hoping to process that for some automatic human docs?
[13:07] <rogpeppe> gary_poster: that's part of the idea, yes
[13:07] <gary_poster> rogpeppe, this might be nice also to have as an API call, even
[13:07] <rogpeppe> gary_poster: that's what i'm thinking
[13:07] <gary_poster> cool, yeah
[13:08] <gary_poster> big +1 rogpeppe :-)
[13:09] <rogpeppe> gary_poster: obviously it has limits (it can't know about the EntityInfo types, for example) but i think it's useful nonetheless
[13:09] <rick_h_> gary_poster: I pulled it aside to clear the rest atm
[13:10] <gary_poster> rogpeppe, definitely.  We'd be able to conditionally add upgrade charm, for instance.  this would immediately help that effort
[13:10] <rick_h_> gary_poster: honestly, if it's a shadow thing I'd rather work on the api issues we've got and such at the moment. If you or someone wants to check with that I'd appreciate it
[13:10] <rick_h_> trying to fry the biggest fish I can for today
[13:10] <gary_poster> rick_h_, +1
[13:10] <rogpeppe> gary_poster: i'm not sure i quite understand what you mean by that
[13:11] <gary_poster> rogpeppe, sorry, yes, realized it was unclear as I sent it.  put more clearly, this would be a way for us to know whether to expose an upgrade charm interface in the GUI, which we are working on right now
[13:11] <rogpeppe> gary_poster: ah, you mean have the GUI introspect the available methods and only allow some things if the API actually provides them?
[13:11] <gary_poster> exactly
[13:12] <rogpeppe> gary_poster: nice idea, yeah
[13:12] <rogpeppe> gary_poster: it's potentially an interesting style of versioning
[13:14] <gary_poster> agreed rogpeppe.  A declarative, fine-grained-but-seemingly-not-to-fine-grained approach that would allow  an unambiguous way of asking "hey local juju env, can you do X?" (assuming meanings of methods don't change, which they shouldn't)
[13:15] <rogpeppe> gary_poster: yes.
[13:15] <gary_poster> s/-to-/-too-/ :-P
[13:15] <rogpeppe> gary_poster: and also "does the information for X contain Y"
[13:15] <gary_poster> ooh, true
[13:15] <gary_poster> that would be nice too
[13:17] <gary_poster> jcsackett, big +1 on #1175150.  May I mark that high?
[13:18] <_mup_> Bug #1175150: Fullscreen landing content should vary with sandbox setting <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1175150>
[13:18] <gary_poster> from GUI perspective
[13:18] <rogpeppe> gary_poster: pity it doesn't work for the delta info though
[13:18] <jcsackett> gary_poster: i have no objection, but give your +1 to rick_h_. i was just making a bug for his card. :-)
[13:18] <gary_poster> jcsackett, heh, ok cool :-)
[13:21] <gary_poster> rogpeppe, deltas: nothing in the data structure here preventing that though, yes?  For example, you appear to have data characteristics as keys ("_nullable" and "_map").  You could have some kind of similar story for describing "a list of 1 or more of any of the following."  I suspect it is farther from the existing data structure than the code you have atm though
[13:22] <gary_poster> re _nullable and _map, what happens if you have something that is both _nullable and a _map?
[13:22] <gary_poster> nested structs?
[13:22] <rogpeppe> gary_poster: it's a different issue than that - i'm generating the info from the Go data types, but the Go data type in this case is an interface - there's no way of knowing what objects it might hold
[13:22] <rogpeppe> gary_poster: yeah
[13:23] <rogpeppe> *map[string]int would look like {"_nullable": {"_map": "number"}}
[13:23] <rogpeppe> gary_poster: it should be more intelligent about pointers actually.
[13:23] <rogpeppe> gary_poster: 'cos a map is naturally nullable anyway
[13:23] <rogpeppe> gary_poster: and json treats ***int the same as *int
[13:24] <gary_poster> rogpeppe, nested structs: gotcha. different issue: yeah, I can see, but my point was that you can assemble the data structure from multiple sources--if the end goal is something consumable then having it be pure interface analysis is unnecessary. domain knowledge is AOK
[13:25] <gary_poster> as long as the multiple sources don't potentially stomp on one another, which is the (slightly?) tricky bit I see atm
[13:26] <rogpeppe> gary_poster: yeah, it needs a bit of thinking about. i think that it's good that the generation is as automatic as possible though.
[13:27] <rogpeppe> gary_poster: otherwise description will rapidly lose sight of reality
[13:28] <gary_poster> rogpeppe, strongly agreed generally.  But the delta structure really ought to be in there, I think, for the goals we want out of this.  OTOH, I'd be a big +1 for getting this general pattern in the code base without the delta information, as long as we knew we could slide the delta information in later.
[13:28] <bac> gary_poster, rick_h_: textarea resizer and tests now in our tree and happy.  ready for review at https://codereview.appspot.com/9077043
[13:29] <gary_poster> bac, looking, great.  rick_h_ is it a bg deal to get these in the YUI gallery or something?  Never done that
[13:31] <rogpeppe> gary_poster: perhaps in addition to the method descriptions, we could include a map from interface (or custom marshaller) type name to a set of possible actual types
[13:31] <gary_poster> bac LGTM
[13:32] <gary_poster> rogpeppe, that would be nice.  So, completely separate data structure, IIUC?
[13:32] <rogpeppe> gary_poster: then the API server would be responsible for filling in the set of types (it would know the set of possible delta types, for example) but everything else would still be automatic
[13:32] <gary_poster> right
[13:32] <rogpeppe> gary_poster: yeah; perhaps at the top level, to avoid another level. "_types": { .... }
[13:33] <rogpeppe> gary_poster: alongside Client and Admin etc
[13:33] <rick_h_> gary_poster: it's a little bit of work. The format/tests have to be in a certain way and they were changing that tooling. hatch might be up on it more. I got one into the gallery under the old tooling and it took a few days.
[13:34] <gary_poster> sounds very good to me rogpeppe.  
[13:34] <bac> gary_poster: thanks.  process-wise, i guess we could've explicitly reached out to the local JS experts, rick and sinzui, and they would've certainly pointed us in the right direction.  also, a more detailed discussion of the work we're each doing during the daily call.  i think you and i spoke in very vague terms b/c *we* knew the task but we didn't broadcast it so no one had a chance to contribute ideas.
[13:35] <gary_poster> rogpeppe, do you have any idea on whether this might land soonish?  It would be nice for Makyo to rely on.
[13:36] <gary_poster> rogpeppe, don't need the types for his use case FWIW
[13:36] <gary_poster> rick_h_, urgh, a few days is a long time. :-/ ok, thanks
[13:36] <rogpeppe> gary_poster: i've no idea tbh. i just remembered it this morning and it wasn't what i was meant to be doing at all :-)
[13:37] <rogpeppe> gary_poster: i'd need to run the idea past william, who wasn't that keen last time i mentioned it, but we'll see
[13:38] <gary_poster> rogpeppe, lol ok.  We do need an answer for "do we show the upgrade charm UI or not?" so we'd like this or some other solution soon.  Would it be worth me asking for some of William's time in this regard, or do you have another suggestion?
[13:39] <gary_poster> bac, the "local" JS experts might include some U1 people too, as well as deryck, depending on our definition of local.  mm.
[13:40] <rogpeppe> gary_poster: one possibility would be to actually try to make an upgrade-charm call (with invalid args). if you get a "no such request" error, you know it's not implemented
[13:40] <gary_poster> rogpeppe, #1160971
[13:40] <gary_poster> come on _mup_...
[13:40] <gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1160971
[13:40] <_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1160971>
[13:40]  * rogpeppe was waiting for mup too
[13:41] <rogpeppe> gary_poster: hmm, i thought i'd fixed that
[13:41] <gary_poster> oh, that would be great!  we were just going by the bug :-)
[13:42] <rogpeppe> aargh, why does pastebin.ubuntu.com discard its pastes?
[13:42] <gary_poster> bac, I'll make a retrospective card with your notes.  thank you
[13:42] <rogpeppe> that makes it a really terrible medium for attaching data to bug reports
[13:42] <gary_poster> ah, argh, good point
[13:43] <bac> thanks gary_poster
[13:44] <rogpeppe> lunch time
[13:44] <gary_poster> :-) ttyl
[13:50] <rick_h_> gary_poster: yea, I knew you guys were working on something but I kept hearing about html. rte/YUI editor and you mentioned trouble of parsing down html to plain text or something. So I thought you guys were doing something more complex related to html edit
[13:50] <rick_h_> gary_poster: and I didn't get too nosy about it until I saw bac's branch come by my email
[13:51] <gary_poster> rick_h_, completely understandable.  We appreciate you looking at the branch when you did.
[13:54] <hatch> morning
[13:55] <gary_poster> morning hatch
[14:00] <bac> rick_h_: could you do a review of my branch.  should look mighty familiar!  :)
[14:00] <hatch> still lf one more review https://codereview.appspot.com/9035045/  plz :)
[14:01] <bac> hatch: i will
[14:01] <hatch> thank yas
[14:08] <bac> hatch: done
[14:08] <hatch> awesome
[14:09] <hatch> gary_poster: new _buildServiceView thoughts? http://bazaar.launchpad.net/~hatch/juju-gui/view-promises/view/head:/app/app.js#L528
[14:10] <hatch> I'm not sold so that's why I'm asking now :)
[14:10] <gary_poster> :-) trying to regain context...
[14:10] <hatch> that method is called anytime you visit a /service url to render the various service views
[14:11] <hatch> this branch now uses promises for the service views and throws a notification if it's deleted while you're viewing it
[14:14] <gary_poster> hatch, I suggest always using a promise.  I don't think the flash will be too bad.  From a UX perspective do you disagree?  Should I give it a try myself?  (To be clear, I mean http://pastebin.ubuntu.com/5622712/or similar)
[14:14] <hatch> yeah the flash is pretty irritating
[14:15] <gary_poster> ok, lemme look.
[14:15] <hatch> you can see it by just removing the model param
[14:16] <hatch> to really get the full annoyance change between the service views
[14:16] <gary_poster> ack, getting branch
[14:19] <gary_poster> heh, commenting out model param alone means it never renders.  trying fulling change...
[14:19] <gary_poster> fuller
[14:21] <hatch> er sorry
[14:21] <hatch> comment out the ifblock leaving only the promise being assigned
[14:21] <gary_poster> yeah np I see it.  looking further
[14:24] <rick_h_> bac: can look at it. I was avoiding it as I was worried I'd be biased :P
[14:24] <bac> i don't think bias will be a problem
[14:24] <bac> thanks
[14:24]  * gary_poster agrees
[14:26] <hatch> rick_h_: I frequently look at old code I've written and go "what is this sh*t, who wrote this???"
[14:26] <hatch> lol
[14:26] <rick_h_> hatch: yea, I was feeling good when bac thought my old code was ok. Usually it's  more "who can I kill for this...oh right..."
[14:26] <hatch> haha
[14:28] <gary_poster> hatch brainstorm with me in guichat?
[14:29] <hatch> sure
[14:30] <rick_h_> bac: r=me, one comment
[14:30] <bac> rick_h_: thx
[14:33] <bac> rick_h_: i think i'll just modify the comment to be more generic.  the file is not a pristine copy as i had to change the namespace to juju.plugins.  i'll update the initial comment to reflect that as well.
[14:35] <rick_h_> bac: cool thanks
[15:40] <hatch> gary_poster: using showView we can set render: false at which point we can control the render cycle from within the view....ala problem solved
[15:41] <hatch> we can move that 100ms uglyness into the view
[15:50] <gary_poster> jujugui kanban now, call in 10
[16:02] <gary_poster> bcsaller_, call now
[16:10] <bac> was my camera working on that call?
[16:11] <gary_poster> bac yes
[16:11] <bac> huh, it showed my 404 icon to me
[16:11] <bac> hope i didn't do anything rude
[16:11] <gary_poster> :-) not that I saw
[16:36] <rick_h_> doh, bac ran now
[17:07] <rick_h_> bac: did you still want to chat?
[17:08] <bac> rick_h_: i don't think so.
[17:08] <rick_h_> bac: cool
[17:08] <bac> thanks though.  i may bug you if i run into integration probs
[17:08] <rick_h_> bac: sure thing, just say the word
[17:08] <bac> grease?
[17:09] <rick_h_> got that
[17:09] <rick_h_> lithium ok?
[17:09] <bac> "Grease is the word.
[17:09] <rick_h_> ah, thought it was bird
[17:09] <bac> or so says john travolta and olivia newton john
[17:10] <hatch> the bird is the word
[17:11] <hatch> the bird is the word
[17:11] <hatch> the bird is the word
[17:11] <hatch> the bird is the word
[17:11] <hatch> the bird is the word
[17:11] <bac> ok, googling "is the word" the first two hits are "bird is the word" and "grease is the word", in that order
[17:12] <rick_h_> lol
[17:12] <bac> so, you crowd followers can go with bird if you want
[17:12] <bac> i'm sticking with grease
[17:12] <hatch> I've never heard 'grease is the word'
[17:13] <rick_h_> hatch is to young for grease 
[17:13] <hatch> I think I've seen it once
[17:14] <hatch> I have a very hard time seeing our local gangsters breaking out into song
[17:19] <jcsackett> the local gangsters here don't sing; but they do occasionally snap their fingers in time and break out into complex street dances.
[17:24] <hatch> and I bet those bastards interrupt traffic while they are doing it too.....ugh....youths!
[17:40] <bac> i have yet to see any dancing thugs here in puerto rico.  false advertising if you ask me.
[17:41] <hatch> gary_poster: fixes the env rendering and adds the promises into the buildserviceview http://bazaar.launchpad.net/~hatch/juju-gui/view-promises/revision/635
[17:42] <jcsackett> hatch, rick_h_: can i get a review on the this very short branch? https://codereview.appspot.com/9088043
[17:43] <rick_h_> jcsackett: sure thing
[17:43] <jcsackett> thanks!
[17:46] <hatch> yup
[17:48] <hatch> jcsackett: so this fixes the scrolltop issue you were saying before?
[17:50] <rick_h_> jcsackett: just one note. I'm assuming I know why you did it but small request. 
[17:53] <rick_h_> gary_poster: I've got the ec2 setup with the test branches from abentley and I here: https://pastebin.canonical.com/90353/
[17:53] <rick_h_> gary_poster: let me know when you get a chance and we can test things out.
[17:56] <rick_h_> abentley: looks like /interseting goes down to around 180kb before gzip. icons are all sub 100ms here. Probably longer when it's on prodstack in london but cool
[17:59] <abentley> rick_h_: Nice.  And we should get some caching from Apache too in production.
[18:01]  * benji takes lunch.
[18:07] <gary_poster> rick_h_, lemme get a review done and then I will hack on the demo to get that set up
[18:07] <gary_poster> actually two reviews done :-)
[18:08] <rick_h_> gary_poster: cool, giong to lunch it up myself
[18:08] <gary_poster> great
[18:08] <rick_h_> wow, 2pm where did today go? 
[18:10] <gary_poster> hatch, checkShowEnvOrBrowser feels kinda hacky but fine as intermediate step/working with existing code.
[18:11] <gary_poster> hatch otherwise looks really nice to me
[18:11] <hatch> gary_poster: yeah I figure we need some type of a controller method for there
[18:12] <gary_poster> hatch, why can't we just use a slash route for env view, as you said on call?
[18:12] <hatch> because / still fires on /:gui: routes :)
[18:13] <gary_poster> hatch, so?  env view would be registered for :gui:/ .  Probably missing something, but want know know what it is :-)
[18:14] <hatch> well /:gui:/service/memcache still fires the / route because / is charmstore
[18:14] <hatch> so if we put env on / then it's always rendered
[18:14] <hatch> just like with *
[18:15] <gary_poster> hatch does /:gui:/service/memvcache fire /:gui:/ ?
[18:15] <hatch> not sure....sec i'll cehck
[18:17] <hatch> doesn't appear to
[18:17] <hatch> nor does path: '/', namespace 'gui'
[18:17] <gary_poster> hatch, so can we register env view for that?
[18:18] <hatch> that's exactly when we don't want it to render though
[18:18] <gary_poster> huh? :-)
[18:18] <hatch> we only want to env to render when it's not /service /charm/ or /logout
[18:19] <gary_poster> hatch, but...guichat  :-)
[18:19] <hatch> haha ok
[18:20] <bcsaller_> hatch: by render you mean call topo.update()?
[18:27] <hatch> nope, bcsaller_ can you join guichat?
[18:50] <jcsackett> rick_h_: just played around and i cannot tell you how much better things feel with the spinner overlay. :-)
[18:51] <rick_h_> jcsackett: :)
[18:51] <jcsackett> hatch: sorry i missed your earlier message, yeah, this sorts what i was talking about.
[18:51] <rick_h_> small touches, trick the user's mind. Love those kinds of things
[18:51] <jcsackett> hatch: just scrolls an element that wasn't in the visible region to the visible rather than figuring out how to reset the scroll value for the view's node.
[18:56] <jcsackett> rick_h_: i hear that. :-)
[18:56] <jcsackett> and clearly my mind is happy to be tricked. :-P
[19:11] <hatch> jcsackett: yeah that's very odd
[19:11] <hatch> I have no idea why it wasn't scrolling to the top
[19:13] <hatch> ok review is done /me going back to finish eating :)
[19:15] <benji> hazmat: do model objects keep any kind of history or log of previous attribute values?
[19:17] <bcsaller_> benji: model change events will have the old and the new values I believe but I also think that when that event has fired the info is gone
[19:17] <benji> yeah I saw that, that's what made me wonder about them keeping more (I'm tracking down a memory leak)
[19:18] <hazmat> benji, in py.  go. or js.  in js per ben's comments
[19:18] <hazmat> have a look at  yui app model changed event
[19:19] <hazmat> http://yuilibrary.com/yui/docs/api/files/app_js_model.js.html#l30
[19:20] <benji> hazmat: are you saying that they do keep all previous values, or that if they do that would be where to find out?
[19:21] <hazmat> benji, in js. its transiently.. the previous value is attached to the event, its not kept, as the soon event is gc'd its gone. if something is capturing/saving model change events, that would be an issue
[19:22] <benji> gotcha
[19:25] <hatch> benji: are you doing snapshots in chrome?
[19:26] <hatch> benji: you can also watch the timeline for memory
[19:26] <benji> I've played with them a little, but not used them in anger yet.  If you have experience with them a consult would be welcome.
[19:26] <hatch> it can give you an indication of what's growing
[19:26] <benji> I can't get the timeline to work.
[19:27] <hatch> you have to hit the record button :)
[19:29] <benji> hatch: you're psychic!
[19:29] <hatch> lol yeah? why's that?
[19:29] <gary_poster> bcsaller_, prelim review done.  call now.  will qa after.  at least one important note I think though
[19:30] <rick_h_> benji: hatch there's also the speed tracer exention that's awesome
[19:30] <bcsaller_> gary_poster: cool, thank you, reading now
[19:30]  * rick_h_ tries to recall if that does memory
[19:30] <rick_h_> nvm, don't see real memory usage there, just kind of UX slowness indicators
[19:30] <hatch> yeah I think all of that stuff might be in the native tools now
[19:34] <hatch> benji: really the first step to debugging a memory leak in js is the profiler and timeline
[19:34] <hatch> so I can give you a hand to get started there if you need
[19:35] <rick_h_> hatch: jcsackett review time if you get a sec please? https://codereview.appspot.com/9099043
[19:35] <benji> hatch: I'm up for a hangout any time
[19:35] <hatch> ok just going to commit this code I'm working on now
[19:35] <hatch> couple minutes
[19:36] <benji> sounds good
[19:48] <hatch> benji: ok guichat?
[19:48] <benji> hatch: sure, I'll be there in a second
[19:55] <benji> hatch: that was a long second :) there now
[20:00] <jcsackett> rick_h_: lgtm; this branch resolves both of your cards, right?
[20:02] <rick_h_> jcsackett: right
[20:16] <rick_h_> jcsackett: hatch or anyone else around to just peek at a small review/check? https://codereview.appspot.com/9101043
[20:16] <rick_h_> extremely weak shot in the dark :)
[20:22] <benji> gary_poster: I can give you the latest on memory leaks any time
[20:22] <gary_poster> ack on calls thanks
[20:27] <bac> hi rick_h_
[20:34] <rick_h_> bac: howdy
[20:35] <bac> rick_h_: hey, i think i'm ok.  i was surprised to see two hidden clones created by the resizingtextarea.  now i see there is a separate one for single_line
[20:35] <bac> rick_h_: http://paste.ubuntu.com/5623854/plain/
[20:36] <rick_h_> bac: hmmm, thinking
[20:37] <bac> note they both have opacity:0 but one has a width and the other doesn't
[20:37] <rick_h_> bac: could there be something where it's run twice and Y.all(textarea) grabs the mirror?
[20:37] <bac> it's ok, i was just surprised
[20:37] <rick_h_> bac: yea, so am I
[20:37] <bac> perhaps.  this is in a test.
[20:38] <rick_h_> bac: checking LP to see if that's true there. 
[20:38] <rick_h_> bac: yea, in LP there's only the two
[20:38] <rick_h_> https://bugs.launchpad.net/juju-gui/+filebug for instance
[20:38] <rick_h_> bac: so I'd expect that to be left over test cruft or something 
[20:39] <bac> ok
[20:47] <rick_h_> bac: any chance I can rope you into a second review? https://codereview.appspot.com/9099043/
[20:48] <bac> rick_h_: in a sec, yes
[20:48] <rick_h_> bac: ty 
[20:58] <bac> rick_h_: looking now.
[20:59] <gary_poster> must run benji
[20:59] <gary_poster> sorry
[20:59] <benji> gary_poster: no worries, I'll catch you tomorrow
[21:06] <bac> rick_h_: done
[21:07] <rick_h_> bac: thanks
[21:07] <bac> rick_h_: your LP example regarding the textarea does not have any that are marked 'single_line' i don't think.  it may be that either the test is creating an extra or the use of 'single_line' is doing it
[21:08] <bac> rick_h_: is there any good way to write a CSS selector that would just get the real one?  i don't see how, as currently written.
[21:08] <rick_h_> bac: lokoing
[21:09] <rick_h_> hmm, can't find your review url in my list
[21:09] <rick_h_> bac: do you have the review url handy? Or just an easy way to view source?
[21:11] <bac> rick_h_: https://codereview.appspot.com/9077043 ... it was linked from the card on the kanban board.  (not always true, though)
[21:11] <rick_h_> bac:  ah thanks
[21:11] <bac> rick_h_: one of my tests does this, and pulls in the clones
[21:11] <bac>  textareaControls = container.all('.control-group textarea.config-field');
[21:12] <rick_h_> bac: so couple of ways. originally you do a Y.all('textarea').plug...?
[21:12] <rick_h_> bac: so you can store that Y.all result list for a reference to the non-clones
[21:12] <bac> rick_h_: something like that
[21:13] <bac> could do
[21:13] <rick_h_> bac: maybe the better thnig would be to stick a class on the clone node that's something like .juju-clone-xx
[21:13] <bac> yeah, i think so
[21:13] <rick_h_> bac: or better yet, set an attribute. data-text-area-clone="yuid of original node"
[21:14] <rick_h_> than you can select Y.all('textarea["data-text-area-clone"])
[21:14] <rick_h_> as well as match the clone to the originally
[21:15] <rick_h_> bac: but yea, looking at the code you're right. 
[21:15] <rick_h_> bac: the _get_single_line_height does another clone
[21:15] <bac> ah, ok
[21:15] <rick_h_> bac: maybe a better fix would be that it would destroy the single line clone once it got the height value? 
[21:17] <rick_h_> bac: so submitted a comment to that MP with a potential/suggested fix for this specific issue. Though I think the class stuff might be helpful one day, but might be YANGNI for now
[21:18] <bac> rick_h_: ok, but that branch is landed.  i may port your comment over to my next MP
[21:18] <rick_h_> bac: right sorry just used it more like a pastebin pointed at the right place in the file :)
[21:18] <bac> cool
[21:34] <hatch> before I go looking does anyone know why unit views are called 8 times?
[23:56] <rick_h_> hatch: still around?