[01:38] gary_poster: sorry that review resulted in such struggle [12:16] gary_poster: morning [12:16] morning frankban. Thank you for qa'ing and finding those two missing go.js implementations [12:18] gary_poster: thanks for the review. re: the add_unit branch you just reviewed: the GUI requires juju-core AddServiceUnits to return the names of the newly created. Right now the API call just returns an error or nil. If rogpeppe agrees, I'd work on a branch for fixing that in juju-core [12:18] frankban, ah! eek. ok thank you. [12:19] frankban: sounds good. [12:19] yay :-) [12:19] gary_poster, rogpeppe: cool [12:31] jcsackett: is sinzui going to be around today? [12:32] bac: i don't recall him saying anything about not being around. [12:32] bac: yea, he'll be around in the next hour [12:32] thx [12:50] frankban, to be clear, I was wrong about my first comment to the relation id review. I have a few other comments that I think are legitimate but overall LGTM [12:53] gary_poster: ack. And I like your solution (space in rel id) more than my current NaN check. [12:53] cool [12:57] uh-oh: node.js has an update... [12:58] gary_poster: so the question is if the legacy ppa is getting updated then :/ [12:58] * rick_h_ checks if we're still using the legacy ppa due to the broken dep [13:01] gary_poster, rogpeppe: FYI, the authentication works great! [13:01] frankban, yay :-) [13:01] and thanks to rogpeppe! [13:04] * frankban -> late lunch [13:09] frankban: good to hear, thanks! [13:09] frankban: BTW i found out the problem with your service not being destroyed [13:10] rick_h_, we are, according to http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/view/head:/hooks/utils.py#L81 [13:11] teknico: dave cheney said he'd fix it [13:11] rick_h_, do you reckon we could move to the non-legacy ppa and use node 0.13.4 in charm on precise too? [13:12] rick_h_, I'm trying to understand if we can use the same dep versions in the charm and in dev [13:16] rogpeppe, he'd fix what exactly? [13:16] teknico: the fact that the package from the mongo PPA doesn't apt-install correctly under quantal [13:17] teknico: perhaps you're talking about something different though? [13:17] rogpeppe, yeah, it's about the nodejs ppa actually :-) [13:17] teknico: ok, bad assumption... [13:21] teknico: the issue hatch found was that a dep didn't work with the new mongo [13:21] teknico: I'm not sure if he ever figured out which one [13:22] rick_h_, wait, are we talking about nodejs, mongo, or both? :-) [13:22] teknico: nodejs sorry [13:23] teknico: having too many convo's at once [13:23] ok :-) [13:31] To Whom It May Concern: I'm starting bug 1168310. However, there's a decent chance I won't be able to finish it, because I'm booked straight in meetings + lunch starting 11:30 or 12:00. Hopefully somebody (bac, benji?) will be ready to take it from me by then, if I'm not done. [13:32] gary_poster: likely [13:32] cool thanks [13:32] I hope so. [13:32] or Brad will [13:33] hatch, I feel bad that your very impressive efforts on add_relation have proven to be such a bunch of rework. Let me know if you want to pair with someone or somehow have more access to resources. Maybe you could let someone else work on remove_relation? [13:33] gary_poster, time for a quick hangout? I need some more guidance [13:33] sure teknico [13:34] teknico, guichat [13:34] ok [13:35] gary_poster: what is the story with add_relation in fakebackend? is it broken in trunk? [13:36] bac partially implemented [13:36] or did hatch just land a fix? [13:36] gary_poster: it is blocking me from doing what bcsaller requested [13:36] bac, on call will talk soon [13:37] ok [13:42] hatch: ping me when you're around [13:49] bac hi, ready [13:49] bac, IME it works when you add a relation to something that has multiple explicit relations [13:49] like mediawiki -> mysql [13:50] bac, you could work with that, I suspect, even though it might be annoying [13:50] bac, or you could maybe build off off hatch's upcoming branch (wherever it is) if that makes it easier [13:50] off of [13:51] gary_poster: i'm adding an explicit relationship, fetching one of the services and checking service.rels. it is always [] [13:51] i added this to the test for adding relationships and it fails: [13:51] + var mysql = fakebackend.getService('mysql').result; [13:51] + assert.lengthOf(mysql.rels, 1); [13:52] so i think it is busted [13:54] bcsaller, possibly simplifying and cleaning assumption for your work, but ignore if it doesn't help deliver on time now: we could make a single PPA that had all of our charm's dependencies, and only have the charm install this. Then, when people (like IS) want to see what they have to have available, they can look there. Slightly nicer alternative that probably fits in nicely with what you are already doing: we ma [13:54] intain specific PPAs for the specific use cases (base deploy with charmhelpers, deploy release, deploy from build, deploy against improv, deploy with sandbox) and then if someone like IS only is interested in a particular use case they can see exactly what they need, and our tests verify that our "documentation" (the specific PPAs) is accurate (because the charms use the PPAs and don't bust) [13:55] bcsaller, talking through that made me think "don't bother bcsaller with this; we'll look at this later, and it will fit in nicely with what he is doing already." So nm. :-) [13:56] bac, I don't know details; maybe. Maybe he didn't know he needed to keep that data structure up to date--he probably does not need it for the use cases he's explored so far. [13:57] bac, you probably need to wait till he is around, but once he is, I would not be surprised if you ought to add maintaining that data structure [13:57] assuming you need it [13:57] bac: it's entirely possible that the version in trunk doesn't work as it's supposed to it was using the interface 'name' not the interface 'type' to relate on [13:58] right now I'm trying to tie up the edge cases with the relationships on the (hopefully) final refactor [13:58] hatch, did you even have a use case for keeping up the rels attribute on services--does your current code do that? [13:58] rogpeppe: what's the problem with services now being destroyed? [13:59] frankban: if a unit is an error state, it can't be destroyed until the error is resolved (using juju resolved [13:59] ) [13:59] is anyone able to deploy any service and get it into a non-pending state? [14:00] rogpeppe: ah! this was handled differently in pyjuju, correct? [14:00] benji: yes, it worked for me against tip an hour ago or so [14:00] frankban: yes - myjuju was very slack about clean teardown [14:00] s/myjuju/pyjuju/ [14:00] rogpeppe: thanks, I'll update and try again; which charm did you deploy? [14:00] gary_poster: the only thing the add_relation code does outside of parsing the various types of data is add a relation into the this.db.relations object - they also need to be stored on each service? [14:00] benji: wordpress [14:00] hatch: or it could be getService is broken when it retrieves the relations [14:00] benji fwiw it works fine against improv. I'm assuming you are asking about juju core [14:01] rogpeppe: thanks (I assume you deployed it like so: "juju deploy wordpress") [14:01] gary_poster: yep [14:01] benji: yup [14:01] cool [14:01] hatch, that's what I thought. bac, hatch, guichat? [14:02] sure [14:02] gary_poster: please see Roger comments above. interesting different behavior of juju-core: it does not allow a service in a error state to be destroyed until the unit is resolved. maybe in the future the GUI should reflect this [14:02] frankban, ah, ok, thanks [14:02] rogpeppe: another quick question: are there any known issues with constraints? When I set a constraint with the API the RPC just hangs forever [14:03] benji: no AFAIK [14:03] k, thanks [14:03] benji: bug reports gratefully received [14:03] sinzui: heads up bac was looking for you this morning. [14:03] sure (I'll make sure it is not something I've done wrong first) [14:03] benji: particularly if they come with a reliable way to reproduce :-) [14:04] :) yep, I have a script [14:06] could anyone please review https://codereview.appspot.com/8706043 ? [14:06] luca____: howdy, Huw landed the change log styling overnight so http://uistage.jujucharms.com:8080/bws/fullscreen/precise/apache2-2 is an example. I wanetd to bring up if we should be truncating or adding some lines to help break up the commits. [14:07] luca____: http://uistage.jujucharms.com:8080/bws/fullscreen/precise/ceph-2 is a better example with the longer commit message lines [14:10] rick_h_: I see what your talking about [14:10] rick_h_: we might have a solution for that, we have some visuals which greg is just about to complete. [14:10] luca____: cool, adding a note in that running docs. Maybe even a simple weighting of the date would help [14:11] luca____: cool, just noting/tracknig as I come across things and that is 'complete' on our end so feel free to edit/go after it [14:11] rick_h_: yea, hopefully you can expect them within the hour [14:11] luca____: very cool, look forward to it [14:15] frankban: looking [14:15] benji: thanks [14:29] benji: thank you, I'll add your tag to the card [14:29] frankban: I thought I already did... [14:31] benji: sometimes it seems the board needs to be manually refreshed [14:31] yeah, it's not quite as rock-solid as one might like [14:40] gary_poster bac it dropped me [14:40] hatch, yeah, ok [14:40] hatch, brad will make that one change to the creation [14:40] alright [14:41] he will not change the return argument of the call [14:41] yep [14:41] so hatch you still need to fix the return arg [14:41] gotcha [14:41] (one way or another) [14:43] hatch, if you want to pair on that, happy to. lemme know. bcsaller, when you get in please ping hatch and me so we can make sure we are clear on fakebackend addrelation goals [14:44] gary_poster:, hatch: I'm kind of here if you have questions [14:44] bcsaller: does the gui ever not send explicit interface names with the relations? [14:45] I have never seen it send anything but serviceName:InterfaceName [14:45] * hatch waves at Goodspud [14:45] Whoa, Goodspud left Canonical and capitalized his name! [14:46] Hey all. [14:46] he's been king'd [14:46] Hey :-) [14:46] heh [14:46] Thought I'd pop in and say hi [14:46] how's the vaca going? [14:46] phew Goodspud, glad you're here. Let me get my list of questions for you to go through. :P [14:46] lol [14:47] Bwa ha ha [14:47] hi Goodspud. you traveling? [14:47] Vacation is good. Mostly been relaxing. [14:47] hatch: the env view currently does map to endpoints :-/ [14:48] had to check the code [14:48] I'm helping out a friend for a couple of days at an agency dealing with fashion brands [14:48] bcsaller: no more ambiguous terminology!!! :P [14:49] While I'm surrounded by attractive women and get to look at models, I miss you guys [14:49] More fun than Canonical? :) [14:49] But back to holiday again next week [14:49] bcsaller: so it /always/ includes the serviceName:interfaceName ? [14:51] jovan2: ping, question for you. In the sidebar the editorial is "new this month" and in the fullscreen it's "new or updated" [14:51] hatch: you can help verify that, but grep for add_relation and remove_relation does seem to be passing endpoints [14:51] Goodspud, your sacrifices (attractive women, models, etc.) for the good of UX are admirable [14:51] jovan2: it's come up we shold split new/updated and determine if we are only going to show new? [14:51] jujugui call in 9. please update kanban board now [14:51] * hatch scowls at bcsaller....lol [14:52] I guess the good news is I now know how relations work [14:52] rofl [14:52] hatch: sorry, I knew it was a requirement of the proper backend, I didn't remember it being that much different code wise [14:53] * gary_poster removes himself from bug 1168310: he never had a chance to start it [14:53] oh it's dramatically simpler code if I don't have to deal with the missing interfaceName [14:53] it's alright [14:55] while writing this i may have stumbled uppon the code to Inception so it wasn't all for naught [14:55] :P [14:56] rick_h_: I think New is probably best - in the same sense as *recent* activity, i.e. the time can vary if we need it to. [14:56] Goodspud Hi! [14:57] teknico: Node 0.10.4 was just released ( if you wanted to test the latest Node) [14:57] * gary_poster looks at kanban. jujugui, call in 3 [14:58] hatch, thanks, but that's not what I'm doing atm :-) [14:58] jovan2: so we're giong to run with showing 'new' charms that did not exist before in those spaces for now. Sound ok? [14:58] jovan2 Hey dude [15:00] teknico: allllllllllrighty then! :) [15:00] rick_h_: sounds ok [15:00] jovan2: awesome. Thanks [15:00] Makyo, starting without you (everybody's here) [15:37] bcsaller and rick_h_: re. leading asteriskes in vim comments: give ":set formatoptions-=r" a shot [15:37] benji: trying [15:39] benji: k, works. Indent doesn't fall right but can work on that seperate [15:39] and getting it local to juju-gui [15:39] cool (yeah, I noticed the indent thing, but like you, figured we could fix that too) [15:40] yep [15:40] benji: what are you using out of curiousity? [15:40] using for... what? [15:40] editor [15:42] oh, vim, vim, and more vim [15:43] Alright, running to the coffee shop. Hoping the dogs are tired enough to just sleep for the next few hours. [15:43] ah ok, so it's more a style preference then vs a function/easy thing ? [15:45] hatch: if you can review this real quick i can land it before lunch. https://codereview.appspot.com/8713043 [15:46] I actually really like the asterisks for aesthetic reasons, but I just barely like the non-asterisk version a bit better because the indentation is saner, specifically continuation lines (with stars you end up with one oddity or another indenting continuation lines) [15:47] benji: ok. just curious. I've never run across the *-less way and was interested in how it came to be. [15:47] benji: but thanks for poining out format options. Looks like lots of goodies in there from the dosc. [15:48] I hope one day to be a full-time vim consultant. Could there be a better life? [15:49] benji: heh, when I was doing screencasts I got asked to do a class. Almost was interested [15:49] benji: but then I decided how I work isn't going to be for everyone. :) [15:49] as demonstrated here. [15:51] benji: do you think there'd be approval to work out a file in tree like this? http://www.vim.org/scripts/script.php?script_id=441 [15:54] rick_h_: there might be; it's nice that using it would be opt-in [15:55] depending on how you use vim, there might be an easier way. Do you generaly start vim in the project directory and then use that one instance for the duration of a work session? [15:55] benji: right, just trying to work out to follow along nicely as this method doesn't mesh with the rest of the projects worked on and need some way to trigger/conditional trigger it for the gui [15:56] benji: yea, I tend to workit to a project dir and gvim from there. Why I was trying to fnid some sort of local vimrc override I can stick in that dir [15:57] rick_h_: in that case you can inspect the pwd or the existancce of a particular key file in your .vimrc and make settings accordingly [15:59] benji: would you have a moment to look at https://codereview.appspot.com/8713043/ [15:59] bac: sure [15:59] benji: yea, I'll look into that. I'd rather not have projects in the vimrc as it's shared/global everywhere, but that's better for sure. [15:59] benji: it'll be quicker than reformatting a single yuidoc block [15:59] bac: is the card for that branch "fix fakebackend addRelation"? [16:00] sí [16:00] gary_poster, hatch, possibly others, have a look when you get a chance: https://codereview.appspot.com/8714043 [16:04] thanks benji [16:04] my pleasure [16:17] teknico, we are still talking but you know addRelation code in Go...could you join us in guichat? [16:24] rogpeppe, is it true that addRelation will return endpoints in a normalized order, which we think is [providing service, requiring service]? [16:25] gary_poster: yes, normalised. will just check the order. [16:25] thank you [16:25] gary_poster: requirer first [16:25] rogpeppe, ok cool thank you [16:27] rogpeppe: the branch making AddServiceUnits return unit names is up for review: https://codereview.appspot.com/8716043 . could you please take a look at that? [16:27] frankban: currently in the midst of another review. will look after that. [16:27] rogpeppe: cool, ty [16:30] bcsaller: can you plz check in the python add relation code and let me know where it's returning the relation endpoints? I need to find out the order [provides, requires] or [requires, provides] [16:34] jovan2: ping, looking ast slide 9 what's "text wraps at 3rd column" ? === matsubara is now known as matsubara-lunch [16:37] rick_h_: the screen is divided in to 4 columns, the panel on the left is one column wide. [16:39] jovan2: ah, so the opened charm details fills the full screen then vs the 1/2. Sorry missed that in looking at it [16:39] rick_h_: yes that's right [16:41] rick_h_: but the text does not go all the way across. Charm details takes up 3 columns in total now. The text only takes up 2 columns. [16:41] jovan2: right, understand now. Thanks [16:49] frankban: do you (or anyone else) know if service constraints got added to a watcher? [16:50] benji: it seems so, in ServiceInfo [16:51] thanks! (it seems it is not being updated in the model, I'll take a look) [16:51] benji, do you know how to remove the control buckets via the aws console? [16:53] benji: you mean, in the GUI model? if so, that's correct, it's not handled at all. there should be an XXX [16:53] teknico: go to http://console.aws.amazon.com/, click on S3, go into the bucket and remove all its contents (it won't let you remove a non-empty bucket) then go back to the top list and then remove the bucket itself [16:53] frankban: right [16:54] benji, oh, S3! I was looking at EC2 :-) thanks [16:54] my pleasure [17:02] benji, does juju create the control bucket, or do I need to create it manually? (I think you recently dealt with these matters, if not feel free to buzz me off :-) ) [17:03] teknico: :) yeah, it will create it [17:13] gary_poster, I'm not being able to test the charm with my branch, and time is running out [17:13] gary_poster, if you or hatch or anyone could try, it would be great [17:13] teknico, on call, sorry [17:13] ok [17:14] teknico email handoff [17:14] will do [17:23] node 0.10.4 is now in the chris-lea ppa fyi [17:30] frankban: enormous review finished. i'll have a look at yours now! [17:31] rogpeppe: thanks [17:32] bcsaller: are you around? Just wonderinf about the endpoint ordering in python [17:32] bcsaller: i made the changes you requested to my destroy_service branch: https://codereview.appspot.com/8684043 . please have a look when you have a moment [17:32] bac: I'll review it. [17:33] hatch: whats the question? [17:33] bcsaller: can you plz check in the python add relation code and let me know where it's returning the relation endpoints? I need to find out the order [provides, requires] or [requires, provides] [17:33] hatch: it shouldn't matter [17:34] in the go side it's being returned as [requires, provides] and it matters for the arrows which will be coming [17:34] the 'relationship arrows' [17:34] hatch: you still have to look at the role to draw arrows, but those arrows are meaningless in practice [17:35] they might model application data flow but don't mean anything to the orchestration layer [17:35] and thus bad UI :) [17:35] the role isn't used right now [17:36] it's hard coded in the UI [17:36] because we don't use it for anything, but if we wanted to use it for something like that ordering is less explicit than role, don't you think? [17:36] but the go always returns in the format [requires, provides] [17:37] so right now (for fakebackend) I need to know if the python does the same, or if it's reversed, or doesn't care [17:37] hatch: I'll peek, but I don't think we have a hard rule for that, at best it was a convention [17:37] frankban: reviewed [17:37] alright thanks, I tried to follow it but my pyfoo is weak :) [17:37] I got lost lol [17:38] rogpeppe: cool, I'll make the changes on monday, have a great weekend [17:38] frankban: and you [17:41] hatch: I read through, I don't see any such convention [17:41] ok so it is just returning whatever it's passed [17:41] that's what I thought but wasn't sure [17:41] in that case I'll implement the go order [17:41] thanks! [17:47] Alright, heading back home [17:47] Fingers crossed for good dogs. [17:58] review requiest for Makyo's branch: https://codereview.appspot.com/8721043/ [17:58] request [18:05] gary_poster: I'll take one [18:05] ty [18:05] hatch, hopefully half hour [18:06] sure np, the roofers are coming in 2h so I'll need to step out for about 15min then but other than that I'm open === deryck is now known as deryck[lunch] [18:11] review done, tag added [18:17] here's a wierd one: has anyone had a (juju gui) test fail and then the expected/actual output shows no differences? [18:17] benji: usually I find those with rendering issues [18:18] rick_h_: I'm running the tests from the command line so I'm not sure that applies [18:18] benji: yea, I only saw it due to looking at the sources of the two strings in teh browser [18:18] when yuo dump that to the cli you don't see the html there [18:54] bcsaller: thanks for the review. i figured out why the tests were passing despite the name change. === BradCrittenden is now known as bac [18:54] bac: thanks for checking that [18:57] Makyo: i'm reviewing your branch. would you have time to do a second review on mine? [18:57] bac, sure. [18:57] in a quid pro quo sort of way. :) [19:08] Makyo: done === matsubara-lunch is now known as matsubara [19:12] Makyo: i'm pushing the envelope on the comment style wars [19:13] bac, Hahaha, I say the body of thecomments should be python style. [19:14] I like pythons """ """ that's pretty cool [19:14] but #'s are ugly :P [19:15] in js you could do /** \n # */ :P [19:16] rofl I just looked at our npm-shrinkwrap.json and it's over 1000 lns [19:22] bac, yuidoc is fine with no @return if it's undefined. [19:22] yeah js fn's return undefined by default [19:22] hatch, Yeah, this was more whether or not yuidoc-lint would be okay with a missing @return [19:23] ohh gotcha :) [19:23] has anyone else noticed that the linter doesn't complain about unused vars? [19:23] do we have that turned off? === deryck[lunch] is now known as deryck [19:40] cool, thanks for checking Makyo. [19:53] hatch: got a sec? [19:53] sure [19:53] guichat? [19:53] yes please [20:31] hatch: http://yuilibrary.com/yui/docs/api/files/app_js_app-base.js.html#l988 [20:32] wha'ts up? [20:33] hatch: comments on there. Each time the `activeView` is set via `showView()`, the previous view will be removed from this node, [20:33] Ohhhhhhhhhhh [20:33] right [20:33] I didn't even think of that [20:33] the details view needs to be rendered [20:33] so changing charmDetails to never do a showView and just render manually [20:33] manually, not via showview [20:33] since it always goes 'with' another view [20:33] yeah [20:33] :) [20:53] Makyo: i think you have a good point about the machines/units. i'll see that those are removed. thanks. [21:04] benji, if you get fast turnaround on reviews, will you land, or should we just wait till Monday? [21:04] gary_poster: I'll land it if reviews go well [21:04] ok, on it [21:07] gary_poster: I THINK that the gui bug is caused by deploy...the add_relation code isn't called at the point the relation is created when it throws the error [21:07] does that sound possible? [21:08] hatch, trying to put context back in my head... [21:09] I should check trunk out first before jumping to conclusions i guess [21:09] oop roofers brb [21:09] hatch, no, I don't know what you are talking about. :-) What are you talking about? There was a bug when I tried to view a unit that had a sandbox relation, but that doesn't sound like what you are talking about [21:10] alright couple minutes and I'll try and repro on trunk [21:10] ok [21:10] bcsaller, I'll send a note to IS that charm will be ready Monday unless you tell me otherwise [21:10] * Makyo dogwalk [21:14] I'm going to step away for a minute. I'll check on the branch when I get back. [21:14] back [21:15] ok benji [21:20] benji LGTM [21:20] https://codereview.appspot.com/8728043/ [21:20] ^^ needs one more review [21:22] I should have known that once the roofers got here there would be no chance the dogs would be quiet lol [21:22] :-) [21:23] ok with trunk I get a different error than I do in my branch [21:24] hatch do you need help?I need to go soon [21:25] umm I should be able to track it back [21:25] ok cool hatch [21:25] might be back later to try and help teknico [21:25] I just need to figure out why the sandbox has the service endpoints in a differnt format [21:26] I don't know what I would do without the callstack section of chrome heh [21:40] hatch: I saw the endpoint format change recently, maybe the sandbox is out-dated [21:40] the format sent over python is the same [21:40] the format that was sent to python.js env changed [21:41] but the output is the same (and that's what we care about here) [21:41] I need more stacktrace [21:41] :) [21:51] rick_h_, recent CI failure was on IE in BrowserCharm test: tracks recent commits in the last 30 days. expected 1 to equal 3 [21:52] I'm trying it on local IE now [21:53] rick_h_, it fails in chrome actually [21:54] trunks tests are broken [21:54] yay CI [22:01] yay CI [22:02] gary_poster: ok, will check it out [22:02] oh hmm, fails in chrome too? [22:02] rick_h_, passes in IE oO [22:02] ok somehow the data is being munged from the `this.get('client').receive(data)` to when it's being used after the relation [22:02] locally [22:02] sooooo confused [22:05] rick_h_, -r-10 still shows error...weird [22:05] -r-15 does... [22:06] -r-25 doesn't have test at all [22:08] neither does -20 or -18 [22:08] exists and fails in -16 [22:10] introduced in -17, and fails. [22:11] trying make clean-all [22:11] nope, still fails [22:12] will clear browser cache [22:12] nope, still fails [22:13] rick_h_, can you dupe? This seems pretty weird from the outside--IE passing, chrome failing, and failing since the test was introduced, even with make clean-all and clearing browser cache [22:14] if you can dupe I won't worry about it [22:15] gary_poster: sorry, in the kitchen making dinner awtm. I can try to dupe later today after the boy goes to bed [22:15] rick_h_, no worries [22:20] gary_poster, duped. [22:20] Thanks Makyo [22:39] rick_h_, the recent_commit_count valueFn is being called on instantiation, rather than after the commits are modified. Also the test data is a bit off AFAICT. http://paste.ubuntu.com/5702985/ fixes it for me, but maybe changing the valueFn to a getter is bad. [22:40] (The munged dates from the test were all in February, so they were not included in the value) [22:43] gary_poster: we need a sample.json equiv for the sandbox :) [22:43] gary_poster: that's strange on both accounts. [22:44] gary_poster: ok, I'll look at the stuff there in just a second. I wonder why it passed at all if there's really strange logic/loading stuff like that. [22:45] async sucks....lets redo this whole thing in PHP [22:45] I had thought the '' around the field would make it lazy so it wouldn't load on instantation [22:45] rick_h_, it was a timebomb I think. test data is old [22:45] hatch, aieee! [22:45] lol [22:45] gary_poster: right, but thought the date adjustments got away from that but just realize it only set the 'day' part of the date [22:45] exactly [22:45] gary_poster: so yea, my munging was done wrong [22:45] cool [22:46] what about valueFn vs getter? [22:46] And do you want me to land this as is? [22:46] Or you can shoot me a mail later [22:46] and do family things now :-) [22:46]