**** BEGIN LOGGING AT Tue Jan 13 02:59:59 2015
Jan 13 15:11:25 <DougReeder> Hey, I just pulled Sampler, and the Enyo submodule has tags 2.4.0 and 2.5.0, but not 2.5.1 nor 2.5.1.1. Do I need to do some funky git pull to get all the tags for a submodule?
Jan 13 15:16:18 <GodGinrai> DougReeder: the submodule shows " enyo @ 0df607c " in github
Jan 13 15:16:54 <GodGinrai> 0df607c is tag 2.5.3-zzz.7
Jan 13 15:17:04 <GodGinrai> which was tagged before 2.5.1.1
Jan 13 15:17:55 <DougReeder> I think git submodule tells you the commit that’s currently used for the submodule.
Jan 13 15:19:05 <GodGinrai> yea, that's my point
Jan 13 15:19:22 <GodGinrai> since a commit that is before 2.5.1.1 is used for the submodule
Jan 13 15:19:33 <DougReeder> So, I’m not sure that git submodule tells us anything we need here.
Jan 13 15:19:34 <GodGinrai> it's only logical that you would not find a 2.5.1.1 tag there
Jan 13 15:19:49 <DougReeder> Oh, I see.
Jan 13 15:20:09 <DougReeder> So, Sampler hasn’t *yet* been updated to 2.5.1.1
Jan 13 15:20:22 <GodGinrai> that seems to be the case
Jan 13 15:20:48 <DougReeder> Is that commit prior to 2.5.1 ?
Jan 13 15:54:24 <DougReeder> https://github.com/enyojs/enyo/blob/master/samples/PlatformSample.js has been updated to show the version of Enyo, but the Sampler app doesn’t seem to use that. What’s going on?
Jan 13 15:56:59 <GodGinrai> it doesn't?
Jan 13 15:57:28 <DougReeder> http://nightly.enyojs.com/latest/sampler/debug.html does, but the latest checked out of GitHub doesn’t
Jan 13 15:57:47 <GodGinrai> weird
Jan 13 16:03:59 <DougReeder> Nuked my repo and cloned sampler again.  Version now visible Core > Platform.  Also, enyo submodule has tags 2.5.1 and 2.5.1.1
Jan 13 16:04:28 <DougReeder> So, just doing a git pull doesn’t properly update sampler and its submodules :-(
Jan 13 16:04:30 <GodGinrai> weird
Jan 13 16:04:50 <GodGinrai> wait
Jan 13 16:05:03 <GodGinrai> you were trying to update the submodules with git pull?
Jan 13 16:05:27 <DougReeder> I ran git pull in sampler.
Jan 13 16:05:42 <GodGinrai> yea, but that only updates the repo
Jan 13 16:05:46 <GodGinrai> not the submodules
Jan 13 16:06:10 <DougReeder> Do you need to do something like git submodule foreach git pull ?
Jan 13 16:06:20 <GodGinrai> you have to use `git submodule update` to update a submodule
Jan 13 16:06:30 <GodGinrai> read `man git-submodule`
Jan 13 16:06:54 <DougReeder> I did that at one point, and was still getting old code.
Jan 13 16:07:49 <GodGinrai> that should not be the case
Jan 13 16:38:46 * Semanticfire_2 has a blackout it seems
Jan 13 16:39:14 <Semanticfire_2> I create component and in its initialization I want to point to another component:
Jan 13 16:40:12 <GodGinrai> a blackout?
Jan 13 16:40:23 <Semanticfire_2> component: [{ kind: "myKind", parameter: this.$.otherkind },{ name: "otherkind", ....
Jan 13 16:40:29 <Semanticfire_2> I thought that shoudl work ?
Jan 13 16:41:00 <GodGinrai> Semanticfire_2: no
Jan 13 16:41:27 <GodGinrai> everything in that array is evaluated before the kind is made
Jan 13 16:41:39 <GodGinrai> so this.$.otherkind does not exist yet
Jan 13 16:41:46 <GodGinrai> because this.$ doesn't exist yet
Jan 13 16:42:06 <Semanticfire_2> well that figures since it doesn't work :)
Jan 13 16:42:25 <Semanticfire_2> is there a option to do that or are bindings my only saviour
Jan 13 16:42:38 <GodGinrai> this is a case you should use bindings more than likely.  Is there a reason you don't want to?
Jan 13 16:42:48 <Semanticfire_2> bloated
Jan 13 16:43:07 <GodGinrai> how so?
Jan 13 16:43:29 <GodGinrai> also, why does one need a reference to the other, anyway?
Jan 13 16:43:45 <Semanticfire_2> one is map, the other a extra layer I want to display on the map
Jan 13 16:44:29 <GodGinrai> ok, so why not communicate between the two using the wrapper kind?
Jan 13 16:44:39 <GodGinrai> you can send and receive events to and from it
Jan 13 16:44:58 <Semanticfire_2> yeah thought about that as well
Jan 13 16:45:04 <GodGinrai> or you could also use signals
Jan 13 16:45:39 <GodGinrai> Or hell, the wrapper kind could just throw the reference to this.$.otherkind in the component in create()
Jan 13 16:46:15 <Semanticfire_2> that kills the loose coupling
Jan 13 16:46:25 <Semanticfire_2> I actually do it the otherway around
Jan 13 16:46:53 <Semanticfire_2> I'll add a new property to the map kind which can contain layer kinds
Jan 13 17:45:26 <Cage1___> or you can set it after rendered
Jan 13 17:57:39 <Semanticfire_2> -v ?
Jan 13 18:00:10 <sugardave> I can't scroll back because I had to reboot this server.  grr.
Jan 13 18:03:10 <GodGinrai> lol
Jan 13 18:04:50 <Semanticfire_2> :)
Jan 13 18:06:39 <Semanticfire_2> I'm totally confused on passing published attributes of a kind as a 'parameter' for kinds components..
Jan 13 18:07:31 <Semanticfire_2> { name: "foo", published { bar: null },components [ { kind: "foobar", element: this.bar } ] }
Jan 13 18:07:37 <Semanticfire_2> I expected this to work
Jan 13 18:14:14 <GodGinrai> nope
Jan 13 18:14:40 <GodGinrai> published is simply for the kind factory
Jan 13 18:14:50 <GodGinrai> it is not used in component notation
Jan 13 18:15:12 <GodGinrai> you just refer to published properties like normal properties
Jan 13 18:15:31 <GodGinrai> { name: "foo", bar: null,components [ { kind: "foobar", element: this.bar } ] }
Jan 13 18:15:49 <GodGinrai> as for the "this.bar
Jan 13 18:15:51 <GodGinrai> part
Jan 13 18:16:04 <GodGinrai> this would refer to the object that you are declaring this kind in
Jan 13 18:16:09 <GodGinrai> not the kind you are declaring
Jan 13 18:18:04 <Semanticfire_2> so how should i refer to bar then ?
Jan 13 18:19:20 <GodGinrai> bindings
Jan 13 18:19:54 <Semanticfire_2> and that was what I wanted to prevent ;)
Jan 13 18:20:06 <GodGinrai> Yea, and I don't know why
Jan 13 18:20:36 <GodGinrai> You are doing a lot of crap that should be done in a kind definition rather than on-the-fly
Jan 13 18:20:50 <GodGinrai> and then trying to stay away from the only easy way to do that
Jan 13 18:21:07 <GodGinrai> what do you have against bindings?
Jan 13 18:21:36 <Semanticfire_2> nothing persee
Jan 13 18:21:44 <Semanticfire_2> but in this case it is too bloated
Jan 13 18:22:26 <GodGinrai> it really isn't
Jan 13 18:23:00 <GodGinrai> *ping* dmanderson sugardave Roy__ for voice of reason
Jan 13 18:24:19 <Semanticfire_2> :)
Jan 13 18:25:46 <Cage1___> Can't you just make the assignment after everything is constructed?
Jan 13 18:26:57 <Semanticfire_2> I'm trying bindings now
Jan 13 18:27:02 <GodGinrai> yay
Jan 13 18:27:16 * GodGinrai starts fixing the red beans and rice
Jan 13 18:27:31 <Semanticfire_2> is there a bug in it ?
Jan 13 18:27:44 <Roy__> GodGinrai: Hmm?  did you break the red beans and rice again?
Jan 13 18:28:31 <GodGinrai> Roy__: fixing as in making, cooking, preparing
Jan 13 18:28:56 <Roy__> Suuuure.
Jan 13 18:29:15 <dmanderson> Morning enyoers
Jan 13 18:29:25 <Semanticfire_2> ey dmanderson
Jan 13 18:30:42 <GodGinrai> Roy__: http://en.wikipedia.org/wiki/Sekihan
Jan 13 18:31:50 <Roy__> Ahhh.
Jan 13 18:32:05 <Roy__> not http://www.foodnetwork.com/recipes/emeril-lagasse/red-beans-and-rice-recipe2.html
Jan 13 18:35:19 <GodGinrai> nope
Jan 13 18:35:56 <GodGinrai> it was a joke about Semanticfire_2 finally using bindings, but I guess no one here got it >.>
Jan 13 18:41:42 <dmanderson> lol
Jan 13 18:41:52 <dmanderson> if no one gets the joke, is it still a joke
Jan 13 18:41:53 <dmanderson> ?
Jan 13 18:41:54 <dmanderson> :p
Jan 13 18:42:21 <GodGinrai> dmanderson: your philosophy is not appreciated here
Jan 13 18:42:26 * GodGinrai shows dmanderson the door
Jan 13 18:42:38 * dmanderson runs out and back in, it’s a new visit now.
Jan 13 18:43:05 * GodGinrai shows the new visitor the newly placed sign "no Philosophy allowed"
Jan 13 18:53:31 <Semanticfire_2> :)
Jan 13 20:16:23 <Cage1___> are modelcontrollers in 2.5 still of use? or can one get away without using it
Jan 13 20:16:55 <dmanderson> Is it bad to say I never use them?
Jan 13 20:20:45 <Cage1___> never is strong word
Jan 13 20:20:52 <Cage1___> does that mean i shouldnt use them either?
Jan 13 20:23:18 <dmanderson> HAHA, I just haven’t found a specific use for them, I don’t think they are bad if you find a good use case for them.
Jan 13 20:24:13 <Cage1___> how cryptic
Jan 13 20:24:19 <Cage1___> what's a good use case for them?
Jan 13 20:27:09 <GodGinrai> Cage1___: He's still looking for one :P
Jan 13 20:53:04 <sugardave> Semanticfire_2: use bindings; love them;  you will be so much happier
Jan 13 20:54:31 <Semanticfire_2> :)
Jan 13 20:54:46 <Semanticfire_2> yeah I've implemented bindings inside the kind now
Jan 13 20:55:21 <sugardave> Cage1___: I was told a good use case for a ModelController is if you need something to act like a single model somewhere but need to change what that mofel is....it is confusing, so I just never use them and do .set("model", newmodel).  We'd need Cole or maybe Roy__ to explain it better
Jan 13 20:55:50 <Cage1___> i think i found one...
Jan 13 20:57:13 <Cage1___> (maybe)...because JS is pass by reference for complex structures....if i want to save the original reference to model , e.g. when i am replacing variable with new information but want to preserve the old info... (if that makes sense)
Jan 13 20:58:17 <Cage1___> for example, i have a popup filled with current info. user makes some changes. if they hit save, i need to save the old info to db, as well as new info. if they hit cancel, i need to discard the changes...
Jan 13 20:59:45 <sugardave> hmm, looking at the source it seems that it might just be helpful for not having to refresh bindings manually when you change something's model...it also propagates events.
Jan 13 21:00:00 <sugardave> that's it
Jan 13 21:02:08 <sugardave> there has to be some other compelling reason to use them, because I thought .refreshBindings() is gone anyway...?
Jan 13 21:03:19 <dmanderson> lol GodGinrai
Jan 13 21:05:31 <sugardave> internally, nothing in core uses a ModelController
Jan 13 22:28:53 <Cage1___> does model.restore() restore it the state prior to commit?  or just to the state prior to the most recent .set()?
Jan 13 22:51:22 <dmanderson> it looks like commited Cage1__
Jan 13 22:51:27 <dmanderson> this.previous =
Jan 13 22:53:36 <Cage1___> hmm, so if i have never committed it and do .restore(), it should unset all properties, even i change them many times...
Jan 13 23:00:31 <dmanderson> looking at the source, I only see it at create time of the model, and commit.
Jan 13 23:12:54 <Cage1___> okay. guess i'm doing something wrong then because that's not the way it's working for me :(
Jan 13 23:21:55 <dmanderson> What version of enyo?
Jan 13 23:22:06 <Cage1___> 2.5.1.1
Jan 13 23:27:07 <Roy__> Did we fix the bug with restore/  Hmm.
Jan 13 23:27:30 <Roy__> There is(was) a bug with restore.  IT just doesn't work.  Not sure if it was fixed yet.
Jan 13 23:27:37 <Roy__> Let me track down the Jira.
Jan 13 23:28:07 <Cage1___>  i have a collection records; i'm doing a collection.map(function(obj){obj.restore(); return obj;}
Jan 13 23:28:43 <Roy__> It isn't fixed.
Jan 13 23:29:00 <Roy__> Restore will not work as implemented.
Jan 13 23:29:06 <Roy__> :/
Jan 13 23:29:28 <Cage1___> simple fix or not? :) :)
Jan 13 23:29:34 <Roy__> Well..
Jan 13 23:29:51 <Roy__> You have to override the model to set a new value into the 'previous' member at creation time.
Jan 13 23:30:09 <Roy__> Currently it clones the value from the passed in data, which causes it to remain in lock-step with the actual value.
Jan 13 23:30:42 <dmanderson> ah good looking out Roy__
Jan 13 23:31:22 <Roy__> ENYO-521.  Not sure why we deferred it.  It's kinda nasty.
Jan 13 23:31:30 <Cage1___> quite :)
Jan 13 23:32:08 <Roy__> Basically, don't do a quick clone into previous.
Jan 13 23:32:43 <Roy__> I will alert Jim to mark this as a known issue in 2.5.1.1
Jan 13 23:32:46 <Cage1___> technically, shouldn't clone work for simple values??
Jan 13 23:35:04 <Roy__> It does work for /simple/ values.  Previous is an object.
Jan 13 23:35:27 <Cage1___> line 721 in Model.js: this.previous = enyo.clone(this.attributes, true);
Jan 13 23:35:43 <Roy__> change true to false and it'll work.
Jan 13 23:35:52 <Roy__> At the cost of some performance.
Jan 13 23:35:57 <Cage1___> enyo.clone, ah is true = deep clone?
Jan 13 23:36:10 <Roy__> no, true is quick clone, I believe.
Jan 13 23:36:24 <Roy__> if that's a direct paste from source.
Jan 13 23:37:47 <Cage1___> it is and you're right, true = quick per doc
Jan 13 23:38:23 <Cage1___> and it solved my problem :)
Jan 13 23:43:21 <Roy__> yay
Jan 13 23:50:31 <Cage_> blah, irc cloud went down...
Jan 13 23:50:34 <Cage_>  changing it to "this.previous = enyo.clone(this.raw(), true);" also works - but prob not advisable??
**** ENDING LOGGING AT Wed Jan 14 02:59:59 2015