[08:05:16 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work <colinclark> if (foo)
[08:09:09 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:11:48 EST(-0500)] * Topic is 'Code Freeze - Testing tasks ( http://wiki.fluidproject.org/display/fluid/Release+Testing+Tasks )' set by Justin_o on 2009-02-17 08:11:48 EST(-0500)
[08:55:55 EST(-0500)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[08:57:25 EST(-0500)] * anastasiac (n=stasia@142.150.154.189) has joined #fluid-work
[09:42:16 EST(-0500)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[09:48:09 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[09:50:09 EST(-0500)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[09:50:11 EST(-0500)] <Bosmon> So, last night I fixed FLUID-2017, which is now closed
[09:50:44 EST(-0500)] <Bosmon> On the JIRA Justin commented that FLUID-2243, which is closely related, is not fixed
[09:50:52 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176132041.dsl.bell.ca) has joined #fluid-work
[09:50:55 EST(-0500)] <Bosmon> Unfortunately I hadn't been aware of that one and it didn't get marked for bug parade
[09:51:03 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:51:14 EST(-0500)] <Bosmon> I am thinking since they are so related, especially in the code they involve, that it makes sense to fix this quickly now
[09:51:36 EST(-0500)] <Bosmon> Especially since correct keyboard accessibility is such an important unique value point of our libraries
[09:51:46 EST(-0500)] <Bosmon> colinclark: We are considering FLUID-2243
[09:52:08 EST(-0500)] <colinclark> lemme take a look
[09:52:30 EST(-0500)] <Bosmon> THE KING drew my attention to it on the fix comment for FLUID-2017 which I did last night
[09:52:59 EST(-0500)] <Bosmon> I had a great coffee....
[09:53:04 EST(-0500)] <colinclark> yum
[09:53:09 EST(-0500)] <Bosmon> In the pretty much the only place in Cambridge that does great coffee
[09:53:17 EST(-0500)] <colinclark> I'm having one now.
[09:53:26 EST(-0500)] <Justin_o> Bosmon: If it is a quick and easy fix I think it may make sense to fix it... as I haven't started testing it yet anyways... anyone else have thoughts
[09:53:27 EST(-0500)] <colinclark> While this cat sits on my lap, trying to get in the way of the keyboard.
[09:53:32 EST(-0500)] <colinclark> Justin_o: Your call.
[09:53:34 EST(-0500)] <Bosmon> CATT!
[09:53:44 EST(-0500)] <colinclark> It's certainly one that can wait if you want to get on with the release.
[09:53:46 EST(-0500)] <Bosmon> I am so constantly impressed at THE CATT
[09:53:49 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[09:53:59 EST(-0500)] <Bosmon> The way it has all these faculties, yet compressed into such a short space
[09:54:04 EST(-0500)] <colinclark> lol
[09:54:37 EST(-0500)] <Bosmon> As we walked along the street just now, an odd smell reminded me that THE CATT also is endowed with the faculty of farting...
[09:54:43 EST(-0500)] <Bosmon> So many CATT FACULTTIES
[09:54:57 EST(-0500)] <colinclark> lol
[09:55:00 EST(-0500)] <Justin_o> colinclark: Bosmon was saying that it will likely only take about 15 minutes to fix.... i don't think anyone will start testing it till after that anyways... so he could probably sneak it in... if it will take longer then it should probably wait
[09:55:14 EST(-0500)] <colinclark> Justin_o: Again, it's totally your call.
[09:55:37 EST(-0500)] <Bosmon> I wonder if apetro considers that the conversation we have here is any more irrelevant and free-wheeling than over in #uportal
[09:55:41 EST(-0500)] <Justin_o> colinclark: thanks... okay.. i would say yes.. provided it can be done within the next half hour...
[09:55:44 EST(-0500)] <Bosmon> ok
[09:55:45 EST(-0500)] <Justin_o> Bosmon: is that okay with you
[09:55:49 EST(-0500)] <colinclark> There should be enough of us around to review the fix.
[09:55:59 EST(-0500)] <Bosmon> I will read a bit less in the loo
[09:56:31 EST(-0500)] <colinclark> Ping me or anastasiac when it's done.
[09:56:57 EST(-0500)] <colinclark> Justin_o: Is everything else looking good for code freeze?
[09:57:11 EST(-0500)] <colinclark> anastasiac: I guess the documentation parade will start up.
[09:57:29 EST(-0500)] * athena7 watches all the parades
[09:57:51 EST(-0500)] <Justin_o> colinclark: pretty much... there is still a problem with the unit tests for UI Options which michelled will take a look at, and fj4000 will be rolling back his changes to FLUID-2121
[09:58:19 EST(-0500)] <colinclark> Justin_o: Okay, great.
[09:58:20 EST(-0500)] <Justin_o> also I'm still waiting to talk to ecocran about the review of FLUID-2224, but I tested it and it seems okay
[09:58:33 EST(-0500)] <colinclark> He sent an email to us this morning, but it was a bit confusing...
[09:58:44 EST(-0500)] <colinclark> I he forwarded the FLUID-2008 message from JIRA...
[09:58:52 EST(-0500)] <colinclark> but I'm pretty sure he meant FLUID-2224.
[09:58:53 EST(-0500)] * apetro wonders why his opinion about irrelevance is being wondered about after being awoken by Bosmon
[09:59:01 EST(-0500)] <anastasiac> colinclark, yes - docs asap
[09:59:10 EST(-0500)] <colinclark> anastasiac: I'll help.
[09:59:22 EST(-0500)] <anastasiac> excellent!
[09:59:24 EST(-0500)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[09:59:27 EST(-0500)] <colinclark> apetro: I think you were just an innocent passer-by.
[09:59:33 EST(-0500)] <colinclark> FISH!
[09:59:43 EST(-0500)] <michelled> KING PENGUIN!
[10:00:00 EST(-0500)] <Justin_o> colinclark: okay... i see the e-mail now... the correct jira was commented, so it should be okay.
[10:00:15 EST(-0500)] * apetro_ (n=apetro@12.164.139.7) has joined #fluid-work
[10:02:22 EST(-0500)] <colinclark> fj4000: How's the reverting going?
[10:02:48 EST(-0500)] <colinclark> michelled: You're rocking FLUID-2215 now?
[10:02:50 EST(-0500)] <colinclark> Need any help?
[10:02:56 EST(-0500)] <fj4000> colinclark - i havent gotten to it yet, preparing some other stuff at the moment
[10:03:02 EST(-0500)] <fj4000> can I ping you if I do?
[10:04:06 EST(-0500)] <colinclark> fj4000: Of course, yes.
[10:04:07 EST(-0500)] <michelled> colinclark: yup, going to take another look to see if I can actually fix them. If not I'll comment them out for the release
[10:04:15 EST(-0500)] <colinclark> michelled: Makes sense.
[10:04:26 EST(-0500)] <Bosmon> What is being reverted?
[10:04:41 EST(-0500)] <Bosmon> OK, I will start to quickly look at FLUID-2243 now
[10:17:01 EST(-0500)] <Bosmon> OK
[10:17:05 EST(-0500)] <Bosmon> I think I have a fix...
[10:17:09 EST(-0500)] <Bosmon> Will test it now...
[10:17:50 EST(-0500)] <Justin_o> Bosmon: that's good... less than 15 minutes too
[10:17:51 EST(-0500)] <Bosmon> Was actually a little more complicated than I thought, and did take up most of the 15 minutes
[10:21:35 EST(-0500)] * apetro_ misses the Opus comic, and muses on this aloud, thereby inserting additional irrelevance.
[10:21:56 EST(-0500)] <Bosmon> Opus can never be irrelevant in an empire ruled by a PENGUIN
[10:23:26 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:28:48 EST(-0500)] <Bosmon> OK
[10:28:51 EST(-0500)] <Bosmon> The fix works, I think
[10:28:56 EST(-0500)] <Bosmon> But it very definitely needs review
[10:29:07 EST(-0500)] <Bosmon> I have had to make a small change to the keyboard-a11y plugin...
[10:30:22 EST(-0500)] <Bosmon> Justin_o: I think FLUID-2165 can be closed
[10:30:36 EST(-0500)] <Bosmon> I'm not sure it is for us to do something about jARIA?
[10:30:37 EST(-0500)] <Bosmon> or is it
[10:30:50 EST(-0500)] <Bosmon> FLUID-1957 I have downgraded to "minor"
[10:30:55 EST(-0500)] <Bosmon> Since it now only afflicts FF2
[10:31:14 EST(-0500)] <Bosmon> FLUID-2018 I have likewise downgraded, I couldn't reproduce it in any browser
[10:31:22 EST(-0500)] <Bosmon> Is it really IE7 only?
[10:34:45 EST(-0500)] <Justin_o> it seems to be present in IE 7 on xp and vista
[10:35:03 EST(-0500)] <Bosmon> That is awkward
[10:35:19 EST(-0500)] <Bosmon> I guess IE7 is now the most popular single browser...
[10:37:07 EST(-0500)] <Justin_o> i guess we can leave it for now... i look at it again later... and maybe look at the priority
[10:37:43 EST(-0500)] <Justin_o> Bosmon: FLUID-1957 is interesting, when i was looking at this yesterday i couldn't tab out of the FCK editor either...
[10:38:09 EST(-0500)] <fj4000> Justin_o: 2121 reversion complete
[10:38:22 EST(-0500)] <Justin_o> Bosmon: so it has sort of the opposite problem as Tiny MCE... where y
[10:38:25 EST(-0500)] <Justin_o> fj4000: thanks
[10:38:34 EST(-0500)] <Justin_o> i'll update the build site
[10:39:43 EST(-0500)] * anastasiac misses the Opus comic, too
[10:41:26 EST(-0500)] * michelled especially misses the jackabassalope from the comic
[10:41:39 EST(-0500)] <Bosmon> Well, these will mostly be problems with the underlying library/technology
[10:41:53 EST(-0500)] <Bosmon> Most of these rich editors are doing absolutely foul things with the browser
[10:42:24 EST(-0500)] <Justin_o> okay... so lots of potential for problems then
[10:42:52 EST(-0500)] * athena7 once convinced a friend that jackalopes were real
[10:43:25 EST(-0500)] <Bosmon> And I think in FF2, TinyMCE is broken in a few fundamental ways....
[10:43:32 EST(-0500)] <Bosmon> Anyway
[10:43:50 EST(-0500)] <Bosmon> I guess I will commit for FLUID-2243
[10:43:58 EST(-0500)] <Bosmon> This is one I think Colin should review...
[10:57:34 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:00:13 EST(-0500)] <Bosmon> KENT
[11:00:14 EST(-0500)] <Bosmon> just in time...
[11:07:30 EST(-0500)] * anastasiac didn't know jackelopes were also called antelabbits
[11:15:04 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[11:39:19 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-17.LIPS.Berkeley.EDU) has joined #fluid-work
[11:41:12 EST(-0500)] <Justin_o> Bosmon, colinclark: I did a quick test fir FLUID-2243 and it appears to be working
[11:41:21 EST(-0500)] <colinclark> Justin_o: Awesome, thanks.
[11:41:36 EST(-0500)] <Justin_o> np
[11:42:21 EST(-0500)] <colinclark> Justin_o: Bosmon and I are going to have a quick skype call in about twenty minutes to talk through the implementation before I'm willing to give it a +1.
[11:42:45 EST(-0500)] <colinclark> I mean, it works and it seems reasonable. But it is a little bit unusual, in part to avoid breaking legacy code.
[11:43:09 EST(-0500)] <Justin_o> okay... makes sense to double check the implementation... thanks
[11:48:39 EST(-0500)] <colinclark> fj4000: I just filed a New Feature in JIRA for the skinning system build: http://issues.fluidproject.org/browse/FLUID-2245
[11:48:53 EST(-0500)] <fj4000> ok, thanks
[11:51:26 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[11:53:36 EST(-0500)] <ecochran> Justin_o and anastasiac : g'morning
[11:53:46 EST(-0500)] <Justin_o> ecochran: good morning
[11:53:47 EST(-0500)] <anastasiac> good morning, ecochran
[11:53:58 EST(-0500)] <ecochran> Justin_o and anastasiac: I'm going to be pretty unavailable today (meetings meetings meetings)
[11:54:05 EST(-0500)] <ecochran> I'll check the list when I can
[11:54:07 EST(-0500)] <ecochran> and IM
[11:54:10 EST(-0500)] <ecochran> and email
[11:54:12 EST(-0500)] <anastasiac> blech
[11:54:14 EST(-0500)] <Justin_o> okay... thanks for letting us know
[11:54:18 EST(-0500)] <ecochran> in case there is anything critical
[11:54:44 EST(-0500)] <ecochran> Justin_o and anastasiac: anything that you think that I should be thinking about or know about in the run up to tomorrow
[11:54:53 EST(-0500)] <ecochran> Justin_o and anastasiac: I still need to build the checklist
[11:55:03 EST(-0500)] <ecochran> I can probably do that while sitting in my first meeting
[11:55:15 EST(-0500)] <anastasiac> ecochran, I can't think of anything in particular. regarding the checklist, it's not really a huge priority
[11:55:20 EST(-0500)] <ecochran> Pretty sure that all the JIRAs are set (between A and I)
[11:55:22 EST(-0500)] <anastasiac> there is a list, it's just not a checklist
[11:55:31 EST(-0500)] <ecochran> anastasiac: true
[11:56:07 EST(-0500)] <ecochran> Justin_o: sorry that I won't be able to test today
[11:56:57 EST(-0500)] <Justin_o> ecochran: that's okay...
[11:57:10 EST(-0500)] * Bosmo1 (n=Bosmon@78-105-207-102.zone3.bethere.co.uk) has joined #fluid-work
[12:01:18 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[12:11:02 EST(-0500)] <Bosmo1> Brief summary of my just now chat with Colin -
[12:11:29 EST(-0500)] <Bosmo1> We have agreed to change the "return value semantics" of activatable to "browser defaults", since we aren't aware of any code that ever depended on this -
[12:11:55 EST(-0500)] <Bosmo1> There was never any specification on the meaning of the return value of an activatable handler, but the majority of users would probably have expected it to agree with a normal event handler in any case
[12:12:29 EST(-0500)] <Bosmo1> To make this consistent, it would be even better if we changed the argument semantics to agree to the JQuery standard too, but that is too much of a change for this release, especially at this point
[12:12:46 EST(-0500)] <Bosmo1> So we will push out that argument normalisation to 1.0, as well as a general rethinking of activatable which has a number of issues with its API
[12:16:04 EST(-0500)] <colinclark> +1
[12:16:17 EST(-0500)] <colinclark> Bosmo1: Ping me when you've got your changes in, and I'll review again.
[12:16:25 EST(-0500)] <Bosmo1> will do
[12:16:40 EST(-0500)] <Bosmo1> THE CATT is looking out to sea
[12:21:36 EST(-0500)] <Bosmo1> OK, new commit for FLUID-2243 is in
[12:21:47 EST(-0500)] <Bosmo1> I will raise the side-JIRAs we mentioned
[12:25:30 EST(-0500)] <Bosmo1> FLUID-2246: Documentation update JIRA
[12:27:28 EST(-0500)] <Bosmo1> FULID-2247: Argument adjustment for activation handler (for 1.0 release)
[12:31:11 EST(-0500)] <Bosmo1> Hi there Justin
[12:31:15 EST(-0500)] <Bosmo1> Justin_o
[12:31:18 EST(-0500)] <Justin_o> Hello
[12:31:25 EST(-0500)] <Bosmo1> Can we still fix FLUID-1825?
[12:31:54 EST(-0500)] <Bosmo1> I am reviewing the full set of 0.8 scheduled issues
[12:31:57 EST(-0500)] <Bosmo1> Going down in priority...
[12:32:40 EST(-0500)] <Bosmo1> FLUID-1825, and FLUID-2244, leap out at me from the list of 51, as being "quick fixes"
[12:33:04 EST(-0500)] <colinclark> Thanks Bosmo1. I'll review your commit after CSpace standup.
[12:33:33 EST(-0500)] <Bosmo1> Other than those, I think all the others which involve touching other than tests or docs are now "unhandleable"
[12:33:58 EST(-0500)] <Justin_o> hmm... what would 1825 and 2244 involve
[12:34:04 EST(-0500)] <Bosmo1> Well
[12:34:08 EST(-0500)] <Bosmo1> It would involve fixing them
[12:34:11 EST(-0500)] <Bosmo1>
[12:34:59 EST(-0500)] <Justin_o>
[12:35:16 EST(-0500)] <Justin_o> i'm reading 1825 and don't quite understand it
[12:35:25 EST(-0500)] <Bosmo1> I think both of those are equal kinds of 5-15 minutes jobs as we had before
[12:35:28 EST(-0500)] <Bosmo1> Probably quicker
[12:35:39 EST(-0500)] <Bosmo1> Well, 1825 is really an issue for the semantics of the framework to itself
[12:35:47 EST(-0500)] <Bosmo1> Fixing it wouldn't actually change any visible behaviour in anything
[12:36:00 EST(-0500)] <Bosmo1> That is, if it was fixed correctly, everything should just work as it does now
[12:36:20 EST(-0500)] <Bosmo1> It would just be easier for people to develop further components against our release code
[12:36:50 EST(-0500)] <Justin_o> okay... i would that for fluid-2244 hold off... mainly because I've already tested that one... for the other double check with colinclark because he would have a better idea of that
[12:36:54 EST(-0500)] <Justin_o> than i would
[12:37:00 EST(-0500)] <Bosmo1> OK
[12:37:07 EST(-0500)] <Justin_o> thanks
[12:37:09 EST(-0500)] <Bosmo1> You have done all the Pager testing?
[13:22:21 EST(-0500)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[13:23:44 EST(-0500)] <anastasiac> Bosmo1: just a reminder that FLUID-2226 has been assigned to you, so if you're looking for work...
[13:24:10 EST(-0500)] <Bosmo1> Oh yes, I will certainly get to that
[13:24:11 EST(-0500)] <Bosmo1>
[13:24:17 EST(-0500)] <anastasiac> thankee, sai
[13:27:40 EST(-0500)] * apetro_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:55:32 EST(-0500)] <anastasiac> Justin_o: Do you know whether or not anyone has updated the "progress indicators" on the component landing pages on the wiki lately?
[13:55:45 EST(-0500)] <anastasiac> I'm thinking the task should be come part of the release proces
[13:55:52 EST(-0500)] <anastasiac> ecochran: ^
[13:56:41 EST(-0500)] <Justin_o> anastasiac: no... i do not... sorry..
[13:56:48 EST(-0500)] <ecochran> anastasiac: I'll add it to the list. Who decides, or where is it documented, what the "progress" state is?
[13:56:53 EST(-0500)] <Justin_o> but seems like a good idea to be part of the release process
[13:57:05 EST(-0500)] <anastasiac> I think Justin_o might be a good person for the task
[13:57:17 EST(-0500)] <anastasiac> he has an excellent feel for the current state of affairs
[13:57:34 EST(-0500)] <anastasiac> he could double-check with relevant developers, if need be
[13:59:04 EST(-0500)] <Justin_o> anastasiac: sure.. sign me up
[13:59:23 EST(-0500)] <anastasiac> ecochran, I'll create a JIRA for that.
[13:59:33 EST(-0500)] <ecochran> anastasiac: thanks
[14:00:14 EST(-0500)] <colinclark> Yeah, ultimately it'd be the component co-leads who would have the specifics of their component's status...
[14:00:57 EST(-0500)] <colinclark> but the QA team has their finger on the pulse of the component's current behaviour, so that's a good place to initiate updating the progress bars.
[14:01:12 EST(-0500)] <anastasiac> Justin_o: FLUID-2249
[14:01:22 EST(-0500)] <colinclark> lessthanzero: I'm just taking a look at you patches. Shall I go ahead and commit them?
[14:01:29 EST(-0500)] <colinclark> Or is this something you'd prefer David to do?
[14:01:58 EST(-0500)] <lessthanzero> colinclark: you can do 'er if your there.
[14:02:06 EST(-0500)] <colinclark> lessthanzero: ok, np
[14:02:07 EST(-0500)] <lessthanzero> I was worried that he was going to patch the trunk.
[14:02:19 EST(-0500)] <lessthanzero> the last 2 (I'm sending another now) you should make sure I don't suck.
[14:02:32 EST(-0500)] <Justin_o> anastasiac: thanks
[14:02:36 EST(-0500)] <lessthanzero> I combined 2 patches, which seems like a straight forward process, but just in case
[14:03:57 EST(-0500)] <lessthanzero> colinclark: and after those 4 patches, thats the bare bones "lets install this somewhere" revision.
[14:04:08 EST(-0500)] <lessthanzero> needs more "halo" work as you put it, but.
[14:04:09 EST(-0500)] <colinclark> ok, no problem
[14:04:14 EST(-0500)] <colinclark>
[14:05:25 EST(-0500)] <lessthanzero> colinclark: can you apply an old patch to a branch? One of my older patches never got committed (or didn't get included in the branch) it was a GUI patch.
[14:05:35 EST(-0500)] <colinclark> sure, no problem
[14:05:42 EST(-0500)] <colinclark> fire me a link and i'll take a look and commit
[14:05:57 EST(-0500)] <lessthanzero> colinclark: http://issues.fluidproject.org/browse/VULAB-144
[14:06:19 EST(-0500)] <colinclark> thanks
[14:06:48 EST(-0500)] <lessthanzero> no, thankyou
[14:07:41 EST(-0500)] <Bosmo1> I tinkered with the progress bars a bit before the last release
[14:07:47 EST(-0500)] <Bosmo1> But I found it a very tedious process
[14:08:03 EST(-0500)] <Justin_o> it can be
[14:08:09 EST(-0500)] <Bosmo1> Involving pasting huge chunks of HTML and colour styles from page to page....
[14:08:31 EST(-0500)] <Justin_o> Bosmo1: i think there is a type-o for the unit test... at least that's what my firebug makes it seem like
[14:08:43 EST(-0500)] <lessthanzero> Bosmo1: shiver that doesn't sound like fun...
[14:08:53 EST(-0500)] <Justin_o> TypeError: dokkument.getElementById is not a function
[14:09:06 EST(-0500)] <Bosmo1> urk
[14:09:08 EST(-0500)] <Bosmo1>
[14:09:14 EST(-0500)] <anastasiac> Justin_o: really? is that there?
[14:09:18 EST(-0500)] <Bosmo1> What do you do, to trigger that?
[14:09:19 EST(-0500)] <colinclark> Bosmo1, Justin_o: Maybe we should just make a "component progress component" with Infusion.
[14:09:30 EST(-0500)] <colinclark> give it a little JSON structure, and the renderer will rock it.
[14:09:45 EST(-0500)] <Justin_o> colinclark: that would be nice
[14:09:50 EST(-0500)] <anastasiac> colinclark: excellent idea!
[14:09:52 EST(-0500)] <Bosmo1> Hm
[14:09:55 EST(-0500)] <Bosmo1> I didn't think of that
[14:10:08 EST(-0500)] <colinclark> I was kinda kidding, but hey.
[14:10:11 EST(-0500)] <Bosmo1> Justin_o: That is the failure with ModuleLayout?
[14:10:12 EST(-0500)] <Bosmo1> What?
[14:10:15 EST(-0500)] <Bosmo1> YOu were kidding?
[14:10:17 EST(-0500)] <lessthanzero> hah
[14:10:17 EST(-0500)] <colinclark> Nice little project for learning how to use the framework.
[14:10:24 EST(-0500)] <colinclark> "kinda kidding:
[14:10:34 EST(-0500)] <colinclark> If it really is onerous to keep them updated, we should just fix it.
[14:10:52 EST(-0500)] <colinclark> And we do think Infusion is useful for fixing things like tedious HTML/CSS work.
[14:10:54 EST(-0500)] <colinclark>
[14:11:19 EST(-0500)] <Bosmo1> It is ludicrously onerous
[14:11:20 EST(-0500)] <Justin_o> Bosmo1: that's the error i'm getting in firebug
[14:12:23 EST(-0500)] <Bosmo1> Oh dear
[14:12:31 EST(-0500)] <Bosmo1> That is a very peculiar problem
[14:13:28 EST(-0500)] <Bosmo1> What number shall I commit the fix against?
[14:13:51 EST(-0500)] <Justin_o> i guess you can commit against the general unit test one... let me dig up the number
[14:14:14 EST(-0500)] <Justin_o> i think it is fluid-1939
[14:16:23 EST(-0500)] <Bosmo1> ok
[14:17:00 EST(-0500)] <colinclark> lessthanzero: Meet laurelw. She's working on the new Fluid website.
[14:17:05 EST(-0500)] <colinclark> She has a question for you.
[14:17:16 EST(-0500)] <lessthanzero> laurelw: whats up.
[14:17:25 EST(-0500)] * lessthanzero does the secret fluid handshake.
[14:17:26 EST(-0500)] <laurelw> lessthanzero: do you say V U Lab or VULab
[14:17:36 EST(-0500)] <colinclark> like V-U-Lab
[14:17:38 EST(-0500)] <colinclark> or ViewLab
[14:17:41 EST(-0500)] <lessthanzero> ahh...
[14:17:43 EST(-0500)] <lessthanzero> Hrrm...
[14:17:54 EST(-0500)] <lessthanzero> I think it was originally intended to be V-U, virtual usability.
[14:18:56 EST(-0500)] <lessthanzero> new Fluid website huh?
[14:23:45 EST(-0500)] <colinclark> lessthanzero: Yep, it's in development at the moment.
[14:23:55 EST(-0500)] <lessthanzero> very cool.
[14:26:32 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:27:18 EST(-0500)] <Bosmo1> Wow
[14:27:31 EST(-0500)] <Bosmo1> There is a crazy syntax error in this test, that none of the browsers seem to care about....
[14:27:43 EST(-0500)] <Bosmo1> It has a list which is not terminated properly
[14:51:33 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:55:28 EST(-0500)] <colinclark> lessthanzero, Bosmo1: I haven't forgotten your code reviews. I'm just having a bit of lunch and then I'll dig into it.
[14:55:35 EST(-0500)] <colinclark> Sorry for the delay.
[14:55:37 EST(-0500)] <lessthanzero> colinclark: np
[14:58:59 EST(-0500)] <Bosmo1> Sheesh
[14:59:10 EST(-0500)] <Bosmo1> The amount of lint in the Renderer is just outrageous....
[14:59:17 EST(-0500)] <Bosmo1> It's like noone ever checks for these things
[15:00:18 EST(-0500)] <Bosmo1> Hmm
[15:00:28 EST(-0500)] <Bosmo1> Could we have the silly line breaking rule turned off for our standards?
[15:00:37 EST(-0500)] <Bosmo1> I think it is a pretty bad idea...
[15:07:55 EST(-0500)] <colinclark> line breaking as in....
[15:08:03 EST(-0500)]
[15:08:03 EST(-0500)] <colinclark> ?
[15:08:38 EST(-0500)] <colinclark> Bosmo1: ^
[15:09:14 EST(-0500)] <Bosmo1> No, not that one
[15:09:26 EST(-0500)] <Bosmo1> The rule about when an operator occurs in a line, you may not put it at the line end
[15:15:20 EST(-0500)] <Bosmo1> His justification for it is pretty weak, and I think it makes the flow positively unclear
[15:15:44 EST(-0500)] <Bosmo1> You could quite easily miss reading an operator, if it was a the end of a line, and consider that a new expression might be starting
[15:17:00 EST(-0500)] <colinclark> show me an example
[15:18:21 EST(-0500)] <Bosmo1> return fluid.isPrimitive(value) || value instanceof Array
[15:18:22 EST(-0500)] <Bosmo1> && (value.length === 0 || typeof(value[0]) === "string");
[15:18:47 EST(-0500)] <Bosmo1> Or, for example
[15:18:48 EST(-0500)] <Bosmo1> fluid.fail("Cannot perform value fixup for valuebinding "
[15:18:48 EST(-0500)] <Bosmo1> + uibound.valuebinding + " since no model was supplied to rendering");
[15:19:06 EST(-0500)] <Bosmo1> Beginning this 2nd line with the bare variable name seems pretty crazy
[15:19:07 EST(-0500)] <colinclark> This seems like a matter of style, to be honest...
[15:19:19 EST(-0500)] <colinclark> since I vastly prefer breaking after the operator, myself.
[15:19:25 EST(-0500)] <Bosmo1> Really?
[15:19:29 EST(-0500)] <colinclark> What argument do you have for it being "bad?"
[15:19:56 EST(-0500)] <Bosmo1> The fact that when you scan the 2nd line you have some proper context, that you are in the middle of an expression, and that also, in a long line, this important context does not "scroll off"
[15:20:15 EST(-0500)] <Bosmo1> Say that the string in the 2nd example was really pretty long
[15:20:20 EST(-0500)] <Bosmo1> You may never see the + operator at all
[15:21:41 EST(-0500)] <colinclark> I see your point, but am not convinced.
[15:21:49 EST(-0500)] <Bosmo1>
[15:22:00 EST(-0500)] <colinclark> I'm keen to see that bike shed style wars don't break out. Which means choosing someone else's style.
[15:22:09 EST(-0500)] <michelled> personally I prefer the operator at the beginning of the line but I don't think it's a problem to have it at the end of the line
[15:22:12 EST(-0500)] <colinclark> So we can all mutual hate Crockford for his annoying style.
[15:22:15 EST(-0500)] <colinclark> mutually
[15:22:22 EST(-0500)] <Bosmo1> Well, we have agreed that sometimes he is insane
[15:22:24 EST(-0500)] <michelled> I'd rather keep with Crockford just because it's easier to check
[15:22:32 EST(-0500)] <Bosmo1> For example, his irrational fear of the compound increment operators
[15:22:38 EST(-0500)] <michelled> is this one of his 'recommended options'?
[15:22:41 EST(-0500)] <colinclark> Bosmo1: Sure, but in those cases I think we've made clearly justifiable choices.
[15:22:43 EST(-0500)] <colinclark> michelled: Yep.
[15:22:52 EST(-0500)] <Bosmo1> Well, I am attempting to clearly justify this one
[15:22:52 EST(-0500)] <colinclark> I'll give you back the book so you can refer to his rationale.
[15:22:59 EST(-0500)] <colinclark> And I am unconvinced.
[15:23:01 EST(-0500)] <Bosmo1> Back?
[15:23:03 EST(-0500)] <Bosmo1> You took it away?
[15:23:19 EST(-0500)] <Bosmo1> I read some of his rationale from some slides I saw of his....
[15:23:35 EST(-0500)] <Bosmo1> His rationale consists of saying "if an erroneous semicolon were put at the end of this line, it would be detected more easily"
[15:23:44 EST(-0500)] <Bosmo1> Which is one of the most nutty justifications I ever heard
[15:25:18 EST(-0500)] <colinclark> Yeah, michelled agrees about that.
[15:25:27 EST(-0500)] <colinclark> But again, it boils down to a stylistic question.
[15:25:58 EST(-0500)] <colinclark> I mean, I guess if you were really passionate about it, we could take it to a vote on the list...
[15:26:00 EST(-0500)] <Bosmo1> Well right, but I am attempting to make argumentation based on "objective" issues of clarity
[15:26:07 EST(-0500)] <colinclark> lol
[15:26:12 EST(-0500)] <Bosmo1> I guess people could even do that for indent spaces...
[15:26:20 EST(-0500)] <Bosmo1> Although it would seem a bit harder...
[15:26:20 EST(-0500)] <colinclark> I find it easier to read when the operator is at the end of the line
[15:26:32 EST(-0500)] <Bosmo1> That is illogical
[15:26:38 EST(-0500)] <Bosmo1> What if you don't see it at the end of the line
[15:26:51 EST(-0500)] <colinclark> This is the thing; we have to be very careful about straying from our "blame that other guy over there" strategy...
[15:27:06 EST(-0500)] <colinclark> because there will inevitably different opinions, each justifiable in some certain way.
[15:27:28 EST(-0500)] <colinclark> But our goal in cases where it isn't very clear and obvious is just to have some general consistency.
[15:27:29 EST(-0500)] <Bosmo1> Well, while we are at it, his "unfiltered for in" thing is pretty insane as well
[15:27:48 EST(-0500)] <colinclark> Bosmo1: It is inappropriate in our world most of the time.
[15:27:49 EST(-0500)] <Bosmo1> It would make our iterations even more inefficient than they already are
[15:28:10 EST(-0500)] <Bosmo1> In a component tree, you know perfectly well everything in it was created with {}
[15:28:11 EST(-0500)] <colinclark> since we rarely deal with things that even have substantial prototypes
[15:28:17 EST(-0500)] <colinclark> i use it as a mental checkpoint, rather than a hard rule
[15:28:29 EST(-0500)] <colinclark> when i see the warning, i double check that i'm not doing anything stupid
[15:28:31 EST(-0500)] <Bosmo1> And anyone who has added stuff to Object.prototype, well......
[15:28:36 EST(-0500)] <colinclark> yes
[15:28:44 EST(-0500)] <colinclark> see above
[15:29:24 EST(-0500)] <colinclark> In the end, these kinds of things involve a certain degree of compromise.
[15:29:40 EST(-0500)] <colinclark> If you really feel uncomfortable about such a compromise, we can take it to the list...
[15:29:53 EST(-0500)] <colinclark> though it always nice to avoid arguing about what colour to paint our bike shed.
[15:30:02 EST(-0500)] <Bosmo1> glarg
[15:30:12 EST(-0500)] <colinclark> lol
[15:30:14 EST(-0500)] <colinclark> i'll take it
[15:30:23 EST(-0500)] <colinclark> glarg, i mean
[15:30:31 EST(-0500)] <Bosmo1> ha
[15:30:55 EST(-0500)] <Bosmo1> I have another "frequent problem", but in this case I am not really sure what to do about it
[15:31:01 EST(-0500)] <colinclark> It's always desirable to see people angry about JSLint!
[15:31:05 EST(-0500)] <colinclark> ok
[15:31:08 EST(-0500)] <Bosmo1> Since, for a start, there seems to be no way to tell Crockford not to complain about it
[15:31:09 EST(-0500)] <Bosmo1>
[15:31:17 EST(-0500)] <Bosmo1> Many times, I reuse variables in functions
[15:32:02 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[15:32:04 EST(-0500)] <Bosmo1> And "to myself", I am clear that even though I know that Javascript doesn't support block scopes, I am happy to notate the fact all the same that I consider these variable usages as "functionally distinct"
[15:32:14 EST(-0500)] <Bosmo1> If nothing else, it would make subsequent refactoring easier
[15:32:32 EST(-0500)] <Bosmo1> I mean, for God's sake, if I have two loops in a function, Crockford would have me say I can't declare them both as "var i"
[15:34:18 EST(-0500)] <colinclark> Bosmo1: Yep, true.
[15:34:38 EST(-0500)] <colinclark> I have just started to avoid that sort of thing.
[15:35:28 EST(-0500)] <Bosmo1> Which sort of thing?
[15:35:34 EST(-0500)] <colinclark> Bosmo1: I hear you are secretly musing about decorators in the renderer...
[15:35:39 EST(-0500)] <Bosmo1> Oh, yes
[15:35:46 EST(-0500)] <Bosmo1> I am just talking FEES through what is in the test case
[15:35:46 EST(-0500)] <colinclark> curious to be "looped in" on that.
[15:35:49 EST(-0500)] <colinclark> cool
[15:35:50 EST(-0500)] <colinclark> tell us about it
[15:35:52 EST(-0500)] <Bosmo1> But I guess I should really do it here
[15:36:03 EST(-0500)] <Bosmo1> I just didn't want to mess up the discussion.... I know people hate to see disorder in IRC
[15:36:07 EST(-0500)] <colinclark> as for "that sort of thing," I just don't bother to reuse variables within a function any more
[15:36:12 EST(-0500)] <Bosmo1> Oh
[15:36:16 EST(-0500)] <Bosmo1> You call them all different things?
[15:36:17 EST(-0500)] <colinclark> i mean, it's just principle
[15:36:19 EST(-0500)] <colinclark> yep
[15:36:21 EST(-0500)] <Bosmo1> glarg
[15:36:27 EST(-0500)] <colinclark> or i define the variable at the top
[15:36:30 EST(-0500)] <Bosmo1> oof
[15:36:39 EST(-0500)] <colinclark> and use it appropriately
[15:36:43 EST(-0500)] <colinclark> that's usually what i do.
[15:36:54 EST(-0500)] <Bosmo1> Well... what if the first name for the variable is the best choice
[15:37:00 EST(-0500)] <colinclark> To mean, it's a meaningful principle, if slightly pedantic.
[15:38:12 EST(-0500)] <Bosmo1> : {ID: "species",
[15:38:12 EST(-0500)] <Bosmo1> value: row.species,
[15:38:12 EST(-0500)] <Bosmo1> decorators: {
[15:38:12 EST(-0500)] <Bosmo1> jQuery: ["click", function() {
[15:38:12 EST(-0500)] <Bosmo1> clickBack(i, "species");
[15:38:13 EST(-0500)] <Bosmo1> }],
[15:38:15 EST(-0500)] <Bosmo1> identify: "species-" + i,
[15:38:17 EST(-0500)] <Bosmo1> addClass: "CATTclick1 CATTclick2"
[15:38:17 EST(-0500)] <michelled> I've seen hard to track bugs crop up from this so I also don't reuse
[15:38:19 EST(-0500)] <Bosmo1> }
[15:38:22 EST(-0500)] <michelled> or define at the top
[15:38:22 EST(-0500)] <Bosmo1> },
[15:38:23 EST(-0500)] <Bosmo1> Here is an example with "compact decorators"
[15:38:25 EST(-0500)] <Bosmo1> {ID: "score",
[15:38:27 EST(-0500)] <Bosmo1> value: row.score,
[15:38:29 EST(-0500)] <Bosmo1> decorators: [
[15:38:31 EST(-0500)] <Bosmo1> {
[15:38:33 EST(-0500)] <Bosmo1> type: "$",
[15:38:35 EST(-0500)] <Bosmo1> func: "change",
[15:38:37 EST(-0500)] <Bosmo1> args: function() {
[15:38:39 EST(-0500)] <Bosmo1> clickBack(i, "score");
[15:38:41 EST(-0500)] <Bosmo1> }
[15:38:43 EST(-0500)] <Bosmo1> },
[15:38:45 EST(-0500)] <Bosmo1> {
[15:38:47 EST(-0500)] <Bosmo1> type: "identify",
[15:38:49 EST(-0500)] <Bosmo1> key: "score-" + i
[15:38:51 EST(-0500)] <Bosmo1> }
[15:38:53 EST(-0500)] <Bosmo1> And here is one with "hydrated decorators"....
[15:38:55 EST(-0500)] <Bosmo1> Did that come through?
[15:39:14 EST(-0500)] <colinclark> Bosmo1: don't you usually use pastie?
[15:39:20 EST(-0500)] <colinclark> that would probably be easier to read
[15:39:22 EST(-0500)] <colinclark>
[15:39:28 EST(-0500)] <Bosmo1> Yeah
[15:39:38 EST(-0500)] <Bosmo1> But I was wanting to make sure this discussion would make sense when logged
[15:39:43 EST(-0500)] <Bosmo1> The pastie will eventually expire
[15:39:50 EST(-0500)] <Bosmo1> I would use pastie, to an individual
[15:40:12 EST(-0500)] <colinclark> Bosmo1: Use http://fluid.pastebin.com/
[15:40:18 EST(-0500)] <colinclark> You can tell it to keep code snippets around forever.
[15:40:20 EST(-0500)] <Bosmo1> Will that never expire?
[15:40:22 EST(-0500)] <Bosmo1> ok
[15:40:32 EST(-0500)] <colinclark> Though I much prefer Pastie
[15:41:06 EST(-0500)] <Bosmo1> The end of my commentary was this:
[15:41:22 EST(-0500)] <Bosmo1> I guess I am continuing with this possibly debunked idea of trying to have compact syntax options for things...
[15:41:23 EST(-0500)] <Bosmo1> But I think in this case it can lead to far less confusion
[15:41:23 EST(-0500)] <Bosmo1> Since decorators cannot be recursive
[15:41:23 EST(-0500)] <Bosmo1> It is always completely clear what level you are on with the containment....
[15:41:44 EST(-0500)] <Bosmo1> And finally:
[15:41:44 EST(-0500)] <Bosmo1> The "identify" one was only invented last night, but it solves an awful lot of problems in the Pager....
[15:41:44 EST(-0500)] <Bosmo1> I am wondering whether "cutpoints" might not also be supported in a decorator mode
[15:45:14 EST(-0500)] <colinclark> Bosmo1: I was mentioning the identify decorator to anastasiac earlier today.
[15:45:19 EST(-0500)] <colinclark> Glad you sent along an example.
[15:46:14 EST(-0500)] <Bosmo1> The full usage is in RendererTest.js, line 94
[15:46:18 EST(-0500)] <Bosmo1> "Decorator and degradation test"
[15:46:42 EST(-0500)] <Bosmo1> For example, after rendering, you can write something like
[15:46:42 EST(-0500)] <Bosmo1> var input = fluid.jById(idMap["score-7"]);
[15:47:30 EST(-0500)] <Bosmo1> And thus the tyanny of the somewhat crazy RSF FullID system is ended....
[15:47:33 EST(-0500)] <Bosmo1> At least partially..
[15:47:47 EST(-0500)] <Bosmo1> It is hard to see how to avoid it, where you are trying to make relative references from within the tree
[15:48:13 EST(-0500)] <Bosmo1> But often, those could actually be done via "identify" too, via a rather bizare "backwards in time" scoping
[15:48:18 EST(-0500)] <Bosmo1> Javascript really is very funny
[15:48:43 EST(-0500)] <Bosmo1> So, what you could do, is make the object reference to idMap visible in the lexical scope of the code constructing the tree
[15:48:59 EST(-0500)] <Bosmo1> THEN, you can write code inside, for example, the event handlers, that will make references to values in it that WILL BE THERE
[15:49:13 EST(-0500)] <Bosmo1> Clearly you could not service an event until after rendering is complete....
[15:49:20 EST(-0500)] <Bosmo1> So by the time your code executes, the map will be filled
[15:49:54 EST(-0500)] <Bosmo1> The system is careful to preserve the absolute object identity of the idMap so that this trick can work
[15:50:12 EST(-0500)] <Bosmo1> Although of course this has interesting questions for anything like options merging for the renderer, if this was ever to happen....
[15:50:25 EST(-0500)] <colinclark> Justin_o: Just to confirm, the repository is now frozen, right?
[15:50:48 EST(-0500)] <Bosmo1> Oops
[15:50:53 EST(-0500)] <Bosmo1> I assume that excludes test cases...
[15:51:35 EST(-0500)] <colinclark> Bosmo1: At this stage, everything in components/trunk should be completely frozen.
[15:51:42 EST(-0500)] <Bosmo1> !!
[15:51:44 EST(-0500)] <Justin_o> colinclark, Bosmo1: yep everything is frozen
[15:51:46 EST(-0500)] <Bosmo1> Sorry
[15:51:52 EST(-0500)] <Justin_o> unless express written consent is given
[15:51:53 EST(-0500)] <colinclark> Since Justin_o uses the unit tests as part of his cross-browser coverage, they need to be frozen, too.
[15:52:00 EST(-0500)] <colinclark> Bosmo1: No worries.
[15:52:07 EST(-0500)] <colinclark> Justin_o: How's this for an idea...
[15:52:12 EST(-0500)] <Bosmo1> I will switch to working on documentation then
[15:52:15 EST(-0500)] <colinclark> I'm already reviewing these last couple of commits.
[15:52:23 EST(-0500)] <Justin_o> colinclark: thanks
[15:52:31 EST(-0500)] <colinclark> Why don't I also include Bosmo1's recent linting and test changes.
[15:52:51 EST(-0500)] <Justin_o> colinclark: sure... that makes sense
[15:52:53 EST(-0500)] <colinclark> And we'll hold off on any more commits in trunk until you give us the sign.
[15:52:56 EST(-0500)] <colinclark> Bosmo1: Cool?
[15:53:25 EST(-0500)] <Bosmo1> Thanks
[15:53:55 EST(-0500)] <colinclark> Not to rain on anyone's linting parade; this is totally awesome.
[15:54:03 EST(-0500)] <colinclark> I just want to make sure Justin_o has a stable base to test on
[15:54:10 EST(-0500)] <colinclark> We're going to make sure the release process document is a bit clearer.
[15:54:22 EST(-0500)] <colinclark> We'll make sure there's a dedicated bug during the bug parade for linting and code cleanup.
[15:55:01 EST(-0500)] <colinclark> Once freeze has been declared, the only issue we can commit against is the "prepare the release" ticket.
[16:05:42 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:06:37 EST(-0500)] <michelled> Justin_o: just to make sure - there are no remaining blockers for 0.8, right?
[16:08:27 EST(-0500)] <Justin_o> there was that fluid-2165 that i don't know if it got done... but at this point I'm guessing we'll have to hold off till 1.0
[16:08:50 EST(-0500)] <Justin_o> and then if we find anything during testing
[16:09:03 EST(-0500)] <michelled> colinclark: is it ok to wait for 1.0 for 2165?
[16:09:18 EST(-0500)] <michelled> it's the problem with jquery extreme noconflicts
[16:09:28 EST(-0500)] <michelled> I'm not sure what uPortal needs
[16:09:35 EST(-0500)] <michelled> and I'm not sure if we are will to hold the release for this
[16:15:05 EST(-0500)] <anastasiac> iirc, athena7's latest update is working fine, so I don't think uPortal is waiting on us, but colinclark might know better
[16:15:30 EST(-0500)] <athena7> i don't believe we're waiting on you for anything
[16:15:44 EST(-0500)] <athena7> the only bug i know of that's still affecting us is that google one
[16:16:03 EST(-0500)] <athena7> which i realize may be in part their fault
[16:16:32 EST(-0500)] <athena7> i think we're having code freeze at the end of the week, but i'm hoping to be able to get 0.8 into the release candidate
[16:55:26 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[17:15:36 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:28:49 EST(-0500)] * michelled (n=team@142.150.154.193) has left #fluid-work
[17:36:20 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[17:40:02 EST(-0500)] * clown (n=clown@142.150.154.101) has left #fluid-work
[17:50:05 EST(-0500)] <Bosmo1> Is FLUID-2165 really still a problem?
[17:50:29 EST(-0500)] <colinclark> Bosmo1: Lemme check...
[17:50:39 EST(-0500)] <Bosmo1> The only thing left is those 2 lines in jARIA
[17:50:42 EST(-0500)] <colinclark> Ah, yes...
[17:50:45 EST(-0500)] <Bosmo1> And I'm not really too sure what to do about them
[17:50:52 EST(-0500)] <colinclark> My pet JIRA issue that no one quite finished.
[17:50:59 EST(-0500)] <Bosmo1> Well
[17:51:04 EST(-0500)] <colinclark> I believe that FLUID-2165 is not really a problem for us, but there is a complete fix.
[17:51:10 EST(-0500)] <Bosmo1> I spent some time clearing up everything but that
[17:51:14 EST(-0500)] <Bosmo1> What do you mean "there is"?
[17:51:22 EST(-0500)] <colinclark> We should switch to using the ARIA functions that Michelle and Scott Gonzalez added to jQuery UI 1.6.
[17:51:30 EST(-0500)] <Bosmo1> aha
[17:51:37 EST(-0500)] <colinclark> In other words, it's a simple fix to toss jARIA altogether.
[17:51:41 EST(-0500)] <colinclark> Not that it wasn't great and all.
[17:51:49 EST(-0500)] <colinclark> But it's not redundant with ui.core.js
[17:51:59 EST(-0500)] <Bosmo1> OK, I see
[17:52:03 EST(-0500)] <Bosmo1> = now?
[17:52:11 EST(-0500)] <colinclark> yes, sorry
[17:52:17 EST(-0500)] <colinclark> "now redundant"
[17:52:31 EST(-0500)] <colinclark> There are those two reference to jQuery in jARIA, but they're in the :role and :state pseudo selectors...
[17:52:34 EST(-0500)] <colinclark> which we never use anywhere.
[17:52:44 EST(-0500)] <Bosmo1> Yes
[17:52:47 EST(-0500)] <colinclark> So while the issue still lingers, I believe it's relatively unlikely to strike anyone
[17:52:48 EST(-0500)] <Bosmo1> Well, I commented on the JIRA
[17:52:59 EST(-0500)] <colinclark> Last time I tried to use those selectors, they didn't even work as advertised.
[17:53:00 EST(-0500)] <Bosmo1> That if they are to be somehow updated, it looks like the "modern way" is to use "Sizzle"
[17:53:06 EST(-0500)] <colinclark>
[17:53:08 EST(-0500)] <colinclark> Sizzle
[17:53:28 EST(-0500)] <colinclark> I keep meaning to ask clown at standup if Dojo 1.3 will also use Sizzle.
[17:53:33 EST(-0500)] <Bosmo1> ha
[17:53:35 EST(-0500)] <colinclark> It's certainly looking pretty fast in jQuery.
[17:53:39 EST(-0500)] <Bosmo1> Yes
[17:53:43 EST(-0500)] <Bosmo1> The code looks as if it is fast
[17:53:52 EST(-0500)] <colinclark> you've been checking it out?
[17:53:55 EST(-0500)] <colinclark> i haven't had time to look yet
[17:54:02 EST(-0500)] <Bosmo1> That is, it looks a whole order of magnitude more incomprehensible than the previous code
[17:54:15 EST(-0500)] <Bosmo1> Which was somewhat possible to reason about, and realise that it would be moderately slow
[17:54:32 EST(-0500)] <colinclark> lol
[17:55:06 EST(-0500)] <colinclark> Heavily optimizing JavaScript can be such a pain to debug... especially when you're tired.
[17:55:20 EST(-0500)] <Bosmo1> Well, you will not be debugging any of this stuff
[17:55:24 EST(-0500)] <colinclark> The new implementation of our tabindex code that is in jQuery 1.3 core is really, really tight.
[17:55:40 EST(-0500)] <colinclark> And Scott and I were totally second guessing our implementation at one point, entirely due to how obfuscated it was.
[17:55:47 EST(-0500)] <Bosmo1> ?
[17:56:01 EST(-0500)] <Bosmo1> There didn't seem to be much room in the tabindex functionality for much complexity....?
[17:56:38 EST(-0500)] <colinclark> Well, there isn't.
[17:56:45 EST(-0500)] <colinclark> That's my point. Even "simple" code is difficult to debug.
[17:56:53 EST(-0500)] <Bosmo1> Isn't our tabindex code about 30 lines?
[17:56:54 EST(-0500)] <colinclark> There is enough to get confused, anyway.
[17:56:58 EST(-0500)] <colinclark> yeah, exactly
[17:57:35 EST(-0500)] <colinclark> Starting at line 993 in jquery-1.3.1.js
[17:57:46 EST(-0500)] <colinclark> There's really not much there, but it's still dense.
[17:57:54 EST(-0500)] <Bosmo1> Yes
[17:58:00 EST(-0500)] <Bosmo1> This doesn't really read much like our code
[17:58:24 EST(-0500)] <colinclark> And then check out line 205 and beyond in ui.core.js
[17:58:24 EST(-0500)] <Bosmo1> I am very fond of the ternary operator, but would probably not cascade 3 of them
[17:58:48 EST(-0500)] <colinclark> I guess it isn't really "our" code anymore, as in Fluid's.
[17:58:51 EST(-0500)] <Bosmo1> oh wow
[17:58:57 EST(-0500)] <colinclark> It's "our" code as in jQuery's.
[17:58:57 EST(-0500)] <Bosmo1> The source references our blog post
[17:58:59 EST(-0500)] <Bosmo1> How nice
[17:59:04 EST(-0500)] <colinclark> Scott optimized it like crazy.
[17:59:17 EST(-0500)] <colinclark> Yeah, I thought that was great.
[17:59:36 EST(-0500)] <Bosmo1> Right
[17:59:46 EST(-0500)] <Bosmo1> Yes, I guess the one thing JQuery can't afford to do, is call JQuery
[17:59:51 EST(-0500)] <Bosmo1> As we know, it is not magic
[18:00:50 EST(-0500)] <colinclark> Bosmo1:
[18:01:08 EST(-0500)] <colinclark> Hey, thanks for pasting the chat transcript summary of our conversation today on the FLUID-2243 ticket.
[18:01:13 EST(-0500)] <colinclark> Very useful to have a pointer to that.
[18:01:23 EST(-0500)] <Bosmo1> no worries
[18:06:52 EST(-0500)] <colinclark> Bosmo1: Which file contains the module layout tests that were failing?
[18:08:37 EST(-0500)] <Bosmo1> It was LayoutReoderer-test.html
[18:08:41 EST(-0500)] <Bosmo1> We only really have the one now...
[18:08:49 EST(-0500)] <Bosmo1> I consolidated them all a while back
[18:09:04 EST(-0500)] <Bosmo1> OK, apart from the Image thing...
[18:17:16 EST(-0500)] <colinclark> Bosmo1: Right. And there are still separate tests for the GeometricManager, which is cool too.
[18:17:25 EST(-0500)] <colinclark> So I've reviewed all of today's commits; we're cool.
[18:18:30 EST(-0500)] <Bosmo1> cool
[18:18:37 EST(-0500)] <colinclark> Reviewing linting is mind numbing, so I just took a brief glance through the files. An errors that could occur should be obvious to Justin in testing.
[18:18:43 EST(-0500)] <colinclark> Thanks for everything today.
[18:18:47 EST(-0500)] <colinclark> We killed a lot of bugs.
[18:18:48 EST(-0500)] <Bosmo1> Thanks likewise
[18:19:03 EST(-0500)] <Bosmo1> Yes, perhaps this is our "best progressed" release so far
[18:19:29 EST(-0500)] <Bosmo1> Soon we will be able to say that "there are no significant number of bugs in our software that our users want fixed"
[18:19:45 EST(-0500)] <colinclark> If we're doing our job, that will probably never be the case.
[18:19:50 EST(-0500)] <Bosmo1>
[18:20:02 EST(-0500)] <colinclark> As long as we can state that there are no significant bugs that are seriously pissing of our users, we're good.
[18:20:04 EST(-0500)] <Bosmo1> In case you don't catch the reference, these words were attributed to Bill Gates in a press interview
[18:20:12 EST(-0500)] <colinclark> lol
[18:20:14 EST(-0500)] <colinclark> i didn't
[18:20:44 EST(-0500)] <Bosmo1> I think this might even have been during the Windows 98 era...
[19:51:30 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined #fluid-work
Unknown macro: { return bar; }
Manage space
Manage content
Integrations