[12:09] <gary_poster> frankban, teknico, approved all days off.  good timing for those national holidays :-)
[12:10] <frankban> gary_poster: thanks, and yes, really :-)
[12:15] <gary_poster> frankban: Firefox: test_gui_unit_tests (__main__.TestBasics) ... ok
[12:15] <gary_poster> YAY!  Rock! :-)
[12:15] <gary_poster> Finished: SUCCESS
[12:16] <bac> :0
[12:16] <bac> er, :)
[12:16] <gary_poster> :-)
[12:17] <bac> hazmat: i'm investigating bug 1170468 -- you have insight?
[12:17] <frankban> cool, and weird, but cool...
[12:52] <hazmat> bac, i filed a separate bug.. the nutshell was that setting config/deploying from the gui lead to invalid yaml somehow
[12:53] <hazmat> bac, a user tried to deploy haproxy from the gui
[12:53] <hazmat> the backend server does yaml validation, so its not clear why it didn't result in an error
[12:53] <hazmat> instead it lead to a relation error on the broken yaml
[12:53] <hazmat> deploying from the cli worked
[12:57] <bac> hazmat: do you have that bug number?
[13:00] <hazmat> bac, hmm.. no i might have seen jorge's and stopped.
[13:01] <bac> ok
[13:36] <hatch> gooood morning
[13:37] <gary_poster> morning hatch.
[13:37] <hatch> thanks for the review
[13:37] <hatch> sorry there were so many steps to reproduce :)
[13:37] <gary_poster> welcome, np :-)
[13:37] <hatch> how was camping?
[13:38] <gary_poster> great! and exhausting :-)
[13:39] <gary_poster> frankban, I was thinking of testing the gui against go (monday qa), and then making a release.  does that duplicate anything you've done or are doing?
[13:40] <hatch> frankban: haha, awesome fix for the CI failures :D
[13:40] <frankban> gary_poster: no, and I am available if you need help, e.g., setting up the env or similar
[13:40] <gary_poster> cool thanks frankban.
[13:42] <frankban> hatch: heh, one loc to fix them all... something in the firefox/selenium/yui ecosystem seems very opaque
[13:45] <jcsackett> sinzui, hatch: can i get a review on https://codereview.appspot.com/8910043 ?
[13:45] <hazmat> bac, just to be clear for reproduce.. bootstrap/deploy gui/deploy haproxy from gui
[13:45] <bac> hazmat: yep
[13:46] <hatch> jcsackett: ....well I dont' start for another 15minutes....
[13:46] <hatch> sooooooo joking....I'm on it :P
[13:46] <jcsackett> hatch: if you want to wait 15 min, that's fine. :-)
[13:46] <hatch> lol
[13:46] <hatch> I am going to grab my coffee first though
[13:48]  * sinzui looks
[13:48] <jcsackett> hatch: very reasonable. :-)
[13:48] <jcsackett> actually, i'm going to get some coffee as well.
[13:55] <gary_poster> frankban, if you are interested in finding a card I have one that might be of interest to you.  "Investigare adding SetUnits to Go API (replacing AddUnits and RemoveUnits in the GUI)."  Whoever starts this would want to talk to Roger first, of course
[13:55] <gary_poster> *Investigate
[13:55] <gary_poster> It is in Maintenance
[13:56] <gary_poster> other options are fine too :-)
[13:57] <frankban> gary_poster: sounds good. so SetUnits takes a service name and a number of units?
[13:58] <gary_poster> frankban, exactly.  And delats + GetService would report not only how many services a unit has but how many it is supposed to have
[13:58] <gary_poster> *how many units a service has
[13:59]  * gary_poster had three nights of bad sleep in a row :-)
[13:59] <gary_poster> sigh, delats == deltas :-)
[14:00] <frankban> gary_poster: but what happens when a service has more units than the ones specified? do we remove random units?
[14:01] <gary_poster> frankban, this is something to discuss with Roger.  When talking about it with Kapil for pyJuju, he suggested removing the newest instances.  I think arguments could be made for either direction (oldest or newest).
[14:02] <gary_poster> Maybe a default policy for flags for other policies would be nice, but also maybe not necessary initially
[14:02] <gary_poster> ...a default policy *and* flags for other policies...
[14:03] <frankban> gary_poster: :-) doesn't the delta already include pending units in the count? 
[14:03] <frankban> (I think I have to check for this) gary_poster: last question, following the checklist: why do we want this? :-)
[14:08] <gary_poster> frankban, delta has pending units: yes, but that's different that the target.  The target should be a single number with transactional semantics.  pending units can easily have race conditions.  Imagine having 5 units, then setting count to 8 (three pending), then *immediately* (before pending units resolve) setting the unit count to 3.  removing units is not instantaneous.  At this point we want to be able to say "
[14:08] <gary_poster> the target is 3" but if we don't explicitly keep track of the target there are a lot of confusing intermediate states we can see.
[14:08] <gary_poster> frankban, thank you for asking why, and why now. :-) that might clarify the previous answer
[14:08] <gary_poster> I actually think there's an old bug for this, come to think of it.  1 sec...
[14:11] <gary_poster> frankban, #1052675 and #1052676
[14:11] <gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1052676
[14:11] <gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1052675
[14:12]  * gary_poster misses _mup_
[14:12] <benji> I hate to admit it, but I miss mup a little.
[14:13] <gary_poster> :-)
[14:14] <gary_poster> frankban, those are all in reference to the unit count widget on the service page, if that is not clear
[14:16] <gary_poster> frankban, lemme know if that makes sense--stopping until you ask more
[14:18] <frankban> gary_poster: yes it does. And I think we also want to maintain the old AddUnits/RemoveUnits, event if they will be no longer used by the GUI
[14:19] <gary_poster> frankban, +1.  A complication will be that we need to use the old API for pyJuju.
[14:19] <gary_poster> and try not to make it more broken than it already is
[14:20] <gary_poster> frankban, an additional complication is that this is the first time we will need to be backwards compatible in the Go API as well!
[14:20] <gary_poster> I think
[14:21] <gary_poster> we should discuss with them what we all think is a reasonable support strategy for these sorts of things
[14:21]  * teknico 's mental state aligned with nation's one: thoroughly befuddled
[14:21] <gary_poster> :-)
[14:21] <gary_poster> teknico, about what I've said, or about your current card, or generally?
[14:22] <teknico> gary_poster, second thing you said
[14:22] <frankban> gary_poster: yes. so setunits set a target number (on the service doc I guess). if another client (not the GUI) calls addunits/removeunits I suppose we might want to increase/decrease that number accordingly. 
[14:22] <gary_poster> teknico, ack.  
[14:23] <gary_poster> frankban, yes.  And Roger said that this will involve a new agent IIRC
[14:23] <gary_poster> To handle converting the number to a reality
[14:24] <frankban> gary_poster: ok thanks
[14:32] <frankban> rogpeppe2: could you please ping me when you have time for a call on the SetServiceUnit functionality?
[14:56] <Makyo> gary_poster, ping
[14:56] <gary_poster> Makyo, pong (though I have call in 4)
[14:57] <Makyo> gary_poster, quick ? then.   Was looking at starting upgrade-charm, but that's not in either juju api. Are we making any changes to pyjuju anymore?
[14:57] <gary_poster> Makyo, no more changes to pyjuju AFAIK
[14:58] <Makyo> gary_poster, alright.  Will come up with a list of other questions for call.
[14:59] <gary_poster> Makyo, cool.  Also maybe worth convening a call with luca and myself when you are ready to have a plan for integration within the current transient UX.  It is not in the 13.10 UX either, but I want the functionality in sooner
[14:59] <hatch> does anyone know (before I go looking) why the environment fires a 'login' event again 5s or so after the environment is fully loaded
[15:00] <Makyo> gary_poster, alright.
[15:02] <gary_poster> hatch, not exactly but I've seen stuff like that caused by...on call.  maybe needs flag
[15:06] <gary_poster> frankban, maybe try rogpeppe again?
[15:06] <frankban> gary_poster: talking with him
[15:06] <gary_poster> oh cool
[15:14] <hatch> i have noticed that sometimes I get a favicon which is bright orange and sometimes it's kind of a washed out orange...anyone ever seen this before?
[15:18] <hatch> rick_h_: I saw your post on G+ about the yui2 removal....yay!
[15:26] <gary_poster> bcsaller, hey.  Could you please add categories metadata to your charm branch?  http://pastebin.ubuntu.com/5592852/
[15:26] <bcsaller> gary_poster: certainly
[15:26] <gary_poster> thank you!
[15:28] <hatch> bcsaller: when you have a second could you take a look at my multi dispatch branch https://codereview.appspot.com/8883043/
[15:28] <bcsaller> hatch: I'll do it now, I've already glanced at it
[15:28] <hatch> ok great thanks
[15:30] <jcsackett> hatch: to make sure i understand your suggestion about the utils thing being an extension. do you mean just create like apiFailingView, which extends view with the apiFailure method? and have other views use that as an extension?
[15:30] <jcsackett> or something more like rick's event tracker?
[15:30] <jcsackett> (e.g. a whole new object)
[15:32] <hatch> jcsackett: can't remember the event tracker...one second
[15:32] <hatch> yep just like that
[15:33] <frankban> gary_poster: time for a call?
[15:33] <gary_poster> frankban, still on another call.  will ping when off
[15:33] <frankban> gary_poster: thanks
[15:33] <hatch> jcsackett: do you see why I don't think it is a utility method?
[15:33] <hatch> an utility method?
[15:33] <hatch> that just doesn't sound right...
[15:33] <hatch> a utility method
[15:33] <hatch> :)
[15:34] <jcsackett> hatch: yeah, i'm fine with that--i'm just talking about implementing it as an extension.
[15:34] <hatch> ahh yeah - you can look at the event tracker or the subapp extension
[15:34] <jcsackett> ok.
[15:35] <hatch> basically you have to create a constructor so that the mixin methods know how to mix them together
[15:41]  * hatch wonders if we have a problem when you needmore lines of documentation than the code is long to explain why it's there :)
[15:43] <Makyo> Explain your spooky action from a distance. :)
[15:46] <hatch> maybe I'll start commenting // because multi-dispatch
[15:46] <hatch> and everyone will just know
[15:46] <hatch> lol
[15:47] <Makyo> HAh
[15:47] <hatch> I'm very confused about this extra 'login' event, I don't even know where it's being fired from...
[15:50] <gary_poster> jujugui please update kanban
[15:52] <hatch> benji: as soon as I get the email i'll qa
[15:52] <hatch> email has been very slow for me today though...
[15:52] <benji> thanks hatch
[15:52] <benji> hatch: here is the URL: https://codereview.appspot.com/8909044
[15:53] <hatch> bcsaller: thanks for the review!
[15:53] <hatch> benji: thanks
[15:59] <gary_poster> jujugui call in 1
[16:10] <Makyo> hatch, you can branch from your local repo, then lbox submit -for=lp:juju-gui; one way to do it.
[16:11] <hatch> oh ok cool, then it will have a proper diff?
[16:11] <Makyo> hatch, I believe so, but someone correct me if I'm wrong. the diff is part of the merge proposal, which only takes into account the submit branch.
[16:12] <hatch> ahh ok
[16:14] <Makyo> hatch, sorry, that should be lbox propose -for=lp:juju-gui, not submit.
[16:20] <hatch> alrighty, notes
[16:20] <hatch> noted*
[16:32] <bac> gary_poster: i've figured out the problem.  would like to chat about solution.
[16:32] <gary_poster> bac ack will ping
[16:33] <hatch> bcsaller: just FYI - yes I could just return the _navigate call but it's return value is pretty hidden under a number of levels of abstraction so if it's ok I'd like to leave as-is. I did remove the navigate() overwite though as it's no longer needed
[16:43] <bac> gary_poster: bug 1170468 is updated.  perhaps we can talk after lunch?
[16:43] <gary_poster> bac +1
[16:49] <gary_poster> Makyo, are you blocked?  If you are not I will ping you in about an hour
[16:49] <Makyo> gary_poster, blocked on the GUI side, but I can start the core branch.
[16:50] <gary_poster> Makyo, would five min now help, or just wait till a bit later?
[16:51] <Makyo> gary_poster, the core branch is pretty clear-cut (as much as it can be), can wait.
[16:51] <gary_poster> cool Makyo thanks.  will ping
[17:00] <Makyo> It's snowing again >:E 
[17:00] <Makyo> Everything just melted over the weekend.
[17:13] <arosales> gary_poster, do you have your staging URL handy?
[17:14] <gary_poster> arosales, what do you mean?  http://uistage.jujucharms.com:8080/
[17:20] <arosales> gary_poster, yes, it looks like this is just specific to the gui, thanks.
[17:21] <arosales> I guess the other URLs are for feature flags turned off/on.
[17:21] <arosales> gary_poster, thanks.
[17:21] <gary_poster> arosales, exactly.  welcome
[17:33]  * benji remembers to do the pre-branch checklist.
[17:42]  * hatch thanks benji for saving lives
[18:05] <hatch> bzr question - is there a way to find out which trunk revision I branched my current branch off of?
[18:05] <benji> is anyone familiar with this test failure on the charm trunk? http://paste.ubuntu.com/5593324/
[18:06] <hatch> benji: sorry never seen that one before
[18:06] <gary_poster> bcsaller, see benji ^^^
[18:08] <gary_poster> Makyo, guichat
[18:08] <gary_poster> ?
[18:10] <Makyo> gary_poster, sure.
[18:10] <gary_poster> cool
[18:25] <bcsaller> benji: uncertain how that happened, but I can check it in the branch I have going
[18:27] <hatch> taking lunch
[18:27] <gary_poster> bac, can talk whenever you are ready
[18:27] <bac> gary_poster: ok
[18:27] <bac> now is good
[18:28] <gary_poster> bac ok guichat!
[18:52] <gary_poster> bac, fwiw in juju-core/charm/config.go:
[18:53] <gary_poster> http://pastebin.ubuntu.com/5593455/
[18:53] <gary_poster> bac ^^
[18:54] <bac> gary_poster: so it would be trivial to support 'text' in the future
[19:00] <Makyo> Running to coffee shop to leave dogs alone.
[19:02] <benji> bcsaller: (I'm back from lunch) I would appreciate it if you can check that failure.
[19:03] <bcsaller> benji: I suspect my review changes went in w/o running the suite 
[19:29] <gary_poster> benji, are you blocked by that charm problem?  It looked like teknico was blocked by some issues in the charm right now
[19:29] <benji> gary_poster: nope, I'm pretending the tests pass; seems to be working ;)
[19:30] <gary_poster> benji :-P ok
[19:39] <hatch> is uistage broken?
[19:40] <hatch> oh someone must have just deleted everything
[19:40] <hatch> http://uistage.jujucharms.com:8080/:gui:/service/wordpress/constraints/
[19:41] <hatch> has that entry point always been broken?
[20:01] <hatch> is there a way I can check from a view if Landscape is enabled?
[20:02] <hatch> jujugui ^
[20:03] <Makyo> hatch, var env = this.db.environment.get('annotations'); if (env['landscape-url'])...
[20:04] <Makyo> app/views/landscape.js:113
[20:04] <gary_poster> hatch, that entry point works for me--it just shows the environ first.  benji might have filed a related bug, not sure
[20:04] <hatch> but that will only happen if a delta is fired though no?
[20:04] <gary_poster> Makyo, doesn't the landscape object offer some kind of abstraction for that as well?
[20:05] <benji> hatch: topo.get('landscape') looks like the easiest way to see if landscape is enabled
[20:05] <hatch> and topo would be env?
[20:05] <benji> hatch, gary_poster: yep, I filed a bug about it
[20:05] <gary_poster> thx
[20:05] <Makyo> topo is the topology in the environment view.
[20:05] <benji> it is caused by bug 1170031
[20:05] <Makyo> and topo.get('landscape') returns the landscape view.
[20:06] <hatch> ok so if I go env.get('topology').get('landscape') it will be undefined if landscape isn't enabled?
[20:07] <Makyo> The topology belongs only to the environment view.
[20:07] <hatch> benji: gary_poster: ok I am rewriting a bunch of this stuff - it appears to solve the console errors on that entry point, and the flash of env
[20:07] <gary_poster> great hatch!
[20:08] <Makyo> get the environment model from the db and see if it has a landscape-url annotation.
[20:08] <gary_poster> sort of like "great scott!" except that it's your nick, not Mako's last name
[20:08] <hatch> haha
[20:08] <hatch> ahhh back to the future, what a great show
[20:08] <gary_poster> :-)
[20:09] <Makyo> Oh, the amount of that I got in high school... :)
[20:09] <gary_poster> lol
[20:10] <hatch> Makyo: making that check doesn't work
[20:10] <hatch> the landscape-url annotation appears to always be there
[20:11] <hatch> i'll try this.get('landscape') as benji mentioned
[20:11] <Makyo> Then line 423 of app/views/utils.js is not valid, which I don't believe is the case.
[20:12] <hatch> by default is it enabled then? on devel
[20:13] <Makyo> hatch, are you running improv or sandbox?
[20:13] <hatch> improv
[20:14] <Makyo> hatch, It is enabled if you're passing -l to improv
[20:14] <hatch> ok here is a little more info...
[20:15] <hatch> on the root service view we call
[20:15] <hatch>       views.utils.updateLandscapeBottomBar(this.get('landscape'),
[20:15] <hatch>           env, service, container);
[20:15] <hatch> which has the check you said
[20:15] <hatch> when I add the same line to the constraints view
[20:15] <hatch> I get an error Uncaught TypeError: Cannot call method 'hide' of null
[20:15] <hatch> which is fine...
[20:16] <hatch> but the issue is that `this.get('landscape')`
[20:16] <hatch> is an object, and the url annotation is there
[20:18] <Makyo> So the attribute landscape is overloaded with an annotations object instead of being the landscape extension?
[20:19] <hatch> the attribute landscape is an instance of views/topology/landscape.js
[20:20] <Makyo> I guess I'm a little confused.  You just said it was an object with the URL annotation.
[20:22] <hatch> sorry, what I meant was the env.get('annotations')['landscape-url'] property exists and there is an instance of the landscape d3module even though landscape is not enabled
[20:22] <hatch> so both mentioned techniques don't give me a way to reliably check if landscape is enabled
[20:24] <Makyo> hatch, I broke on the render function for service constraints view and: this.get('db').environment.get('annotations')['landscape-url'] [20:25]  * gary_poster thinks we ought to have a shared abstraction (like a function) for that
[20:25] <Makyo> That could be part of the landscape extension, yeah
[20:25] <hatch> Makyo: that's so odd because the updateLandscapeBottomBar method is throwing an error from within that if check
[20:26] <hatch> ohh, I figured it out
[20:26] <hatch> heh
[20:26]  * hatch bows head and sulks into a corner
[20:27] <hatch> thanks for dealing with my stupidity Makyo :)
[20:28] <Makyo> hatch, What was it?  Curious, because now I'm thinking of ways to improve he landscape handling.
[20:28] <gary_poster> Makyo, I'm having another instance of that crazy jumping service (when you start to drag) :-/
[20:28] <Makyo> D:
[20:28] <hatch> container.one('.landscape-controls').hide() was throwing an error and I am apparently dislexic and read the wrong line number
[20:29] <Makyo> gary_poster, sandbox in chrome?
[20:29] <gary_poster> Makyo, no, Go environment in chrome.  Was trying to qa for release :-/
[20:31] <gary_poster> Makyo, reloaded and can't dupe now.  Wonder if it is related to ghost -> drag -> confirm -> drag...
[20:31] <Makyo> gary_poster, Oooh, I didn't try that when I tested.
[20:33] <gary_poster> Makyo, yes!  I made one without the ghost drag and it is fine, and then made one with a ghost drag and it is hosed...
[20:33] <Makyo> gary_poster, A good starting point, then!
[20:33] <Makyo> gary_poster, Maybe reopen that bug with ac omment?
[20:33] <hatch> ok I think I can FINALLY push up this service stuff
[20:34] <hatch> famous last words I'm sure
[20:36] <gary_poster> Makyo, db attrs from bad and good service: see lines 22 and 23 from bad service
[20:36] <gary_poster> http://pastebin.ubuntu.com/5593706/
[20:36] <gary_poster> Makyo, the x and y are being copied over
[20:37] <hatch> yup
[20:37] <hatch> famous last words
[20:37] <hatch> :/
[20:38] <Makyo> gary_poster, http://pastebin.ubuntu.com/5593719/
[20:39] <gary_poster> Makyo, !! cool!  Thanks!
[20:39] <Makyo> gary_poster, I'm not actually running it, but I think that should work?  Does it?
[20:39] <gary_poster> Trying...
[20:41] <Makyo>  Oh, that makes it jump back to the default location.  Hmm.
[20:41] <Makyo> But just temporarily.  Let me see if there's a better way to do it.
[20:42] <gary_poster> Makyo, fwiw, the attrs are copied over when the model is set on the bounding box.  app/views/utils.js line 756
[20:42] <gary_poster> So in theory we could exclude x and y
[20:42] <gary_poster> there
[20:42] <gary_poster> but would be nicer to actually fix it earlier
[20:43] <Makyo> gary_poster, yeah.
[20:44] <Makyo> gary_poster, http://pastebin.ubuntu.com/5593738/ worked for me.
[20:44] <Makyo> After reverting the previous patch
[20:44] <gary_poster> ack trying
[20:49] <gary_poster> Makyo did not work for me.  Digging.  x and y are still set. 
[20:49] <gary_poster> Makyo, bah, code did not refresh
[20:50] <gary_poster> Makyo, +1!
[20:50]  * Makyo would dance, but is in a coffee shop :)
[20:50] <gary_poster> lol
[20:52] <Makyo> gary_poster, Should I make a trivial branch for that, or will it be part of your release stuff?
[20:53] <gary_poster> Makyo, the only thing not necessarily trivial is the test.  Have not investigated yet.  wdyt?
[20:53] <gary_poster> Makyo, reopening bug atm
[20:55] <Makyo> gary_poster, quick check, may be fairly easy.
[20:56] <gary_poster> Makyo, you up for pushing a branch with fix/test through?
[20:56] <gary_poster> My EoD is soon
[20:56] <Makyo> gary_poster, sure.
[20:56] <gary_poster> Thanks Makyo.  Will put into Maintenace Active Code...
[21:12] <Makyo> gary_poster, https://codereview.appspot.com/8750047 (may be past EOD, sorry)
[21:12] <gary_poster> Makyo, looking!
[21:13] <gary_poster> Makyo LGTM, with exclamation marks
[21:13] <Makyo> \o/!
[21:14] <gary_poster> :-)
[21:14] <Makyo> Good to land?
[21:15] <gary_poster> Makyo, sorely tempting, but we can probably get a quick +1 from hatch?
[21:16] <hatch> looking
[21:16] <Makyo> gary_poster, sure.  hatch, 'tis only a wafer thin mp...
[21:16] <gary_poster> :-)
[21:17] <hatch> dun
[21:17] <Makyo> \o/
[21:18] <Makyo> Going to run home once submit finishes.
[21:18] <Makyo> Supid sideways snow.
[21:18] <gary_poster> heh
[21:18] <hatch> yikes - it's sunny and melting here
[21:18] <gary_poster> thank you both
[21:19] <hatch> no problemo, I'm going to propose my WIP branch to get some input but I can't land it until I, or someone fixes the multi login event issue
[21:23] <Makyo> Alright, back in a few.
[22:09] <hatch> I think the only thing worse than writing tests....is fixing tests
[22:09] <hatch> :)
[22:30] <hatch> what's the truck to get the console logging in the tests working again?
[23:04] <rick_h_> huwshimi: howdy
[23:04] <huwshimi> rick_h_: Hey there.
[23:05] <rick_h_> huwshimi: I was out today, under the weather. I tried to keep tabs though
[23:05] <rick_h_> huwshimi: so lots of bugs files from UX folks
[23:05] <huwshimi> rick_h_: Yeah :)
[23:05] <rick_h_> huwshimi: I started to go through a few. If you get a chance can you see about giving them a run through. Some need discussion/comments/clarifications
[23:06] <rick_h_> huwshimi: so I'd like to get our questions/etc ready and lined up for calls tomorrow
[23:06] <huwshimi> rick_h_: A lot were on my to do list anyway, but I'll have a look through them all
[23:07] <rick_h_> huwshimi: yea, bugs make for handy todo list and a good way for them to know where we are so I say let them file away :)
[23:07] <huwshimi> rick_h_: Yeah, it's good.
[23:07] <rick_h_> huwshimi: as for new stuff, I didn't get anything new, but jcsackett was working on landing your branch and had one that started search out
[23:07] <rick_h_> huwshimi: so have fun and let me know if you need anything.  Any bugs I should bring up in calls let me know and I'll make sure we get info.
[23:08] <huwshimi> rick_h_: Yeah, looks like he landed my branch. I have a list of stuff to get through. I'll let you know if I have questions. Thanks Rick.