[09:00:34] our first meeting of the 1.7 era! it's a brand new day! [09:00:49] it's a new dawn [09:01:09] although ajpiano needs to respond more quickly to his email [09:01:17] that's what gnarf told em [09:01:18] me [09:01:18] har har [09:01:22] ajpiano is it.... breaking dawn? [09:01:31] that's what dawn said [09:01:38] it's a new life, danheberden [09:01:45] it's a new DAYYYY [09:01:49] howdy -dev [09:01:53] how ya feeling? [09:02:28] so rwaldron did you stick the cross in the door handles on the way out of the church? [09:02:32] hi! [09:02:38] hola timmywil [09:02:39] ahahaha [09:02:44] no church [09:02:55] it was at a mansion in beverly mass [09:03:09] sweet [09:03:19] i downloaded the DC comics reader app for iphone [09:03:19] hokay, lesse what we got here [09:03:31] I've been reading the "No Man's Land" arc [09:03:31] rwaldron: it's awesome. [09:03:37] great stuff [09:03:50] i put a bunch of stuff on the agenda, dunno how far we'll get [09:04:10] i think we're in pretty good shape on 1.7.1, lots of commits today and yesterday [09:04:26] we need to give ppl some time to report bugs i guess [09:04:34] jsut need to get those html5 related things in [09:04:36] DaveMethvin ^ [09:04:40] should be painless [09:04:43] yeah we can land those this afternooon [09:04:55] and i have a couple of event things [09:05:20] and google still needs to get 1.7 into their cdn [09:05:22] the deprecation blog post looks good, DaveMethvin [09:05:47] so any thoughts on 1.7.1 rc and final dates? [09:06:00] prolly should be sooner than the 18th [09:06:10] eek [09:06:15] 18th, I'm AFK all day [09:06:23] can we do it before then? [09:06:33] how about tomorrow? [09:06:37] lol [09:06:39] 14/15th? [09:06:46] well i think ppl will still have bugs streaming in [09:06:50] ok [09:07:02] we should start releasing as 1.7.-1 [09:07:07] we've been able to fix them quickly but no reason to put out 1.7.1 if we still have bugs coming in [09:07:14] so that when everyone gets it and tests it, we can do the next final as 1.7.0 [09:07:24] so frustrating danheberden [09:07:27] haha [09:07:33] the second the final is out they give a shit [09:07:37] before that, meh [09:07:45] but i like the concept [09:08:14] ok so how about the 14th for rc and then final maybe the 16th? [09:08:34] hey, did you know we have uses of .size() in the test suite? [09:08:46] I suspect most of our bug reports are the result of people using http://code.jquery.com/jquery.js [09:08:55] are you saying .size() does matter? [09:08:57] and forgetting [09:09:09] DaveMethvin: no, just ironic [09:09:18] yeah [09:09:46] we now have $.browser used in the ajax test in the suite [09:09:57] face it we're all just lazy [09:10:03] yea, I'm inclined to say screw that test [09:10:18] hey jrburke [09:10:29] Hi timmywil [09:10:31] i held my nose putting in that onclick test [09:10:31] well.... [09:10:33] heya jrburke [09:10:47] Hi addyosmani :) [09:10:49] oh yeah the other big thing to land is the AMD stuff [09:10:51] :) [09:10:56] DaveMethvin timmywil we could still use the shiny new back-compat plugin for the test suite [09:11:04] haha [09:11:04] we dont need to ship that shit [09:11:27] hey jrburke! [09:11:40] So jrburke, I think we should put the define and window exposure in a separate js file [09:11:49] it would be interesting to run the old unit tests against newer versions to see what broke [09:11:55] Howdy rwaldron! [09:12:21] we need it included in the test suite [09:12:23] I mobile so may loose connectivity [09:12:42] jrburke thanks for all your help on this [09:12:51] yea for sure [09:13:19] anybody have objections to what I'm suggesting here? [09:13:24] no that sounds clean [09:13:45] timmywil: it makes perfect sense [09:13:49] any other 1.7.1 bugs needing discussion? [09:13:57] otherwise seems under control so far [09:14:25] so i had the postmortem question on the list [09:14:44] basically, any thoughts about the process and how we can do it better? [09:14:44] an interesting addition.... [09:14:55] timmywil: You want me to update that pull request for that or is it something you want to do? [09:15:26] one thing (that seems almost like an impossible battle) is the lack of tests for older behaviours [09:15:42] jrburke: either way. the makefile will need an update, but it's simple enough. [09:15:47] DaveMethvin and I almost tore out jQuery.fragments altogether [09:15:55] yeah, almost by defn the things that are bugs don't yet have unit tests [09:15:58] because there was ZERO testing [09:16:06] and it was unclear what was really happening [09:16:37] but then... how the hell do we figure out what the coverage looks like? [09:16:37] also if we put in createContextualFragment i wonder if we *should* remove the frag cache [09:16:55] jrburke: for now we can leave the amd test and discuss including amd loaders for testing (it may be better to not include so we don't have to be concerned about keeping them up-to-date) [09:17:11] it does take a lot of mem in cases like that ticket, where many unique frags are being created [09:17:14] DaveMethvin I think we'll still want to cache re-usable "contextual fragments" [09:17:29] we [09:17:38] jrburke: perhaps you could include a test in requirejs and we can get John to put a test in curl [09:17:41] will have to see how that code looks, i need to ping wycats [09:18:03] Not afraid to say, his patch was "eh" [09:18:10] but I tihnk he freely admits [09:18:15] POC [09:18:22] if we could pull out something ... i was more worried about the size [09:18:39] and as far as things like classList goes i think they are dead [09:18:44] timmywil: Ok will ping you once I get into office [09:19:00] a <2x speedup isn't worth the size increase and two code paths [09:19:14] jrburke: thanks :) [09:19:26] DaveMethvin: agreed [09:19:48] DaveMethvin, timmywil also agreed [09:19:57] that brings me to a few other things... [09:20:07] classList, dataset, Traversal API [09:20:17] I can get to the support rework sometime this week [09:20:22] none of these are actually "code reducers" [09:20:27] dead, dead, dead for 1.8 i think [09:20:34] we need to all get in agreement on those [09:20:56] i mean we can vote on them to see pro/con but again i don't think they represent wild gains for the size [09:20:58] they will _all_ require crazy conditions/code paths [09:21:03] maybe 1.9, but I think we agree that size is first priority for 1.8 [09:21:09] and I can argue against all of them [09:21:16] even though 2 were my own damn idea [09:21:34] classList: fast until you want to do anything with >=2 class names [09:21:40] dataset: same [09:21:43] so the other thing i wondered about was the landing phase on these 1.7 patches, we prolly should have reviewed them more [09:21:51] Traversal API: dual code path? NO THANKS [09:21:58] (almost zero gain) [09:22:01] perf wise [09:22:17] and for 1.8 i think we'll want to look at the final code and see the size gain/loss [09:22:28] for each feature or thing we land [09:22:43] agreed [09:22:49] i just wish there was some way to get ppl to test the damn betas [09:22:51] perhaps a second approval process [09:22:56] i'd like to modify the byte counter [09:23:11] danheberden [09:23:13] so that it stores a table of current master to compare against [09:23:19] (optionally) [09:23:21] 's idea about -1 isn't so crazy [09:23:22] :) [09:23:42] what idea? [09:23:56] rwaldron: i would like that [09:23:59] about shipping 1.7.-1 so we could fix bugs before 1.7.0 [09:24:30] rwaldron: yes i like the idea of having the comparison right there [09:24:42] oh that was serious? :P [09:24:45] we could always just commit a change to build after each release? [09:24:55] timmywil: no but maybe it woudl work :D [09:25:03] timmywil: I think DaveMethvin was just kidding..at least..I thought so :) [09:25:12] you never know with me [09:25:17] you're so dry [09:25:19] ok deprecation... [09:25:26] more meme! [09:25:28] plz [09:25:40] i'll put some lolcats in the blog post [09:25:44] word [09:26:06] any ideas about the deprecation blog draft? also is tehre anything else we want to deprecate for 1.7? [09:26:11] speak now or wait for .8 [09:26:16] that rhymes [09:26:29] does sproutcore use $.sub? [09:26:45] timmywil yeah [09:26:47] well they could use the plugin [09:26:51] #1 customer [09:26:59] that's what i thought. oh well. [09:27:03] like i said this is intended to be an aggressive list of all possibliites [09:27:14] DaveMethvin: I'll probably end up writing a parallel one that covers jslim - people are going to wonder about lack of a modular 'build' given targeting trim-ness. Same old same old. [09:27:17] DaveMethvin timmywil I'm ok with deprecation right now, can wait for 1.8 [09:27:28] will give us better chance to spread the word [09:27:31] my chop-it-out numbers are there to give you an idea of savings [09:27:34] DaveMethvin: wycats had said that it wasn't possible to make $.sub a plugin. [09:27:57] really? [09:27:59] wycats: ping [09:28:09] yeah. I remember him saying the same [09:28:09] i was looking at it more and I think it could be a plugin if we expose rootJQuery [09:28:15] timmywil++ [09:28:19] kswedberg: i think that was b/c it used "internals" but we can make it work [09:28:23] that was the only issue at the time [09:28:36] and again it's more of thinking about what we can remove/refactor [09:28:42] DaveMethvin, danheberden: cool. [09:28:52] i dont see it using anything internal [09:28:55] am I crazy? [09:28:58] blind? [09:29:06] it's in the closure [09:29:12] rwaldron: just rootjQuery [09:29:21] nope [09:29:27] nice try though <3 [09:29:36] what do you mean? [09:29:36] wat [09:29:39] that is internal [09:29:45] "rootjQuerySub" [09:29:46] ? [09:29:53] yes, it is remaking rootjQuery [09:29:57] which only exists in that fnction [09:29:59] sorry danheberden just laughing at your version joke a ways back [09:30:02] exactly [09:30:11] what am I missing? [09:30:19] Should probably just confirm with him his original reasoning. If the plugin route works, no reason not to go for it. [09:30:20] are you looking at the source right now? [09:30:46] yeah - rwaldron this doesn't look like how i remember? [09:30:57] i don't see anything internal in it [09:31:00] DaveMethvin heh [09:31:04] every reference inside of sub's definition is _exclusive_ to that function body [09:31:14] rwaldron: I'm saying that if rootjQuery were exposed, $.sub would not need to be in core. As it is, $.sub could be rebuilt by monkeypatching the init function and giving it a different root. [09:31:16] unless I'm totally missing something [09:31:32] timmywil, there is no reference to rootjQuery in the definition [09:31:35] oh yeah i kinda remember this [09:31:38] please tell me I'm making a mistake [09:31:42] yes i know [09:31:50] notice the different init [09:31:53] it worms its way into the closure b.c of the prototype being this() [09:31:53] and that I've completely misunderstood this implementation [09:31:55] yep [09:32:03] passing it's own rootjQuery [09:32:25] everything else is the same [09:32:29] the one called "rootjQuerySub" [09:32:35] but that own rootjQuery is its own, thus it could be external, ya? [09:32:43] so other than knowing some rather deep internals it could easily be taken out [09:32:49] which is defined here: var rootjQuerySub = jQuerySub(document); [09:32:54] inside the function body [09:32:58] which is all in scope of sub [09:33:27] plenty of things like special events have knowledge at least that deep, and if this were an official plugin i'd have no problem with that kind of linkage [09:33:49] right [09:34:00] my sword to thee, DaveMethvin rwaldron timmywil [09:34:08] ok, i don't know how to explain more [09:34:30] that's because it's kind of strange, and the semantics aren't documented well [09:35:17] new stuff added to the .sub() copy doesn't share the closure with the original jquery [09:35:38] and all because there's a different root [09:35:56] which is created by passing undefined to the root on jQuery.fn.init [09:35:57] either the sub tests suck, or I'm awesome [09:36:12] i just removed sub, put it in a sep file, added that file to end of the list in test/index.html [09:36:18] and ran the tests [09:36:19] full pass [09:36:34] so if you call .data() on the sub that will use the original closure's data but if you monkey-patched .data() your patch would be in the sub's closure [09:36:46] ok it's coming out in 1.7.1 :D [09:37:10] alrighty then i think we have our list for 1.7, just keep the other stuff in mind [09:37:16] https://github.com/rwldrn/jquery/tree/substinks [09:37:17] and we can add more later during the 1.8 process [09:37:28] DaveMethvin timmywil danheberden that branch has the changes [09:38:20] yes, good [09:39:05] so we can prolly discuss the 1.8 stuff in detail later, but someone asked about the UI process for deprecating stuff [09:39:14] they did something that i am not sure we can do [09:39:39] I remember the original implementation used rootjQuery, but this doesnt use references to anything outside of it's own function body [09:39:46] when they redefined a lot of their api they kept (or are keeping) both ways in [09:39:52] its* [09:40:07] and the old stuff is comign out in 2.0 [09:40:16] my point was not that it requires internals, sry. My point was that the plugin could be one line. [09:40:33] but the way they are doing that is basically "old stuff at the bottom" [09:40:52] and then when it comes time to remove it they just basically chop off the bottom of the file [09:41:03] timmywil oh, huh...? I didnt get that at all :| [09:41:57] but for us, maybe we could do something where a lot of the hooks were in separate files that we included [09:42:19] and at the very least someone could build a reduced one even if we didn't provide one [09:42:23] rwaldron: rootjQuery, the internal, could be exposed so that sub can be implemented by simply changing the root to another instance. [09:42:23] kind of like... what I just did with jQuery.sub? [09:42:41] sorry, that was to DaveMethvin not you timmywil [09:42:48] yeah, although i think that might be a supported plugin [09:42:56] anyway, that's more a -dev convo [09:43:03] timmywil sounds good [09:43:14] Seems like you have a solid approach [09:43:18] my goal: get it out [09:43:21] your goal; same [09:43:21] agreed [09:43:23] win [09:43:25] i never liked it [09:43:29] nor did i [09:43:37] not for core anyway [09:43:51] since it can live outside core i say we kick it out of the nest eventually [09:44:02] +1 [09:44:06] it's easy for someone to just cut these parts out if they desperately need them [09:44:19] but most people aren't using the stuff i have in that spreadsheet, or should not be [09:44:40] ok so we'll save the 1.8 discussino for another time [09:45:04] but i will put out the blog post tomorrow [09:45:12] let's see what activity that generates [09:45:19] gnarf: yt? [09:45:40] anything else needing discussion? [09:45:55] i'd like to get the the common failing tests out of swarm [09:46:11] oh yeah, how about we do that before 1.7.1 [09:46:17] this afternoon even [09:46:24] that would be great [09:46:37] then we won't be STILL FAILING [09:46:44] i'm gonna miss that guy [09:46:47] NOT [09:46:58] ok, well that's all i have [09:46:59] yea, maybe we'll see a SUCCESS in our lifetime ;) [09:47:04] dreamer [09:47:24] hehe [09:47:29] ok thanks [09:47:32] less talk, more code! cya in -dev