All times are UTC.
00:08:41 <instant-buildbot> build #467 of linux-onCommit is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-onCommit/builds/467 00:24:14 --> mconley has joined #instantbird 00:35:15 <-- clokep has quit (Ping timeout) 00:48:00 <-- mconley has quit (Input/output error) 01:02:20 <-- Mook_as has quit (Quit: Mook_as) 01:27:10 <swills> jesus, talk about spam 01:35:29 <-- wnayes has quit (Connection reset by peer) 01:35:31 --> wnayes has joined #instantbird 02:40:57 --> Mook has joined #instantbird 03:02:18 <-- Suiseiseki has quit (Ping timeout) 03:03:49 --> Suiseiseki has joined #instantbird 03:38:33 --> mconley has joined #instantbird 03:39:23 <instant-buildbot> build #992 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/992 03:40:36 <-- mconley has quit (Input/output error) 03:41:33 <instant-buildbot> build #969 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/969 04:17:13 <instant-buildbot> build #1073 of win32-nightly-default is complete: Failure [failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1073 04:22:10 <-- wnayes has quit (Quit: wnayes) 04:41:54 --> FireFly_TB has joined #instantbird 05:23:47 --> gerard-majax has joined #instantbird 05:25:27 <-- gerard-majax has quit (Ping timeout) 05:41:27 --> gerard-majax has joined #instantbird 05:52:54 <-- EionRobb has quit (Ping timeout) 05:53:55 --> EionRobb has joined #instantbird 06:01:18 <-- Suiseiseki has quit (Ping timeout) 06:06:30 <-- EionRobb has quit (Quit: Leaving.) 06:06:35 <-- gerard-majax has quit (Ping timeout) 06:08:50 --> Suiseiseki has joined #instantbird 06:15:12 <-- FireFly_TB has quit (Ping timeout) 06:16:26 --> gerard-majax has joined #instantbird 06:17:03 --> jb has joined #instantbird 06:22:03 <instant-buildbot> build #457 of win32-onCommit is complete: Failure [failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-onCommit/builds/457 blamelist: Florian Qu?ze <florian@instantbird.org>, aleth <aleth@instantbird.org>, Nihanth Subramanya <nhnt11@gmail.com> 06:22:44 <-- flo-retina has quit (Ping timeout) 06:22:50 --> flo-retina has joined #instantbird 06:22:50 * ChanServ sets mode +qo flo-retina flo-retina 06:29:40 <-- jb has quit (Ping timeout) 06:32:20 --> FireFly_TB has joined #instantbird 06:48:14 <-- Mook has quit (Quit: Mook) 07:11:26 --> nhnt11 has joined #instantbird 07:12:18 <nhnt11> Lots of check-ins! :) 07:12:30 <nhnt11> flo-retina: That's weird, I'll look into it in the evening :-\ 07:12:36 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 07:12:39 --> nhnt11 has joined #instantbird 07:12:52 <nhnt11> (I'm talking about the opacity thing) 07:20:39 <-- gerard-majax has quit (Ping timeout) 07:20:41 --> gerard-majax_ has joined #instantbird 07:22:15 <flo-retina> nhnt11: thanks :) 07:26:57 <flo-retina> clokep: thanks for closing all the bugs :) 07:32:08 <instantbot> New Instantbird (UI) bug 2169 filed by nhnt11@gmail.com. 07:32:09 <instantbot> nhnt11@gmail.com requested review from florian@instantbird .org for attachment 2881 on bug 2169. 07:32:13 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2169 nor, --, ---, nobody, NEW, Status attribute in newtab-items is not set for chats, but isn't cleared if it was previously set 07:32:14 <nhnt11> flo-retina: That should fix it :) 07:33:01 <flo-retina> the evening came faster than I expected! 07:33:02 * nhnt11 has to go 07:33:10 <nhnt11> I had a spare few minutes :) 07:33:16 <nhnt11> Have a nice day. 07:33:18 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 07:59:43 <-- gerard-majax_ has quit (Ping timeout) 08:05:08 <instantbot> florian@instantbird.org granted review for attachment 2881 on bug 2169. 08:05:12 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2169 nor, --, ---, nobody, NEW, Status attribute in newtab-items is not set for chats, but isn't cleared if it was previously set 08:24:14 <instantbot> benediktp@ymail.com denied review for attachment 2877 on bug 2168. 08:24:17 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 08:24:49 --> dionisos has joined #instantbird 08:34:39 --> jb has joined #instantbird 08:55:15 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 08:55:53 --> flo-retina has joined #instantbird 08:55:53 * ChanServ sets mode +qo flo-retina flo-retina 09:02:27 <-- jb has quit (Quit: jb) 09:05:07 --> jb has joined #instantbird 09:22:32 --> gerard-majax_ has joined #instantbird 10:18:02 --> clokep has joined #instantbird 10:18:02 * ChanServ sets mode +o clokep 10:20:06 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 10:26:02 <clokep> flo:No problem. :) 10:33:17 <-- gerard-majax_ has quit (Ping timeout) 10:34:44 --> gerard-majax_ has joined #instantbird 10:36:14 <-- FireFly_TB has quit (Ping timeout) 10:41:24 --> FireFly_TB has joined #instantbird 10:43:34 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 10:49:22 --> nhnt11 has joined #instantbird 10:53:08 <nhnt11> Good evening/afternoon 10:53:39 --> flo-retina has joined #instantbird 10:53:39 * ChanServ sets mode +qo flo-retina flo-retina 10:55:57 <flo-retina> nickserv is feeling talkative today (a nickserv tab opened, even though there was only 7s between 'please identify' and 'you are now identified') 10:56:44 <-- jb has quit (Ping timeout) 10:57:06 <flo-retina> likely unrelated (as the timestamp is half an hour earlier); I've got this error 3 times (once per IRC account?) the the error console: Error: [Exception... "'TypeError: this._account is undefined' when calling method: [nsIStreamListener::onDataAvailable]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] 10:57:40 <flo-retina> this was likely when disconnecting the accounts by typing /offline 10:58:14 --> aleth has joined #instantbird 10:58:14 * ChanServ sets mode +h aleth 10:59:04 * nhnt11 clears out his mq 11:02:02 <-- dew has quit (Ping timeout) 11:02:13 --> dew has joined #instantbird 11:02:32 <nhnt11> flo-retina: Thanks for updating the patch on bug 2042, btw. I didn't realize it had bitrotted :( 11:02:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2042 nor, --, 1.5, nhnt11, RESO FIXED, Starting conversations on unrelated keyboard- or mouse-events 11:02:58 <flo-retina> it's ok; it's not your fault that the review took so long 11:03:10 <flo-retina> nhnt11: have you verified that it works correctly in today's nightly? :) 11:04:12 <-- nhnt11 has quit (Ping timeout) 11:04:58 <instantbot> florian@instantbird.org set the Resolution field on bug 2169 to FIXED. 11:05:01 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2169 min, --, 1.5, nhnt11, RESO FIXED, Status attribute in newtab-items is not set for chats, but isn't cleared if it was previously set 11:05:52 <-- jamesw has quit (Ping timeout) 11:06:39 <flo-retina> nhnt11: I discussed our performance issues with Yoric yesterday at lunch. I couldn't find a valid reason for not doing all the ranking/sorting of IRC channels/log crawling on a worker (ie on a separate thread). Have you considered this solution? 11:06:49 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/b20ffe48f223 - Nihanth Subramanya - Bug 2169 - Status attribute in newtab-items is not set for chats, but isn't cleared if it was previously set, r=fqueze. 11:07:01 --> nhnt11 has joined #instantbird 11:07:31 <nhnt11> Bah, lost messages 11:07:46 <nhnt11> 16:33:27 - nhnt11: flo-retina: I can't, it's a windows bug and my windows partition isn't booting :( 11:07:46 <nhnt11> 16:34:09 - nhnt11: At best I can predict if it's working, but from the code changes I can already predict that. 11:07:58 <flo-retina> completing nicks of people who have left makes it a bit too easy to talk to people who aren't here :-S 11:08:32 <flo-retina> nhnt11: ah, that's annoying (especially as we don't have Windows nightlies :-S) 11:09:11 <nhnt11> flo-retina: I've read a bit about worker threads when I was reading about the event loop, etc. If that's something we can use, I'll look into it further. 11:09:38 <nhnt11> Right now though, my priority is bug 2143 because I want ranking to be in the code I submit to Google ;) 11:09:41 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 11:09:42 <flo-retina> nhnt11: the main problem with them is that they don't support XPCOM 11:10:18 <flo-retina> I'm not sure about sqlite 11:10:31 <nhnt11> Hmm. 11:10:35 <flo-retina> if they don't support it yet, it will likely happen in a reasonably near future 11:10:55 <nhnt11> Definitely something worth taking a look at either way. 11:12:14 <flo-retina> nhnt11: Using a worker would would let us not care about chunking the work we do :) 11:12:37 <nhnt11> Yeah, it would be much more straightforward. 11:13:07 <flo-retina> and you could maybe use OS.File synchronously 11:14:35 <nhnt11> Yeah. 11:22:08 <flo-retina> nhnt11: when do you expect bug 2143 to need reviewing time again? 11:22:12 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 11:22:33 <flo-retina> I'll have a 1h train ride Sunday afternoon. 11:22:42 <-- aleth has quit (Quit: Ciao) 11:22:47 --> aleth has joined #instantbird 11:22:47 * ChanServ sets mode +h aleth 11:22:48 <nhnt11> flo-retina: I'm working on it now at least until dinner, and possibly after, so I'm guessing tomorrow-ish. 11:23:36 <flo-retina> I'll be in SF from Sunday evening to Friday 20th evening, and will likely not be very available during that time (and definitely on a different timezone) 11:24:44 <nhnt11> flo-retina: Hopefully I can get a new patch up tonight or early tomorrow, so maybe aleth can give it another look before your train ride to iron it out further? 11:24:51 <aleth> nhnt11: Using the latest nightly, open an awesometab and then connect to freenode. Do you see any new channels appear? 11:25:03 <nhnt11> aleth: They won't until you open another one 11:25:12 <nhnt11> It's designed to request room info only when a new observer is added 11:25:29 <nhnt11> (That was intentional, but is it a bug?) 11:25:33 <aleth> nhnt11: Bit of an edge case, but I'm not sure that's ideal. 11:25:41 <aleth> It certainly surprised me just now... 11:26:08 <nhnt11> Hmm, so perhaps we should request room info on account-connected if we have observers? 11:26:25 <aleth> Other than that all the lag has gone :) 11:26:44 <nhnt11> :) 11:26:45 <aleth> nhnt11: Sounds reasonable. 11:26:58 <aleth> nhnt11: I think you can also file a bug with a patch to pref it on :) 11:27:09 * nhnt11 is finishing up bug 2168 11:27:13 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 11:27:40 <aleth> Is there anything blocking you on the opacity of offline contacts? 11:28:30 <nhnt11> aleth: Ah, no. I keep forgetting about that :( 11:28:33 <aleth> flo-retina: :) on bug 1626 11:28:37 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1626 nor, --, 1.3, aleth, RESO FIXED, Some screen readers say the word "frame" a lot when moving the selection in the contacts list 11:28:40 <nhnt11> (Probably because they're at the bottom of my list and I never see them) 11:28:43 <aleth> Actually I meant L( 11:28:45 <aleth> :( 11:28:49 * aleth can't type today 11:32:11 --> jamesw has joined #instantbird 11:35:32 <instantbot> aleth@instantbird.org cancelled review?(aleth@instantbird.o rg) for attachment 2874 on bug 2136. 11:35:35 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2136 min, --, ---, qheaden, ASSI, Yahoo! Mobile status not taken into account 11:35:37 <nhnt11> Bah, I think the best way to do this is to just add a focus listener to the listbox 11:35:43 * nhnt11 hopes JS has a focus event 11:37:20 <instant-buildbot> build #467 of macosx-onCommit is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-onCommit/builds/467 11:40:43 <-- nhnt11 has quit (Ping timeout) 11:40:57 <instantbot> nhnt11@gmail.com requested review from benediktp@ymail.com for attachment 2882 on bug 2168. 11:41:00 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 11:45:51 <instantbot> nhnt11@gmail.com cancelled review?(benediktp@ymail.com ) for attachment 2882 on bug 2168. 11:45:52 <instantbot> nhnt11@gmail.com requested review from benediktp@ymail.com for attachment 2883 on bug 2168. 11:45:55 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 11:49:01 --> nhnt11 has joined #instantbird 11:49:05 <nhnt11> WTF 11:49:16 <nhnt11> My moznet IRC account disappeared 11:49:40 <nhnt11> I had an #instantbird tab open, and I see a ton of "TypeError: this._conv is undefined" in the error console from conversation.xml 11:50:01 <aleth> Get a debug log if you can. 11:50:05 <nhnt11> Happened every time I tried to send a message, and the newtab spawned errors too and was completely blank 11:50:09 --> clokep_ has joined #instantbird 11:50:14 <nhnt11> So I restarted Ib, and poof! my moznet account is gone 11:50:19 <nhnt11> Let me try... 11:50:32 <aleth> If you restarted, it's likely too late... 11:51:14 <nhnt11> Yeah.. 11:51:24 <-- gerard-majax_ has quit (Ping timeout) 11:51:34 <clokep_> SO MANY BUGS 11:52:14 <aleth> regressive bugs... 11:52:48 <nhnt11> We don't store debug logs anywhere, do we? :( 11:52:48 * nhnt11 didn't think to get a debug log... 11:53:53 <aleth> Is there anything in the error console? 11:54:11 <aleth> Is your old account really gone completely? 11:54:18 <nhnt11> Yeah, i had to make a new one 11:54:26 <aleth> I mean, in the profile 11:54:27 <nhnt11> Well, it wasn't in the accounts dialog 11:54:31 <nhnt11> Let me chek 11:54:33 <nhnt11> check* 11:54:46 <aleth> Did you see errors after restart from that account is what I mean 11:54:48 <clokep_> aleth: I meant fixed bugs. 1.5 is going to be cr-azy. 11:54:51 <nhnt11> Nope 11:55:02 <nhnt11> Nothing after restart. 11:55:12 <aleth> clokep_: Big step up for a point release :) 11:55:58 <nhnt11> aleth: Where should I look in my profile to see if the account is still in some database? I hope I don't have to dig through sqlite files. 11:56:29 <nhnt11> Considering there's nothing in the error console though, it looks like it's gone 11:56:36 <nhnt11> I wonder if I accidentally pressed the delete button somehow 11:56:42 <clokep_> aleth: Yeah...well...depending what we get done maybe we should consider a higher number, but I don't wan tto bikeshed on that. 11:56:44 <clokep_> We have work to do! 11:56:53 <nhnt11> Because computers are smarter than to delete my accounts randomly :P 11:56:53 <aleth> I'm not sure what you could look at if not sql. Get the number of accounts or something... 11:57:04 * aleth does not care about version numbers ;) 11:58:12 <nhnt11> aleth: I see a moznet account in the database, but only one entry 11:58:21 <clokep_> nhnt11: Did you miss the check-in where we check for your username and then delete that account? 11:58:29 <nhnt11> which is probably the one I just created, assuming the databases are flushed immediately 11:58:54 <aleth> Oh well, maybe it will disappear again ;) 11:58:57 <nhnt11> clokep_: I don't know what you're talking about, so I probably did miss it. 11:58:59 <nhnt11> aleth: :P 11:59:30 <aleth> nhnt11: Out of interest, when you recreated the account, do you get to see the existing log files 11:59:45 * nhnt11 still thinks he probably clicked delete 11:59:49 <nhnt11> aleth: for conversations? yes. 11:59:58 <aleth> Good. 11:59:59 <nhnt11> Logs are stored by prpl/account name after all ;) 12:00:07 * nhnt11 was very happy about that. 12:00:16 <nhnt11> It was the first thing I checked :) 12:00:26 * flo-retina isn't sure why bug 1626 is making aleth smile at him. 12:00:30 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1626 nor, --, 1.3, aleth, RESO FIXED, Some screen readers say the word "frame" a lot when moving the selection in the contacts list 12:00:46 <flo-retina> ah, it was a :( 12:01:02 <nhnt11> There's a warning after you click the delete button on an account before actually deleting it right? 12:01:05 <aleth> nhnt11: If you click delete there should be a confirm dialog 12:01:25 <nhnt11> Yeah, I think I've ticked "Don't show this again" or whatever without realizing. 12:01:35 <nhnt11> let me see if I can reset those.. 12:02:43 <nhnt11> messenger.accounts.promptOnDelete;false 12:02:44 <nhnt11> :( 12:03:05 <aleth> RESOLVED YOUROWNFAULT ? ;) 12:03:10 <nhnt11> :D 12:04:30 <flo-retina> nhnt11: have you toggled the pref to not have a confirm prompt when deleting an account? 12:04:45 <nhnt11> I just toggled it back. 12:05:37 <aleth> nhnt11: It does sound like you should file a bug though for the this.conv is undefined stuff when you delete an account with open convs 12:05:41 <flo-retina> nhnt11: so if I read correctly the scrollback, it seemed like deleting an account while the awesometab is visible causes issues; is this right? 12:05:45 <aleth> (assuming you can reproduce that) 12:05:53 <nhnt11> flo-retina: The problem isn't with awesometab 12:06:09 <flo-retina> bah, I should just shut up, people are already saying everything I want to say a few seconds before me today :-D. 12:06:09 <nhnt11> The problem is with the conversation binding 12:06:22 <flo-retina> nhnt11: whatever; file a bug with the info you have about the problem :) 12:06:27 <nhnt11> ok. 12:06:37 <aleth> flo-retina: Before or after, depending on IRC lag ;) 12:07:07 <clokep_> If only we had ping we could tell what that lag was... 12:07:37 <flo-retina> aleth: well, if my message appeared later locally, I don't think the IRC lag could help me look like I'm providing useful contributions to the conversation ;). 12:08:00 <flo-retina> clokep_: so actually, what have we done for 1.5? 12:08:00 --> nhnt12 has joined #instantbird 12:08:08 <-- nhnt12 has left #instantbird () 12:08:12 <aleth> clokep_ is returning invalid timestamps from pings :P 12:08:37 <flo-retina> all the stuff I can remember didn't make 1.5 really awesome, but mostly made 1.4 seem unusable by comparison. 12:08:55 <flo-retina> aleth: why is the ping command expected to send a timestamp? 12:09:00 <nhnt11> Error: [Exception... "'TypeError: this.imAccount is undefined' when calling method: [nsIStreamListener::onStopRequest]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] 12:09:07 <nhnt11> That's what I get when I delete the account 12:09:41 * flo-retina also had errors earlier today: http://log.bezut.info/instantbird/today#m84 12:10:09 <nhnt11> Hmm, could be a common underlying bug 12:10:35 --> nhnt12 has joined #instantbird 12:10:36 <flo-retina> nhnt11: mine seems like a recent regression. 12:10:56 <-- nhnt12 has left #instantbird () 12:11:01 <flo-retina> I haven't tried deleting accounts recently, so I don't know if yours is recent 12:11:14 <nhnt11> Hmm 12:11:23 <nhnt11> The error I just posted isn't thrown right after deleting the account 12:11:25 <nhnt11> so never mind 12:11:38 <nhnt11> Wait, now it's not thrown at all 12:11:44 <aleth> clokep_: Did you test that patch in the last few days? Mark it checkin-needed when you have... 12:11:45 <flo-retina> well, we still need to figure out where it's coming from 12:12:19 --> nhnt12 has joined #instantbird 12:12:38 <-- nhnt12 has left #instantbird () 12:12:58 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 12:13:11 --> nhnt11 has joined #instantbird 12:14:36 <clokep_> aleth: I did not. 12:14:41 <clokep_> flo-retina: Because that's how we tell when it was sent. :) 12:15:11 * aleth assumed that question was rhetorical :-| 12:15:13 <flo-retina> nhnt11: so what's the deal with bug 2168? You select an item automatically when tabbing into the listbox, and it stays selected if you tab out of it? 12:15:17 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 12:15:53 <flo-retina> clokep_: I guess what I mean is: does this rely in anyway on the user's local clock being accurate? 12:16:33 <nhnt11> flo-retina: Er, I guess. It did cross my mind if we should deselect when tabbing out of it but then I forgot about it :] 12:18:34 <nhnt11> I'm seeing lots of errors I've never seen before today 12:18:54 <nhnt11> http://pastebin.instantbird.com/336070 12:20:04 --> nhnt12 has joined #instantbird 12:20:17 <-- nhnt12 has left #instantbird () 12:20:36 <clokep_> flo-retina: I don't see why it would. I don't think you understand what we're using it for. 12:20:46 <clokep_> We only compare it to their own clock. 12:21:25 <-- nhnt11 has quit (Ping timeout) 12:22:04 <flo-retina> clokep_: I obviously don't understand; that's why I'm asking questions! 12:22:43 <flo-retina> clokep_: so what are the exchanged messages? 12:23:08 <clokep_> flo-retina: We sent PING <timestamp>, they send PONG <whatever we sent them> 12:23:18 --> nhnt11 has joined #instantbird 12:23:20 <flo-retina> ok 12:23:24 <flo-retina> can they tinker with the value? 12:23:24 <clokep_> flo-retina: Yes, I understand you're trying to understand; but I'm unsure what you're actually trying to get at. 12:23:28 <clokep_> Sure. 12:23:28 <instantbot> New Instantbird (UI) bug 2170 filed by nhnt11@gmail.com. 12:23:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2170 nor, --, ---, nobody, NEW, Erratic behavior when an account is deleted with open conversations 12:23:45 <flo-retina> do we handle that correctly? / do we ignore absurd values? 12:23:55 <clokep_> Define "absurd". 12:24:02 <flo-retina> less than what you sent 12:24:26 <flo-retina> or really, just an value that you never sent to that nick 12:24:35 <flo-retina> *any 12:25:07 <clokep_> We don't keep track of what we send. 12:25:17 <nhnt11> flo-retina: So do you think the selected item should be deselected when tabbing out of the listbox? I'm not sure about this 12:25:31 * clokep_ isn't really sure what the concern is here. :-/ 12:25:33 <nhnt11> because then the user would lose the ability to press enter and open a conv with the selected item 12:28:25 <nhnt11> Bah, my stats patch is bitrotted again 12:29:22 --> jb has joined #instantbird 12:31:20 <flo-retina> clokep_: I think I'll need to have another look at the PING patch before commenting more on this 12:33:01 <clokep_> flo-retina: Can you at least share what your concern is, because I have no idea what we're really discussing. 12:33:06 <clokep_> Are you concerned about a data leak? 12:33:12 <clokep_> Or someone messing with the return data? 12:33:20 <clokep_> I don't see how that's like different then someone sending us a message though. 12:33:40 <flo-retina> I'm concerned about us displaying broken/unverified data as coming from Instantbird rather than random stuff coming from a non-trusted server 12:34:54 <clokep_> We could store the time we send the message and then send some random hash, but this seemed way more convenient. 12:35:30 <flo-retina> we could just store the time we send, and ignore PONG that don't match something we sent 12:36:00 <flo-retina> (like if for some reason the value got truncated and the last digit is missing, or whatever could happen if the client on the other side is broken) 12:36:03 <nhnt11> bbiab 12:36:05 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 12:36:07 <clokep_> Isn't that what I just said? 12:36:24 <flo-retina> nah, your suggestion was more complicated; it involved a hash 12:36:57 <flo-retina> that looked liked you were concerned about sharing the user's local time (which isn't a relevant concern if we reply to the time command; and I think we do). 12:38:08 <clokep_> I'm not concerned about that at all. 12:38:21 <clokep_> It's the same idea, I dislike the ocmplication of storing the data we're sending. 12:38:44 <clokep_> They can still mess with us by not sending a pong for a really long time. 12:39:53 <flo-retina> how do we react if we receive a PONG but never sent a PING before? 12:42:56 <clokep_> We'll display it. 12:43:03 <clokep_> With that patch, we would. 12:43:07 <clokep_> We keep no state of what we've sent. 12:45:36 <flo-retina> that doesn't seem right :-/ 12:47:19 <clokep_> It's also what we do when we ping the server, by the way. 12:47:31 <clokep_> But that's essentially to keep the socket open, we don't really process that data ta all. 13:00:49 <flo-retina> clokep_: we don't display it then ;) 13:27:27 --> nhnt11 has joined #instantbird 13:29:58 <-- FireFly_TB has quit (Ping timeout) 13:31:30 <nhnt11> flo-retina: http://log.bezut.info/instantbird/130913/#m288 13:32:23 <aleth> nhnt11: What bug is that? 13:32:36 <nhnt11> aleth: bug 2168 13:32:39 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 13:33:14 <aleth> I read that bug as really being a shift-tab bug. 13:33:49 <flo-retina> aleth: yeah, but Mic decided he wants the focus to be visible on the richlistbox, and nhnt11 handled that by selecting the first item automatically... 13:33:55 --> FireFly_TB has joined #instantbird 13:34:18 <nhnt11> First visible item, but yeah ;) 13:34:28 <flo-retina> nhnt11: I'm not sure either; I just think an asymetrical behavior would be strange 13:34:42 <aleth> Right, it should just be symmetric. 13:35:37 <aleth> Selecting an item in the richlistbox doesn't make it look focused imho 13:35:57 <nhnt11> OK, so is there some other visual indicator we can use? 13:36:37 * nhnt11 doesn't like focus rings 13:37:14 <nhnt11> I think the most important part of that bug was that tabbing wasn't working properly, at least that's been solved. 13:37:27 <aleth> I don't think it makes sense to visualize the focus on top of the selection, as we select on hover anyway 13:37:55 <nhnt11> agrred 13:37:58 <nhnt11> agreed* 13:38:44 <aleth> Focus just matters for a11y as that's what gets read out... 13:39:10 <aleth> For keyboard usage per se it doesn't matter as everything gets forwarded anyway. 13:40:14 <nhnt11> aleth: Are you saying we shouldn't be worrying about indicating that the listbox has been focuseed? 13:40:25 <aleth> nhnt11: Yes 13:41:06 <aleth> The two things to ensure are keyboard behaviour works as expected, and that behind the scenes the right thing is focused so screen reader users can use everything properly. 13:41:27 <nhnt11> That's taken care of by the first patch on that bug 13:41:29 <aleth> Screen reader users are not interested in visual indications of focus ;) 13:41:58 <nhnt11> Right 13:43:41 <nhnt11> I guess flo has the final vote on this :) 13:43:56 <flo-retina> nhnt11: nah 13:44:01 <nhnt11> (not that we're "voting" of course, but since Mic is for and you're against..) 13:44:15 <flo-retina> I would have r+'ed the first patch, but Mic didn't, so if you disagree with him, request review from _him_ again with a rationale 13:44:27 <nhnt11> I don't agree/disagree really. 13:48:32 <aleth> nhnt11: It may be a bug that by using TAB it's impossible to select the tab 13:50:15 --> qheaden has joined #instantbird 13:50:25 <qheaden> Hello everyone. 13:51:55 <flo-retina> aleth: what? 13:52:02 <flo-retina> isn't that what the first patch fixes? 13:52:40 <aleth> flo-retina: Maybe it does - I didn't look at the patch. In which case sorry nhnt11 ;) 13:58:03 <-- nhnt11 has quit (Ping timeout) 13:59:10 --> nhnt11 has joined #instantbird 14:04:15 <-- nhnt11 has quit (Ping timeout) 14:05:17 --> nhnt11 has joined #instantbird 14:05:37 <clokep_> Hello qheaden . 14:09:36 --> sabret00the has joined #instantbird 14:14:34 <-- ivan has quit (Ping timeout) 14:19:38 --> ivan has joined #instantbird 14:27:17 --> mconley has joined #instantbird 14:31:39 <-- nhnt11 has quit (Ping timeout) 14:34:23 --> nhnt11 has joined #instantbird 14:35:46 <nhnt11> flo-retina: Btw, the reason I used for each...in instead of for..of is because I get a "TypeError: this._statsByConvId is not iterable" 14:38:59 <nhnt11> Hmm, I wonder if I should be using hasOwnProperty here 14:40:48 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 14:40:54 --> nhnt11 has joined #instantbird 14:50:10 --> wnayes has joined #instantbird 14:55:20 <-- nhnt11 has quit (Ping timeout) 14:58:17 <flo-retina> nhnt11: ok 14:58:18 --> nhnt11 has joined #instantbird 14:58:40 <nhnt11> flo-retina: ping 14:58:51 <flo-retina> nhnt11: pongish (in a meeting) 14:59:15 <nhnt11> I'm trying to address your comment about putting computedScore in the possible conversation prototype 14:59:48 <clokep_> nhnt11: I can take a look too if you want. 14:59:53 <nhnt11> I propose to have a method in the ConversationStats prototype to do the actual computing, and keep it cached in the PossibleConversation 15:00:46 <nhnt11> clokep_: Sure. Right now there's a getter for the computed score in the ConversationStats prototype. Have you seen this patch at all btw? 15:00:56 <clokep_> Not at all. :) 15:01:52 <nhnt11> Ok, so a quick summary: ConversationStats objects store the stats (message counts and the last date). They have a getter that computes their score from these stats 15:02:16 <nhnt11> flo says it makes more sense for PossibleConversations to have the computedScore attribute. 15:03:45 <nhnt11> The problem is, ConversationStats are stored by id in the stats service, so PossibleConversations don't have direct access to it. 15:03:52 <nhnt11> to them* 15:04:13 <clokep_> Do you know when they change? Could you cache the value and then clear it on change? 15:04:17 <nhnt11> I could make PossibleConversations keep references to their stats, but I don't like this really. 15:04:28 <nhnt11> clokep_: Yes I can, that's what I propose to do :) 15:05:02 <nhnt11> But the problem of getting these stats from the stats service is still there. One thing I could do is make _statsByConvId a global variable 15:06:15 <nhnt11> The other would be to keep it as it is and cache the score in ConversationStats objects 15:06:24 <aleth> nhnt11: Would it be simpler to just cache them during each sort process? 15:06:40 <aleth> i.e. recalculate once per sort and entry 15:07:04 <nhnt11> aleth: The problem is, I don't know when a "sort" ends or begins. 15:07:08 <nhnt11> They're sorted as they're added 15:07:34 <nhnt11> aleth: And while we're caching them, why not cache them permanently (until their stats change) 15:07:35 <aleth> So you are effectively proposing to resort an entry each time someone sends a message in a conversation? 15:07:52 <nhnt11> Ah, I see what you mean now 15:08:13 <aleth> I mean, maybe that's OK, but if you're trying to minimize calculations... 15:08:59 <nhnt11> aleth: This is actually a real problem worth thinking about imo. 15:09:08 <aleth> My question is basically whether you are going for sort-after-search or keep-everything-sorted-all-the-time 15:09:12 <nhnt11> Sorting the whole list every now and then isn't really a good solution imo. 15:09:27 <nhnt11> So I say keep the list sorted. 15:09:57 <nhnt11> aleth: How about keeping a Set of convs whose stats have mutated, and resorting them (and recalculating their stats) in _cacheAllStats? 15:09:58 <aleth> It's possible to go for a combination too, i.e. sort alphabetically and calculate ranks on search request 15:10:19 <nhnt11> _cacheAllStats is called every 10 minutes so it seems reasonable 15:10:25 <aleth> "Sorting the whole list every now and then" sounds like the worst of all worlds 15:11:21 <aleth> "How about keeping a Set of convs whose stats have mutated, and resorting them (and recalculating their stats) in _cacheAllStats?" idk without looking at the code 15:11:59 <-- nhnt11 has quit (Ping timeout) 15:13:33 --> nhnt11 has joined #instantbird 15:13:42 <nhnt11> 20:40:59 - nhnt11: aleth: That would mean an alphabetically sorted list on opening a newtab, which is against one of the main goals 15:13:42 <nhnt11> 20:41:06 - nhnt11: Or maybe I misunderstand you 15:13:42 <nhnt11> 20:41:27 - nhnt11: aleth: I like my idea, do you see anything obviously wrong with it? 15:13:42 <nhnt11> 20:42:05 - nhnt11: Resorting a few conversations every 10 minutes is pretty reasonable imo. 15:14:08 <nhnt11> aleth: "idk without looking at the code" ok, didn't see this. 15:14:53 <aleth> I didn't mean an alphabetically sorted list for the user. I meant an alphabetically sorted db and a ranking db and combining the two on demand. (Not suggesting this as the way to go, but it's an option) 15:15:15 <nhnt11> aleth: That seems like something to think about after we have a db... 15:15:40 <aleth> By "db" I just meant "the whole list of possible entries" for now 15:16:19 <aleth> "Resorting a few conversations every N minutes" Nothing wrong with that per se, if it was also done when opening a newtab 15:16:56 <nhnt11> Possibly /only/ when opening a newtab would work too 15:17:52 <nhnt11> Though I doubt a few messages could affect a conversation's rank noticeably unless the user is very new :) 15:18:02 <aleth> Yeah, as long as that doesn't cause any lag... 15:18:17 * nhnt11 thinks every 10 minutes is probably fine 15:18:46 <clokep_> No. 15:18:50 <clokep_> That'll cause jank whenever it does it. 15:18:53 <clokep_> And the user won't understand why. 15:18:58 <clokep_> It's like what happens with gloda. 15:19:15 <aleth> nhnt11: I still don't understand your setup. 15:19:24 <nhnt11> clokep_: executeSoon? 15:19:39 <aleth> Most possible chats don't have a score at all, after LIST. 15:19:44 <nhnt11> It's not the whole list, it's only the few conversations the user has participated in the last 10 minutes. 15:20:08 <nhnt11> aleth: What parts would you like me to clarify? 15:20:20 <nhnt11> aleth: These chats get a score once a conversation is started with them 15:20:37 <aleth> When you say "I want to keep everything sorted all the time" what is 'everything'? 15:20:55 <nhnt11> PossibleConversations.. 15:21:42 <nhnt11> What I'm saying is, if the stats for 10 conversations changes, I shouldn't be resorting the whole list. Instead, remove and re-add these 10 convs using the binary search we already have 15:21:51 <nhnt11> (I think this is the obvious thing to do) 15:22:00 <nhnt11> s/changes/change 15:22:22 * flo-retina is back. 15:23:27 <aleth> That sounds right, but why do it only every ten minutes? 15:24:09 * aleth thinks we are talking past each other somehow 15:24:45 <nhnt11> Ah, why indeed. 15:25:05 <nhnt11> I guess I was thinking, if we send/receive a ton of messages, we shouldn't resort the conv a ton of times 15:25:18 * nhnt11 chuckles at "a ton of times" 15:25:42 <aleth> Right, that was one of the things I was asking about... 15:26:06 <nhnt11> So this is why I said every 10 mintues, along with updating our cache file 15:26:30 <nhnt11> I guess on opening a new tab is a reasonable time to do it too. 15:26:52 <nhnt11> Although if we have a lot of conversations whose stats mutated, this might cause lag 15:27:06 <aleth> It would be better to do it asap when there is time to do it (i.e., some kind of queueing again) 15:27:15 <nhnt11> (for which an executeSoon would probably suffice) 15:27:22 * nhnt11 is liking the sound of worker threads even more :P 15:27:54 <aleth> That's an interesting suggestion 15:28:50 <nhnt11> I think it's overkill for this 15:29:58 <aleth> For this patch, certainly ;) 15:30:14 * clokep_ waits for Florian to catch up and tell us we're all wrong. :) 15:30:26 * nhnt11 expects that too 15:30:41 * aleth thought nhnt11 already had flo's review comments ;) 15:31:24 <flo-retina> clokep_: you are all wrong 15:31:30 <flo-retina> clokep_: but I don't know why yet :-P. 15:32:09 <nhnt11> aleth: flo didn't quite cover this there... 15:32:20 * nhnt11 wonders if flo /did/ talk about it and he didn't realize 15:33:05 <aleth> nhnt11: Your original question confused me because if you are proposing a huge list which is kept sorted at all times, then every time you move an entry you can cache the store in the entry. So I don't understand the question... 15:33:16 <aleth> s/store/score 15:33:31 <flo-retina> "ConversationStats are stored by id in the stats service, so PossibleConversations don't have direct access to it." what does that mean? 15:34:01 <flo-retina> nhnt11: "I could make PossibleConversations keep references to their stats, but I don't like this really." why do you not like it? 15:34:02 <nhnt11> flo-retina: _statsByConvId is a property of the stats service, so I need a reference to the stats service to obtain the stats for a given id 15:34:26 <nhnt11> flo-retina: Because PossibleConversations are removed/added in realtime when accounts disconnect for example 15:34:48 <nhnt11> But I suppose if I passed a conv its stats in the constructor... 15:35:01 <nhnt11> bah, seems like overcomplicating it to me 15:35:10 <aleth> nhnt11: That's my point, how do you know where to add them without having the score? If your approach is to keep it sorted... 15:35:12 <nhnt11> Right now the stats service manages everything, and convs don't need to know about their stats. 15:35:25 <nhnt11> aleth: The stats service does know the score 15:36:30 * nhnt11 goes to eat dinner 15:37:01 <-- jb has quit (Ping timeout) 15:38:59 <-- nhnt11 has quit (Ping timeout) 15:40:48 <flo-retina> nhnt11: so, if you are observing the conversations for new messages, you can easily keep a list of all the conversations that have received messages and are thus no longer sorted. Then you can just remove and re-insert (with the binary search) each conversation when it is closed (or when it hasn't received any message for a while?). And when a newtab is opened, resort immediately all the conversations that have received new messages 15:40:48 <flo-retina> since the last time a newtab was opened. 15:45:47 <flo-retina> btw, are there still patches that we expect to land soon to optimize the LIST processing, or are we ready to reprofile (and hopefully decide that it's good enough to pref on?) 15:46:38 <aleth> Afaik its' ready to reprofile and pref on 15:50:15 <aleth> All the optimization patches have landed... 15:51:33 <flo-retina> that's great :) 15:52:17 <flo-retina> I find the stuff I most frequently fail to find in the awesometab to start a conv with are IRC nicks that I've had previous conversations with in the past 15:53:02 <aleth> That, and that search doesn't work within words means I often get no results at all. 15:53:30 <aleth> i.e. I scroll more than I should have to ;) 15:54:20 <aleth> It'll be interesting to see how the profile of LIST has changed now 15:58:20 <flo-retina> I suspect QueryInterface will be showing up a lot more 15:58:38 <flo-retina> as it's one of the things I wanted to optimize, but didn't have time to look into yet 16:05:29 <aleth> I have no good ideas on how to fix the screen reader regression 16:06:15 <flo-retina> yeah 16:06:23 <flo-retina> I hope we won't get the mutation warning back :-S 16:09:03 <aleth> Getting someone to look at the underlying gecko bug seems unlikely too :-/ 16:17:32 <flo-retina> I thought the bug was expected to also be fixed on the screen reader side; and our previous patch was just a workaround :-/ 16:17:42 <flo-retina> what's the gecko bug? 16:17:46 <flo-retina> can we patch it ourselves? 16:17:47 <aleth> iirc I don't think the screen reader side has a bug. 16:18:02 <flo-retina> patch it ourselves = I mean "trivially add a null check" 16:18:31 <aleth> https://bugzilla.mozilla.org/show_bug.cgi?id=786508 16:18:37 <clokep_> flo-retina: So I had a conversation over Twitter recently about screen readers on OS X... 16:18:44 <clokep_> Have we ever had reports about this not working? 16:18:46 <clokep_> aleth: ^ 16:18:55 <flo-retina> clokep_: has it ever worked? 16:19:10 <flo-retina> I think Mozilla supporting screen readers on OS X is quite recent 16:20:27 <aleth> The only thing we could patch is gecko (there are too many different screen readers out there...) 16:20:53 <flo-retina> aleth: IIRC the screenreader accesses the 'accessible' objects asynchronously, and the first notification's object is dead by the time the screen reader attempts to touch it. 16:22:48 <aleth> Yes, but gecko does fire two events where it should only fire one. Of course screen readers could work around that... 16:24:44 <clokep_> flo-retina: No idea. :) Pretty much I told the guy I have no idea about OS X and to file a bug. :) 16:26:01 * flo-retina goes to watch that video again :-D 16:26:57 <flo-retina> uh, which add-on is that guy talking about on the mailing list? :-S 16:27:28 <flo-retina> can we tell him to try Instantbird and send us a debug log? :-P 16:27:35 <flo-retina> he would need a nightly and to enable JS-XMPP though :-/ 16:29:27 <aleth> MUCs on JS-XMPP may be disappointing though ;) 16:29:45 <flo-retina> but if he's on Tb, he's using that 16:30:04 <aleth> Ah right. 16:30:42 <aleth> I'm pretty sure we had reports about hipchat being strange in some ways on this channel before 16:30:58 <flo-retina> yeah 16:31:03 <flo-retina> but I don't remember what the problems were 16:31:17 <aleth> something about participant names iirc 16:31:53 <clokep_> flo-retina: aleth I'm pretty sure he's just trying to CREATE a chat room, which XMPP doesn't support IIRC. 16:31:59 <clokep_> (Our XMPP code, not the XMPP protocol) 16:32:15 <clokep_> (Ours being libpurple in INstantbird or JS-XMPP) 16:32:23 <clokep_> I think it has some other crazy menu that's available only in Pidgin. 16:33:09 <aleth> I can create MUCs with libpurple XMPP on IB 16:33:55 <aleth> Unless it only looks like it works but is actually broken... 16:34:33 <clokep_> Hmm, maybe you can. 16:34:45 <clokep_> I figured someone should reply and say "Yo get us a debug log and tell us WTF your issue is" :) 16:34:47 <clokep_> (Or come on IRC) 16:35:02 --> nhnt11 has joined #instantbird 16:36:29 <flo-retina> replying and saying Yo seems a great idea :) 16:37:22 <flo-retina> anyway, week-end time! 16:37:25 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 16:39:50 <nhnt11> http://log.bezut.info/instantbird/today/#m475 seems like flo-retina agrees with me and aleth :) 16:40:45 <-- mconley has quit (Connection reset by peer) 16:40:46 --> mconley_ has joined #instantbird 16:41:46 * mconley_ is now known as mconley 16:41:59 --> jb has joined #instantbird 16:46:34 --> skeledrew has joined #instantbird 16:47:05 <aleth> Clicking through logs is much snappier now :) 16:48:04 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 16:48:32 --> nhnt11 has joined #instantbird 16:51:21 * clokep_ wants a new nightly. :( 16:52:18 <aleth> Must feel like you're still on 1.4 ;) 16:52:53 <nhnt11> ouch :P 16:52:57 <clokep_> More like 0.1.3. :P 16:53:38 <aleth> Don't worry, the contact list is coming soon! :P 16:54:02 * aleth actually has no idea when that was added... 16:54:34 <-- nhnt11 has quit (Ping timeout) 16:54:37 --> nhnt11 has joined #instantbird 16:59:34 --> Mook_as has joined #instantbird 17:04:06 --> gerard-majax_ has joined #instantbird 17:05:53 <-- gerard-majax_ has quit (Ping timeout) 17:07:43 --> gerard-majax_ has joined #instantbird 17:14:48 <nhnt11> aleth: Would it be ok to have a global gStatsService variable, and set it to |this| in the stats service's _init function? 17:15:08 <nhnt11> That would give PossibleConversations and ConversationStats objects access to it... 17:15:57 <aleth> Is that /really/ the best way? 17:17:34 <aleth> It smells r-., but then I don't understand the problem. 17:19:18 <nhnt11> If you're asking if that's the best way to expose the stats service to these objects, then the only other way I can think of is by passing it in their constructors. If you mean why expose it at all, well if ConversationStats are going to watch for new texts then they need access to the _cacheAllStats function.. 17:20:12 <nhnt11> I guess I can use flo's first suggestion as an alternative.. 17:20:27 <aleth> What's cacheAllStats? 17:21:02 <nhnt11> aleth: When new texts are received, a timer is set to call cacheAllStats in 10 minutes, which updates the JSON cache file. 17:22:07 <aleth> Serializing the JSON seems distinct from updating things in memory 17:23:20 <nhnt11> How will the stats service know that things in memory have been updated, so it can schedule an update to the JSON cache? 17:23:59 <nhnt11> I think I'll try my best to handle this and post a new patch, and we can discuss further after that. 17:24:15 <nhnt11> Right now I think we're talking past each other too much 17:24:28 <aleth> I'm sorry, I just don't understand the way you are structuring this :( It will be easier when you put up the next patch I think 17:27:12 <-- FireFly_TB has quit (Ping timeout) 17:45:55 --> Mnyromyr has joined #instantbird 17:45:57 <-- jb has quit (Ping timeout) 17:46:04 <nhnt11> aleth: Do you have time to look at a patch now? 17:46:29 <aleth> Some. 17:46:52 <aleth> Not enough for a detailed review... 17:47:54 <nhnt11> That's fine 17:47:59 * nhnt11 will upload a patch 18:00:14 <instantbot> nhnt11@gmail.com cancelled review?(aleth@instantbird.o rg) for attachment 2862 on bug 2143. 18:00:15 <instantbot> nhnt11@gmail.com requested review from florian@instantbird .org for attachment 2884 on bug 2143. 18:00:19 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 18:02:49 <nhnt11> aleth: I hope nothing is too confusing... 18:03:52 <nhnt11> Basically the way I've coded this, the stats service maintains both possible convs, and stats, and does the work to sort convs based on stats, but it does its work such that PossibleConversation objects never have to deal with stats and vice versa.. 18:41:27 <aleth> nhnt11: "// Duplicate this._convs to avoid modifying it while adding existing convs" sounds like something it would be nice to avoid 18:43:19 <aleth> Would it make sense to filter /first/ and then insert the existing convs where appropriate? 18:46:00 <aleth> Also I wonder whether your list of existingConvs and your list of current convs for the stats services should somehow be merged (this is a vague comment as I'm still reading the patch) 18:49:28 <aleth> gStatsService does not seem to be used anywhere anymore? 18:50:01 <nhnt11> aleth: gStatsService got in there? I exported a new patch without it before uploading (or so I thought) 18:51:23 <nhnt11> aleth: "somehow be merged" Do you mean insert/delete them at the appropriate observer notifications? 18:51:40 <nhnt11> If so we had a discussion about it iirc and flo said it's fine to just insert them at filter-time. 18:51:45 <aleth> idk, I just notice there are two lists of basically the same underlying thing. 18:52:02 <nhnt11> oh wait 18:52:10 <nhnt11> you mean _statsByPrplConvId? 18:52:16 <aleth> Yes 18:52:42 <nhnt11> Hmm. 18:53:16 <nhnt11> One is for imConversations and one is for prplConversations, I'm not sure how inter-convertible they are. 18:53:16 <aleth> If those are exactly the instances for which stats can change, it makes sense to treat that together 18:53:41 <nhnt11> interesting. 18:53:42 <aleth> I haven't got a clear proposal, it just seems that there should be a way to make that neater 18:53:47 <aleth> When does this._computedScore get recalculated? 18:54:14 <nhnt11> aleth: Er, there should be a |delete stats._computedScore| in the new-text notification handling code 18:54:19 <aleth> aha! 18:54:21 <nhnt11> (sorry) 18:55:05 <nhnt11> aleth: I haven't implemented the resorting-convs-whose-stats-have-changed stuff 18:55:20 <nhnt11> I've only responded to flo's review comments for now (most of them) 18:55:22 <aleth> Yeah, I saw that. 18:55:30 <aleth> So my main feedback is that exactly the stats you worry about because they get updated are the ones in existingConv so maybe there is some scope use that as you proceed 18:57:15 <aleth> anyway, gtg, sorry 18:57:24 <nhnt11> ok, good night! 18:57:56 --> qlum has joined #instantbird 18:59:42 <-- aleth has quit (Quit: Ciao) 19:02:21 <-- Suiseiseki has quit (Ping timeout) 19:03:37 --> Suiseiseki has joined #instantbird 19:04:00 --> jb has joined #instantbird 19:17:07 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 19:18:21 <clokep_> Would anyone here like to be convinced to write a blog post? 19:18:24 <clokep_> About GSoC? 19:24:21 <-- jb has quit (Ping timeout) 19:25:17 <qheaden> clokep_: You mean like a blog about our experience? 19:25:34 <qheaden> If so, I plan on doing one soon. 19:26:38 --> jb has joined #instantbird 19:32:22 <clokep_> qheaden: Kind of, I meant from the team's perspective, so aleth, Florian, me, Mic most likely would do it. 19:32:36 <qheaden> Ahh okay. 19:33:56 * clokep_ goes home. 19:39:02 <-- clokep_ has quit (Quit: http://www.mibbit.com ajax IRC Client) 19:46:04 <-- jb has quit (Ping timeout) 19:55:59 <-- mconley has quit (Connection reset by peer) 19:56:20 --> mconley has joined #instantbird 20:05:16 --> jb has joined #instantbird 20:05:21 <instantbot> benediktp@ymail.com granted review for attachment 2883 on bug 2168. 20:05:24 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2168 nor, --, ---, nhnt11, NEW, Tab key doesn't behave as expected in the new conversation tab. 20:22:23 --> jb1 has joined #instantbird 20:22:27 <-- jb has quit (Connection reset by peer) 20:27:55 --> flo-retina has joined #instantbird 20:27:55 * ChanServ sets mode +qo flo-retina flo-retina 20:29:37 <flo-retina> "<aleth> Clicking through logs is much snappier now :)" I'm surprised you see a noticeable difference, but that's a nice surprise :) 20:31:13 --> EionRobb has joined #instantbird 20:31:44 <flo-retina> actually, I think it could be much snappier if we got rid of the Bubble fade-in animation that just seems to blink for no reason 20:34:20 <-- mconley has quit (Connection reset by peer) 20:34:27 <flo-retina> nhnt11: "Would it be ok to have a global gStatsService variable" yes, if it significantly simplifies the code. We have something like that for other services (maybe in imContacts.js) 20:34:37 --> mconley has joined #instantbird 20:38:41 <flo-retina> clokep_: if GSoC was successful, we can count our students as being part of the team ;). 20:38:52 <flo-retina> I see no problem with qheaden writing a blog post for blog.instantbird.org 20:39:34 <-- jb1 has quit (Ping timeout) 21:16:47 --> florian has joined #instantbird 21:20:18 <-- mconley has quit (Input/output error) 21:23:06 <instantbot> New Instantbird (UI) bug 2171 filed by florian@instantbird.org. 21:23:07 <instantbot> florian@instantbird.org requested review from aleth@instantbird.o rg for attachment 2885 on bug 2171. 21:23:14 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2171 nor, --, ---, nobody, NEW, bubbles shouldn't fade in when displayed in the log viewer 21:25:11 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 21:27:39 <-- qlum has quit (Client exited) 22:58:39 <-- sabret00the has quit (Ping timeout) 23:18:40 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.19/2010030105]) 23:21:14 <-- gerard-majax_ has quit (Ping timeout) 23:25:44 --> mconley has joined #instantbird