/irc-logs / mozilla / #accessibility / 2012-02-09 / end
Options:
- # Session Start: Thu Feb 09 00:00:00 2012
- # Session Ident: #accessibility
- # [00:05] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
- # [00:10] * Quits: shorlander (shorlander@moz-853043D6.dhcp.insightbb.com) (Ping timeout)
- # [00:10] * jimm is now known as jimm-bbiab
- # [00:10] * Joins: shorlander_ (shorlander@moz-853043D6.dhcp.insightbb.com)
- # [00:13] * Quits: skyler_brungardt (skyler@3459447D.62BEB748.75EC3910.IP) (Ping timeout)
- # [00:14] <WeirdAl> oh, I see what you mean
- # [00:17] * Joins: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca)
- # [00:19] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
- # [00:24] * Joins: hub (hub@83874EA1.EB7C1AF9.6F478678.IP)
- # [00:24] * ChanServ sets mode: +o hub
- # [00:28] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
- # [00:32] <WeirdAl> jimm-bbiab: does accessibility have the concept of a "retry" response, a la "I'm busy right now, call me back in a moment"?
- # [00:32] <WeirdAl> err, s/accessibility/ipc
- # [00:39] * khuey is now known as khuey|1on1
- # [00:40] * jimm-bbiab is now known as jimm
- # [00:40] <jimm> WeirdAl: not really.
- # [00:40] <jimm> the problem here is that one of the processes is stuck in a modal loop that isn't processing windowing events.
- # [00:41] <jimm> that can happen on the fx or plugin-container side
- # [00:41] <jimm> it's a problem with our implementation on windows.
- # [00:41] <WeirdAl> mmm
- # [00:41] <jimm> supposedly content processes are supposed to address it somewhat.
- # [00:42] <WeirdAl> but somehow we found a way past all those barriers
- # [00:43] <jimm> not sure if we did, I think our suggestion was that people using accessibility software should disable out of process plugins
- # [00:43] <jimm> davidb would know if that's still the case
- # [00:45] <WeirdAl> even so, the fact we're using these API's makes it a little harder to do that
- # [00:45] <WeirdAl> numbers-wise, I mean
- # [00:46] <jimm> btw, why is Ask using accessibility apis?
- # [00:46] <WeirdAl> our code definitely has to be smarter
- # [00:46] <WeirdAl> I don't know the answer to that. Brian knows, but he signed off a few hours ago
- # [00:47] <jimm> well I need to do some more dubugging on our end so I cvan get a clear picture of what's going on.
- # [00:47] <WeirdAl> my best guess is we didn't know any alternatives to do a little screen-scraping
- # [00:48] <WeirdAl> ... I personally think we need to hire someone on our side to speak loudly on how browser vendors like Mozilla will react
- # [00:48] <WeirdAl> my voice doesn't carry enough weight
- # [00:50] <jimm> WeirdAl: what location do you work out of? Mtn View?
- # [00:50] <WeirdAl> jimm: I work for Ask, in Oakland
- # [00:50] <jimm> that's what I mean, was just curious where Ask was head quartered.
- # [00:51] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
- # [00:51] <WeirdAl> we have offices in NY, and here in Oakland
- # [00:52] * Quits: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca) (Ping timeout)
- # [00:53] <WeirdAl> btw, jimm, did you have a chance to write up that detailed analysis for 719561?
- # [00:54] <jimm> ah, no I want to do some more debugging first.
- # [00:55] <WeirdAl> ok
- # [00:56] <jimm> you guys caught me in the middle of another project today.
- # [00:56] <@hub> I wonder how much bug 627699 will have in relation to a11y.
- # [00:56] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=627699 nor, --, ---, stransky, ASSI, Port GTK2 to GTK3
- # [00:56] <WeirdAl> I appreciate your help on all this, jimm, seriously
- # [00:56] <jimm> np
- # [01:03] * khuey|1on1 is now known as khuey
- # [01:13] <Jamie> jimm: WeirdAl: the IPC problem is still an issue, but for some reason, we rarely see it now
- # [01:13] <Jamie> We'd need to find a page that causes a lot of IPC traffic and load to reproduce it
- # [01:14] * Jamie doesn't have out-proc plugins disabled. Occasionally see a11y fail, but not often enough for it to irritate me
- # [01:17] <Jamie> jimm: I assume bug 667883 doesn't actually apply to normal trunk builds, only e10s-enabled ones?
- # [01:17] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=667883 nor, --, mozilla8, mounir, RESO FIXED, Implement nsAttrAndChildArray::SizeOf()
- # [01:17] <Jamie> err
- # [01:17] <Jamie> bug 677883
- # [01:17] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=677883 maj, --, mozilla10, jmathies, RESO FIXED, [e10s] WM_GETOBJECT regularly fails on content process windows in anything but the first tab
- # [01:24] * Joins: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca)
- # [01:28] <jimm> no idea on 667883
- # [01:29] <jimm> oh
- # [01:29] <jimm> sorry, was looking at the first firebot msg
- # [01:29] <jimm> so that fix only "kicks in" if oopp is enabled.
- # [01:45] * Quits: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca) (Ping timeout)
- # [01:50] * Joins: muralisr92 (chatzilla@moz-511DFF61.spnp.nus.edu.sg)
- # [01:52] <Jamie> jimm: oopp = out of process plugins = applies in current nightlies?
- # [01:54] <Jamie> jimm: if so, that fix should solve that WM_GETOBJECT failure you were discussing above re a11y tools
- # [01:59] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
- # [01:59] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Connection reset by peer)
- # [02:00] <jimm> it fixes the specific problem we had there where those events were getting mysteriously dropped.
- # [02:00] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [02:02] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Ping timeout)
- # [02:04] * Quits: WeirdAl (chatzilla@moz-D461843.ask.info) (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120129021758])
- # [02:04] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [02:09] * Joins: surkov (surkov@E3B837DE.44A4068D.222B27F0.IP)
- # [02:09] * ChanServ sets mode: +o surkov
- # [02:16] * Quits: @surkov (surkov@E3B837DE.44A4068D.222B27F0.IP) (Ping timeout)
- # [02:16] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
- # [02:18] * Joins: surkov (surkov@E3DF49AD.6EAE5E0.5D3F4C44.IP)
- # [02:18] * ChanServ sets mode: +o surkov
- # [02:19] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [02:19] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
- # [02:21] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [02:23] <Jamie> hey surkov :)
- # [02:25] <@surkov> hey, Jamie!
- # [02:28] * Quits: @davidb (davidb@moz-A4A01B28.eng.wind.ca) (Ping timeout)
- # [02:29] * Joins: davidb (davidb@moz-6F9F653A.dsl.bell.ca)
- # [02:29] * ChanServ sets mode: +qo davidb davidb
- # [02:29] <@davidb> ishi all
- # [02:31] <@surkov> hi, davidb
- # [02:33] * Quits: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP) (Input/output error)
- # [02:34] <@hub> hi
- # [02:39] * Quits: muralisr92 (chatzilla@moz-511DFF61.spnp.nus.edu.sg) (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120129141257])
- # [02:50] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
- # [02:52] * Quits: Mook_as (mook@moz-1FCC0032.activestate.com) (Quit: ChatZilla 0.9.88-rdmsoft [XULRunner 1.9.2.13/20101203074205])
- # [02:53] * khuey is now known as khuey|away
- # [02:53] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [02:53] * Quits: tty234 (telex@moz-F9058B8A.net) (Ping timeout)
- # [03:01] <Jamie> hey davidb :0
- # [03:01] <@davidb> hi Jamie
- # [03:02] * Joins: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP)
- # [03:09] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Quit: nhirata)
- # [03:10] * Quits: jimm (jmathies@moz-7F164CA1.pn.at.cox.net) (Quit: )
- # [03:19] * Quits: shorlander_ (shorlander@moz-853043D6.dhcp.insightbb.com) (Quit: Quit)
- # [03:21] <@davidb> guys
- # [03:21] <@davidb> https://lists.mozilla.org/listinfo/accessibility
- # [03:21] <@davidb> surkov: ^
- # [03:21] <@hub> is that new?
- # [03:22] <@davidb> yes
- # [03:22] <@hub> sub'd
- # [03:22] <@davidb> good
- # [03:22] <@davidb> google seems slow to archive
- # [03:23] <@davidb> related bug is bug 721388
- # [03:23] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=721388 nor, --, ---, dgherman, RESO FIXED, New discussion forum: mozilla.accessibility
- # [03:23] <@surkov> davidb: what is this mail list for?
- # [03:23] <@davidb> surkov: sort of a long story, but everything to do with accessibility and the web
- # [03:24] <@surkov> ok
- # [03:24] <@davidb> i wish we had our own archives
- # [03:26] <@davidb> we might see Ken Saunders show up on channel one day soon
- # [03:26] <@davidb> he's going to help grow accessibility contribution at mozilla
- # [03:26] <@davidb> especially web sites contribution i think
- # [03:27] <@davidb> there is also satdav that will be overlapping i think
- # [03:27] <@davidb> i'll know more after the next meeting with David Boswell
- # [03:31] <Jamie> davidb: hmm. aren't there plenty of general web access lists around already? :)
- # [03:31] <@davidb> i expect these comments to come :)
- # [03:31] <Jamie> davidb: not that it really matters, just curious
- # [03:31] <Jamie> i.e. the motivation for creating a new one
- # [03:33] <@davidb> part of it is confusion
- # [03:33] <@davidb> we have some community members who want a list and were confused/ put off by "dev-"
- # [03:34] <@davidb> i know it is a bit funny
- # [03:34] <Jamie> davidb: sure, but surely that's Mozilla specific, no?
- # [03:34] <Jamie> as opposed to "general a11y"
- # [03:34] <@davidb> which?
- # [03:35] * khuey|away is now known as khuey
- # [03:35] <Jamie> davidb: It's just that "general" lists tend to end up being a forum for questions like "this web site is inaccessible, how do we fix it" and end up becoming less useflu than originally intended
- # [03:35] <Jamie> I'm sure you've already had all of these thoughts yourself, though :)
- # [03:35] <@davidb> that might happen
- # [03:35] <@davidb> an example discussion we might see on accessibility@mozilla is "support.mozilla.com needs a11y overhaul"
- # [03:35] <Jamie> davidb: Mm, I mean you said you had community members wanting an a11y list and didn't like dev-, but surely they were mozilla specific questions
- # [03:36] <Jamie> davidb: whereas this list is "general a11y"
- # [03:36] <@davidb> is it?
- # [03:36] <@davidb> i hope web related.
- # [03:36] <Jamie> err, ok, web a11y
- # [03:36] <Jamie> but not mozilla specific, unless I'm just misinterpreting
- # [03:36] <@davidb> i'm not sure how it will evolve
- # [03:37] <Jamie> "This is an informal forum for web accessibility topics. Please be excellent to each other." - I didn't see the word mozilla in there, hence my query
- # [03:37] <@davidb> ah!
- # [03:37] <@davidb> I can add one :)
- # [03:37] <Jamie> heh, woops. maybe we're on the same page now :)
- # [03:38] <@davidb> wow i didn't realize people actually read mailing list descriptions
- # [03:38] <Jamie> well, I guess you figured the fact that it's on lists.mozilla.org was enough. I misread because I know Mozilla are also open to making things better in general, not just for Mozilla
- # [03:38] <Jamie> davidb: haha. I am a perfectionist/thorough
- # [03:39] <@davidb> we are
- # [03:39] <Jamie> and a bit obsessive about efficiency, so I tend to read this stuff before I act
- # [03:39] <@davidb> open
- # [03:39] <@davidb> so in the back of my mind is the w3c wanting a list
- # [03:39] <Jamie> davidb: sure, I know, but my point was that that was why I wasn't sure what the list was for without the phrase "Mozilla and web accessibility" ro similar
- # [03:39] <@davidb> i suggested wai-xtech but meh
- # [03:40] <@davidb> Jamie: updated
- # [03:40] <Jamie> davidb: got it. clear. :)
- # [03:40] <@davidb> sorta
- # [03:41] <Jamie> davidb: sorry, wasn't being difficult, was quite sincerely confused
- # [03:41] <@davidb> maybe people will think it is just for mozilla websites now
- # [03:41] <Jamie> heh
- # [03:41] <@davidb> but let's see how it evolves
- # [03:41] <Jamie> so it's not just for mozilla web sites? :)
- # [03:41] * Jamie chuckles
- # [03:41] <Jamie> this ought to be interesting
- # [03:42] <@davidb> lol
- # [03:44] <Jamie> damn, found another bug in caret offset stuff
- # [03:45] * Jamie wishes fixing bugs was as easy as finding them
- # [03:46] <@davidb> caret is on my mind these days
- # [03:47] <Jamie> oh goody, it's not a firefox bug
- # [03:47] <Jamie> it's an NVDA bug
- # [03:47] <@davidb> i would have lost that bet
- # [03:47] * Jamie laughs
- # [03:48] <Jamie> No disrespect meant, but so would I
- # [03:48] <@davidb> lol
- # [03:48] <Jamie> firefox and caret just don't seem ot get along so well as firefox and other things a11y :)
- # [03:48] <@davidb> caret bugs are mostly in our layout module
- # [03:48] * Quits: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP) (Input/output error)
- # [03:52] * Joins: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP)
- # [03:53] <@davidb> surkov: do you have thoughts on bug 675685?
- # [03:54] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=675685 nor, --, ---, askalski, NEW, TextUpdater::DoUpdate computes Levenshtein Edit Distance inefficiently
- # [03:55] <@surkov> I didn't look yet
- # [03:59] <@davidb> shibby
- # [03:59] * Quits: @davidb (davidb@moz-6F9F653A.dsl.bell.ca) (Quit: davidb)
- # [03:59] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
- # [04:39] * Joins: nhirata (nhirata.bu@moz-2A9C9106.hsd1.ca.comcast.net)
- # [05:11] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
- # [05:11] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
- # [05:12] * Joins: aaronlev (chatzilla@moz-9058091D.bstnma.fios.verizon.net)
- # [05:24] <@firebot> surkov.alexander@gmail.com granted review for attachment 595422 on bug 721947.
- # [05:24] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=721947 nor, --, ---, hub, NEW, don't use nsIWeakShell
- # [05:25] * Quits: aaronlev (chatzilla@moz-9058091D.bstnma.fios.verizon.net) (Quit: ChatZilla 0.9.88 [Firefox 12.0a2/20120208042017])
- # [05:31] <@firebot> surkov.alexander@gmail.com granted review for attachment 595486 on bug 706134.
- # [05:31] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=706134 nor, --, ---, askalski, NEW, ARIA listitem shouldn't expose selectable state and pick up aria-selected and aria-checked
- # [05:38] <@firebot> surkov.alexander@gmail.com granted review for attachment 595446 on bug 539694.
- # [05:39] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=539694 nor, --, mozilla11, jigneshhk1992, ASSI, accessible objects should have private copy constructor
- # [05:45] * khuey is now known as khuey|away
- # [06:28] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
- # [06:39] * Quits: @hub (hub@83874EA1.EB7C1AF9.6F478678.IP) (Input/output error)
- # [06:48] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
- # [07:11] * Joins: MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net)
- # [07:11] * ChanServ sets mode: +o MarcoZ
- # [07:12] <@MarcoZ> Good morning all!
- # [07:15] <Jamie> MarcoZ: hi.
- # [07:15] <Jamie> MarcoZ: I can't reproduce your bug :(
- # [07:15] <Jamie> MarcoZ: however, I suspect it might be specific to the braille table you're using.
- # [07:16] <Jamie> MarcoZ: if it is, it's a bug in liblouis
- # [07:19] <@MarcoZ> Jamie: It's the German 8 dot braille table.
- # [07:22] <Jamie> MarcoZ: re gmail: I'll be it's another instance of bug 677154
- # [07:22] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=677154 nor, --, ---, nobody, NEW, Detached document accessibility tree
- # [07:22] <Jamie> bet*
- # [07:22] <Jamie> that bug is really serious and I'm seeing more and more of it
- # [07:22] <@MarcoZ> Jamie: I agree! Surkov, any progress in reproducing it with Jamie's profile?
- # [07:23] <@surkov> I didn't tried yet, sorry
- # [07:23] <@MarcoZ> surkov: If it is at all possible, please try it SOON. I believe this is a lurking problem that somehow gains exposure. :(
- # [07:24] * @MarcoZ updates the blog post.
- # [07:24] <@surkov> yes, I know
- # [07:25] <Jamie> MarcoZ: how do I repro this gmail problem?
- # [07:25] <Jamie> MarcoZ: I'll have a quick snoop
- # [07:27] <Jamie> MarcoZ: err, I still can't repro with german 8 dot
- # [07:27] <@MarcoZ> Jamie: Strange! I'll watch out for that braille problem and see if I find other STR to repro.
- # [07:27] <@MarcoZ> Jamie: Log into gmail, standard view, and allow it to switch to the newest version of their layout.
- # [07:28] <@MarcoZ> Jamie: For me, the last thing shown is the iframe where the search is in. Below it, the v buffer ends.
- # [07:28] <Jamie> MarcoZ: can you still repro with about: right now? as in... is it always reproable?
- # [07:28] <@MarcoZ> Jamie: Interesting enough, Dominic pointed out, and I have yet to verify this, if you turn off Google's single-letter keystrokes, the bug goes away.
- # [07:30] <Jamie> MarcoZ: yup, that's bug 6775COMError: (-2147418113, 'Catastrophic failure', (None, None, None, 0, None))
- # [07:31] <Jamie> err
- # [07:31] <Jamie> that's bug 677154
- # [07:34] <@firebot> New Core - Disability Access APIs bug 725572 filed by hub@mozilla.com.
- # [07:34] <@firebot> Bug 725572 was not found.
- # [07:43] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
- # [07:44] <@MarcoZ> Jamie: Thanks, I just updated the bug with this info and bumped priority and importance.
- # [07:44] * Joins: hub (hub@moz-E2FCA694.figuiere.net)
- # [07:44] * ChanServ sets mode: +o hub
- # [07:52] * Quits: @hub (hub@moz-E2FCA694.figuiere.net) (Ping timeout)
- # [08:39] <@firebot> New Core - Disability Access APIs bug 725581 filed by surkov.alexander@gmail.com.
- # [08:39] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725581 nor, --, ---, nobody, NEW, caretOffset for textarea should be -1 when textarea doesn't have a focus
- # [08:42] <@firebot> surkov.alexander@gmail.com requested review from trev.saunders@gmail .com for attachment 595669 on bug 725581.
- # [08:42] <@firebot> surkov.alexander@gmail.com changed the Status on bug 725581 from NEW to ASSIGNED.
- # [08:49] <@firebot> jigneshhk1992@gmail.com requested review from trev.saunders@gmail .com for attachment 595671 on bug 724452.
- # [08:49] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=724452 nor, --, ---, jigneshhk1992, NEW, use nsFocusManager::GetFocusManager() more
- # [09:03] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
- # [09:11] * Quits: Jamie (jamie@moz-CA26021.jantrid.net) (Quit: bye all)
- # [10:07] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
- # [10:35] * Joins: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com)
- # [10:41] * Quits: @tbsaunde (tbsaunde@moz-9DECD0.pc.cs.cmu.edu) (Ping timeout)
- # [10:44] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
- # [10:44] * Joins: tbsaunde (tbsaunde@moz-9DECD0.pc.cs.cmu.edu)
- # [10:45] * Quits: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com) (Quit: ChatZilla 0.9.88 [Firefox 13.0a1/20120208175111])
- # [10:57] * Joins: muralisr92 (chatzilla@moz-8D846020.dynip.nus.edu.sg)
- # [11:02] <muralisr92> marcoz: can i ask you some doubts regarding bug 702560 now??
- # [11:02] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=702560 nor, --, ---, murali.sr92, NEW, add a11y mochitest for HTML 5 contextmenu
- # [11:03] * ChanServ sets mode: +o tbsaunde
- # [11:08] * Parts: muralisr92 (chatzilla@moz-8D846020.dynip.nus.edu.sg)
- # [11:19] <@firebot> surkov.alexander@gmail.com granted review for attachment 595463 on bug 725178.
- # [11:19] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725178 nor, --, ---, tobbi.bugs, ASSI, get rid ensureAccessibleTree of common.js
- # [11:43] * Quits: @surkov (surkov@E3DF49AD.6EAE5E0.5D3F4C44.IP) (Ping timeout)
- # [11:51] * Joins: surkov (surkov@EB9D20A1.F78D7EEB.34044A7F.IP)
- # [11:51] * ChanServ sets mode: +o surkov
- # [11:55] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
- # [11:56] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
- # [11:56] * Quits: a-865 (fmcz@moz-A5D13CA.cable.mindspring.com) (Ping timeout)
- # [11:57] * Quits: JulienP (julien.pic@moz-DFEC0675.opera.com) (Ping timeout)
- # [11:58] * Joins: JulienP (julien.pic@moz-DFEC0675.opera.com)
- # [11:58] * Joins: a-865 (fmcz@moz-A5D13CA.cable.mindspring.com)
- # [12:43] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
- # [12:44] * Joins: jprmc (jprmc@moz-7F2FF3EB.cpe.net.cable.rogers.com)
- # [12:44] * ChanServ sets mode: +o jprmc
- # [13:08] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Connection reset by peer)
- # [13:18] * Quits: @MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net) (Quit: Reboot.)
- # [13:20] * Joins: MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net)
- # [13:20] * ChanServ sets mode: +o MarcoZ
- # [13:31] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
- # [13:31] * ChanServ sets mode: +o askalski
- # [13:31] <@askalski> hi everyone!
- # [13:51] * Quits: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP) (Input/output error)
- # [14:09] <@tbsaunde> hi a-865
- # [14:20] <@askalski> surkov, I wrote an email to older friend from University who PHDd on text algorithms, I wait for his answer on LED
- # [14:20] <@askalski> surkov, he will probably list me all options and we'll pick among them, ok?
- # [14:20] <@surkov> askalski: thanks for looking in deep
- # [14:20] <@surkov> that'd be great
- # [14:20] <@askalski> surkov, my pleasure
- # [14:51] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Ping timeout)
- # [14:52] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
- # [14:52] * ChanServ sets mode: +o askalski
- # [15:08] * Joins: davidb (davidb@F2D29657.F60B0462.67AC9B1.IP)
- # [15:08] * ChanServ sets mode: +qo davidb davidb
- # [15:08] <@davidb> hi all!
- # [15:12] <@MarcoZ> Hi davidb!
- # [15:13] <@askalski> davidb, hi!
- # [15:19] <@askalski> surkov, I patched the ARIA patch, should I add you to review again or not?
- # [15:20] <@surkov> aleiva: no, just upload the patch and I will land it
- # [15:22] <@tbsaunde> askalski: ^
- # [15:22] <@askalski> tbsaunde, yeah, got it
- # [15:22] <@askalski> surkov, done.
- # [15:22] <@surkov> thx
- # [15:23] <@surkov> thx, tbsaunde :)
- # [15:24] <@MarcoZ> davidb: With the mozconfigs now in central and other places, do we still need local .mozconfigs, or can we just specify some command line param to say "build me nightly"?
- # [15:25] <@davidb> good question!
- # [15:25] <@MarcoZ> davidb: OK, I'll ask in #build.
- # [15:25] <@tbsaunde> we should have fwer people in here so tabcomplete is easier =p
- # [15:25] <@davidb> :)
- # [15:25] <@davidb> tbsaunde: you are an op...
- # [15:26] <@surkov> askalski: please mark old patches as obsolette
- # [15:27] <@askalski> surkov, yeah, I forgot. is there a way to back to edition?
- # [15:27] <@surkov> click to details and then edit
- # [15:28] <@surkov> askalski: and please specify your name and comment when you upload the patch
- # [15:29] <@surkov> next time I mean
- # [15:29] <@askalski> name? in comment or where?
- # [15:30] <@surkov> askalski: if you use queues then do qref -m "commit comment" -u "your name <email>"
- # [15:30] <@MarcoZ> davidb: Got an answer, just point MOZCONFIG env variable to one that's in the repo.
- # [15:30] <@davidb> neat
- # [15:35] <@askalski> davidb, I am waiting for e-mail answer from some guys who phd in text algorithms towards LED. I can either start to implement my best idea or give them a day-two for answering and do something else in meanwhile. which one you prefer?
- # [15:36] <@davidb> askalski: what is LED?
- # [15:36] <@MarcoZ> Levenstein distance.
- # [15:36] <@askalski> Levenshteind distance
- # [15:36] <@davidb> ah
- # [15:36] <@davidb> askalski: hold off for the reply
- # [15:36] <@davidb> and yeah do something else :)
- # [15:37] <@davidb> got anything on your plate?
- # [15:37] <@askalski> davidb, ok, I'll look on ahoy and give you some propositions.
- # [15:37] <@askalski> davidb, no, two landing, two pending for consensus
- # [15:37] <@davidb> askalski: you don't have to restrict yourself to first bugs
- # [15:37] <@askalski> davidb, a script to loop mochitest 80% done
- # [15:37] <@davidb> surkov: do you have anything else in mind for askalski? ^
- # [15:38] * @davidb resists temptation to suggest caret bugs
- # [15:38] <@askalski> ok, I was planning to look for a bug on ahoy
- # [15:38] <@askalski> caret bugs?
- # [15:38] <@davidb> don't ask :)
- # [15:38] <@surkov> davidb: bug?
- # [15:38] <@davidb> surkov: yes a bug.
- # [15:39] <@davidb> i don't have a particular bug in mind yet
- # [15:39] <@surkov> davidb: sure, win64 bit support, implement 32bit unique ids
- # [15:39] <@davidb> good one!
- # [15:40] <@surkov> askalski: bug 606080
- # [15:40] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=606080 nor, --, ---, nobody, NEW, (64bit) fix unique id casting to NS_PTR_TO_INT32 issue
- # [15:43] * khuey|away is now known as khuey
- # [15:45] <@MarcoZ> Yeah that's a good one, and I believe 64-bit versions that will actually be released are coming closer...
- # [15:48] <@askalski> MarcoZ, you're telling me that f. ex. ubuntu still ships 32?
- # [15:48] <@askalski> (in 64 version)
- # [15:51] <@MarcoZ> askalski: I'm not sure whether this bug applies to all platforms or Windows only. I'd have to re-read the whole thing, but believe it specifically applies to the Windows version.
- # [15:51] <@MarcoZ> askalski: I think tbsaunde once mentioned that Firefox on GNOME is generally 64 bit, but better ask him ourselves again...
- # [15:51] <@askalski> surkov, to your last comment to this bug *606080 - you mention linear search?
- # [15:51] <@MarcoZ> askalski: Mac builds are definitely 64 bit.
- # [15:51] <@askalski> MarcoZ, thanks
- # [15:53] <@surkov> askalski: sounds so
- # [15:54] <@askalski> surkov, I guess that provided with some amount of memory I can construct some kind of partially ordered set to make put/lookup in log(n) time
- # [15:54] * Quits: victorporof (victorporo@C092FEB2.1C233438.79933D60.IP) (Connection reset by peer)
- # [15:56] <@surkov> yes, that's nice
- # [15:57] * Joins: victorporof (victorporo@C092FEB2.1C233438.79933D60.IP)
- # [15:57] <@surkov> askalski: can you estimate required memory for that, that could be bottleneck because we are going to keep there all objects
- # [15:59] <@askalski> surkov, let me think. I'll iterate among my ideas and come back to you ASAP. what time you finish today?
- # [16:00] <@surkov> askalski: I'm not sure, when I fall asleep :) just put into bug and I'll read it
- # [16:03] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
- # [16:03] <@askalski> surkov, I guess it will be linear, though we would need to do some overallocation like in vectors, so we don't pay reallocation penalty too often
- # [16:03] <@askalski> surkov, I can fight for getting constant as low as possible
- # [16:04] <@surkov> that's what we want, penalty should be small as possible because now AT gets these 32bit unique ids "for free"
- # [16:04] <@surkov> and I bet they can use it a lot
- # [16:04] <@askalski> surkov, the basic approach would be (size of data + sizeof(index)*amount of data), but I think it might be advisable to fight for cache optimisation
- # [16:05] <@askalski> surkov, AVL trees or black-red is the obvious solution, right?
- # [16:06] <@surkov> maybe not for me :)
- # [16:06] <@firebot> New Core - Disability Access APIs bug 725647 filed by sgautherie.bz@free.fr.
- # [16:06] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725647 maj, --, mozilla13, markcapella, ASSI, [SeaMonkey] mochitest-a11y: test_embeds.xul needs to support non-Firefox applications too
- # [16:07] <@firebot> sgautherie.bz@free.fr granted in-testsuite on bug 707654.
- # [16:07] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=707654 nor, --, mozilla12, surkov.alexander, RESO FIXED, embeds relation on root accessible can return not content document
- # [16:08] <@surkov> askalski: anyway, put some summary of your ideas into bug so I can get learn some necessary background if needed
- # [16:09] <@askalski> surkov, http://en.wikipedia.org/wiki/AVL_tree
- # [16:10] <@askalski> surkov, I think about creating a pair of such trees to provide two way mapping
- # [16:10] <@surkov> sounds good
- # [16:10] <@askalski> surkov, tell me where to place it and where to take memory from (probably not just wild alloc(), right?)
- # [16:11] <@askalski> surkov, all I need is alloc, realloc and free
- # [16:11] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
- # [16:11] <@surkov> askalski: put new files under msaa folder
- # [16:12] <@askalski> surkov, I was talking about function calls :)
- # [16:13] * @tbsaunde sees interesting happening ut got to stay away till 1200 :/
- # [16:14] <@surkov> askalski: we need some testing so probably they should live in base directory and then you can extend nsIAccessible to make them visible from js
- # [16:14] <@surkov> and then we can start to use that in MSAA
- # [16:14] <@askalski> surkov, btw, I can also use red-black trees, like STL does
- # [16:14] <@surkov> askalski: what's difference in two words?
- # [16:14] <@askalski> surkov, I am not sure if implementing log(n) mapping is nor reinventing the wheel
- # [16:15] <@askalski> surkov, AVL trees are more rigidly balanced than red-black trees, leading to slower insertion and removal but faster retrieval. (wiki) + AVL has lower memory footprint
- # [16:15] <@surkov> do you mean in gecko?
- # [16:15] <@surkov> always a trade
- # [16:17] * Joins: tty234 (telex@moz-F9058B8A.net)
- # [16:18] <@surkov> maybe we should prefer fast insertion and removal
- # [16:18] <@surkov> since that's going to happen everytime
- # [16:19] <@askalski> surkov, tbsaunde, I can either implement the mapping 64 <-> 32 with log(n) in all operations and log(n) memory usage OR create this pool of freeID as proposed by Trevor, I think also log(n) everything and O(n) space
- # [16:19] <@askalski> surkov, red-black are twice as much memory consuming
- # [16:20] <@askalski> surkov, acting pretty much as fast/slow as std::map
- # [16:20] * davidb is now known as davidb|mtg
- # [16:20] <@askalski> surkov, because this is the way it's implemented to my knowledge
- # [16:21] <@askalski> surkov, OR we can just use two std::map<int32, int64> and std::map<int64, int32> as mapping solution, two lines, no brainer
- # [16:24] <@surkov> askalski: btw, gecko has own hash tables, you might want to look
- # [16:24] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
- # [16:24] <@askalski> surkov, ok, I think that the problem is about having this reuse-pool
- # [16:24] <@askalski> I wrote such thins several years ago, I'll propose something
- # [16:24] <@surkov> ok
- # [16:26] <@askalski> surkov, tbsaunde, I'll write it now, and then I'd like someone to tutor me where to attach it to get the bug fixed, ok?
- # [16:26] <@surkov> sure
- # [16:29] * Joins: aaronlev (aaronlev@moz-CDA191A6.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com)
- # [16:30] * clown is now known as clown_mtg
- # [16:33] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
- # [16:48] <@tbsaunde> askalski: yeah, I think my idea there was generally constant time in good cases no idea about what real world performance wuld end up looking like
- # [16:49] <@tbsaunde> askalski: you could also consider splay trees :|
- # [16:49] * Joins: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP)
- # [16:49] <@askalski> tbsaunde, right now I was hacking about Interval Tree
- # [16:49] <@askalski> splay tree... which one was that
- # [16:49] <@tbsaunde> askalski: I'm really not sure what the right solution is, but if you propose something I can help with problems you have
- # [16:50] <@tbsaunde> rinterval tree?
- # [16:50] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
- # [16:50] <@tbsaunde> askalski: they are ... a bit weird read wikipedia
- # [16:50] <@askalski> tbsaunde, why?
- # [16:50] <@tbsaunde> they have the zig zag zig zag thing to move most recent used element to top
- # [16:51] <@askalski> ok
- # [16:51] <@tbsaunde> askalski: I don't remember the details
- # [16:57] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
- # [16:58] <@tbsaunde> askalski: btw I think a free pool can be O(1) creation of an id and then O(1) amortized for freeing an id
- # [16:58] <@askalski> tbsaunde, I see no such option yet
- # [16:58] <@askalski> splay trees you say?
- # [16:59] <@askalski> tbsaunde, to wikipedia, they amortise to log(n)
- # [17:00] <@tbsaunde> askalski: I think that's how you spell it
- # [17:00] <@tbsaunde> I thought they had something that was log(log(n))
- # [17:01] <@tbsaunde> askalski: I'm pretty sure I'm write about the bounds on a free pool
- # [17:01] <@askalski> tbsaunde, my idea right now is to enrich red-black trees with interval information as described in CORMEN
- # [17:01] <@tbsaunde> askalski: I see
- # [17:02] <@askalski> tbsaunde, is it OK? or should I dig more
- # [17:02] <@tbsaunde> askalski: if I'm write about the constant time bounds on a free pool I think it may be the right answer
- # [17:02] <@tbsaunde> askalski: I think a tree is fine if you tell me why you don't believe constant time free pool will work
- # [17:03] <@askalski> tbsaunde, balancing after deletion of empty nodes
- # [17:03] <@askalski> tbsaunde, I see no option to avoid this
- # [17:03] * khuey is now known as khuey|away
- # [17:03] <@tbsaunde> askalski: you don't need to balance them
- # [17:03] <@tbsaunde> askalski: you just have an array
- # [17:03] <@tbsaunde> and a min used number
- # [17:04] <@askalski> tbsaunde, en.wikipedia.org/wiki/Splay_tree
- # [17:04] <@tbsaunde> err, max used
- # [17:04] <@askalski> we
- # [17:05] <@askalski> tbsaunde, we're talking about a struct that has operations pick(), free(int) and that's it, right?
- # [17:05] <@tbsaunde> askalski: for a free pool yes, I'd call them allocate and free though
- # [17:06] <@tbsaunde> askalski: yes, that was the tree I was thinking of
- # [17:06] <@askalski> tbsaunde, so the first sentence states it's logarithmic and balanced
- # [17:06] * clown_mtg is now known as clown
- # [17:06] <@tbsaunde> ok
- # [17:07] <@tbsaunde> askalski: note I am not suggesting using a tree for a free pool since there is no reason to
- # [17:07] <@askalski> tbsaunde, but then they write it's used in garbage collectors etc, so sounds familiar...
- # [17:08] <@tbsaunde> askalski: well, the fast access for recently used nodes is a good feature
- # [17:08] <@tbsaunde> askalski: so, do you think my time bounds on a free pool using an array are correct?
- # [17:08] <@askalski> tbsaunde, do we need to ensure that the ID are as small as possible?
- # [17:08] <@tbsaunde> askalski: no
- # [17:09] <@askalski> tbsaunde, or just unique
- # [17:09] <@tbsaunde> askalski: just unique
- # [17:09] <@tbsaunde> how you deal with 2^32 + 1 objects is unclear
- # [17:09] <@askalski> tbsaunde, sure, just adding a element to the "free pool" is easy
- # [17:10] <@askalski> tbsaunde, yeah, but you can decrease it only by half at the best day, right?
- # [17:10] <@askalski> tbsaunde, because the worst case scenario is 1) allocate all 2) free all odd
- # [17:10] <@askalski> tbsaunde, and whatever you do, you're with 2^31 singletons
- # [17:11] <@tbsaunde> askalski: well, you can only decrease the pool size when you free the highest number
- # [17:11] <@tbsaunde> askalski: singletons?
- # [17:11] <@askalski> tbsaunde, set of size 1
- # [17:12] <@askalski> tbsaunde, the word singleton means set with single member in group theory
- # [17:12] <@askalski> tbsaunde, anyway, whatever we do, this worst case scenario kills it
- # [17:13] <@tbsaunde> askalski: yeah, I knew that just didn't understand what you meant
- # [17:13] <@tbsaunde> I see now
- # [17:13] <@askalski> tbsaunde, it's still pesimistic linear memory
- # [17:13] <@tbsaunde> askalski: true, do we care about that case though?
- # [17:14] <@askalski> tbsaunde, not really sure.
- # [17:15] <@davidb|mtg> speed!
- # [17:15] * davidb|mtg is now known as davidb
- # [17:15] <@davidb> speed speed speed
- # [17:15] <@tbsaunde> I tend to think not, but I'm uncomfortable just guessing
- # [17:15] <@askalski> davidb|mtg, we can do really miracles if we spend some more memory
- # [17:15] <@davidb> how much memory we talking?
- # [17:15] <@askalski> there are two options
- # [17:15] <@davidb> also i haven't read scrollback
- # [17:16] <@tbsaunde> askalski: on the other hand it has better memory size if the pool stays small
- # [17:16] <@askalski> either we go with 2*maxN
- # [17:16] <@askalski> so 32-64 mb...
- # [17:16] <@askalski> and it's deamn fast
- # [17:16] <@davidb> uhm
- # [17:16] <@askalski> or we go with balanced tree that removes non used nodes
- # [17:16] <@askalski> that is smaller for most of the time
- # [17:16] <@askalski> but worst case scenario is still as bad
- # [17:16] <@askalski> and we consume some time balancing tree
- # [17:18] <@askalski> or I can try to do some magic with shared-prefixes, but to such small sequences I would waste a lot of time (both computation and programming )and got not much in return
- # [17:18] <@tbsaunde> askalski: I wonder how hard it would be to write a free pool hook it in and see what it is like in real life browsing
- # [17:18] <@askalski> we're talking about worst case scenario, so 2^32 objects existing
- # [17:19] <@askalski> so if for example our object have some decent size, the machine would froze anyway
- # [17:19] * Quits: drexler (chatzilla@moz-2C2B7D1F.hsd1.vt.comcast.net) (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120129021758])
- # [17:19] <@tbsaunde> askalski: well, the worst case is more than that many accessibles in which case we are sort of screwed
- # [17:20] <@askalski> to be honest
- # [17:20] <@askalski> while considering only worst case scenarios
- # [17:20] <@askalski> your solution is optimal :)
- # [17:20] <@tbsaunde> askalski: well, for that worst case
- # [17:20] <@askalski> yes. I can do some savings in pool
- # [17:21] <@tbsaunde> but in the case you creat 2^32 accessibles and then free all but the last one its pecimal
- # [17:21] <@askalski> storing freed IDs in ranges
- # [17:21] <@askalski> or even storing all available IDs in ranges and keep the invariant
- # [17:21] <@askalski> of balancing the tree
- # [17:22] <@askalski> I don't know. we would use some info on what is the average number of objects
- # [17:22] <@tbsaunde> askalski: I'm not sure I understand what your suggesting
- # [17:23] <@askalski> my first idea was to keep a balanced tree representing free ranges (or occupied, no difference), and allow modifying it by "take" and "put" operation
- # [17:23] <@tbsaunde> askalski: life cycle patterns would also help
- # [17:23] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
- # [17:23] <@askalski> this can be done in log(n) where n is the number of objects
- # [17:23] <@askalski> (operations actually)
- # [17:23] <@askalski> (no, objects in tree)
- # [17:23] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
- # [17:24] <@askalski> having a tree gives me some footprint
- # [17:24] <@tbsaunde> askalski: well, the worst case for that is that each id is its own range
- # [17:24] <@askalski> true. then you have number of singleton + tree struct of linear size
- # [17:24] <@tbsaunde> if you keep the tree sorted merging ranges is easy other wise its slow
- # [17:25] <@askalski> I need to keep it sorted in all cases to have sub-linear deletion
- # [17:25] <@tbsaunde> true
- # [17:26] <@askalski> I have another idea
- # [17:26] <@askalski> most cases, the IDs will be freed in bunches
- # [17:26] <@askalski> like "101 objects removed"
- # [17:26] * Quits: nhirata (nhirata.bu@moz-2A9C9106.hsd1.ca.comcast.net) (Quit: nhirata)
- # [17:27] <@tbsaunde> askalski: well, yes sorrt of
- # [17:27] <@askalski> not necessarily they will be a valid range
- # [17:27] <@askalski> but there are data structures that allow fast melding to sets
- # [17:27] <@askalski> *two sets
- # [17:27] <@tbsaunde> we'll terar down a document when it goes away and that will cause a bunch of accessibles to go away, but we won't really know n accessibles with ids x y and z are going away
- # [17:27] <@askalski> I could use such struct to store all available numbers, producing more lazily if necessairy
- # [17:29] <@tbsaunde> askalski: this is union find?
- # [17:30] <@askalski> tbsaunde, no ,binomial heaps
- # [17:30] <@tbsaunde> oh hm
- # [17:30] <@askalski> find and union does not support divie
- # [17:30] <@askalski> *divide
- # [17:31] <@askalski> I was thinking of something like "ok, let's have a pool of 2046 free id's. if you need more, I'll lazily produce more"
- # [17:31] <@askalski> and also "oh, over 100 IDs have been freed, I guess I'll merge that bunch with a pool"
- # [17:31] <@tbsaunde> I see
- # [17:31] <@askalski> everything lazily, but with public triggers "ok, merge it now"
- # [17:32] <@askalski> that might be super fast, because the freed tree will be always kept small
- # [17:32] <@askalski> thus log(small) time footprint
- # [17:32] <@askalski> the tricky part is to get addressing function right, because binomial heaps are non-trivial
- # [17:33] <@tbsaunde> askalski: addressing function?
- # [17:33] <@askalski> tbsaunde, to have a tree in an array instead of pointers
- # [17:33] <@tbsaunde> I don't really remember if binomial heaps are different from a standard one
- # [17:33] <@askalski> it's easy in balanced-ary
- # [17:34] <@askalski> http://en.wikipedia.org/wiki/Binomial_heap
- # [17:34] <@askalski> I am talking about having two heaps each representing a pool of free numbers. one is the original and other is freed
- # [17:34] <@askalski> take new-id is "deletemin" on any of these
- # [17:34] <@askalski> release id is "add to smaller one"
- # [17:35] <@askalski> produce more is "create next subheap and merge it with bigger one"
- # [17:35] <@askalski> and "relax" is "merge small with big"
- # [17:35] <@askalski> it's sick complicated, but might be fast
- # [17:36] * Joins: shorlander (shorlander@moz-853043D6.dhcp.insightbb.com)
- # [17:36] <@tbsaunde> askalski: I see, that might be reasonable
- # [17:36] <@tbsaunde> but its complicated
- # [17:37] <@askalski> tbsaunde, I figured a problem
- # [17:37] <@askalski> tbsaunde, I need to remember which number haven't been produced yet, and it's only partially ordered
- # [17:37] <@askalski> but ... that can be done, just create them ordered
- # [17:37] <@askalski> I'll think about it more
- # [17:37] <@askalski> now I need to go for a lunchs
- # [17:37] <@askalski> *lunch
- # [17:37] <@tbsaunde> askalski: ok
- # [17:38] <@askalski> you can ask someone to review this idea
- # [17:38] <@tbsaunde> askalski: well, surkov should is reasonable
- # [17:39] <@askalski> surkov, can you read my idea from <askalski> I was thinking of something like "ok, let's have a pool of 2046 free id's. if you need more, I'll lazily produce more
- # [17:39] <@askalski> ?
- # [17:39] <@askalski> I am going now
- # [17:39] <@askalski> bye
- # [17:39] <@surkov> tbsaunde: do we have any telemetry data about amount of objects? no, right?
- # [17:40] <@tbsaunde> surkov: when I proposed that you said no ;p
- # [17:40] * khuey|away is now known as khuey
- # [17:40] <@tbsaunde> :)
- # [17:40] <@surkov> askalski: hard to say, but that's ok for the start
- # [17:40] <@surkov> tbsaunde: yep, right :)
- # [17:40] <@tbsaunde> surkov: but shouldn't be hard
- # [17:40] <@surkov> I said we need memory not amount
- # [17:40] <@surkov> maybe it makes sense to do
- # [17:41] <@surkov> at least temporary
- # [17:41] <@tbsaunde> surkov: yeah, just turns out those are fiarly coorilated
- # [17:41] <@tbsaunde> modulo doc accessibles being a lot bigger
- # [17:43] * Quits: webben (benjamin@moz-BA505DDD.static.cloud-ips.com) (Ping timeout)
- # [17:43] <@tbsaunde> surkov: askalski my one concern is if this is worth the extra time to implement
- # [17:44] <@surkov> tbsaunde: are you about pool or telemtry
- # [17:44] <@surkov> ?
- # [17:45] <@tbsaunde> surkov: about askalski's idea for a pool
- # [17:46] <@tbsaunde> surkov: telemetry is easy, though waiting for data will take a while
- # [17:46] <@surkov> well, I didn't follow you unfortunately to be helpful
- # [17:49] <@tbsaunde> surkov: ok
- # [17:52] * khuey is now known as khuey|away
- # [17:52] * Joins: hub (hub@83874EA1.EB7C1AF9.6F478678.IP)
- # [17:52] * ChanServ sets mode: +o hub
- # [17:52] * khuey|away is now known as khuey
- # [17:57] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
- # [17:59] * khuey is now known as khuey|away
- # [17:59] * khuey|away is now known as khuey
- # [18:01] <@MarcoZ> Good morning hub!
- # [18:01] * @MarcoZ is totally stumped by the discussion between askalski and tbsaunde. I must admit this went waaaaay over my head. LOL
- # [18:01] * @MarcoZ noticed he's getting old, with his computer science studies being 15 years behind him.
- # [18:02] <@hub> MarcoZ: I finished CS in university in 1995
- # [18:03] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
- # [18:03] <@MarcoZ> hub: What year were you born?
- # [18:05] <@firebot> marco.zehe@googlemail.com changed the Status on bug 723833 from RESOLVED to VERIFIED.
- # [18:05] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=723833 nor, --, mozilla13, surkov.alexander, RESO FIXED, IAccessibleText::setCaretOffset on location or search bar causes focus to jump
- # [18:15] <@firebot> hub@mozilla.com changed the Target Milestone on bug 672504 from --- to mozilla13.
- # [18:15] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=672504 nor, --, mozilla13, hub, ASSI, Don't keep pointer to weak presshell in accessible
- # [18:15] <@firebot> hub@mozilla.com changed the Target Milestone on bug 673405 from --- to mozilla13.
- # [18:15] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=673405 cri, --, mozilla13, hub, NEW, Rename GetDocAccessible() to Document()
- # [18:16] <@firebot> hub@mozilla.com changed the Target Milestone on bug 721947 from --- to mozilla13.
- # [18:16] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=721947 nor, --, mozilla13, hub, NEW, don't use nsIWeakShell
- # [18:16] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Quit: Wychodzi)
- # [18:23] * @MarcoZ crosses fingers
- # [18:36] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [18:38] * Joins: webben (benjamin@moz-BA505DDD.static.cloud-ips.com)
- # [18:46] * Quits: @surkov (surkov@EB9D20A1.F78D7EEB.34044A7F.IP) (Quit: surkov)
- # [18:53] * Joins: mib_jdp4rw (Mibbit@moz-211991B3.broadband10.iol.cz)
- # [18:54] <@tbsaunde> man, a minion would be great
- # [18:54] <khuey> srsly
- # [18:56] <@hub> MarcoZ: crossing even more fingers as the try build I had last night was carrying other patches from inbound and it was a bit orange.
- # [18:56] <@hub> I'm confident
- # [18:56] * @hub knock on wood
- # [19:00] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
- # [19:00] * Joins: drexler (chatzilla@moz-2C2B7D1F.hsd1.vt.comcast.net)
- # [19:01] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
- # [19:03] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
- # [19:03] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
- # [19:04] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
- # [19:04] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
- # [19:05] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
- # [19:06] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
- # [19:06] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
- # [19:06] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
- # [19:08] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
- # [19:10] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
- # [19:17] <@MarcoZ> hub: We'll see what happens! At least it didn't burn the tree, meaning it seems to compile OK! Now it just needs to pass tests without the leaks. :)
- # [19:23] <@firebot> bmo@edmorley.co.uk changed the Status on bug 539694 from ASSIGNED to RESOLVED.
- # [19:23] <@firebot> bmo@edmorley.co.uk set the Resolution field on bug 539694 to FIXED.
- # [19:23] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=539694 nor, --, mozilla11, jigneshhk1992, RESO FIXED, accessible objects should have private copy constructor
- # [19:35] * @MarcoZ is off for the evening. See you!
- # [19:35] * Quits: @MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net) (Quit: night!)
- # [19:36] * Parts: mib_jdp4rw (Mibbit@moz-211991B3.broadband10.iol.cz)
- # [19:36] <@firebot> New Firefox - Disability Access bug 725725 filed by sokiawri@wegwerfemail.de.
- # [19:36] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725725 nor, --, ---, nobody, UNCO, Javascript Security Error 1000 blocks functionalities like opening links in many website (including
- # [19:45] <@firebot> longsonr@gmail.com changed the Status on bug 725725 from UNCONFIRMED to RESOLVED.
- # [19:46] <@firebot> longsonr@gmail.com set the Resolution field on bug 725725 to DUPLICATE of bug 725634.
- # [19:46] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725634 cri, --, ---, nobody, NEW, Google Search results not working when cookies disabled
- # [19:48] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
- # [19:52] <@hub> Linux is green
- # [20:10] * Quits: @hub (hub@83874EA1.EB7C1AF9.6F478678.IP) (Ping timeout)
- # [20:49] * Joins: hub (hub@21B7B9F2.B87E9213.6E712CE2.IP)
- # [20:49] * ChanServ sets mode: +o hub
- # [20:52] <@hub> apparently Windows leak. I have no idea why this time
- # [20:52] <@hub> it is not in a11y
- # [20:52] <@tbsaunde> hub: if its not in mochitest-a11y it almost certainly isn't your fault
- # [20:53] <@tbsaunde> search bugzilla or wait for someone who has time to star it
- # [20:58] <@hub> yeah that'
- # [20:58] <@hub> what I think
- # [20:59] <@hub> it is on inbound anyway so the sheriffs will take care of it
- # [20:59] <@hub> cool
- # [20:59] <@hub> it got starred by philor
- # [21:00] <@hub> and android is bonkers, but that's almost expected
- # [21:06] <@davidb> looks like it stuck
- # [21:06] <@davidb> nice
- # [21:07] * @davidb reads about nsHTMLReflowState
- # [21:11] <@hub> now if I had a solution for my notifications on Mac :-/
- # [21:12] <@hub> trying to figure out what we do wrong
- # [21:12] <@tbsaunde> now we get to see how the weak ref to the doc does
- # [21:12] <@hub> tbsaunde: yeah that's why I wanted to land it
- # [21:12] <@tbsaunde> hub: what events does safari fire?
- # [21:12] <@tbsaunde> have you looked at what events webkit fires?
- # [21:15] <@hub> tbsaunde: yeah and I fire them too. they seems to not be taken into account
- # [21:24] <@tbsaunde> hub: weird
- # [21:26] <@tbsaunde> hub: can you build webkit on mac if so is it accessible and do the right thing?
- # [21:29] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
- # [21:32] <@firebot> bolterbugz@gmail.com requested feedback from bzbarsky@mit.edu for attachment 594239 on bug 495912.
- # [21:32] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=495912 nor, --, ---, bolterbugz, NEW, Expose alternative content in Canvas element to ATs
- # [21:55] * khuey is now known as khuey|away
- # [22:41] * Quits: @davidb (davidb@F2D29657.F60B0462.67AC9B1.IP) (Quit: davidb)
- # [22:47] * khuey|away is now known as khuey
- # [22:53] * Joins: aaronlev_ (chatzilla@moz-CDA191A6.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com)
- # [23:00] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
- # [23:14] * Quits: victorporof (victorporo@C092FEB2.1C233438.79933D60.IP) (Quit: Linkinus - http://linkinus.com)
- # [23:16] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Ping timeout)
- # [23:18] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
- # [23:22] * Joins: satdav (satdav@moz-1ECB932B.cable.virginmedia.com)
- # [23:23] <satdav> !seen davidb
- # [23:23] <@firebot> davidb was last seen 2 hours, 15 minutes and 58 seconds ago, saying '* davidb reads about nsHTMLReflowState' in #accessibility.
- # [23:23] <satdav> hey guys does anyone know if hes still about in the office
- # [23:26] <@hub> i'm not in Toronto
- # [23:27] <satdav> hub what one you in
- # [23:40] * Joins: Jamie (jamie@moz-CA26021.jantrid.net)
- # [23:42] <satdav> has anyone suscribed to the new mailing list
- # [23:43] <@hub> satdav: I'm in Vancouver.
- # [23:43] <@hub> and yes I subscribed to that list
- # [23:43] <satdav> OK
- # [23:43] <satdav> same
- # [23:49] * Joins: davidb (davidb@moz-6F9F653A.dsl.bell.ca)
- # [23:49] * ChanServ sets mode: +qo davidb davidb
- # [23:49] * Quits: @davidb (davidb@moz-6F9F653A.dsl.bell.ca) (Input/output error)
- # Session Close: Fri Feb 10 00:00:00 2012
The end :)