### Log session started at Thu Nov 29 00:00:00 2007 ### [00:02:05] bz: so, i hit that breakpoint 6 times loading the testcase; how do i choose which one? [00:02:16] (i set it at #2050) [00:03:04] ah, just saw your instructions, looking [00:03:38] <@bz> You could even set it at 2062 [00:04:24] well, locally I sure don't get a timeout [00:06:29] peterv [peterv@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [00:06:46] taras [taras@moz-99B4231C.gv.shawcable.net] has quit IRC: Ping timeout [00:08:07] bz: with s/aOuterReflowState/mBlockReflowState/ in your two conditions, it's the second breakpoint of the 6, and mMinLineHeight = 720 [00:10:35] wgianopoulos [gianopou@moz-7A06A043.hsd1.ma.comcast.net] has quit IRC: Quit: ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508] [00:12:04] Enn [enn@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [00:12:58] <@bz> dwitte: ok [00:13:06] <@bz> dwitte: good catch on the variable name [00:13:12] <@bz> dwitte: 720 is correct. That's 12px [00:13:15] <@bz> dwitte: ok... [00:13:27] <@bz> dwitte: what happens after that? ;) [00:13:33] hehe [00:13:35] dwitte steps [00:13:50] <@bz> In particular, what do we get for [00:13:53] <@bz> fontAscent [00:13:56] wgianopoulos [gianopou@moz-7A06A043.hsd1.ma.comcast.net] has joined #developers [00:13:57] <@bz> fontHeight [00:13:58] what was doing testing a week or two ago with really long timeouts? [00:14:22] Looks like the OS X normally does a test cycle in 15-20 minutes, but the oranges took 2 hours. :/ [00:14:37] dolske: our favorite OSX bug, of course! [00:14:46] oh, right! [00:14:51] :p [00:15:08] (assuming you mean xserve08) [00:15:27] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Connection timed out [00:15:37] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve11 Depend Debug + Leak Test' has changed state from Success to Test Failed. [00:15:40] Build 'Linux hoshi Clobber release' has dropped from the 'Mozilla1.8-SeaMonkey' tinderbox. [00:15:47] sayrer [chatzilla@moz-45994475.mountainview.mozilla.com] has quit IRC: Ping timeout [00:15:55] dwitte: qm-xserve01, actually. [00:16:31] oh. i thought we tested with 08? [00:16:41] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has joined #developers [00:16:41] if i'm right, must've been something else [00:16:56] joduinn-dinner [joduinn@moz-E31CD2CB.mozilla.org] is now known as joduinn [00:18:15] bz: 720 & 900 [00:18:28] dwitte: no, it's qm-xserve01 that's taking 2 hours today to show orange on this test timeout. [00:19:05] dolske: yeah, we only messed with bm-xserve08 on that bug. [00:19:10] myk [chatzilla@moz-8D033489.hsd1.ca.comcast.net] has joined #developers [00:19:29] <@bz> dwitte: hmm [00:19:43] <@bz> dwitte: 900 is fontHeight ? [00:19:55] bz: yup [00:20:27] <@bz> huh [00:20:44] <@bz> ok [00:20:51] <@bz> so we compute leading as -180 ? [00:20:57] sayrer [chatzilla@moz-45994475.mountainview.mozilla.com] has joined #developers [00:21:33] bz: so loading a data: URI from a bookmark is always safe? [00:21:40] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve11 Depend Debug + Leak Test' has changed state from Test Failed to Success. [00:21:54] <@bz> philor: define "safe"? It loads it with a one-off null principal [00:22:01] <@bz> dwitte: leading is -180? [00:22:15] bz: checking... [00:22:36] koifans [chatzilla@moz-73B1F9C1.vc.shawcable.net] has joined #developers [00:22:39] <@bz> dwitte: and yTop ends up -630, I assume? [00:22:55] <@bz> dwitte: with yBottom being 90? [00:23:06] ted [ted@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: ted [00:23:10] <@bz> Now what are minY and maxY at that point? [00:23:34] <@bz> and actually, what line are you on? ;) [00:23:53] bz wants to make sure we're on the same page [00:24:01] Mossop [Mossop@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: Fleeing the scene... [00:24:48] bz: "safe: no firedrill 3.0.0.1 could result from any data URI which was once loaded being loaded again from a bookmark at some later time" [00:25:53] I'm so confused - we CheckLoadURI with DISALLOW_INHERIT_PRINCIPAL, which says no to data:, before creating item bookmarks, but data: doesn't actually inherit? [00:25:56] and now I've run the mochitest locally with my test included without trouble, I'll take a look tomorrow again [00:25:59] bz: grumble, i'm running into "values optimized out" stuff here, something to do with fx's default config... [00:26:08] bz: but i've pieced it together, your 3 values are right [00:26:42] i'm on 2103 [00:27:39] wait, 2106 ;) [00:27:55] schrep_ [Mike@moz-7542B0EB.dsl.static.sonic.net] has quit IRC: Ping timeout [00:29:16] woot woot [00:29:24] mw22: it was your patch [00:29:28] mac just went green [00:29:30] well, your test [00:29:42] ok [00:29:43] Firefox: 'MacOSX Darwin 8.8.4 qm-xserve01 dep unit test' has changed state from Test Failed to Success. [00:29:57] but it sucks that I can't reproduce it myself [00:29:59] <@bz> philor: inherit what where how? [00:30:07] peterv [peterv@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [00:30:09] <@bz> philor: checkLoadURI checks the target URI [00:30:23] ok, I'm landing now [00:30:25] <@bz> dwitte: What are minY and maxY there before we set them? [00:30:31] bz: minY/maxY -120/120 before the two |if|s @ 2105 [00:30:39] <@bz> ok [00:30:41] <@bz> And after? [00:31:04] -630/120 [00:31:18] Ryan_ [rflint@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [00:31:41] <@bz> aha [00:31:44] <@bz> there you are [00:31:50] <@bz> that's where the 12.5px comes from [00:32:14] dietrich [dietrich@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: dietrich [00:32:15] 750 rounds to 12.5px, or something? [00:32:23] <@bz> 750 is 12px [00:32:27] <@bz> 1px is 60 [00:32:32] <@bz> er, 12.5px [00:32:37] <@bz> So 12px is 720 [00:32:38] gotcha [00:32:40] <@bz> ok [00:32:41] <@bz> so... [00:32:44] <@bz> What happened here [00:32:49] caytchen [caytchen@moz-C2830356.pool.einsundeins.de] has quit IRC: Quit: Verlassend [00:32:51] <@bz> we had a line-height of 12px [00:33:06] <@bz> And before we started this whole thing we had a minY of -2px and a maxY of 2px [00:33:25] <@bz> That comes from the "font: 2px/4px serif" part [00:33:50] <@bz> 2px because of the font size, and -2px because of the extra 2 in the line-height [00:33:53] <@bz> So far so good. [00:34:05] <@bz> Now we ask our font metrics for info [00:34:09] <@bz> for our, if you recall, 12px font [00:34:23] <@bz> Our font metrics come back with an ascent of 12px and a total height of 15px [00:34:55] <@bz> Giving us -3px of leading [00:35:23] <@bz> We apparently divvy that up half-and-half [00:36:14] <@bz> So we set yTop to -10.5px (the ascent, minus half the leading) [00:36:31] sayrer: ping? [00:36:33] <@bz> And yBottom to 1.5px (yTop + 12px) [00:36:50] sayrer [chatzilla@moz-45994475.mountainview.mozilla.com] has quit IRC: Ping timeout [00:37:09] <@bz> So we end up overall with minY at -10.5 and maxY at 2 [00:37:11] <@bz> hrm [00:37:19] <@bz> you want to comment in the bug, or should I? [00:37:41] seems like you know what's going on better than i ;) [00:37:43] <@bz> ok [00:37:46] <@bz> I'll comment.... [00:39:43] so is this an issue with the logic / divvying we're using? and if so, howcome we don't see this on other plats? (presumably the font metrics are different?) [00:40:20] <@bz> I think it's an issue with a 15px font being returned when we asked for a 12px one [00:40:34] <@bz> As best I understand the font metrics mess... [00:40:56] Enn [enn@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [00:42:36] chro [rhg_xu@D14E8F0D.A43DD08.393EA42D.IP] has joined #developers [00:42:52] hello, everybody [00:43:06] I am newer on firefox hacker [00:43:31] Mnyromyr [MnyroWork@moz-E0F31C11.tal.de] has joined #developers [00:43:40] bz: okay, I guess it's just collateral damage from our use of disallow_inherit_principal to mean disallow_javascript:_and_any_future_scary_thing_as_a_bookmark [00:43:56] <@bz> hmm? [00:44:01] <@bz> What's collateral damage? [00:44:02] I use rhel5 compile firefox 2.0.0.9 with debug, but when I debug it, I meet big trouble, please help me [00:44:12] <@bz> disallow_inherit_principal disallows javascript: and data: at the moment [00:44:20] <@bz> chro: details? [00:44:40] that we won't add a bookmark to a data: URI that we find in a feed, even though you're saying it wouldn't actual inherit a principal when loaded from a bookmark [00:44:51] maikmerten [merten@moz-9D8BA0A0.cs.uni-dortmund.de] has joined #developers [00:44:52] <@bz> Ah [00:44:54] <@bz> yeah [00:44:54] <@bz> indeed [00:45:18] <@bz> well, I'm not sure it wouldn't [00:45:24] <@bz> if you load it over top of an existing page, it might [00:45:35] I set breakpoint on nsXBLStreamListener::Load module [00:45:40] bz misudenrstood how you were loading it earlier [00:46:02] <@bz> misunderstood, even [00:46:07] Build 'WINNT 5.1 tpol Clobber release' has dropped from the 'Mozilla1.8-SeaMonkey' tinderbox. [00:46:19] when I step to nsXBLBindingRequest* req = (nsXBLBindingRequest*)mBindingRequests.ElementAt(0); [00:46:48] okay, I'll put exhaustive STR in the bug, maybe that'll help [00:48:43] I want to view nsXBLBindingRequest::mBoundElement NodeInfo for this element, but I dig to deeper pointer, but cannot get it [00:49:27] petea [petea@F7BDB098.FC63495D.2321E71E.IP] has joined #developers [00:49:44] bz: thanks for the help. ;) [00:50:58] <@bz> chro: what exact commands are you using? [00:51:01] <@bz> dwitte: thank _you_ [00:53:10] I use gdb p req->mBoundElement->mRawPtr->Tag() [00:54:34] Anatolik [tolikk@5176CC8E.38BB09A6.1FCE22BB.IP] has joined #developers [00:55:00] <@bz> Ok [00:55:01] <@bz> and it returns? [00:55:03] it say "return (class nsIAtom *) pointer" , but the class of pointer have not correct method to get element name, I am curious [00:55:12] <@bz> well [00:55:16] <@bz> it's a virtual base class [00:55:21] <@bz> I suggest "set print object on" [00:55:25] <@bz> and trying again [00:57:49] tH_ [Rob@adsl-87-102-34-33.karoo.KCOM.COM] has joined #developers [00:57:59] ok , I try it , now it return "(nsStaticAtomWrapper *) 0x811c2f8", I will continue try , thanks you very much bz: [00:58:07] tH_ [Rob@adsl-87-102-34-33.karoo.KCOM.COM] is now known as tH [00:59:38] what got changed in the last 24 hours that makes build take forever? [00:59:52] <@bz> chro: no problem [00:59:55] <@bz> chro: fwiw [01:00:12] <@bz> def satom [01:00:12] <@bz> p *((class nsStaticAtomWrapper*)$arg0)->mStaticAtom [01:00:12] <@bz> end [01:00:21] <@bz> Then satom req->mBoundElement->mRawPtr->Tag() [01:01:28] Ryan_ [rflint@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [01:03:14] that you input "satom" mean what, I donot understand, I have poor english, please make me clear [01:04:26] <@bz> You can define a macro for seeing the value of static atoms [01:04:35] <@bz> if you end up doing a lot of Gecko debugging, you'll want it [01:04:38] <@bz> for now, don't worry about it [01:05:21] ok , I got it, thanks a lot [01:06:05] mw22 [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] has quit IRC: Ping timeout [01:06:51] mw22_ [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] has joined #developers [01:07:09] mw22_ [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] is now known as mw22 [01:08:14] bz [bzbarsky@moz-C9A4D477.dsl.chcgil.sbcglobal.net] is now known as bz_sleep [01:11:22] sayrer [chatzilla@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [01:11:23] sayrer [chatzilla@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Client exited [01:11:44] darin [darin@moz-CD91E596.google.com] has joined #developers [01:15:07] bz: I want ask you another question [01:15:09] Mook [mook@moz-13092AE3.dsl.pltn13.pacbell.net] has quit IRC: Ping timeout [01:15:15] are you here? [01:17:49] I want to print req->mBindingURL url name, but it is "nsCOMPtr" type, it is "interface nsIURL : nsIURI" [01:18:42] <@bz_sleep> chro: yes [01:18:58] I can not access "attribute AUTF8String filePath;", it is why, [01:19:16] <@bz_sleep> chro: set print object on should tell you te type of req->mBindingURL.mRawPtr, no? [01:19:48] <@bz_sleep> In C++ that's a GetFilePath method [01:20:28] chewey_ [chewey@moz-B22104C1.dip.t-dialin.net] is now known as chewey [01:21:02] ok, yes , I print it , it display correct type, thank you again, [01:21:55] I delay you rest, sorry for it, thank you again [01:22:21] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Burning to Test Failed. [01:23:10] gavin__ [gavin@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [01:23:17] blassey [blassey@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [01:23:31] Ryan_ [rflint@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [01:23:58] <@bz_sleep> You're welcome [01:24:03] bz_sleep sleeps for real [01:24:27] stephend [stephend@moz-269E8BF7.hsd1.ca.comcast.net] has joined #developers [01:24:34] dietrich [dietrich@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [01:24:52] smaugZzz [chatzilla@moz-DDD2A5AD.pp.htv.fi] is now known as smaug [01:24:59] wolfiR [wolfiR@moz-9CF12453.dip0.t-ipconnect.de] has joined #developers [01:30:50] brendan_ [brendaneic@moz-37758455.hsd1.ca.comcast.net] has joined #developers [01:31:44] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Ping timeout [01:34:19] midnightaz [chatzilla@155526C9.F50E6DAB.3D0C8E44.IP] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504] [01:36:23] darin [darin@moz-CD91E596.google.com] has quit IRC: Quit: Leaving [01:36:48] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has joined #developers [01:37:45] brendan_ [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Ping timeout [01:42:19] davida [dascher@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [01:44:45] peterv [peterv@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [01:45:17] surkov [chatzilla@moz-C9017CC8.icc.ru] has quit IRC: Ping timeout [01:50:32] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Test Failed to Success. [01:51:20] nattokirai [jdaggett@moz-4AF8B077.dsl.snfc21.pacbell.net] has quit IRC: Quit: nattokirai [01:53:47] abwillis [abwillis@moz-AB2CBE3D.hlrn.qwest.net] has quit IRC: Client exited [01:57:20] dveditzAway [dveditz@moz-530FA17.cruzio.com] is now known as dveditz [01:57:45] ChanServ [services@mozilla.org] has set mode +o dveditz [02:08:35] deb00t [Miranda@moz-4319B9E7.t-com.sk] has joined #developers [02:09:14] glazou [daniel@moz-204094DD.disruptive-innovations.fr] has joined #developers [02:09:16] bonjour [02:13:47] bonsoir [02:19:38] karlt [karl@moz-334F2010.mountainview.mozilla.com] has joined #developers [02:19:59] huomenta [02:23:47] gavin__ [gavin@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [02:25:23] zwnj [behnam@D45EABFC.52777A3A.8944D239.IP] has quit IRC: Quit: Leaving. [02:26:02] zwnj [behnam@D45EABFC.52777A3A.8944D239.IP] has joined #developers [02:27:04] stephend [stephend@moz-269E8BF7.hsd1.ca.comcast.net] has quit IRC: Quit: stephend [02:35:21] surkov [chatzilla@B5C852AC.56B80CFD.5B715A5B.IP] has joined #developers [02:35:22] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Connection reset by peer [02:35:44] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [02:35:46] Tomcat_ [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [02:36:45] Tomcat [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [02:36:50] Tomcat_ [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] is now known as Tomcat [02:38:50] Firefox: 'WINNT 5.1 qm-winxp01 dep unit test' has changed state from Test Failed to Success. [02:38:58] gavin__ [gavin@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [02:39:06] dietrich [dietrich@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [02:40:09] reed [reed@tech.monkey] has quit IRC: Quit: --> out until Dec. 10th or so... if needed, e-mail/IM/call/etc. [02:42:38] stransky [stransky@moz-2952D2D0.redhat.com] has joined #developers [02:42:39] Wes [chatzilla@moz-BEF0C255.page.ca] has quit IRC: Max SendQ exceeded [02:42:46] Tomcat [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [02:43:22] davida [dascher@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: davida [02:44:36] faaborg [faaborg@moz-F53C9D9B.hsd1.ca.comcast.net] has joined #developers [02:44:49] dietrich [dietrich@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [02:44:55] Tomcat_ [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [02:45:22] Tomcat_ [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] is now known as Tomcat [02:47:54] philor [ringnalda@moz-55B07213.eug.or.uspops.net] has quit IRC: Ping timeout [02:48:55] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve11 Depend Debug + Leak Test' has changed state from Success to Burning. [02:48:58] Firefox: 'Linux fx-linux-tbox Depend Nightly' has changed state from Success to Burning. [02:49:12] sicking: damnit [02:49:25] sicking: dude you said you were going to land hours ago :( [02:50:56] Firefox: 'MacOSX Darwin 8.8.4 qm-xserve01 dep unit test' has changed state from Success to Burning. [02:50:59] Firefox: 'Linux qm-centos5-01 dep unit test' has changed state from Success to Burning. [02:51:15] Simon [Simon@moz-24AE7147.range86-141.btcentralplus.com] has joined #developers [02:52:46] laurentj [laurentj@moz-204094DD.disruptive-innovations.fr] has joined #developers [02:54:57] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Success to Burning. [02:55:00] Thunderbird: 'WINNT 5.2 tbnewref-win32- Depend release' has changed state from Success to Burning. [02:55:11] zwnj [behnam@D45EABFC.52777A3A.8944D239.IP] has quit IRC: Quit: Leaving. [02:56:35] sicking: are you on the red? [02:56:58] Firefox: 'WINNT 5.1 qm-winxp01 dep unit test' has changed state from Success to Burning. [02:57:01] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve08 Depend Universal Nightly' has changed state from Success to Burning. [02:58:59] Firefox: 'WINNT 5.2 fx-win32-tbox Depend Nightly' has changed state from Success to Burning. [02:59:44] the tree is looking very festive! [03:00:13] poor dietrich, I hope he's asleep already. :P [03:00:54] roc [roc@moz-5FBC55BC.dsl.telstraclear.net] has joined #developers [03:00:59] SeaMonkey: 'MacOSX Darwin 8.8.1 cb-xserve02 Depend Universal Nightly' has changed state from Success to Burning. [03:01:02] Thunderbird: 'MacOSX Darwin 8.8.4 bm-xserve09 Depend Universal Nightly' has changed state from Success to Burning. [03:01:42] jwatt [roslea@jwatt.irc.users.mozilla.org] has quit IRC: Ping timeout [03:02:18] yeah [03:02:21] I'm going to call sicking in a minute [03:03:01] Firefox: 'Linux fxdbug-linux-tbox Depend' has changed state from Success to Burning. [03:03:14] biesi [cbiesinger@32FA898A.65A91F68.C521C193.IP] has quit IRC: Ping timeout [03:03:28] he landed a fix didn't he ? [03:03:33] ah, yeah, just now [03:03:40] at least I just saw it [03:03:49] yay bonsai/tinderbox [03:05:01] SeaMonkey: 'Linux cb-sea-linux-tbox Depend Nightly' has changed state from Success to Burning. [03:08:21] Tomcat [Tomcat@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Connection reset by peer [03:09:03] Firefox: 'WINNT 5.2 fxdbug-win32-tb Depend Debug + Leak Test' has changed state from Success to Burning. [03:09:10] karlt [karl@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [03:11:03] Camino: 'MacOSX Darwin 8.10.0 boxset Depend CmTrunk' has changed state from Success to Burning. [03:11:05] Build 'MacOSX Darwin 8.10.1 cb-xserve01 Depend Cm1.5.4' has dropped from the 'Camino' tinderbox. [03:11:07] Build 'MacOSX Darwin 8.10.1 cb-xserve01 Depend Cm1.0-M1.8.0' has dropped from the 'Camino' tinderbox. [03:12:21] "sicking landed" [03:14:52] mw22_ [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] has joined #developers [03:16:41] mw22 [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] has quit IRC: Ping timeout [03:16:46] mw22_ [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] is now known as mw22 [03:16:50] dolske [dolske@moz-F8EC3862.hsd1.ca.comcast.net] has quit IRC: Ping timeout [03:17:05] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve11 Depend Debug + Leak Test' has changed state from Burning to Test Failed. [03:17:24] stransky [stransky@moz-2952D2D0.redhat.com] has quit IRC: Ping timeout [03:20:03] kirschkern [Daniel_Kir@moz-D0597FF7.dip.t-dialin.net] has joined #developers [03:21:48] Is anyone working on the clipboard interface? hasDataMatchingFlavors throws an error "NOT_ENOUGH_ARGS" with the latest trunk. see bug 405947 [03:22:33] dolske [dolske@moz-F8EC3862.hsd1.ca.comcast.net] has joined #developers [03:23:07] Firefox: 'MacOSX Darwin 8.8.4 qm-xserve01 dep unit test' has changed state from Burning to Test Failed. [03:25:04] sicking: tbox orange is a fatal assertion " ###!!! ASSERTION: Shallow unbind won't clear document and binding parent on kids!: 'aDeep || (!GetCurrentDoc() && !GetBindingParent())', file /builds/tinderbox/Fx-Trunk-test_mem/Darwin_8.8.4_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2086" [03:27:11] Firefox: 'Linux fx-linux-tbox Depend Nightly' has changed state from Burning to Success. [03:29:59] jwatt [roslea@jwatt.irc.users.mozilla.org] has joined #developers [03:31:12] mayhemer [Miranda@moz-E61C758C.ip.b26.cz] has quit IRC: Connection reset by peer [03:32:12] stransky [stransky@moz-2952D2D0.redhat.com] has joined #developers [03:35:11] Firefox: 'WINNT 5.2 fx-win32-tbox Depend Nightly' has changed state from Burning to Success. [03:35:33] roc: hey [03:35:33] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Connection reset by peer [03:35:47] you had a blog entry somewhere about zoom/text/pixels [03:35:58] or at least bz said there was some blog chain between you and glaozu [03:36:01] gah, glazou [03:36:02] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [03:36:05] lelik52 [Lelik@84E95C8D.29975E35.62494813.IP] has joined #developers [03:36:25] any suggestions for how i could find that? :) [03:36:50] timelyx: uh ? [03:38:09] i just need a way to invalidate/wontfix https://bugs.maemo.org/attachment.cgi?id=560&action=edit and bz said you two had some discussion in blogs [03:39:14] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Burning to Test Failed. [03:39:17] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve08 Depend Universal Nightly' has changed state from Burning to Success. [03:39:44] caillon [caillon@moz-2952D2D0.redhat.com] has joined #developers [03:41:15] Thunderbird: 'MacOSX Darwin 8.8.4 bm-xserve09 Depend Universal Nightly' has changed state from Burning to Success. [03:41:18] Thunderbird: 'WINNT 5.2 tbnewref-win32- Depend release' has changed state from Burning to Success. [03:41:27] kirschkern: I commented in the bug [03:44:13] peepo [Jay@moz-2D3CC6D6.range86-153.btcentralplus.com] has joined #developers [03:45:16] Firefox: 'MacOSX Darwin 8.8.4 bm-xserve11 Depend Debug + Leak Test' has changed state from Test Failed to Success. [03:45:28] hi [03:46:50] Hamaryns [hamaryns@moz-D5DD1388.sfb.uni-tuebingen.de] has joined #developers [03:48:00] kiko [kiko@F9C12DED.EB611C7.358EBA0.IP] has joined #developers [03:49:18] Firefox: 'Linux qm-centos5-01 dep unit test' has changed state from Burning to Test Failed. [03:49:21] Firefox: 'Linux fxdbug-linux-tbox Depend' has changed state from Burning to Test Failed. [03:50:04] miksago [miksago@moz-B0B9DA8E.dyn.iinet.net.au] has joined #developers [03:51:45] James Ross? Has he a nick here? [03:51:53] hi all, btw [03:53:01] hi [03:53:20] NeilAway: Thanks for the info. Added a comment too. [03:53:25] firebot: silver [03:53:27] smontagu: I have heard that silver is James Ross, mailto:silver@warwickcompsoc.co.uk [03:53:42] Hamaryns: ^^ [03:54:22] smontagu, thanks, but I don’t want to mail him, it’s not that important [03:54:34] ah, you mean silver is his nick as well [03:54:43] :) [03:54:52] hm, how can I tell firebot who I am? [03:55:05] firebot: help [03:55:07] Hamaryns: help info /msg'ed [03:55:19] kirschkern: good point, I'll add the dev-doc-needed keyword to the original bug [03:55:32] firebot: Hamaryns [03:55:37] NeilAway: Sorry, I've no idea what 'Hamaryns' might be. [03:55:42] NeilAway: thebot knew: iirc, Hamaryns is sorry for the patches, I saw your comment only just now [03:55:52] lol [03:56:08] ??? I didn’t tell him that [03:56:13] jpb [chatzilla@moz-DF053F63.cse.bris.ac.uk] has joined #developers [03:56:25] firebot: thebot [03:56:26] Hamaryns: I have heard that thebot is a bot whose infobot database is full of useless crap [03:56:32] lol [03:56:45] firebot: you got that one right [03:56:50] smontagu: Sorry, I've no idea what 'you got that one right' might be. [03:57:35] firebot Hamaryns [03:57:50] firebot: Hamaryns [03:58:03] Hamaryns: you are sorry for the patches, I saw your comment only just now [03:58:04] Hamaryns: you are sorry for the patches, I saw your comment only just now [03:58:26] biesi [cbiesinger@32FA898A.65A91F68.C521C193.IP] has joined #developers [03:58:42] firebot: who Hamaryns [03:58:46] Hamaryns: Sorry, I've no idea what 'who Hamaryns' might be. [03:59:01] !who Hamaryns [03:59:09] !seen silver [03:59:10] silver was last seen 2 weeks, 6 days, 10 hours, 27 minutes and 57 seconds ago, saying 'Nice!' in #chatzilla. [03:59:28] Firefox: 'WINNT 5.1 qm-winxp01 dep unit test' has changed state from Burning to Test Failed. [04:00:05] Hamaryns: long dialogs with firebot are better done by /msg [04:00:28] yes, sorry, but I still don’t find how to make it tell something like for silver [04:00:51] firebot: Hamaryns is Hendrik Maryns [04:00:53] smontagu: But Hamaryns is 'sorry for the patches, I saw your comment only just now'... [04:00:59] firebot: no, Hamaryns is Hendrik Maryns [04:01:00] smontagu: ok [04:01:04] NeilAway: What is the original bug? any id? [04:01:10] aha, cheers [04:01:18] 374347 [04:02:03] OK. Thanks [04:02:23] miksago [miksago@moz-B0B9DA8E.dyn.iinet.net.au] has quit IRC: Connection reset by peer [04:02:34] Hamaryns [hamaryns@moz-D5DD1388.sfb.uni-tuebingen.de] has quit IRC: Quit: Salu, hé. [04:05:25] Archaeopteryx [itsme@moz-B6884483.pools.arcor-ip.net] has joined #developers [04:05:29] Firefox: 'WINNT 5.2 fxdbug-win32-tb Depend Debug + Leak Test' has changed state from Burning to Test Failed. [04:07:30] Firefox: 'MacOSX Darwin 8.8.4 qm-xserve01 dep unit test' has changed state from Test Failed to Success. [04:08:20] Gijs [Hannibal@moz-56384856.direct-adsl.nl] has joined #developers [04:08:55] deb00t [Miranda@moz-4319B9E7.t-com.sk] has quit IRC: Connection reset by peer [04:11:31] Camino: 'MacOSX Darwin 8.10.0 boxset Depend CmTrunk' has changed state from Burning to Success. [04:17:33] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Test Failed to Burning. [04:17:49] deb00t [Miranda@moz-4319B9E7.t-com.sk] has joined #developers [04:20:59] deb00t [Miranda@moz-4319B9E7.t-com.sk] has quit IRC: Ping timeout [04:28:41] koifans [chatzilla@moz-73B1F9C1.vc.shawcable.net] has quit IRC: Ping timeout [04:30:58] kiko [kiko@F9C12DED.EB611C7.358EBA0.IP] is now known as kiko-afk [04:35:51] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Connection reset by peer [04:36:03] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [04:37:29] joduinn [joduinn@moz-E31CD2CB.mozilla.org] is now known as joduinn-zzz [04:38:06] Firefox: 'Linux qm-centos5-01 dep unit test' has changed state from Test Failed to Success. [04:45:37] stevee [Miranda@moz-33D212DB.sotn.cable.ntl.com] has joined #developers [04:46:09] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Burning to Success. [04:46:14] Firefox: 'Linux fxdbug-linux-tbox Depend' has changed state from Test Failed to Success. [04:47:09] deb00t [Miranda@moz-4319B9E7.t-com.sk] has joined #developers [04:49:20] Gus [Gus@moz-11C3C389.adsl.hansenet.de] has joined #developers [04:50:11] SeaMonkey: 'Linux cb-sea-linux-tbox Depend Nightly' has changed state from Burning to Success. [04:51:09] deb00t [Miranda@moz-4319B9E7.t-com.sk] has quit IRC: Connection reset by peer [04:58:13] Firefox: 'WINNT 5.1 qm-winxp01 dep unit test' has changed state from Test Failed to Success. [05:08:07] mayhemer [Miranda@moz-E61C758C.ip.b26.cz] has joined #developers [05:10:02] evan [evan@moz-7738C241.sun.com] has quit IRC: Quit: Leaving [05:11:00] mayhemer [Miranda@moz-E61C758C.ip.b26.cz] has quit IRC: Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org [05:11:59] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [05:13:43] mayhemer [Miranda@moz-E61C758C.ip.b26.cz] has joined #developers [05:14:05] roc [roc@moz-5FBC55BC.dsl.telstraclear.net] has quit IRC: Ping timeout [05:16:32] peepo [Jay@moz-2D3CC6D6.range86-153.btcentralplus.com] has quit IRC: Quit: later [05:16:53] miksago [miksago@moz-B0B9DA8E.dyn.iinet.net.au] has joined #developers [05:18:26] does minefield work with flash/java plugins? [05:18:27] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] has joined #developers [05:19:15] it seems to be crashing when using java after trying to connect using flash [05:19:19] NeilZZZ [neil@moz-54D497BC.lutn.cable.ntl.com] has quit IRC: Ping timeout [05:19:35] dolske [dolske@moz-F8EC3862.hsd1.ca.comcast.net] has quit IRC: Ping timeout [05:19:37] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] is now known as NeilZZZ [05:20:21] Firefox: 'WINNT 5.2 fxdbug-win32-tb Depend Debug + Leak Test' has changed state from Test Failed to Success. [05:21:40] deb00t [Miranda@moz-4319B9E7.t-com.sk] has joined #developers [05:22:10] roc [roc@moz-C4F0528.dsl.telstraclear.net] has joined #developers [05:24:21] SeaMonkey: 'MacOSX Darwin 8.8.1 cb-xserve02 Depend Universal Nightly' has changed state from Burning to Success. [05:24:40] how to get/compute line number of rendered text, for example, for text inside html:p, should I count frames that represents texts or? [05:26:23] Firefox: 'WINNT 5.1 talos trunk qm-pxp03' has changed state from Success to Burning. [05:27:35] not sure [05:31:08] miksago: which platform are you using? [05:32:07] plugins should work. file a bug if you see crashes. (search first if someone has filed the problem you see) [05:32:20] smonsarr [chatzilla@76B201BD.7953E199.4769A60B.IP] has joined #developers [05:32:28] first-line css selector works then someone knows how to get line number :) [05:32:50] wgianopoulos [gianopou@moz-7A06A043.hsd1.ma.comcast.net] has quit IRC: Quit: ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508] [05:33:02] jwatt [roslea@jwatt.irc.users.mozilla.org] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504] [05:33:05] surkov: I bet roc knows the answer to your question [05:33:31] hmm? [05:33:31] smaug, thanks, then I will cc him on the bug [05:33:47] roc, how to get line number for the text? [05:33:50] first-line doesn't use line numbers [05:33:53] for example, for html:p [05:33:54] you'll have to count lines [05:34:04] blocks expose an nsILineIterator interface [05:34:22] it's ugly though [05:34:28] o, great, thanks, I'll look [05:36:23] sean_t23_ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [05:38:44] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Ping timeout [05:38:58] um, XP sp2 [05:44:34] Gijs [Hannibal@moz-56384856.direct-adsl.nl] has quit IRC: Quit: uni [05:44:50] igo1 [igor@moz-1B33589C.nextgentel.com] has joined #developers [05:45:34] igor [igor@moz-1B33589C.nextgentel.com] has quit IRC: Connection reset by peer [05:47:54] dveditz [dveditz@moz-530FA17.cruzio.com] has quit IRC: Ping timeout [05:49:25] igo1 [igor@moz-1B33589C.nextgentel.com] has quit IRC: Ping timeout [05:55:20] deb00t [Miranda@moz-4319B9E7.t-com.sk] has quit IRC: Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org [05:56:46] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Quit: brendan [06:07:17] Aleksej [Aleksej2@moz-4D90EC08.broadband.corbina.ru] has joined #developers [06:07:22] roc [roc@moz-C4F0528.dsl.telstraclear.net] has quit IRC: Ping timeout [06:07:25] nerovengene [abc@74DAA025.88C71422.E6FFA187.IP] has joined #developers [06:08:00] hrm [06:08:27] stransky [stransky@moz-2952D2D0.redhat.com] has quit IRC: Quit: Connection reset by beer [06:09:41] Aleksej2 [Aleksej2@moz-A334C43A.broadband.corbina.ru] has quit IRC: Ping timeout [06:10:13] I'm using xulrunner1.8.0.4 and theres this curious thing I noticed, which is, when I try to start the app with -console, and whenever I minimize the console, the memory usage in windows taskman, shows a major drop, like a garbage collect or something. Whats really happening? [06:11:32] stransky [stransky@moz-2952D2D0.redhat.com] has joined #developers [06:11:38] nth10sd [skywalker@moz-833F66E3.kappa58.maxonline.com.sg] has quit IRC: Quit: nth10sd [06:11:51] roc [roc@moz-721AA383.dsl.telstraclear.net] has joined #developers [06:14:11] roc [roc@moz-721AA383.dsl.telstraclear.net] has quit IRC: Quit: roc [06:16:28] asac [asac@moz-591D695A.adsl.alicedsl.de] has quit IRC: Ping timeout [06:18:17] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [06:19:24] asac [asac@moz-12FF8A82.adsl.hansenet.de] has joined #developers [06:20:05] Littlemutt_afk [chatzilla@moz-AE1A8284.dhcp.embarqhsd.net] has joined #developers [06:20:54] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [06:26:10] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [06:27:17] faaborg [faaborg@moz-F53C9D9B.hsd1.ca.comcast.net] has quit IRC: Quit: faaborg [06:33:07] kiko-afk [kiko@F9C12DED.EB611C7.358EBA0.IP] is now known as kiko [06:36:30] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [06:38:24] oh, great [06:38:34] sean_t23_ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Ping timeout [06:38:41] now my email server is misreporting the number of new messages in my bugzilla folder, not just my inbox [06:41:52] dmose [dmose@moz-5BD04EDD.sfo1.dsl.speakeasy.net] has quit IRC: Ping timeout [06:45:34] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [06:47:51] smontagu [chatzilla@moz-F90AD10B.red.bezeqint.net] is now known as smontaguZZZ [06:48:10] caytchen [caytchen@moz-C2830356.pool.einsundeins.de] has joined #developers [06:49:00] Yoric [yoric@moz-1513168E.fbx.proxad.net] has joined #developers [06:49:56] self [chatzilla@moz-90FD512.pppoe-dynamic.nb.aliant.net] has joined #developers [06:56:37] dao [dao@moz-BB52506C.pool.einsundeins.de] has joined #developers [06:57:26] chro [rhg_xu@D14E8F0D.A43DD08.393EA42D.IP] has quit IRC: Quit: [06:59:45] dria [dria@moz-B7FD1F7E.cpe.net.cable.rogers.com] has joined #developers [07:00:31] Ancestor [miviento@moz-E44A25EC.internetdsl.tpnet.pl] has joined #developers [07:02:30] db48x pokes the mochitests [07:04:39] hello! [07:05:30] ah, no wonder they won't start [07:05:38] I'm already using that port [07:05:56] shaver: hello [07:08:52] miksago [miksago@moz-B0B9DA8E.dyn.iinet.net.au] has left #developers: /me is away: "Any inconviences that may occur are purely coincidential, and we applaud them." [07:10:33] asac [asac@moz-12FF8A82.adsl.hansenet.de] has quit IRC: Ping timeout [07:11:55] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [07:12:31] karlt [karl@moz-334F2010.mountainview.mozilla.com] has joined #developers [07:12:34] nerovengene: what windows does is that whenever you minimise a window it trims the working set of its process [07:13:09] nerovengene: the working set is the bit of the process that is currently in RAM, as opposed to the VM size, which includes the parts swapped to disk [07:13:30] asac [asac@moz-24545303.adsl.alicedsl.de] has joined #developers [07:13:57] nerovengene: this is so annoying that Firefox normally bypasses it by manually minimising itself, although as you noticed that trick doesn't work with the console [07:19:00] KaiRo [robert@moz-F2134722.gumpendorf.xdsl-line.inode.at] has joined #developers [07:20:06] beaufour [beaufour@moz-299A3F6B.lid.theveniceproject.com] has joined #developers [07:20:20] dmoseMsgMe [dmose@moz-5BD04EDD.sfo1.dsl.speakeasy.net] has joined #developers [07:20:36] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [07:26:49] igor [igor@moz-46A85847.nextgentel.com] has joined #developers [07:28:24] jminta|zzz [chatzilla@moz-67193C20.client.dsl.net] is now known as jminta [07:28:56] gavin [gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com] has quit IRC: Ping timeout [07:35:41] sp3000 [tt@moz-17B3DC1A.dhcp.inet.fi] has joined #developers [07:37:21] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [07:38:40] tor [tor@F85D7A6B.C46E910A.461D20FE.IP] has joined #developers [07:42:36] Littlemutt_afk [chatzilla@moz-AE1A8284.dhcp.embarqhsd.net] has quit IRC: Client exited [07:43:42] Marja [chatzilla@moz-600F3E56.c3-0.lex-ubr3.sbo-lex.ma.cable.rcn.com] has joined #developers [07:45:29] nsHashsets.h is not usable on trunk with frozen linkage [07:45:31] true or false? [07:45:42] it includes nsDoubleHashtable.h which includes nsString.h [07:46:00] inclusion isn't the issue, AIUI, it's which APIs are actually employed [07:46:03] so there! [07:46:07] take that, Prague-boy! [07:46:11] I mean: good morning. [07:46:20] listen mounty-boy [07:46:22] magneto [chatzilla@moz-43BC8898.dial1.atlanta1.level3.net] has joined #developers [07:46:28] you might be right [07:46:39] I renamed nsString.h to figure out which of a chain of header files was including it [07:46:42] plasticmillion renames it back [07:46:57] (shaver is so much more fun since he stopped sleeping) [07:47:07] I got a full night's sleep last night [07:47:14] because my wife and daughter were up at my dad's place [07:47:18] due to furnace repairs [07:47:34] hmmm, you're like a fine wine then [07:47:39] funnier with age? [07:47:46] maybe a fine cheese would be a better analogy [07:47:50] I think your tastes are just maturing :) [07:47:54] touche [07:48:27] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [07:49:28] shaver: inclusion is the issue since I get the dreaded "Internal string headers are not available from external-linkage code." [07:49:47] so I have to make my own hash set implementation? [07:49:52] plasticmillion pouts [07:50:52] std::map? [07:51:37] surkov [chatzilla@B5C852AC.56B80CFD.5B715A5B.IP] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 3.0b2pre/2007112205] [07:51:59] hmmm, is that supported everywhere? [07:52:16] also I think I need a string hash set which will be pain if I use std [07:52:16] magneto [chatzilla@moz-43BC8898.dial1.atlanta1.level3.net] has quit IRC: Client exited [07:52:23] why? [07:52:35] I mean, why would it be pain? [07:52:56] ignoring the somewhat obvious "just hash on the UTF-8 representation of the string" [07:53:10] you can specify custom hash functions for the standard containers, I'm pretty clear [07:53:17] hashing is not the issue [07:53:18] (not that map is a hash, typically; it's a tree) [07:53:28] anyone here remember oeone? i'm looking for a vmware image w/ homebase [07:53:41] mail them? [07:53:43] shaver: so you think I can put an nsCString in std::map? [07:54:02] sure, people put crazier stuff than that in there [07:54:10] anyway I guess I can still use the Mozilla hashtables so probably the easiest is to make a hashset wrapper on that [07:55:05] and I can use the brain cells that I don't have to devote to another hashtable API to do something useful like remembering my grocery list [07:55:19] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [07:55:24] you have that much native C++ code, and don't know the STL? [07:55:27] I feel for you [07:55:41] MrMazda [fmcz@moz-E514B004.cable.mindspring.com] has quit IRC: Quit: ChatZilla 0.9.79 [SeaMonkey 1.1.6/2007110320] [07:55:45] don't use STL at all [07:56:10] we use boost for something I think... generating random numbers or something [07:56:22] until now we got all the STL goodness from Mozilla [07:56:44] or I could just wait for bsmedberg to show up and say "you can get hashsets with frozen linkage by doing X" [07:56:56] where X is something that never occurred to me but seems obvious in retrospect [07:57:34] heh, you can get hashsets with frozen linkage using nsTHashtable [07:58:14] well that's really a hashtable but okay [07:58:26] explain the difference to me? [07:58:35] set can have multiple values for the same key [07:58:41] oh [07:58:41] as he uses the term [07:58:48] which is not how everyone else does, I think [07:58:52] but hey! [07:58:52] no, indeed not [07:58:53] no [07:58:59] I'm using the same terminology as Mozilla [07:59:02] a hashtable maps a key to a value [07:59:12] a hashset is just a set of stuff indexed on a hash [07:59:16] so you can do fast lookups, removes, etc. [07:59:25] how perverse [07:59:29] right, nsTHashtable doesn't have a value [07:59:37] ah ok [07:59:45] that seems obvious in retrospect :-) [08:00:00] but isn't it a bug that nsDoubleHashtable.h includes nsString.h and not nsStringGlue.h? [08:00:22] nsDoubleHashtable is deprecated, no? [08:00:41] 39 * nsDoubleHashtable.h is OBSOLETE. Use nsTHashtable or a derivative instead. [08:00:47] ah ok [08:00:58] so the whole of nsHashSets is deprecated I guess [08:01:01] plasticmillion is always the last to know [08:01:08] NeilZZZ [neil@moz-54D497BC.lutn.cable.ntl.com] has quit IRC: Ping timeout [08:01:49] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [08:02:15] FYI nsHashSets.h isn't marked as deprecated but it includes nsDoubleHashtable.h [08:02:30] this has been Today's Useless Mozilla API Factoid [08:02:35] jims [jims@moz-54B286AC.dsl.static.sonic.net] has joined #developers [08:02:42] bug #? [08:02:43] (tm) [08:03:43] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] has joined #developers [08:04:56] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] is now known as NeilZZZ [08:05:07] biesi [cbiesinger@32FA898A.65A91F68.C521C193.IP] has quit IRC: Connection timed out [08:05:10] https://bugzilla.mozilla.org/show_bug.cgi?id=405988 [08:05:20] jiha_ [jiha@moz-601F4228.dip0.t-ipconnect.de] is now known as jiha [08:05:30] biesi [cbiesinger@32FA898A.65A91F68.C521C193.IP] has joined #developers [08:05:43] I'm turning up quite a few little nits so there's probably more where that came from [08:07:35] jims [jims@moz-54B286AC.dsl.static.sonic.net] has quit IRC: Quit: jims [08:09:52] CTho|zzz [chris@moz-A76A5A1A.austin.res.rr.com] is now known as CTho|work [08:11:18] magneto [chatzilla@moz-43BC8898.dial1.atlanta1.level3.net] has joined #developers [08:13:51] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [08:24:32] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [08:31:30] karlt [karl@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [08:32:04] deb00t [Miranda@moz-4319B9E7.t-com.sk] has joined #developers [08:32:58] wow, nsISchemaAttribute changed between 1.8 and 1.9 [08:33:11] plasticmillion thought those interfaces were basically dormant [08:36:37] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [08:37:52] Wes [chatzilla@moz-BEF0C255.page.ca] has joined #developers [08:38:21] I'm trying to compile xulrunner (for mozswing - it includes binaries but I have to find out how to compile the whole thing as sooner or later we'll be on SPARC solaris) and it's giving some headaches with linking (so it seems): http://paste.debian.net/43730 [08:38:59] NeilAway: thanx.. cool that explains :) [08:39:29] What library are those FT_ functions in? You're probably not including it in your link line [08:39:37] freetype [08:39:53] BTW, if you have a choice, go with Solaris 10, you'll find it the most GNU-like out of the box [08:40:11] nerovengene [abc@74DAA025.88C71422.E6FFA187.IP] has quit IRC: Quit: [08:40:31] shaver: is that libXft.so? (just guessing from his compiler output) [08:40:50] think so, but it's pretty version-sensitive [08:40:54] because they like to move symbols around [08:41:04] Ugh [08:41:08] ugh indeed [08:41:09] not openssl-like [08:41:21] though I thought we used pango, and that it would have all the FT stuff sorted out [08:41:33] but that stack is sort of blurry for me [08:41:51] Firefox: 'WINNT 5.1 talos trunk qm-pxp03' has changed state from Burning to Success. [08:42:02] jiha [jiha@moz-601F4228.dip0.t-ipconnect.de] has quit IRC: Client exited [08:42:23] no, libXft is not freetype [08:42:29] freetype is libfreetype, surprisingly enoguh [08:42:48] jiha [jiha@moz-601F4228.dip0.t-ipconnect.de] has joined #developers [08:42:48] His code is using libgfxps.a which is what's missing the FT_* symbols [08:42:53] shaver, that output is from a branch build where we don't use pango [08:43:01] sorry, not "missing" but "not finding" [08:43:12] oh [08:43:15] branch build? [08:43:27] yeah, I got nothin' [08:43:29] xulrunner-1.8.1.4-source.tar.bz2 [08:43:38] hey, look at that [08:43:48] And if have biesi says is right, maikmerten, the reason you can't find those symbols is because you're not linking in -lfreetype [08:43:55] in parts of the tree we rely on indirect dependencies to get libraries, which is somewhat unfortunate [08:44:13] jwatt [roslea@jwatt.irc.users.mozilla.org] has joined #developers [08:44:26] Wes, I'm just wondering why configure doesn't handle this and just slams -lfreetype in there. How can I force that? [08:44:30] uh... to "get" in what sense? [08:44:36] Wes, that doesn't seem to be "his" code btw, it's libXUL [08:44:46] (sorry, I'm just disguised as developer, I'm more a Java guy) [08:45:06] bsmedberg, well, I mean that we don't explicitly list them on the linker cmdline [08:45:06] Wes doesn't know squat about Mozilla, so don't feel bad [08:45:39] I can't tell you how to do get configure to include what you want.. HOWEVER, there are a couple of options which you might be able to use until you find a better solution: [08:45:44] libs that we use symbols from directly? Hrm, I thought we used a compiler flag to prevent that [08:46:14] 1) Copy and paste the pasty you pasted and add -lfreetype (and any necessary path info) [08:46:47] 2) export LDFLAGS or LOADLIBES = "-lfreetype" before running configure (whether that works depends on behaviour I can't guarantee in configure) [08:46:57] But these are obviously more debugging steps than anything [08:46:59] KaiRo [robert@moz-F2134722.gumpendorf.xdsl-line.inode.at] has quit IRC: Ping timeout [08:47:56] thanks - and sorry for pestering with some apparently unofficial xulrunner version (but mozswing apparently depends on it) [08:48:14] biesi/bsmedberg - are you referring to the ELF feature where one lib puts a dependency on another? If so, I'm not sure that's possible in this case, since the dependant lib in his case is .a static lib [08:49:01] Wes wishes he could be more helpful, but is not sufficiently mozilla-1337 [08:49:02] KaiRo [robert@moz-F2134722.gumpendorf.xdsl-line.inode.at] has joined #developers [08:49:16] kiko [kiko@F9C12DED.EB611C7.358EBA0.IP] has quit IRC: Quit: Connection reset by santa [08:52:38] Wes, well, my guess here is that the libXUL build depends on some other lib pulling in libfreetype, and that it no longer does so [08:52:44] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [08:53:23] For a commit message for bug 404935 I used the bug number for bug 403878. How this can be fixed? With cvs admin? [08:53:29] Ah, I see what you mean with respect to implicit dependency. [08:53:47] igor, file a bug [08:54:04] biesi: bug against what? [08:54:40] mozilla.org/CVS:Administration [08:54:44] Or can I back out the patch and recommit it> [08:54:48] ? [08:55:06] igor: just do a second empty commit with the correct bug# [08:55:07] if you want to go the recommit route, just use cvs ci -f [08:58:05] biesi: I did cvs ci -f, thanks. [09:00:11] mkaply [mkaply@moz-66DA7862.co.us.ibm.com] has joined #developers [09:00:11] ChanServ [services@mozilla.org] has set mode +o mkaply [09:00:52] bsmedberg: we use a lot of stuff from nsStreamUtils.h [09:01:00] are we just out of luck? [09:01:09] do I have reimplement stuff or copy it into our tree? [09:01:42] Anatolik [tolikk@5176CC8E.38BB09A6.1FCE22BB.IP] has left #developers [09:01:58] Mnyromyr [MnyroWork@moz-E0F31C11.tal.de] has quit IRC: Input/output error [09:02:52] we even use e.g. nsInputStreamReadyEvent, which doesn't seem to be exposed via XPCOM [09:05:03] is there a chance I could lobby to get nsStreamUtils.h into XPCOM glue? [09:05:13] peterv [peterv@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [09:05:42] bug #? [09:06:12] shaver: so you're saying it's worth filing a bug? [09:06:23] sure [09:06:27] ok [09:06:31] if nothing else, we'll get a record of the reasoning for the WONTFIX [09:06:36] yeah [09:06:37] better than a few lost lines in IRC logs [09:06:49] this is going to be a major pain point for us I think [09:08:08] anything that you could file a "please move this into the glue" bug about could also be replicated in your own code, I'm pretty sure [09:08:25] sure [09:08:34] that's true of all of the glue, no? [09:08:56] what do you mean by replicated? [09:08:57] I think so [09:09:06] plasticmillion: "copy the code, or write equivalent code" [09:09:07] you mean that stuff is exported in some library? [09:09:09] so I don't think it's unreasonable to add more things to the glue [09:09:20] bsmedberg: of course I can copy all the code into our tree [09:09:23] no, we can glue lots of reasonable stuff [09:09:25] but that's kind of crazy [09:09:28] if they can be done in frozen-consuming-only ways [09:09:46] our extension is already too big [09:09:56] glue is linked in either way [09:10:03] so that's not a very compelling argument [09:10:14] shaver: we have glued stuff which is not frozen-consuming-only [09:10:18] brahmana [Srirang@1B349602.6D29DAAE.6179D7BD.IP] has joined #developers [09:10:19] oh is that righ? [09:10:20] right [09:10:22] bsmedberg: reckless!@ [09:10:31] I shouldn't be so judgemental: that argument does not compel _me_ in the slightest :) [09:10:50] I feel awfully compelled [09:10:53] bsmedberg neither... you can't link against it without #including the nonfrozen header [09:11:02] so glue is just one big static library? [09:11:11] so you still have to make a conscious decision at some point [09:11:15] is there a reason why we can't share the same code as FF? [09:11:41] we only want to export frozen stuff from libXUL [09:11:52] Is there a general solution out there in Mozilla-lang for getting unique IDs of NSPR threads? [09:12:05] Wes: check the SetContextThread impl? [09:12:07] in JS [09:12:19] Heeey, good idea! [09:12:21] brb [09:12:28] am I even linking to libxul? [09:12:46] is that part of MOZ_COMPONENT_LIBS? [09:12:59] plasticmillion: you probably are but don't need to be [09:13:13] ok I'm lost [09:13:16] well libXUL is where the impl of that stuff lives [09:13:24] so libxul is this big shared library that I could use so share code with FF [09:13:36] but instead I'm linking to this humungous static glue library [09:13:40] cause I need APIs that aren't frozen [09:13:43] is that right? [09:14:00] let us separate [09:14:02] plasticmillion doesn't think that's right [09:14:07] A) interfaces [09:14:09] B) symbols [09:14:52] libxul only export frozen *symbols* [09:15:00] ok [09:15:11] and the non-frozen stuff is linked statically in libxpcomglue [09:15:13] right? [09:15:19] the glue library allows you to use the frozen symbols using familiar code patterns such as nsCOMPtr, nsString, etc [09:15:36] right, for that I need static linkage anyway [09:15:43] and I don't have to link to libxul because... [09:15:55] because actually what provides your symbols is libxpcom.so [09:15:58] libxpcom exports the stuff [09:16:05] which happens to forward everything to libxul as an implementation detail [09:16:16] okay, and libpxpcom is part of MOZ_COMPONENT_LIBS, presumably [09:16:21] indeed [09:16:32] and I guess the stream utils APIs aren't frozen [09:16:38] so if they are moved to glue I'll still be linking statically [09:16:47] so I might as well just move the files into our tree [09:17:17] ajschult [andrew@moz-30D83D47.bflony.east.verizon.net] has quit IRC: Input/output error [09:17:44] plasticmillion: except for maintenance of the files, yes [09:18:15] mento [mark@F4381B10.C8C6FF5E.4065847B.IP] has joined #developers [09:18:18] so should I: [09:18:27] a) just suck it back and but the relevant files in our tree [09:18:34] b) file a bug to request that they can move to glue [09:18:41] c) file a bug and request that they get frozen (!) [09:18:43] d) all of the above [09:18:52] b) is only going to be fruitful if you provide a patch [09:18:59] not c) [09:19:01] well I can do that [09:19:05] what's the deal with c)? [09:19:08] a) is the fast-path, b) is a decent path [09:19:11] will that kind of stuff ever be frozen? [09:19:36] in 1.9 we only freeze C symbols name NS_blahblah [09:19:40] mostly not in their current state [09:19:41] yeah [09:19:50] c++ utility classes by definition aren't frozen, they're just safe to link against [09:20:13] plasticmillion doesn't understand why they aren't frozen "by definition" [09:20:35] what are the rules for freezing interfaces in 1.9? [09:20:50] interfaces? [09:20:55] of little concern to you [09:20:56] you'd have to file a bug and get MOA and such [09:21:03] but it's really not worth it [09:21:22] by definition <-- because you can't guarantee ABI compat [09:22:07] I really don't understand why you can't guarantee ABI compat [09:22:11] if the function signature is frozen [09:22:18] what am I missing? [09:22:24] a compiler with a frozen C++ ABI [09:22:42] oh [09:23:02] well the nsStreamUtils utility functions are C, not C++ [09:23:05] yes, compilers tend to change c++ ABIs around [09:23:42] NeilZZZ [neil@moz-54D497BC.lutn.cable.ntl.com] has quit IRC: Ping timeout [09:23:45] also, cross-compiler abi compat does basically not exist for C++ [09:23:58] bienvenu_ [DavidBienv@moz-5D8C491A.dsl.pltn13.pacbell.net] has joined #developers [09:24:10] is there something C++ like about the nsStreamUtils stuff? [09:24:28] you were mentioning nsInputStreamReadyEvent [09:25:08] well that's used internally [09:25:11] federico [federico@D1AB4B3C.DD0CFA9E.66A10872.IP] has joined #developers [09:25:12] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] has joined #developers [09:25:20] but I guess the fact that those methods have parameters that are C++ classes [09:25:43] no idea how that affects the ABI [09:25:56] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] is now known as NeilZZZ [09:25:58] if I have: [09:26:04] void foo(bar*); [09:26:15] then binary compatibility is ensured if bar is a struct but not if it is a class? [09:26:17] that seems weird [09:26:26] structs == classes in C++ [09:26:30] just with different visibility [09:26:37] yeah exactly [09:26:55] so I don't know why you think they would be ensured in one case [09:27:04] you need extern "C" [09:27:11] for binary compat [09:27:11] yeah ok [09:27:11] shaver -- good idea, actually, it turns out to be what I've already got, which boils down to get PR_GetCurrentThread(). Which, BTW, returns the pointer to the NSPR thread struct. [09:27:13] The problem I see there is two-fold - [09:27:14] - Pointer can get bigger than JSVAL_MAX_INT (2^30 - 1 IIRC) -- I'm working around this by dividing the pointer by sizeof(pointer), which assumes that align(struct) >= align(pointer) -- I can't think of a case where that's not true unless you're being stupid - __attribute__((packed)) [09:27:16] - Pointer can get re-used, which means the threadID isn't truly one-time unique... Although, I suppose, that's never true for an reasonable thread implementation, is it? [09:27:29] C++ sucks [09:27:36] let's invent our own implementation language... [09:27:38] plasticmillion -- if you are building them with a C++ compiler, they have C++ name mangling unless you explicitly extern "C" {} the function prototypes [09:27:47] Wes, what about 64-bit platforms? [09:27:47] that mangling problem is _why_ COM exists, really [09:27:49] Wes: got it [09:28:26] plasticmillion does a) and makes a mental note to do b) later when he has time to make a patch [09:28:29] smontaguZZZ [chatzilla@moz-F90AD10B.red.bezeqint.net] is now known as smontagu [09:28:59] biesi, Hmm, you're right, the address space could get WAY bigger than 2^30 * 4. Thanks for that. [09:30:31] Oh, but wait, could it get bigger than 2^30 * 8? Multiplying by eight is the same as left shifting 3. So, yeah, definately. [09:31:23] Maybe the right answer is to return the thread ID as a string instead of a JSINT [09:33:45] or a double [09:34:01] bit-punned from the *, that is [09:34:17] that could give some fun results [09:34:29] what happens when the id makes an invalid floating point number? [09:34:31] you could get NaN [09:34:45] so? [09:34:49] you're not going to use it as a double [09:34:57] you might want to check it against numbers [09:35:16] but I don't know what wes is doing, so maybe not [09:35:45] when you compare two invalid floats, does the comparison succeed? [09:35:49] I'm writing a general purpose Thread class for my Spidermonkey embedding. [09:36:15] db48x - and more interestingly, does one NaN==another NaN? [09:36:19] no [09:36:22] NaN == nothing [09:36:25] right [09:36:27] NaN is never equal to anything [09:36:27] even the same other NaN [09:36:33] Wes has never trusted those pesky floating pointer numbers [09:36:45] so if you create a thread, and it makes an invalid floating point number, you have no way to compare it against anything [09:37:11] which defeats the whole purpose of defining a unique thread id [09:37:57] Yeah. Which could be a problem. I forsee the possibility that threadID could be used down the road for "ownership" claiming or some such. [09:38:23] You'd think that coming up with a unique number would be easier than it is. Hee hee. [09:38:50] plasticmillion has to admit that a) was pretty painless [09:39:08] Wes, just make up your own numbers [09:39:19] each time your js creates a thread, increment a global counter [09:39:25] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [09:39:34] store that as a thread private variable or something [09:39:59] Yes, in another incarnation I was actually using an atomic incrementer in the class prototype. The problem _then_ becomes: what happens after you've spawned 2^30 threads? [09:40:15] do you foresee that happening? [09:40:20] Not simultaenous threads, of course, but _total_ [09:40:28] well that's a billion threads [09:40:30] it'll never happen [09:40:41] but you can use a 64-bit var [09:40:52] even if you store that in a double, you have 52 bits [09:40:53] Wes: I'm thinking about setting up a web service that delivers guaranteed unique numbers for a penny a pop [09:40:56] Wes: you in? [09:41:04] 64-bit numbers will cost extra, of course [09:41:13] But, again, with a 64-bit var I'm back to trying to fit it into a JS data type [09:41:20] heh [09:41:27] Wes, store it in a double, you have 52 bits of precision [09:41:34] email me your credit card details and I'll sign you up [09:41:35] db48x imagines what happens when creating a thread means you have to talk to a web service [09:41:36] plasticmillion -- oh, I could use the GID algorithm for that if I had no number size restrictions. [09:41:39] jims [jims@moz-44BEB5A5.dsl.pltn13.sbcglobal.net] has joined #developers [09:42:14] jpb [chatzilla@moz-DF053F63.cse.bris.ac.uk] has quit IRC: Quit: Chatzilla 0.9.75.1 [SeaMonkey 1.1.6/2007103013] [09:42:17] Are the tabs in FF multi-threaded? [09:42:23] brahmana, no [09:42:23] Though my question is not related to the current discussion, I asked it as you were talking about threads [09:42:43] a regular 32 bit integer is plenty big enough for a thread id [09:42:48] biesi -- Hmm. Are all doubles up to 52 bits reasonably representable? (I hate finding out things like 2=1.99999999999999999999999999) [09:43:07] integers are fine [09:43:08] micadeyeye [micadeyeye@moz-BEFBBD62.ee.uct.ac.za] has joined #developers [09:43:08] biesi: Is that going to happen? I mean is it in as a feature for any of the future releases? [09:43:18] brahmana, no [09:43:21] davida [dascher@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [09:44:04] even if you create 100 threads a second, it'll still take you a solid year to use all 4 billion odd numbers [09:44:31] brahmana: that doesn't mean it couldn't happen though [09:44:35] (js integers aren't 32 bit) [09:45:08] ok.. Because a friend of mine was talking about that and even I thught it would be a nice feature. [09:45:18] ok, 6 months for a 31 bit number then. how big are they, anyway? [09:45:19] brahmana, our code totally does not support it [09:45:41] brahmana: yea, it'd be a great feature. it would also be a lot of work too [09:45:44] biesi: so it will require a heavy re-writing of the code? [09:45:47] db48x: we even he uses the other 4 billion even numbers, that'll win him another year, right? [09:45:48] indeed [09:45:48] ok [09:45:49] schrep_ [Mike@moz-7542B0EB.dsl.static.sonic.net] has joined #developers [09:46:31] I came across this: http://parallelbrowser.blogspot.com/ [09:46:44] I wanted to know we are heading in that way. [09:46:46] gandalf [e-gand@moz-F885AD9B.neoplus.adsl.tpnet.pl] has joined #developers [09:47:56] aaronlev [chatzilla@moz-100F13EC.hsd1.ma.comcast.net] has joined #developers [09:48:02] I think that's a pretty pedestrian view of the future of mobile devices, but maybe that's not germane [09:48:51] ssieb_home [ssieb@moz-7AFF2D28.vs.shawcable.net] has joined #developers [09:49:32] db48x: germane?? [09:50:11] it would be better to use something like Prism and let the OS handle spreading the load of multiple processes across multiple cores [09:50:13] brahmana: relevant or pertinant [09:50:20] pertinent, that is [09:50:22] pertinent [09:50:30] yup... googled it out.. :) [09:50:55] and why the heck does he need a cup? [09:51:09] oh, I see [09:51:11] heh [09:51:12] because it makes for a cute image [09:51:24] the real future is in mobile devices that modify our vision much more directly [09:51:38] that makes no sense... in reality you would use wifi or something to communicate with a display in the table top [09:51:45] reality == my addled imagination of the future [09:52:11] blatant product placement for Coke if you ask me [09:52:14] Intel has no shame [09:52:16] no, in reality you would be wearing a display over your eyes that could replace your vision of the table top with the webpage you want to view [09:52:38] ssieb_home [ssieb@moz-7AFF2D28.vs.shawcable.net] has quit IRC: Ping timeout [09:52:39] over? that's so old skool [09:52:51] in reality we'll all have brain implants with wifi connectivity [09:53:19] Another question which I am asked a lot of times -- Why does FF take much more time to start up as compared to IE? [09:53:28] http://www.eyetap.org/research/medr/times_square_email.avi [09:53:33] brahmana: cause most of the IE components are loaded during OS startup? [09:53:46] which is why Windows takes so damn long to start [09:53:59] :D [09:54:40] daim [David_Mart@20A20C50.14A6DDD8.CAE56860.IP] has joined #developers [09:54:59] that's a video capture from an actual wearable computer [09:55:32] well I thought it had something to do with loading of extensions.. [09:55:59] brahmana: yea, extensions can slow it down [09:56:15] maikmerten [merten@moz-9D8BA0A0.cs.uni-dortmund.de] has quit IRC: Quit: Verlassend [09:56:30] but even an unextended firefox is generally slower to show a window than ie, simply because ie has already been loaded [09:56:52] ok [09:57:26] philor [ringnalda@moz-325D69B9.eug.or.uspops.net] has joined #developers [09:59:10] caillon [caillon@moz-2952D2D0.redhat.com] has quit IRC: Ping timeout [10:05:07] koifans [chatzilla@moz-73B1F9C1.vc.shawcable.net] has joined #developers [10:06:30] dietrich [dietrich@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: dietrich [10:06:41] Plouj [Plouj@moz-2AC8F884.cs.yorku.ca] has joined #developers [10:06:43] hi [10:06:58] Isn't there a pre-load-firefox extension out there somewhere? Where it makes firefox as evil as IE? [10:07:17] is saveMedia() the function that is called whenever the user tries to "save as" anything or just images? [10:07:49] sayrer? [10:07:50] curses [10:08:07] mw22 [chatzilla@moz-DBCA600B.wildpalms-wifi1.mozilla.hq] has quit IRC: Ping timeout [10:08:21] db48x - checking math -- JSINT would exhaust threads at 1000 tps in only 12.4 days. But 1000 tps is is about 1000 bigger than expected average use. Hmm. [10:09:30] yeah, so when you hit maxjsint, you make every thread get a new ID [10:09:32] and you're back [10:09:43] do you need historical data? [10:10:48] maybe internalSave is what I'm looking for [10:11:09] glazou [daniel@moz-204094DD.disruptive-innovations.fr] has quit IRC: Quit: [10:11:29] I'm just looking for a way to disable downloads [10:11:53] Plouj: probably worth posting in d-a-f or dev-extensions; someone there will know for sure [10:12:07] bretr [bret_recka@moz-334F2010.mountainview.mozilla.com] has joined #developers [10:12:20] magneto [chatzilla@moz-43BC8898.dial1.atlanta1.level3.net] has quit IRC: Client exited [10:12:48] kirschkern [Daniel_Kir@moz-D0597FF7.dip.t-dialin.net] has quit IRC: Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.10/2007111504] [10:12:55] mrtech [mreyes@moz-123C4B04.ny.emusic.com] has joined #developers [10:14:11] gavin__ [gavin@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [10:14:15] what's d-a-f exactly? [10:14:41] mozilla.dev.apps.firefox [10:15:27] ah, ok [10:15:57] caillon [caillon@moz-56E3641A.redhat.com] has joined #developers [10:19:04] brahmana [Srirang@1B349602.6D29DAAE.6179D7BD.IP] has quit IRC: Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew. [10:20:01] jiha [jiha@moz-601F4228.dip0.t-ipconnect.de] has quit IRC: Client exited [10:22:36] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [10:23:33] schrep_ [Mike@moz-7542B0EB.dsl.static.sonic.net] has quit IRC: Ping timeout [10:24:32] mfinkle [mfinkle@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: mfinkle [10:24:35] smontagu [chatzilla@moz-F90AD10B.red.bezeqint.net] has quit IRC: Client exited [10:25:07] davida [dascher@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: davida [10:25:54] Ryan_ [rflint@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [10:27:08] koifans [chatzilla@moz-73B1F9C1.vc.shawcable.net] has quit IRC: Ping timeout [10:27:17] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [10:29:01] shaver - OH. "you make every thread get a new ID" [10:29:06] Geez, you know, that's not so bad. [10:29:32] if you don't need historical uniqueness, it'll probably work [10:29:39] I was thinking of scanning slots and picking lowest unused, but that significantly increases the cost of [10:29:41] if you do need historical uniqueness, well [10:29:53] it does mean that you need to be able to change a thread's ID [10:30:04] I don't know where they're stored or referenced [10:30:07] Ah, crap. historical uniqueness could very well be wanted. [10:30:11] could be a pain to update all those places [10:30:18] See, I don't know either, because I'm trying to write a general purpose class. [10:30:20] you could use a generation number as well [10:30:54] The update wouldn't be bad, I have to keep a list of running threads anyhow so that they can join() [10:30:57] pamg [pamg@moz-CD91E596.google.com] has joined #developers [10:31:33] koifans [chatzilla@moz-73B1F9C1.vc.shawcable.net] has joined #developers [10:31:46] mw22_ [chatzilla@moz-45994475.mountainview.mozilla.com] has joined #developers [10:31:50] Does using a generation number help increase the number-space? I suppose it partitions the space so that I could declare an entire generation dead and consider it orthogonal to the original space. [10:31:55] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has joined #developers [10:32:03] mw22_ [chatzilla@moz-45994475.mountainview.mozilla.com] is now known as mw22 [10:32:14] or use the generation number for historical data [10:32:51] for a general purpose thread class, I think you are going to end up needing a 64-bit quantity [10:32:52] Off [Miranda@4E51E586.BEE4C790.2E9ECE08.IP] has joined #developers [10:33:21] dietrich [dietrich@moz-45994475.mountainview.mozilla.com] has joined #developers [10:33:22] but that's why I try to avoid building general stuff :) [10:33:23] Yeah. The "historical" reason I'm thinking of is because, well, let's see. Say a guy makes a really long-lived massive thread-spawning program. And one thing he does is stake a claim that says "hey, _I_ own this object", and he does that by jotting his threadID down in that object. [10:33:37] cf_nthomas [chatzilla@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: ---> office [10:33:38] yeah [10:33:52] it's not too hard to do the reuse system you're describing, though [10:34:00] with a bitmap of allocated IDs [10:34:02] I suppose he could jot down his thread handle, instead, but then the thread handle might never go out of GC scope, and then we have leaks. That's why I want a number. [10:34:16] talk to stuart when he comes back, he did a bunch of that for bitmapping the unicode space [10:34:24] and x86 at least has hardware support for "find next zero bit" [10:34:40] Hmm, kind of like malloc? [10:34:46] (really? that'd be a neat instruction) [10:35:16] See, if I'm willing to go with a 64-bit quantity, I can then easily use the NSPR thread handle's address. [10:35:30] But I don't really want to make that horribly expensive to pass back to JS. [10:35:50] I suppose I could expose threadID_lowWord and threadID_highWord (yes, I'm kidding) [10:35:54] dietrich [dietrich@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: dietrich [10:36:03] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Connection reset by peer [10:36:06] An eight-char string would do, but that means, HM [10:36:18] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [10:36:23] ARM10 has CLZ [10:36:28] I could generate the thread ID and store it as an interned string. Then I wouldn't need to re-create the darned string every time the getter is called [10:36:52] Archaeopteryx [itsme@moz-B6884483.pools.arcor-ip.net] has quit IRC: Quit: Archaeopteryx [10:36:56] Standard8 [mark@B7F1AE36.48015583.54C3481B.IP] has joined #developers [10:37:14] and x86 and alpha have most/least-significant 1 bit [10:38:21] PPC as well, I think [10:38:41] Hm. That's definately interesting. I'll definately ping stuart if I get the chance... google isn't being overly helpful [10:38:45] gavin__ [gavin@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [10:39:53] And I just realized, storing the interned string would be a bad idea, I don't think those are ever subject to garbage collection. [10:40:04] Marja [chatzilla@moz-600F3E56.c3-0.lex-ubr3.sbo-lex.ma.cable.rcn.com] has quit IRC: Ping timeout [10:40:44] they are not [10:41:00] anything you want to store permanentlyish can't be GCd [10:41:36] Sander [me@moz-B871F4D3.direct-adsl.nl] has joined #developers [10:41:45] http://www.penguin.cz/~literakl/intel/b.html#BSF [10:42:03] koifans [chatzilla@moz-73B1F9C1.vc.shawcable.net] has quit IRC: Ping timeout [10:42:34] Ryan_ [rflint@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [10:42:35] dietrich [dietrich@moz-45994475.mountainview.mozilla.com] has joined #developers [10:43:22] Wow, it never ceases to amaze what a good job Intel did putting the C in CISC [10:44:19] some RISC CPUs have that too [10:44:30] ARM for one [10:44:32] I just realized, I should rephrase this problem: I want a bag of ints between 1 and JS_INT_MAX. I want to be able to take ints out of the bag, and put them back in when I'm done with them. [10:44:36] alpha too [10:44:39] yeah [10:44:41] and PPC? [10:44:51] petea [petea@F7BDB098.FC63495D.2321E71E.IP] has quit IRC: Quit: petea [10:44:58] Okay, go and counter-example me with scroll back from a half page ago. :) [10:45:01] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Quit: brendan [10:45:06] dietrich [dietrich@moz-45994475.mountainview.mozilla.com] has quit IRC: Connection reset by peer [10:45:10] dietrich [dietrich@moz-45994475.mountainview.mozilla.com] has joined #developers [10:45:40] schrep_ [Mike@moz-334F2010.mountainview.mozilla.com] has joined #developers [10:46:03] how do i return a js array of floats from c++? [10:46:21] kig: in IDL or in JSAPI? [10:48:17] IDL i think. i'm trying to hack getTransform() -> transform matrix to nsCanvasRenderingContext2D [10:48:22] what's jsapi? [10:48:35] deb00t [Miranda@moz-4319B9E7.t-com.sk] has quit IRC: Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org [10:48:58] mkmelin [chatzilla@moz-1431B88E.fi] has joined #developers [10:49:09] myk [chatzilla@moz-8D033489.hsd1.ca.comcast.net] has quit IRC: Input/output error [10:49:25] thalakan - spidermonkey embedding api [10:49:57] that bypasses xpcom? nice [10:50:28] taras [taras@moz-99B4231C.gv.shawcable.net] has joined #developers [10:50:39] predates and is orthogonal to [10:50:48] myk [chatzilla@moz-8D033489.hsd1.ca.comcast.net] has joined #developers [10:51:08] ctyler_roaming [ctyler_roa@moz-FB7AC549.senecac.on.ca] has joined #developers [10:51:57] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [10:52:55] nattokirai [jdaggett@moz-334F2010.mountainview.mozilla.com] has joined #developers [10:53:41] r3ap3r [BrandonCol@moz-FB7AC549.senecac.on.ca] has joined #developers [10:54:54] Off [Miranda@4E51E586.BEE4C790.2E9ECE08.IP] has quit IRC: Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org [10:56:17] peterv [peterv@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Ping timeout [10:56:37] jiha [jiha@moz-601F4228.dip0.t-ipconnect.de] has joined #developers [10:57:59] petea [petea@moz-3B20417C.sub-75-208-43.myvzw.com] has joined #developers [10:58:56] schrep__ [Mike@moz-334F2010.mountainview.mozilla.com] has joined #developers [10:59:20] jorendorff [jorendorff@moz-E229E605.hsd1.tn.comcast.net] has joined #developers [11:00:15] Marja [chatzilla@moz-600F3E56.c3-0.lex-ubr3.sbo-lex.ma.cable.rcn.com] has joined #developers [11:00:50] tigerdog [tigerdog@moz-4D12B25A.san.res.rr.com] has joined #developers [11:01:34] coop [ccooper@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:02:44] rob_arnold [Grendel@moz-80D0F63E.wv.cc.cmu.edu] has joined #developers [11:03:18] joduinn-zzz [joduinn@moz-E31CD2CB.mozilla.org] has quit IRC: Ping timeout [11:04:24] damons [gnubeard@moz-AFBF1588.hsd1.ca.comcast.net] has quit IRC: Quit: damons [11:05:20] sicking_ [chatzilla@moz-4A1ED93A.hsd1.ca.comcast.net] has joined #developers [11:05:38] hmm, no Enn [11:05:58] bc [bclary@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:06:13] smaug: any idea how reliable event.rangeParent is for the popupshowing of a popup opened by showPopup? [11:06:31] sicking_ [chatzilla@moz-4A1ED93A.hsd1.ca.comcast.net] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504] [11:07:05] mfinkle [mfinkle@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:07:50] jimm [jmathies@moz-45994475.mountainview.mozilla.com] has joined #developers [11:09:23] myk [chatzilla@moz-8D033489.hsd1.ca.comcast.net] has quit IRC: Ping timeout [11:10:04] laurentj [laurentj@moz-204094DD.disruptive-innovations.fr] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504] [11:11:42] sean_t23 [sean_t23@55DE267.862EF1F5.84320120.IP] has joined #developers [11:12:07] Standard8 [mark@B7F1AE36.48015583.54C3481B.IP] is now known as Standard8Away [11:13:38] caillon [caillon@moz-56E3641A.redhat.com] has quit IRC: Quit: Leaving [11:14:33] schrep__ [Mike@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [11:14:40] alice [alice@moz-45994475.mountainview.mozilla.com] has joined #developers [11:14:45] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Success to Burning. [11:14:48] schrep__ [Mike@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:15:20] Ryan_ [rflint@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:15:22] Littlemutt_afk [chatzilla@moz-AE1A8284.dhcp.embarqhsd.net] has joined #developers [11:15:50] stefanh [stefanh@moz-C0717DF0.static.s-h.siw.siwnet.net] has joined #developers [11:15:52] gavin__ [gavin@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:16:36] Mossop_away [Mossop@moz-B9F6E8D3.oxymoronical.com] is now known as Mossop [11:18:13] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [11:18:13] gavin___ [gavin@moz-45994475.mountainview.mozilla.com] has joined #developers [11:19:04] Hey, does anyone in here know plugins at all? [11:19:17] gavin__ [gavin@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [11:19:21] I was wondering if someone could explain a little what nsPluginInstancePeer is [11:19:35] gavin___ [gavin@moz-45994475.mountainview.mozilla.com] is now known as gavin__ [11:19:52] Going through all this plugin code, is giving me a headache, it's so difficult to understand what is going on [11:20:18] Enn [enn@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:21:47] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [11:22:18] davida [dascher@moz-45994475.mountainview.mozilla.com] has joined #developers [11:22:35] WeirdAl [chatzilla@moz-44BEB5A5.dsl.pltn13.sbcglobal.net] has joined #developers [11:23:39] Tomcat [Tomcat@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:23:43] <@mkaply> Is the toolbar blending into content on Firefox 3 deliberate? [11:23:47] !seen glazou [11:23:48] glazou was last seen 7 hours, 46 minutes and 56 seconds ago, saying 'timelyx: uh ?' in #developers. [11:24:07] cf_nthomas [chatzilla@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:24:37] kaie [kaie@moz-8AE14A9A.dip.t-dialin.net] has joined #developers [11:24:41] cpearce_ [chatzilla@moz-DA1295AB.adsl.paradise.net.nz] has joined #developers [11:26:37] cpearce [chatzilla@moz-DA1295AB.adsl.paradise.net.nz] has quit IRC: Ping timeout [11:26:52] cpearce_ [chatzilla@moz-DA1295AB.adsl.paradise.net.nz] is now known as cpearce [11:27:08] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [11:29:40] mkaply: see bug 402125 [11:30:37] <@mkaply> On Windows things look really strange. on youtube you can't tell where the toolbar ends and the page begins [11:31:10] mkaply [mkaply@moz-66DA7862.co.us.ibm.com] has quit IRC: Connection reset by peer [11:31:15] oh, windows? That must be something different [11:31:20] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [11:31:36] ah, misread you [11:31:47] koifans [chatzilla@moz-BA946301.yvr.sxip.com] has joined #developers [11:33:32] mkaply [mkaply@moz-66DA7862.co.us.ibm.com] has joined #developers [11:33:32] ChanServ [services@mozilla.org] has set mode +o mkaply [11:34:10] pamg [pamg@moz-CD91E596.google.com] has quit IRC: Quit: pamg [11:36:29] <@mkaply> Components not defined. That seems bad [11:39:21] Yoric [yoric@moz-1513168E.fbx.proxad.net] has quit IRC: Quit: 40 pass / 23 fail. [11:39:27] damons [gnubeard@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:39:28] Yeah thats not usually a good sign [11:40:18] sheppy [sheppy@moz-AD5989BE.dhcp.kgpt.tn.charter.com] has joined #developers [11:40:57] mcsmurf [chatzilla@moz-7FAD3359.dip.t-dialin.net] has joined #developers [11:41:31] stransky [stransky@moz-2952D2D0.redhat.com] has quit IRC: Quit: Connection reset by beer [11:41:32] "As briefly discussed during last weeks leak meeting we're moving the leak meeting to wednesdays 10am and merging it with the leak meeting." [11:41:38] um, does this make sense? [11:41:58] Only when read in conjunction with the replies [11:42:39] "9:30 AM PST - 10:00 PM PST”" [11:42:45] yay ;) [11:43:25] schrep__ [Mike@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: Leaving [11:43:53] faaborg [faaborg@moz-F53C9D9B.hsd1.ca.comcast.net] has joined #developers [11:45:14] ctalbert [clint@moz-7EFF73E1.dsl.pltn13.sbcglobal.net] has joined #developers [11:45:52] redfive [redfive@346ECF13.BBC87276.3E8C195A.IP] has joined #developers [11:46:23] ted [ted@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:46:56] mcsmurf: I saw it as a joke - merging a meeting with itself, so that one pointer to it doesn't leak... [11:47:03] petea [petea@moz-3B20417C.sub-75-208-43.myvzw.com] has quit IRC: Ping timeout [11:47:06] uuh ;) [11:47:51] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [11:48:13] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has joined #developers [11:48:23] petea [petea@moz-4908C5F5.sfo4.dsl.speakeasy.net] has joined #developers [11:49:28] peterv [peterv@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:50:02] mw22 [chatzilla@moz-45994475.mountainview.mozilla.com] has quit IRC: Ping timeout [11:51:10] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [11:52:03] philor [ringnalda@moz-325D69B9.eug.or.uspops.net] has quit IRC: Ping timeout [11:52:39] jorendorff [jorendorff@moz-E229E605.hsd1.tn.comcast.net] has quit IRC: Ping timeout [11:53:02] mw22_ [chatzilla@moz-334F2010.mountainview.mozilla.com] has joined #developers [11:53:20] mw22_ [chatzilla@moz-334F2010.mountainview.mozilla.com] is now known as mw22 [11:53:39] pamg [pamg@moz-CD91E596.google.com] has joined #developers [11:54:05] josh [josh@moz-45994475.mountainview.mozilla.com] has joined #developers [11:54:27] jorendorff [jorendorff@moz-E229E605.hsd1.tn.comcast.net] has joined #developers [11:55:25] gletelli [chatzilla@moz-C4CA0E64.cambridge.arm.com] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.9/2007102514] [11:55:38] joduinn [joduinn@moz-E31CD2CB.mozilla.org] has joined #developers [11:56:10] gletelli [chatzilla@moz-C4CA0E64.cambridge.arm.com] has joined #developers [11:56:36] <@mkaply> Is the fact that the radio button focus ring is bigger on Firefox 3 a feature or a bug? [12:00:11] mvl [michiel@moz-2F035FEA.direct-adsl.nl] has joined #developers [12:00:12] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Quit: Leaving. [12:00:17] damons [gnubeard@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: damons [12:01:00] davida [dascher@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: davida [12:01:07] <@bz_sleep> mkaply: which os? [12:01:14] <@mkaply> bz_sleep: windows. [12:01:20] bz_sleep [bzbarsky@moz-C9A4D477.dsl.chcgil.sbcglobal.net] is now known as bz [12:01:23] <@bz> odd [12:01:32] <@mkaply> the focus ring for chexboxes/radio used to go around the text. Now it extends all the way to the right of the dialog [12:01:40] <@bz> oh [12:01:43] <@bz> in xul [12:01:46] <@mkaply> yeah [12:01:48] <@mkaply> sorry [12:01:56] <@bz> not sure [12:02:07] <@bz> can you get me a simple testcase? [12:02:13] <@mkaply> Just go to options [12:02:17] <@bz> in a standalone xul file? [12:02:24] <@mkaply> sure [12:02:28] nsCOMArrays release the objects they are holding on to on destruction, right? I don't have to take any extra steps to make sure things get deleted properly? [12:02:31] blassey [blassey@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: blassey [12:02:34] <@bz> Then I can tell you when the behavior changed [12:02:39] <@bz> redfive: yep [12:02:44] <@mkaply> bz: let me check with aaron leventhal first. [12:02:49] <@mkaply> Maybe there was an accessibility resason [12:03:51] <@bz> I was figuring the checkin comments in the range would tell us that. ;) [12:03:57] koifans [chatzilla@moz-BA946301.yvr.sxip.com] has quit IRC: Ping timeout [12:03:58] mkaply: fx2 options download settings has the focus ring extend the full width [12:04:34] davida [dascher@moz-45994475.mountainview.mozilla.com] has joined #developers [12:04:42] <@mkaply> mfinkle: tab to "always ask where to save files" [12:04:57] <@mkaply> mfinkle: actually, go to the tabs page [12:05:08] <@mkaply> everything there is to the length of the text [12:05:22] pamg [pamg@moz-CD91E596.google.com] has quit IRC: Quit: pamg [12:05:47] <@bz> in general, the focus is around the box [12:05:50] blassey [blassey@moz-63806515.wildpalms-wifi2.mozilla.hq] has joined #developers [12:05:55] <@bz> however big the box is [12:05:55] <@mkaply> I guess the behavior now is inconsistent in the opposite way it was inconsistent before :) [12:06:01] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [12:06:22] <@bz> which means simple changes to the xul can affect it [12:06:28] blassey [blassey@moz-63806515.wildpalms-wifi2.mozilla.hq] has quit IRC: Quit: blassey [12:06:30] mkaply: hmm, download checkboxes are full width, but tabs checkboxes are not -must be the way the controls are flexed [12:06:40] mconnor: is there a plan for un-breaking proto on nightly builds? [12:06:50] <@mkaply> mfinkle: Are there any known differences between dynamically adding menus in FF3? [12:06:58] no proto makes me :-( [12:07:08] <@mkaply> My menus are visually different in FF3, but I can't explain why [12:07:19] <@mkaply> They are more compact [12:07:39] mkaply: vista or xp? [12:07:41] mkaply: use domi to see how they differ [12:07:43] rob_arnold [Grendel@moz-80D0F63E.wv.cc.cmu.edu] has quit IRC: Quit: rob_arnold [12:07:49] mkaply: might be a different class or something [12:07:49] <@mkaply> mfinkle: xp [12:07:57] anyone know what might have changed recently for compiling on FC7 that adding -Wno-attributes to the compile line no longer removes all the warnings about lowering visibility of ‘void nsCOMPtr::assign_from_qi(nsQueryInterface, const nsIID&) [with T = sbIRemotePlayer]’ to match its type ? [12:08:56] db48x needs faster disks [12:08:59] wolfiR [wolfiR@moz-9CF12453.dip0.t-ipconnect.de] has quit IRC: Quit: Leaving [12:09:52] <@bz> db48x: ping? [12:09:56] also, why are there 33 copies of beagled-helper runnign? [12:09:59] bz: pong [12:10:10] <@bz> db48x: seen the comments on that drag bug? [12:10:15] yea [12:10:16] koifans [chatzilla@moz-BA946301.yvr.sxip.com] has joined #developers [12:10:21] schrep_ [Mike@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [12:10:40] <@bz> db48x: if you can retest when you get a chance, that would rock [12:10:45] mkaply: the differences in the options dialog (Fx2) are likely due to vs. containers [12:10:50] it's definitely still a bug [12:11:09] try dragging an image from a webpage while you have layout.css.dpi set to 144 [12:11:13] it's very noticeable [12:11:17] schrep_ [Mike@moz-334F2010.mountainview.mozilla.com] has joined #developers [12:11:35] joduinn [joduinn@moz-E31CD2CB.mozilla.org] is now known as joduinn-mtg [12:11:42] it also affects drag and drop in the tab strip [12:11:44] mkaply needs two screens for stuff like this [12:11:49] <@bz> db48x: do you get that with full zoom too? [12:11:58] bz: hmm, dunno [12:12:22] <@bz> db48x: can you check? And either way, comment and renominate> [12:12:29] josh: can't we fix the bgcolors on toolbars/titlebars/statusbars in the native theme code? [12:12:44] <@bz> db48x: since I bet this is a regression on high-dpi screens [12:12:47] stefanh looks at bug 402125 [12:12:59] stefanh: I don't know enough about that issue. Probably, but it may not be the right fix. [12:13:22] no, if I set the dpi down to 96 (man, forgot how unreadble things are) the bug goes away [12:13:29] and changing the page zoom doesn't bring it back [12:14:04] what was the bug number, again? [12:14:15] josh: ok, hmm. Hard-coding the color in the binding doesn't seems right... now I understand why seamonkey's windows look kinda funny :/ [12:14:40] <@mkaply> Weird. I'm getting menu-iconic-text where I wasn't before [12:14:40] ah, found it [12:14:45] places to the rescue [12:14:46] schrep_ [Mike@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [12:14:46] NeilZZZ [neil@moz-54D497BC.lutn.cable.ntl.com] has quit IRC: Ping timeout [12:14:47] mkaply wonders if that is it [12:15:38] <@mkaply> no, that was coming in before in another way. [12:15:41] how do you think I should deploy firefox on multiple Windows stations where I modified a bunch of files in the C:\Program Files\Mozilla Firefox directory [12:15:49] <@mkaply> Something definitely change in menu padding [12:15:56] dveditzAway [dveditz@moz-530FA17.cruzio.com] has joined #developers [12:15:58] <@mkaply> Plouj: build your own installer [12:16:20] NeilAway: no idea about event.rangeParent, sorry [12:16:31] cygwin + rsync? :) [12:16:50] piratepenguin [declan@moz-4DC90F72.bas504.dsl.esat.net] has joined #developers [12:16:58] Wes: that's what I was thinking of [12:17:12] Wes was kidding, but that would work [12:17:29] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Burning to Test Failed. [12:17:30] Doesn't M$ have some fancy multiple desktop deployment thing? Like IKEA or . ah, I dunno [12:17:52] heh, IKEA? [12:18:10] Internet .. Kit .. Exploring .. Ass-hatness? [12:18:27] I dunno, some acronym I read about about a thousand years ago [12:18:41] <@mkaply> IEAK [12:18:47] ctyler_roaming [ctyler_roa@moz-FB7AC549.senecac.on.ca] has quit IRC: Ping timeout [12:18:59] oh [12:18:59] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] has joined #developers [12:19:14] mkaply: where do I look for how the original firefox installer is built? [12:19:19] pamg [pamg@moz-CD91E596.google.com] has joined #developers [12:19:20] Hey, that's it! [12:19:34] Plouj: if you want to use mozilla's software updates then you have to be careful what you modify [12:19:52] r3ap3r [BrandonCol@moz-FB7AC549.senecac.on.ca] has quit IRC: Ping timeout [12:19:54] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] is now known as NeilZZZ [12:20:06] Doesn't really help, though. [12:20:06] cf_nthomas: I'll most likely use the same version of firefox for a long time, but I'd like something that will let me propogate my own changes later on [12:20:21] <@mkaply> http://www.kaply.com/weblog/2007/07/27/manually-repackaging-the-firefox-installer-on-windows/ [12:20:29] Plouj, are you able to share the types of changes you made? Perhaps there is a better way to roll _those_ out [12:20:30] thanks [12:20:33] I would use some random software deployment system (or build your own installer and maybe silent mode, hm) [12:20:50] Cartman [chatzilla@moz-66DA7862.co.us.ibm.com] has joined #developers [12:20:58] or write those modifications as an extension [12:21:03] Wes: yeah, I disabled a lot of the UI to crate a kiosk type of interface [12:21:04] it's easy to update those [12:21:27] florian [fqueze@moz-334F2010.mountainview.mozilla.com] has joined #developers [12:21:35] <@mkaply> Plouj: and http://www.kaply.com/weblog/2007/03/20/deploying-firefox-2-within-the-enterprise-part-3/ [12:21:43] Yeah, I was thinking the same thing. An extension could use the extension update mechanism to stay up to date [12:21:50] <@mkaply> Plouj: you should be able to do all that as an extension [12:22:20] <@mkaply> Wes: that won't really work because if you hide the extension as a system extension, when it gets updated it becomes visible (unless you hide add-ons completrely) [12:22:39] <@mkaply> Plouj: I would strongly recommend that you do this as an extension. Makes Firefox MUCH easier to deploy [12:22:53] humm [12:23:15] erwan [erwan@moz-4908C5F5.sfo4.dsl.speakeasy.net] has joined #developers [12:23:19] I think I'll deploy what I have now and then work on doing these changes in an extension [12:23:26] thankfully I saved all of the changes in a version conrol system [12:23:27] ianloic [ian@moz-1817B4DB.dreamhostps.com] has joined #developers [12:24:05] That's why God invented source code control. :) [12:24:24] I changed a lot of stuff in chrome/browser chrome/toolbox defaults genprefs and even browserconfig.preferences [12:24:35] toolit* [12:24:37] toolkit* [12:24:48] <@mkaply> Plouj: You should be able to do it all via an exteions. And there is the CCK that lets you set default things as well [12:24:59] what's cck? [12:25:11] <@mkaply> https://addons.mozilla.org/en-US/firefox/addon/2553 [12:25:30] <@mkaply> ARGH. addons still doesn't do greater than and less then correctly [12:26:07] do we know what's with the orange? [12:26:40] is there a way to make extensions auto update without asking the user? [12:26:40] faaborg [faaborg@moz-F53C9D9B.hsd1.ca.comcast.net] has quit IRC: Quit: faaborg [12:27:04] gandalf [e-gand@moz-F885AD9B.neoplus.adsl.tpnet.pl] has quit IRC: Quit: Ex-Chat [12:27:30] faaborg [faaborg@moz-F53C9D9B.hsd1.ca.comcast.net] has joined #developers [12:27:46] dietrich: ping [12:27:46] humm [12:27:49] faaborg [faaborg@moz-F53C9D9B.hsd1.ca.comcast.net] has quit IRC: Quit: faaborg [12:27:53] gavin| thwaps bsmedberg for telling igor to cvs ci -f instead of filing a bug [12:27:58] vlad: hi [12:28:02] Standard8Away [mark@B7F1AE36.48015583.54C3481B.IP] has quit IRC: Quit: back later [12:28:09] dietrich: so i'm looking at this orange.. this looks like a spontaneous explosion =/ [12:28:32] none of the ptaches seem remotely related [12:28:46] vlad: ben is working on that box [12:29:07] erm [12:29:25] working as in working on fixing? or doing stuff on? [12:29:34] gavin|: please don't mess with CVS history... it mucks with the hg import scripts badly [12:29:49] vlad: as in, had to reboot it [12:30:01] bsmedberg: commit log changes do? [12:30:13] bsmedberg: moves I can understand, I don't see how the log changes would [12:30:33] and, not that this is a strong argument or anything, but "we do them all the time" [12:30:41] we import continuously, so a commitlog change either 1) won't get picked up or 2) will get picked up twice... I'm not sure which [12:30:58] dietrich: hrm.. so after reboot it's showing the orange? [12:31:01] vlad: yep, doesn't look related. probably fine to check in [12:31:07] are either of those especially problematic? [12:31:16] well.. i've got a cairo update to check in [12:31:21] would rather not have any tree horkage [12:31:29] to make sure any problems are caught [12:31:31] vlad: er, yeah lets wait a cycle to see if goes green then [12:32:31] piratepenguin [declan@moz-4DC90F72.bas504.dsl.esat.net] has quit IRC: Ping timeout [12:34:40] blassey [blassey@moz-334F2010.mountainview.mozilla.com] has joined #developers [12:37:14] vlad: fix to nsCanvasRenderingContext2D::IsPointInPath: cairo_save(mCairo); cairo_identity_matrix(mCairo); *retVal = (PRBool) cairo_in_fill(mCairo,x,y); cairo_restore(mCairo); [12:38:05] dveditzAway [dveditz@moz-530FA17.cruzio.com] is now known as dveditz [12:38:07] gavin__: the first is just annoying (it kinda moots the long-term advantage of changing the message in the first place). The second is pretty wretched, but I don't know what the tools would do with it [12:38:07] kig: yeah, or just saving the matrix [12:38:10] ChanServ [services@mozilla.org] has set mode +o dveditz [12:38:22] kig: but i'll have to think about whether that makes sense or not [12:38:26] Vampire- [aleks@589A1C8F.900E138.E16F0CF5.IP] has joined #developers [12:38:48] I -think- it does [12:39:17] vlad: fwiw, opera does it that way. the way it is currently is useless since you can't get the current transformation matrix [12:39:53] bsmedberg: I don't know how that import works, but does it really rely on the commit message without taking into account the revision number? [12:40:29] dmoseMsgMe [dmose@moz-5BD04EDD.sfo1.dsl.speakeasy.net] has quit IRC: Quit: dmoseMsgMe [12:40:43] 2) seems like something that should never happen [12:40:45] I'd have to go back and look at the script [12:41:03] kig: well, you can't get it, but you can always do save(); setTransform(1,0,0,1,0,0); isPointInPath(); restore(); [12:41:24] i'm trying to think of a case when you really would need the current CTM applied [12:41:38] gavin__ [gavin@moz-45994475.mountainview.mozilla.com] has left #developers [12:41:55] and they're basically cases for when your point isn't user input but is something else [12:42:14] ted [ted@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: ted [12:42:21] since using an identity matrix is only useful if it's user input [12:42:27] doh! "firefox removed-files.log" gives me nonEnglish google results! [12:42:53] even that'll behave weirdly if there is css scale involved (e.g. canvas width="100" height="100" but css width: 200px; height: 200px) [12:43:40] mixedpuppy [mixedpuppy@472E0656.E54D1AE5.13B1F7EE.IP] has joined #developers [12:45:52] shaver: can any xpidl interface be implemented by javascript? [12:46:11] taras, any scriptable one, that doesn't have noscript or noxpcom functions [12:46:15] taras: "no" - some of them are not marked scriptable [12:46:40] ok, that's good news [12:47:12] ideally that shouldn't significantly reduce your workload =b [12:47:15] biesi's also right :) [12:47:28] is removed-files.log just used to remove files from previous FF installs? [12:47:32] note also inheritance [12:47:47] it's not a question of my workload..it's the quistion of how much use my workload will be :) [12:47:49] or methods that take/return nonscriptable params [12:48:02] note that some of these details are bugs [12:48:06] specifically the take/return one [12:48:15] i had a patch somewhere to fix that [12:48:21] vlad: i see the sense in save(); identity(); isPointInPath(); restore();, but i think the whatwg spec says that the x,y-coords are device-space coords (the wording in it isn't the clearest) [12:49:05] roc [roc@moz-721AA383.dsl.telstraclear.net] has joined #developers [12:49:38] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Quit: brendan [12:49:45] why couldn't have someone picked scheme as the original embedded browser language? [12:49:52] timelyx: to clarify..if a method takes a non-scriptable param..it can't be implemented in js? [12:49:57] yep [12:49:57] kig: yeah [12:50:09] and that's a bug not a requirement [12:50:15] taras: the *method* can't, but the interface still can without implementing that method [12:50:24] well yeah... [12:50:33] damons [gnubeard@moz-334F2010.mountainview.mozilla.com] has joined #developers [12:50:35] so things can implement interfaces incompletely? [12:50:38] basically any js object trying to implement that method will throw an exception when called [12:50:41] taras: absolutely [12:50:47] crikey [12:50:52] you can have an object that claims to implement all interfaces [12:50:58] function QueryInterface(){return this} [12:51:15] as long as the interface claims to be scriptable, your object will be allowed [12:51:24] ok, so we're back to there *not* being a distinction then? [12:51:28] jwatt [roslea@jwatt.irc.users.mozilla.org] has quit IRC: Ping timeout [12:51:40] between "script-may-call-this-interface" and "script-may-implement-this-interface"? [12:51:42] function Z(){} Z.prototype.QueryInterface=function(){return this} [12:52:08] kig: That only makes sense if the CTM applies to paths at construction time, not at render time, so it doesn't make sense with the current spec (and I don't think everyone has agreed that Firefox's way is correcter than the spec's) [12:52:14] jorendorff: interfaces have an attribute scriptable [12:52:14] ack, it's a Bottom object! [12:52:29] timelyx: which means both [12:52:31] lacking that interface guarantees it won't be wrappable by xpconnect [12:53:00] right, I'm saying it's either both, or neither, as far as you can tell by looking at xpidl anyway [12:53:03] individual methods then have noscript/notxpcom [12:53:26] jorendorff: plus we can't make a claim "this currently isn't implemented by js...so it wont be implemented by js in the future" [12:53:38] dietrich: no go [12:53:42] dietrich: who did you say was looking at the machine? [12:53:53] jorendorff: essentially there's no distinction, yes [12:54:04] hmm [12:54:05] the idea of xpcom is that things should be able to impersonate/implement *anything* [12:54:11] exceptions are imo bugs [12:54:13] glazou [daniel@moz-C4A1EE4B.fbx.proxad.net] has joined #developers [12:54:18] vlad: bhearsum was looking at the red, and rebooted. i'll start digging into the orange. [12:54:18] WeirdAl: hi [12:54:19] notxpcom/noscript especially [12:54:19] right, the context in which this came up was [12:54:21] Philip: i just wish to have some way to detect when a path is under the mouse cursor :> [12:54:29] timelyx: yeah sounds like it [12:54:29] glazou: hey, good to see you [12:54:37] switching XPCOM to support C++ exceptions (experimentally, decision is not made) [12:54:52] jorendorff: i could easily have guessed :) [12:55:11] jorendorff: my personal policy has always been that exceptions should not be allowed across xpcom boundaries [12:55:14] so basically if we want to change any methods, we have to change how xpidl works [12:55:18] and we realized that calling *any* XPCOM method might throw exceptions from xpconnect itself (the supposedly invisible layer in there) [12:55:28] or change things on C++ & other sides [12:55:33] beaufour [beaufour@moz-299A3F6B.lid.theveniceproject.com] has quit IRC: Quit: Leaving [12:55:34] taras: not just "xpidl" but the entire xptcall/xptinfo stack [12:55:47] This might even be in use... [12:55:49] if your method is reachable via xpcom, you must not allow an exception to pass past that point [12:55:52] I don't think it's worthwhile to piecemeal change outparams [12:55:53] right [12:55:58] ted [ted@moz-334F2010.mountainview.mozilla.com] has joined #developers [12:56:01] there could be debugger code somewhere that creates JS proxies for nearly-arbitrary XPCOM objects [12:56:06] certainly doesn't look like it now [12:56:10] I think it would be easier and more reliable to do the whole shebang at once [12:56:14] jorendorff: right [12:56:18] debugger, or java proxies [12:56:22] or all sorts of other fun things [12:56:24] random proxies too [12:56:27] bsmedberg: means we also have to figure out what that means [12:56:36] taras: indeed we do [12:56:43] taras / jorendorff: this is why i never understood why you people thought this would work :) [12:56:44] bsmedberg: brendan was talking about a C++ core [12:56:48] but maybe i wasn't clear enough on that point [12:56:59] i'm not sure if that means evaluating classes which shouldn't be in xpcom [12:57:10] timelyx: heh :) the clueful one among "you people" is brendan [12:57:13] which would increase our workable set [12:57:15] taras: I don't know what a "C++ core" means [12:57:16] well, bsmedberg too [12:57:20] timelyx: this will all work [12:57:29] timelyx: just not sure how yet :) [12:57:40] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has joined #developers [12:57:44] taras: whatever [12:57:45] self [chatzilla@moz-90FD512.pppoe-dynamic.nb.aliant.net] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504] [12:57:48] timelyx mutes [12:58:03] jorendorff returns to mmgc, since he's been muted [12:58:24] sounds like i should seek this elusive C++ core for answers [12:58:32] brendan: ping [13:00:07] kiko-zzz [kiko@moz-21AE8E0E.dsl.telesp.net.br] is now known as kiko [13:00:08] damons [gnubeard@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: damons [13:01:04] dietrich: http://pastebin.mozilla.org/251753 [13:02:28] darin [darin@moz-CD91E596.google.com] has joined #developers [13:02:36] ah, forgot the column headers [13:02:45] http://pastebin.mozilla.org/251757 <- this one will last forever [13:03:59] Tomcat [Tomcat@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [13:06:14] daim [David_Mart@20A20C50.14A6DDD8.CAE56860.IP] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504] [13:06:28] bent [chatzilla@346ECF13.BBC87276.3E8C195A.IP] has joined #developers [13:08:51] the browser.js for that trace post-processed: http://pastebin.mozilla.org/251760 [13:09:00] (for line number matching) [13:09:15] Tomcat [Tomcat@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:09:58] stevee [Miranda@moz-33D212DB.sotn.cable.ntl.com] has quit IRC: Quit: My firefox blog @ http://steveengland.wordpress.com [13:12:46] hmm, that got cut off [13:15:29] mixedpuppy [mixedpuppy@472E0656.E54D1AE5.13B1F7EE.IP] has quit IRC: Quit: mixedpuppy [13:17:54] Cartman [chatzilla@moz-66DA7862.co.us.ibm.com] has quit IRC: Ping timeout [13:18:19] petea [petea@moz-4908C5F5.sfo4.dsl.speakeasy.net] has quit IRC: Quit: petea [13:18:24] petea [petea@moz-4908C5F5.sfo4.dsl.speakeasy.net] has joined #developers [13:19:43] ted [ted@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: ted [13:20:32] jwatt [roslea@jwatt.irc.users.mozilla.org] has joined #developers [13:20:48] Cartman [chatzilla@moz-66DA7862.co.us.ibm.com] has joined #developers [13:21:02] Mook_sb [mook@346ECF13.BBC87276.3E8C195A.IP] has joined #developers [13:21:48] karlt [karl@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:22:20] Mano [chatzilla@87D0E4C6.EDE4C1F3.475835C0.IP] has joined #developers [13:22:21] Ryan_ [rflint@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [13:22:21] myk [chatzilla@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:23:13] dietrich: you should prolly close the tree [13:23:17] davida [dascher@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: davida [13:23:24] roc [roc@moz-721AA383.dsl.telstraclear.net] has quit IRC: Quit: roc [13:23:48] joduinn-mtg [joduinn@moz-E31CD2CB.mozilla.org] is now known as joduinn [13:24:16] davida [dascher@moz-45994475.mountainview.mozilla.com] has joined #developers [13:24:50] davida [dascher@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: davida [13:25:19] taras: any that is not labelled [noscript], yes [13:25:27] stefanh [stefanh@moz-C0717DF0.static.s-h.siw.siwnet.net] has quit IRC: Quit: Chatzilla 0.9.75.1 [SeaMonkey 1.1.7/2007111912] [13:25:53] k [13:26:01] Mossop [Mossop@moz-B9F6E8D3.oxymoronical.com] is now known as Mossop_away [13:26:35] ctalbert [clint@moz-7EFF73E1.dsl.pltn13.sbcglobal.net] has quit IRC: Quit: ctalbert [13:26:43] MrMazda [fmcz@moz-E514B004.cable.mindspring.com] has joined #developers [13:28:19] Mano [chatzilla@87D0E4C6.EDE4C1F3.475835C0.IP] has quit IRC: Client exited [13:29:46] ted [ted@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:33:47] Where is the call made to open unkownContentType.xul? [13:34:11] nattokirai [jdaggett@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: nattokirai [13:34:46] nsHelperAppDlg.js(.in) [13:35:44] biesi: thanks [13:36:08] Mossop_away [Mossop@moz-B9F6E8D3.oxymoronical.com] is now known as Mossop [13:36:12] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has quit IRC: Connection reset by peer [13:36:34] sean_t23__ [sean_t23@99661652.180209F2.C52C7D68.IP] has joined #developers [13:36:57] bz [bzbarsky@moz-C9A4D477.dsl.chcgil.sbcglobal.net] has quit IRC: Ping timeout [13:37:01] dolske [dolske@moz-F8EC3862.hsd1.ca.comcast.net] has joined #developers [13:37:46] koifans [chatzilla@moz-BA946301.yvr.sxip.com] has quit IRC: Connection reset by peer [13:38:05] Ryan_ [rflint@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:38:18] koifans [chatzilla@moz-BA946301.yvr.sxip.com] has joined #developers [13:39:12] bz [bzbarsky@moz-C9A4D477.dsl.chcgil.sbcglobal.net] has joined #developers [13:39:12] ChanServ [services@mozilla.org] has set mode +o bz [13:39:14] bz [bzbarsky@moz-C9A4D477.dsl.chcgil.sbcglobal.net] has quit IRC: Quit: bz [13:39:24] bz [bzbarsky@moz-C9A4D477.dsl.chcgil.sbcglobal.net] has joined #developers [13:39:24] ChanServ [services@mozilla.org] has set mode +o bz [13:40:32] hrm [13:40:35] how do I build 1.8 on leopard [13:41:05] karlt [karl@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [13:43:02] dholbert [dholbert@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:43:04] shebs [shebs@moz-F69D7FA6.lv.lv.cox.net] has joined #developers [13:43:04] vlad: I haven't had any problems [13:43:04] don't think I had to change anything since upgrading [13:43:35] ah, it bailed on me with the 10.5 SDK [13:43:38] 10.4u works fine [13:44:34] oh, that does sound familiar [13:44:48] although I think I had the oppositeproblem, trying to build with dtrace enabled on 10.5 with the old SDK [13:45:31] cpearce_ [chatzilla@moz-628A39EA.adsl.paradise.net.nz] has joined #developers [13:45:41] dmoseMsgMe [dmose@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:46:35] cpearce [chatzilla@moz-DA1295AB.adsl.paradise.net.nz] has quit IRC: Ping timeout [13:46:42] cpearce_ [chatzilla@moz-628A39EA.adsl.paradise.net.nz] is now known as cpearce [13:47:18] dolske [dolske@moz-F8EC3862.hsd1.ca.comcast.net] has quit IRC: Quit: dolske [13:47:24] sdwilsh|away [sdwilsh@moz-42DEA58D.public.engin.umich.edu] has joined #developers [13:47:48] Anybody know where PR_ErrorToString() is documented? Or, alternatively, whether it's MT-safe and a stable API? [13:48:16] dmoseMsgMe [dmose@moz-334F2010.mountainview.mozilla.com] is now known as dmose [13:49:06] NSPR API is stable [13:49:25] http://www.mozilla.org/projects/nspr/#DocumentationTraining [13:50:33] myk [chatzilla@moz-334F2010.mountainview.mozilla.com] has quit IRC: Ping timeout [13:50:43] graydon [graydon@moz-4CF3055C.vc.shawcable.net] has quit IRC: Quit: Leaving. [13:50:55] Even if the only mention you can find of a symbol is in a header file? :) [13:51:18] if it says PR_ it's public [13:51:23] jorendorff [jorendorff@moz-E229E605.hsd1.tn.comcast.net] is now known as jorendorff-bicycle [13:51:53] Sweet, thanks. :) [13:52:13] I'm guessing the entire lib is MT safe? [13:52:42] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [13:52:57] <@bz> http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/include/prerror.h#253 [13:53:02] <@bz> Seems to document it reasonably well... [13:53:22] <@bz> as for threadsafe... [13:53:30] zwnj [behnam@moz-E1E3A14D.linux.ir] has joined #developers [13:53:50] <@bz> 124 /* static buffer only used if code is using inconsistent error message [13:53:50] <@bz> 125 * numbers, so just ignore the possible thread contention [13:53:50] <@bz> 126 */ [13:53:50] <@bz> 127 static char buffer[25]; [13:53:58] <@bz> Not sure what that means in practice. ;) [13:54:13] dmose [dmose@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: dmose [13:54:20] myk [chatzilla@moz-334F2010.mountainview.mozilla.com] has joined #developers [13:54:28] means that if the caller is correct, you won't go into that path, so don't worry about the case of multithreaded caller bogosity, I do believe [13:54:29] Heh. [13:55:33] I think somebody (me?) needs to hit the MDC wiki at some point with some of the NSPR stuff that's not documented. I was surprised to see PR_GetError but not PR_GetErrorString in there. [13:56:09] Wes is currently trying to figure out why his code can return PR_DEADLOCK_ERROR [13:56:21] yeah, the NSPR docs have not been completely ported [13:56:27] davida [dascher@moz-45994475.mountainview.mozilla.com] has joined #developers [13:56:40] Is the stuff in the header files considered correct? [13:56:49] bhearsum: so win2k3 is still orange eh [13:56:56] urgh [13:57:07] sdwilsh|away [sdwilsh@moz-42DEA58D.public.engin.umich.edu] has quit IRC: Quit: Leaving [13:57:07] looks like the clobber build is still going [13:57:16] it's failing focusy things [13:57:24] m [13:57:24] you're not still logged in or something silly like that are you [13:57:28] not afaik [13:57:30] bhearsum checks [13:57:40] nope [13:58:10] Noah [opera@moz-B1F7CB31.dial1.dallas1.level3.net] has joined #developers [14:00:18] roc [roc@moz-628A39EA.adsl.paradise.net.nz] has joined #developers [14:00:20] damons [gnubeard@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:00:57] schrep_ [Mike@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:02:07] Firefox: 'WINNT 5.2 qm-win2k3-01 dep unit test' has changed state from Test Failed to Success. [14:02:10] vlad: well, given that the other win unit test box is not failing the same tests, it seems to be box-related [14:02:21] heh [14:02:30] yay [14:02:32] phew [14:02:39] ok, gonna land! [14:02:52] vlad: do you want me to close the tree for your landing? [14:03:01] winner [14:03:26] dietrich: up to you, i'm not anticipating problems [14:03:29] <@bz> vlad: whatcha landing? [14:03:35] ok [14:03:36] gavin|: anyone thinking of implementing the full/zoom toggle in Firefox yet? only I'd want to agree on the pref name if possible [14:03:45] bz: just updating cairo [14:04:08] smaug [chatzilla@moz-DDD2A5AD.pp.htv.fi] has quit IRC: Quit: ChatZilla 0.9.79 [Firefox 3.0a9pre/2007110314] [14:04:10] Mossop [Mossop@moz-B9F6E8D3.oxymoronical.com] is now known as Mossop_away [14:04:28] <@bz> vlad: ah, cool [14:04:30] we need to anticipate problems [14:04:31] NeilAway: I'm not sure - you mean a toggle for text vs. full zoom? [14:04:35] even if we don't expect them [14:04:37] <@bz> vlad: anything particularly exciting in this update? [14:05:06] NeilAway thwaps ChatZilla [14:05:08] bz: nah [14:05:10] we should really take the fix that someone ASCII-sketched in whatever bug, that beltzner liked [14:05:21] gavin|: that's the one [14:05:23] yeah, when does anything complicated ever *not* break [14:05:29] I ascii sketched it [14:05:31] adding an optoin [14:05:36] based on the dude's idea [14:05:38] it was elegant, yeah [14:05:39] NeilAway: I vaguely recall a bug on the issue, I haven't been following that very closely [14:05:40] make it so! [14:05:40] NeilAway now sees he accidentally skipped the word text [14:05:45] [x] Do what the hell i mean [14:05:54] https://bugzilla.mozilla.org/show_bug.cgi?id=401322 [14:05:55] <@bz> yes [14:05:59] <@bz> we need more options like that one [14:06:04] <@bz> I mean ted's proposed option [14:06:11] <@bz> Ideally, the app would do that by default... [14:06:16] <@bz> It's a hard problem. :( [14:06:20] [x] Do what the hell i want [14:06:22] comment 38, none of the bullshit undeneath [14:06:23] (forget what i mean) [14:06:39] [x] Do what the hell I need [14:06:39] bz longs for comment moderation [14:06:39] 38 or 39? [14:06:42] <~stuart> gzipping a 700mb text file takes too long;( [14:06:47] <@bz> [-1e9 Irrelevant] [14:07:05] aaaand we're off [14:07:28] gavin|: so, should I just check in my patch with a pref of browser.zoom.full as it stands, and assume you'll use the same pref? [14:07:32] bz: we can privatize spam, but yeah, that's not enoug [14:07:45] NeilAway: I suppose - comment in the bug? [14:08:01] [Bug Karma: 2 (+1 Not Stupid, +1 Relevant)] [14:08:17] +1 Read previous comments [14:08:27] (+1 Technical) [14:08:31] -1 Repeats previous comments [14:08:31] shaver: 39, whoops :) [14:08:45] gavin|: so that pref name sounds reasonable to you? [14:08:53] full-page? [14:09:02] -1 Advocacy [14:09:05] <@bz> vlad: so about bug 405740 [14:09:12] fullPage? [14:09:19] <@bz> vlad: I'm not sure we're creating a 13k tall temp surface (though I could check) [14:09:27] hmm, we already have fullZoom.* [14:09:36] <@bz> vlad: we're drawing a 13k-tall clip path, however, and this appears to give Render conniptions [14:09:38] NeilZZZ [neil@moz-54D497BC.lutn.cable.ntl.com] has quit IRC: Ping timeout [14:09:39] and toolkit.zoomManager.fullZoomValues [14:09:49] dunno if that's still used [14:09:57] render isn't involved in clipping I don't think [14:10:00] though I could be wrong about that [14:10:20] <@bz> vlad: let me look up the exact stack in the profile [14:10:50] gavin|: you appear to use it, yes [14:10:52] <@bz> vlad: btw, if we only need to clip for PushGroup, does that mean we can skip clipping if canAvoidGroup? [14:10:53] Mossop_away [Mossop@moz-B9F6E8D3.oxymoronical.com] is now known as Mossop [14:10:56] mcsmurf_ [mcsmurf@moz-7FAD3359.dip.t-dialin.net] has joined #developers [14:10:58] petea [petea@moz-4908C5F5.sfo4.dsl.speakeasy.net] has quit IRC: Quit: petea [14:11:04] <@bz> gfxContext::Clip [14:11:09] <@bz> calls INT__moz_cairo_clip_preserve [14:11:12] mcsmurf [chatzilla@moz-7FAD3359.dip.t-dialin.net] has quit IRC: Quit: ChatZilla 0.9.79 [SeaMonkey 2.0a1pre/2007112817] [14:11:13] <@bz> calls _cairo_gstate_clip [14:11:17] <@bz> calls _cairo_clip_clip [14:11:22] <@bz> calls _cairo_surface_composite_trapezoids [14:11:26] I'd have to look at the code again, but I don't think we can [14:11:27] gavin|: toolkit.zoomManager.fullZoomEnabled? [14:11:30] <@bz> calls XRenderComposite [14:11:31] ah, so [14:11:41] <@bz> And calls XRenderCompositeTrapezoids [14:11:42] composite_trapezoids there means we're ending up in the mask clip case [14:11:51] brendan [brendaneic@moz-37758455.hsd1.ca.comcast.net] has quit IRC: Quit: brendan [14:11:51] we're compositing the clip traps to a surface to use as the clip surface [14:11:59] <@bz> ok [14:12:01] Simon [Simon@moz-24AE7147.range86-141.btcentralplus.com] has quit IRC: Quit: Simon [14:12:17] bz wonders why [14:12:19] NeilAway: would it be possible to unfork viewZoomOverlay.js ? [14:12:26] <@bz> this is just a straight rectangle clip, right? [14:12:34] orph [agraveley@moz-CA9102EF.vmware.com] has joined #developers [14:12:35] petea [petea@moz-4908C5F5.sfo4.dsl.speakeasy.net] has joined #developers [14:12:51] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] has joined #developers [14:12:54] (eventually, not necessarily as a precondition to you landing your patch) [14:13:22] bz: it should be, though it sounds like it's not pixel-aligned [14:13:55] mixedpuppy [mixedpuppy@472E0656.E54D1AE5.13B1F7EE.IP] has joined #developers [14:14:01] gavin|: where does the content prefs service fit in? [14:14:03] Neil_ [neil@moz-54D497BC.lutn.cable.ntl.com] is now known as NeilZZZ [14:14:10] <@bz> vlad: I get the slowness no matter how I align it [14:14:13] <@bz> vlad: fwiw [14:14:26] bz: does it always hit xrender? [14:14:33] I wonder if we're creating a too-big clip surface [14:14:37] Firefox: 'Linux fx-linux-tbox Depend Nightly' has changed state from Success to Burning. [14:14:37] though really [14:14:40] <@bz> vlad: I don't know [14:14:44] bah, stupid linux [14:14:46] <@bz> vlad: I can step down and check. One sec. [14:14:48] NeilAway: I don't think it's related to the toolkit viewZoomOverlay file [14:14:50] NeilAway: at least I hope not [14:15:05] ../../../dist/include/thebes/gfxContext.h:560: error: comma at end of enumerator list [14:15:08] vlad rolls his eyes [14:15:29] stefanh [stefanh@moz-C0717DF0.static.s-h.siw.siwnet.net] has joined #developers [14:15:57] pucko is scared by a couple of eyes rolling by [14:16:04] lulz [14:16:13] Firefox: 'Linux qm-centos5-01 dep unit test' has changed state from Success to Burning. [14:16:13] yay extra commas [14:16:22] isn't that ok in C99 or something? [14:16:30] gavin|: ok, so I had a quick look at toolkit viewZoomOverlay.js and it seems unlikely that we'd be able to unfork it [14:17:05] Noah [opera@moz-B1F7CB31.dial1.dallas1.level3.net] has quit IRC: Ping timeout [14:17:19] NeilAway: why? I'm not all that familiar with what they both do, but they look similar. [14:17:23] of course, this is where I ask the question of why the try server linux machine compiled this fine [14:17:41] newer gcc! [14:17:45] <@bz> (gdb) p *clip [14:17:45] <@bz> $5 = {mode = CAIRO_CLIP_MODE_REGION, surface = 0x0, surface_rect = {x = 0, y = 0, [14:17:45] <@bz> width = 0, height = 0}, serial = 1, region = {rgn = {extents = {x1 = 0, y1 = 0, [14:17:45] <@bz> x2 = 1263, y2 = 673}, data = 0x0}}, has_region = 1, path = 0x0} [14:17:48] well yeah [14:17:50] gavin|: ok, I'll have to look again in more depth, once windows updates have finished installing... [14:18:02] bz: after the clip? [14:18:18] bz: I don't understand why you're seeing composite_traps from clip() [14:18:21] in that case [14:18:24] <@bz> This is at the entrance to _cairo_clip_clip [14:18:27] oh, yeah [14:18:29] what is it at the end? [14:18:32] <@bz> So that's the existing clip on there [14:18:34] <@bz> working on it. ;) [14:18:49] <@bz> (gdb) p gstate->clip [14:18:49] <@bz> $10 = {mode = CAIRO_CLIP_MODE_REGION, surface = 0x0, surface_rect = {x = 0, y = 0, [14:18:49] <@bz> width = 0, height = 0}, serial = 2, region = {rgn = {extents = {x1 = 8, y1 = 0, [14:18:49] <@bz> x2 = 809, y2 = 673}, data = 0x0}}, has_region = 1, path = 0x0} [14:18:55] <@bz> This is after we return from _cairo_clip_clip [14:19:09] and that clip went through composite_trapezoids? [14:19:15] NeilAway: anyways I guess that's a separate issue that isn't really related to what you asked me [14:19:19] <@bz> double-checking that [14:19:32] bhearsum: any idea why vlad's patch would have been ok on the try server? [14:19:34] because i'm almost certain that if it does, you'll end up with CLIP_MODE_SURFACE and a non-NULL surface [14:19:53] NeilAway: I'm not too concerned about the pref's name - something under browser. is OK I guess [14:20:04] hmm [14:20:21] <@bz> hmm [14:20:22] try server uses the same mozconfig afaik, i don't know why it would fail on tinderbox [14:20:29] <@bz> no, that clip doesn't seem to go through there... [14:20:30] <@bz> one sec [14:20:31] lelik52 [Lelik@84E95C8D.29975E35.62494813.IP] has quit IRC: Quit: Leaving [14:20:31] except some code change since it was tested on the try server [14:21:09] <@bz> hah [14:21:24] <@bz> So this is not the original "clip to the border rect" clip that goes through there [14:21:30] <@bz> it's the DoSideClipSubPath(ctx, iRect, oRect, side, borderStyles, borderRadii); [14:21:34] humm, something is causing my firefox installations to igore the proxy settings in all.js [14:21:34] <@bz> The clip that produces [14:21:38] bz: gotta run meet someone at lunch [14:21:41] ah! yeah, I can believe that [14:21:41] hmm [14:21:53] <@bz> vlad: all good. I'll put whatever I find in the bug [14:21:57] dbaron [dbaron@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:21:57] ChanServ [services@mozilla.org] has set mode +o dbaron [14:22:15] dolske [dolske@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:24:40] ctalbert [clint@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:25:26] dmoseMsgMe [dmose@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:26:01] Standard8Away [mark@B7F1AE36.48015583.54C3481B.IP] has joined #developers [14:26:19] davida [dascher@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: davida [14:26:31] Standard8Away [mark@B7F1AE36.48015583.54C3481B.IP] is now known as Standard8 [14:28:08] gavin|: ok, so it looks as if you don't have a custom zoom or a list of zoom presets on your menu [14:28:46] we used to, iirc, I guess we got rid of them [14:28:48] (the presetS) [14:29:08] but we could add that to the toolkit file and just not use it in our menu [14:29:47] bsmedberg: so, the confvars.sh stuff requires a clobber to take effect, right? [14:29:49] gavin|: ok, browser.zoom.full it is [14:30:15] mconnor: hrm, it might [14:30:18] Firefox: 'MacOSX Darwin 8.8.4 qm-xserve01 dep unit test' has changed state from Success to Test Failed. [14:30:20] NeilAway: what's the bug # for this? [14:30:31] technically it only requires a reconfigure, but there's not an easy way to force reconfigure without a total rebuild [14:30:53] bsmedberg: what I'm thinking about is how to remove domi sanely [14:31:37] gavin|: bug 405133 [14:31:40] <@bz> Isn't that just a matter of disabling it at build time? [14:31:42] Enn: menupopup.click() used to open the window, but it looks like it no longer does [14:31:46] <@bz> via --enable-extensions stuff? [14:31:47] Enn: er, open the popup [14:31:55] Enn: is that expected/known? [14:31:56] joduinn [joduinn@moz-E31CD2CB.mozilla.org] is now known as joduinn-transit [14:31:58] joduinn-transit [joduinn@moz-E31CD2CB.mozilla.org] has quit IRC: Quit: joduinn-transit [14:31:59] aha, we have an Enn [14:32:41] mconnor: so, why not check in a confvars.sh change (and presumably a removed-files.in change) and then clobber? [14:32:50] Enn: in a popupshowing handler is event.rangeParent the only reliable way of knowing which element a popup is anchored to? [14:32:59] NeilAway thwaps Microsoft [14:33:04] graydon [graydon@moz-D53B2287.vc.shawcable.net] has joined #developers [14:33:10] davidb [davidb@9E2B4113.F7A93B2A.A20A274E.IP] has joined #developers [14:33:15] first I have to apply a service pack for .NET 1.1, then a security update, which means another reboot :-( [14:33:33] Pike [chatzilla@moz-334F2010.mountainview.mozilla.com] has joined #developers [14:34:02] NeilAway: heh I also had that and then it told me it cannot install the SP [14:34:16] sean_t23_ [sean_t23@55DE267.862EF1F5.84320120.IP] has joined #developers [14:34:17] looked under Software and then just deinstalled .net 1.1, as I already have 2.0 ;-) [14:34:19] bsmedberg: I guess I can just do that, and post to dev.planning so people can pick up the change themselves [14:34:32] dmoseMsgMe [dmose@moz-334F2010.mountainview.mozilla.com] has quit IRC: Quit: dmoseMsgMe [14:34:40] rginda [rginda@moz-2EF64D22.hsd1.ca.comcast.net] has quit IRC: Ping timeout [14:35:04] uuh [14:35:12] gavin|: why would you expect it to? [14:35:21] schrep_: yt? [14:35:23] Enn: "because it used to work" [14:35:28] something is broken on very-current trunk, might be SeaMonkey specific though: [14:35:32] zwnj [behnam@moz-E1E3A14D.linux.ir] has quit IRC: Ping timeout [14:35:33] I don't know why that method was used before [14:35:54] do you mean menu.click or menupopup.click? [14:36:01] If I use the middle mouse to get the scroll icon, the browser window kind of minimizes and the icon appears in the upper left of the screen [14:36:07] and I cannot restore the window [14:36:19] Firefox: 'Linux fx-linux-tbox Depend Nightly' has changed state from Burning to Success. [14:36:42] sean_t23 [sean_t23@55DE267.862EF1F5.84320120.IP] has quit IRC: Ping timeout [14:36:43] davida [dascher@moz-45994475.mountainview.mozilla.com] has joined #developers [14:36:57] neilaway: rangeParent gives what you clicked on [14:37:06] Enn: menupopup.click [14:37:25] ok, this code is just broken [14:37:39] gavin|: that doesn't make any sense. If the popup isn't open, clicking on it isn't possible [14:37:45] davida [dascher@moz-45994475.mountainview.mozilla.com] has quit IRC: Quit: davida [14:37:54] which code is this? [14:37:54] mcsmurf_: that's not helpful, as apps require a specific version of .net [14:38:02] Enn: I'm just surprised that it used to work [14:38:06] mcsmurf_: you can download the service pack though [14:38:07] I agree that it doesn't make sense [14:38:17] NeilAway: maybe, did not notice one broken app so far [14:38:26] maybe I already deinstalled that app though :] [14:38:29] Enn: this is code using showPopup [14:38:29] Enn: http://lxr.mozilla.org/seamonkey/source/browser/components/search/content/search.xml#685 [14:39:01] Enn: _popup is http://lxr.mozilla.org/seamonkey/source/browser/components/search/content/search.xml#86 [14:39:27] Enn: I guess the click() bubbled up to the