All times are UTC.
01:11:46 <-- EionRobb has quit (Ping timeout) 01:12:59 --> EionRobb has joined #instantbird 01:16:10 <-- Mook_as has quit (Quit: Mook_as) 01:23:44 --> nhnt11 has joined #instantbird 01:38:14 <-- flo-retina1 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 01:47:26 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 01:47:32 --> nhnt11 has joined #instantbird 02:11:53 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 02:12:09 --> nhnt11 has joined #instantbird 02:12:34 <-- nhnt11 has left #instantbird () 02:13:41 --> nhnt11 has joined #instantbird 02:13:51 <-- nhnt11 has left #instantbird () 02:16:24 --> nhnt11 has joined #instantbird 02:16:29 <-- nhnt11 has left #instantbird () 02:18:18 --> nhnt11 has joined #instantbird 02:18:41 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 02:22:15 --> mconley has joined #instantbird 02:40:08 <-- wnayes has quit (Quit: wnayes) 03:10:22 <instant-buildbot> build #977 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/977 03:25:15 <-- mconley has quit (Input/output error) 03:35:25 <instant-buildbot> build #999 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/999 05:49:57 --> nhnt11 has joined #instantbird 06:32:12 <-- nhnt11 has quit (Ping timeout) 06:36:44 --> nhnt11 has joined #instantbird 07:31:31 <-- EionRobb has quit (Ping timeout) 07:32:19 --> EionRobb has joined #instantbird 07:41:00 <-- EionRobb has quit (Ping timeout) 07:42:12 --> EionRobb has joined #instantbird 07:44:55 <-- nhnt11 has quit (Ping timeout) 08:18:13 <-- gerard-majax has quit (Ping timeout) 08:27:03 --> nhnt11 has joined #instantbird 08:46:24 <-- nhnt11 has quit (Ping timeout) 08:48:44 --> qlum has joined #instantbird 08:52:35 --> nhnt11 has joined #instantbird 08:57:34 <-- nhnt11 has quit (Ping timeout) 09:07:56 --> nhnt11 has joined #instantbird 09:08:19 --> rosonline has joined #instantbird 09:26:43 <-- EionRobb has quit (Ping timeout) 09:27:14 --> gerard-majax has joined #instantbird 09:30:41 --> EionRobb has joined #instantbird 09:31:31 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 09:31:44 --> aleth has joined #instantbird 09:31:44 * ChanServ sets mode +h aleth 09:35:33 <-- sabret00the has quit (Ping timeout) 09:39:23 <nhnt11> Hi aleth 09:39:44 <aleth> Hi :) 09:39:45 <nhnt11> I've been trying for the last 2 days to fix up the stats service in a way that's intuitive and in general not confusing 09:39:53 <nhnt11> stats patch * 09:40:10 <nhnt11> (Mostly the bit about caching the scores of contacts) 09:40:18 <aleth> It seems like the kind of problem that is obvious only after you have solved it ;) 09:43:14 <nhnt11> I created a new object called MergedConversationStats, which would represent the total stats of a contact's buddies, and return the cumulative score, etc. I then tried storing these by contact id in another object (_statsByContactId), but ran into the problem of how to tell these merged stats that the stats of one of the buddies has changed. 09:43:52 <nhnt11> I thought a lot about using some sort of observer system, and even wrote part of it 09:44:08 <aleth> That sounds complicated... 09:44:11 <nhnt11> then decided that this is way too complicated for what I'm trying to accomplish, and now I'm just sitting and pondering what to do 09:45:06 <aleth> Have you profiled the patch as is to discover how much time is spent in getScoreForConv? 09:45:41 <nhnt11> Er, no... I got rid of getScoreForConv in favor of getters in the PossibleConversation prototypes 09:46:01 <nhnt11> (I changed _statsByConvId to a global gStatsByConvId) 09:46:27 <aleth> Right, I remembered only after I commented that the problem with that would be how to notify possibleConvs of stats changes 09:46:34 <aleth> Sorry about that. 09:47:06 <nhnt11> For just buddy stats, it's not that hard 09:47:44 <nhnt11> What I was thinking was of caching contact scores separately, and when a buddy's score changes, delete the cached score of the corresponding contact (forcing a recomputation) 09:47:46 <aleth> My point is with the patch as it is, the only worry is about contacts, because if it wasn't for contacts there wouldn't be a getScoreForConv 09:47:55 <nhnt11> Yeah 09:49:11 <aleth> Caching contact scores separately may be a good idea. But I'm open to "we don't actually spend much time in getscoreforconv so it doesn't need optimizing for now" 09:49:18 <aleth> If that were the case. 09:49:23 <nhnt11> :P 09:49:31 <nhnt11> I'll do some profiling then.. 09:50:54 <aleth> But otherwise I think you are right, just have temporary statsByConvId entries for contacts 09:51:37 <aleth> The advantage of that being that this._statsByConvId[aPossibleConv.id] will then "just work" for all source types 09:51:47 <aleth> (unless I am missing something) 09:52:30 <aleth> (e.g. would ids for contacts clash with those for buddies?) 09:52:31 <nhnt11> I've got to run, sorry. Have a lab. 09:52:40 <nhnt11> I'll be back in 2 hours ish 09:52:50 <aleth> On Saturday afternoon? Bad luck... ;) 09:54:20 <-- nhnt11 has quit (Ping timeout) 09:54:52 --> sabret00the has joined #instantbird 10:09:07 --> clokep has joined #instantbird 10:09:08 * ChanServ sets mode +o clokep 10:20:13 <-- qlum has quit (Quit: Getting the <censored> out.) 10:24:28 --> jb has joined #instantbird 10:37:34 <-- aleth has quit (Ping timeout) 10:37:56 --> aleth has joined #instantbird 10:37:57 * ChanServ sets mode +h aleth 10:48:44 <-- EionRobb has quit (Quit: Leaving.) 10:50:17 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 11:00:28 <-- gerard-majax has quit (Ping timeout) 11:01:55 --> dew has joined #instantbird 11:02:31 <-- dew1 has quit (Ping timeout) 11:19:01 <-- jb has quit (Ping timeout) 11:58:21 --> nhnt11 has joined #instantbird 11:58:31 <nhnt11> aleth: http://log.bezut.info/instantbird/today/#m73 - yeah :( 12:00:55 <nhnt11> aleth: If we cache scores for contacts, I think it should be in a different object 12:01:17 <nhnt11> Because that way we wouldn't have to worry about not flushing them to the cache file, and id's won't clash 12:01:41 <nhnt11> (Yes, currently the id of a contact is the id of the preferred buddy so they clash) 12:02:38 <nhnt11> Though, is flushing contact scores to the cache file a bad thing? 12:02:47 <aleth> Whatever seems cleanest :) 12:03:17 <aleth> I guess the only issue with saving contact scores is that contacts can change 12:03:23 <nhnt11> (I think the answer to that question is yes, it's kinda wasteful) 12:03:33 <nhnt11> Ok, let me think about all this and come up with some code. 12:04:03 <aleth> The issue is, I guess, to avoid storing every buddy twice ;) 12:04:14 <aleth> (assuming most buddies are not merged) 12:12:39 --> mconley has joined #instantbird 12:15:21 <-- nhnt11 has quit (Ping timeout) 12:27:15 --> nhnt11 has joined #instantbird 12:30:09 <-- mconley has quit (Input/output error) 13:11:00 <-- nhnt11 has quit (Ping timeout) 13:27:26 --> mconley has joined #instantbird 13:29:16 <-- mconley has quit (Input/output error) 13:29:24 --> mconley has joined #instantbird 15:00:57 --> jb has joined #instantbird 15:14:35 --> qlum has joined #instantbird 15:15:13 --> gerard-majax has joined #instantbird 15:15:31 <-- BWMerlin has quit (Quit: BWMerlin) 15:17:05 <-- gerard-majax has quit (Ping timeout) 15:21:00 --> gerard-majax has joined #instantbird 15:26:59 --> flo-retina has joined #instantbird 15:26:59 * ChanServ sets mode +qo flo-retina flo-retina 15:27:24 <flo-retina> hello :) 15:33:07 <-- flo-retina has quit (Ping timeout) 15:38:00 --> flo-retina has joined #instantbird 15:38:00 * ChanServ sets mode +qo flo-retina flo-retina 15:39:13 <instantbot> firstname.lastname@example.org requested review from email@example.com for attachment 2898 on bug 608. 15:39:16 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=608 nor, --, ---, florian, NEW, Exception from buddies of an unknown account type 15:39:25 * flo-retina couldn't sleep and was bored in the plane. 15:39:44 <flo-retina> It wasn't easy to find something I could fix without any internet access. 15:41:16 <flo-retina> I had prepared tabs with bug 1547 to be able to review it whenever I would have time, even without internet connection, but unfortunately my Firefox had restarted, and the tab title were shown, but replaced with an error page when I actually selected the tabs. :-/ 15:41:19 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1547 nor, --, ---, nobody, NEW, Check for open conversations when adding a buddy 15:42:13 <aleth> It's annoying when things drop from the cache just when you want them... 15:42:26 <flo-retina> yeah... 15:42:31 <flo-retina> I was a bit disappointed 15:43:38 <aleth> or maybe it's that FX should notice it is offline and not try to reload :P 15:43:39 <flo-retina> the 3G on the phone seems almost as unreliable at the train station as it usually is in trains :-/ 15:44:06 <flo-retina> aleth: well, the problem is it drops the pages when restarting, and reloads only when the tab is shown. 15:44:10 --> nhnt11_phone has joined #instantbird 15:44:13 <flo-retina> that's usually a reasonable behavior to save resources 15:44:23 <flo-retina> but in this specific case, it was annoying :-/ 15:44:52 * flo-retina is at the airport, waiting for a train connection in an hour and a half 15:45:19 <flo-retina> (although I may try jumping in the train that is in one hour) 15:45:22 <dew> flo-retina is a trooper and always works on bugs in his spare time ;) 15:45:42 <aleth> He works on bugs in his paid time too, just different ones ;) 15:47:30 * nhnt11_phone wonders if flo-retina has considered printing pages to PDFs for offline use 15:48:10 <flo-retina> nhnt11_phone: that wouldn't let me insert review comments 15:48:59 <nhnt11_phone> Better than losing them? Idk, just a thought :) 15:49:19 <flo-retina> nhnt11_phone: well, I could also download the raw patch and to the review in emacs... 15:49:34 <flo-retina> nhnt11_phone: but anyway, if I had assumed the tabs weren't there, I would have reloaded them just before leaving the office 15:49:43 <nhnt11_phone> Heh 15:49:44 <nhnt11_phone> OK 15:50:14 --> wnayes has joined #instantbird 15:52:59 <-- nhnt11_phone has quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) 15:58:18 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 15:59:58 <-- gerard-majax has quit (Ping timeout) 16:02:11 --> flo-retina has joined #instantbird 16:02:11 * ChanServ sets mode +qo flo-retina flo-retina 16:04:34 <flo-retina> https://bugzilla.mozilla.org/show_bug.cgi?id=919180 fun :-P 16:04:54 <dew> so if I got this okcupid plugin working would it be included in the default install? 16:07:27 <flo-retina> aleth: not sure if this is what you were wondering, but contact, buddy, and conversation ids are all different, and numbered from 1, so very likely to clash. 16:07:44 <flo-retina> dew: do you think it should? 16:07:57 <dew> that's your call! 16:08:05 <dew> I have to finish it first 16:08:12 <flo-retina> (I'm not opposed to it.) 16:08:28 <flo-retina> it wouldn't be in the "popular protocols" first tab, but in the whole list, I don't see any reason to not include it 16:08:41 <aleth> flo-retina: I'm not sure if he's thinking of using those id's or the long text ones corresponding to log file names for this 16:08:54 <flo-retina> alright 16:09:13 <flo-retina> I don't remember anything of what's in the patch I looked at, and it seems it has changed significantly since that and is changing again right now 16:09:15 <aleth> But he said there was a clash already, so... 16:09:23 <aleth> I'd wait for the next iteration 16:09:27 <flo-retina> ok 16:09:53 <flo-retina> I guess I'll rather spend my spare time on figuring out what's going on with the Windows VM then... 16:13:58 <-- jb has quit (Ping timeout) 16:15:02 * aleth can't remember if TB24 includes debug logging, but suspects no 16:16:34 <-- flo-retina has quit (Ping timeout) 16:19:30 --> flo-retina has joined #instantbird 16:19:30 * ChanServ sets mode +qo flo-retina flo-retina 16:26:03 <flo-retina> aleth: It has debug logging, but no UI for it... 16:30:18 <flo-retina> in my current debug build, if I try to reorder buddies inside a contact, I get "Error: NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN: Cannot modify properties of a WrappedNative 16:30:18 <flo-retina> Source File: file:///Users/florian/buildhg/obj-instantbird-dbg/mozilla/dist/InstantbirdDebug.app/Contents/MacOS/components/imContacts.js Line: 692" 16:30:54 <flo-retina> it's a debug build, so in the terminal I also get: ###!!! ASSERTION: Invalid state to get the params object - all calls will fail!: 'state == mozIStorageStatement::MOZ_STORAGE_STATEMENT_READY', file /Users/florian/buildhg/hg.instantbird.org/mozilla/storage/src/mozStorageStatementJSHelper.cpp, line 131 16:31:09 <flo-retina> I wonder if this is a regression with moz23, or just my local debug build that's somehow busted 16:31:15 <aleth> I get that in a nightly too 16:31:41 <flo-retina> ok, I guess we will need to investigate then 16:31:43 <aleth> Idk if it ever worked (never tried to reorder buddies) 16:32:04 <flo-retina> it definitely worked a year or two ago (and was nicely animated) 16:32:21 <flo-retina> but I don't remember testing it recently, so the regression may be older than moz23 16:32:43 <flo-retina> this smells like something wanting unit tests ;) 16:33:20 <aleth> UI unit tests... is that the whole mochitest thing? 16:34:26 * aleth has only a dim idea of what those are 16:35:53 <flo-retina> aleth: not related to UI at all. 16:36:00 <flo-retina> aleth: it's imContacts.js that we need to test in this case 16:36:46 <flo-retina> I would also like us to have mochitests at some point, but that's for different things (could be useful to test interactions with the awesometab, or the account wizard, ...) 16:38:04 <aleth> Oh, I see. I thought you meant tests from a buddy list user perspective (merging/moving contacts etc) 16:38:23 <flo-retina> I said _unit_ test ;). 16:39:04 <flo-retina> the part I would really like us to test though, is the automatic reconnections of accounts in imAccount, based on the status changes. 16:39:18 <flo-retina> we keep breaking/fixing it, so it would be nice to know that we can't break any more the cases that we fixed recently ;) 16:39:33 <aleth> Yes 16:39:42 <flo-retina> I would have attempted to look into writing tests for that, if my flights lasted another few hours. 16:40:03 <flo-retina> but imContacts.js also desperately needs testing 16:40:27 <flo-retina> especially as I would like at some point to rewrite the whole back-end to stop using mozStorage 16:40:41 <flo-retina> (I'm thinking that a JSON file would be more appropriate for what we actually do with this data) 16:41:11 <aleth> You mean, rewrite it in a test-driven way... 16:41:38 <flo-retina> not necessarily 16:41:43 <flo-retina> but kindof :) 16:41:50 * aleth still needs to add tests for tab completion... 16:42:01 <flo-retina> yeah :) 16:42:03 <flo-retina> would be really nice 16:42:17 <aleth> Same thing, for before I try moving it to a module ;) 16:42:46 <flo-retina> ah, I thought moving it to a module was more or less required to you to be able to unit test it? 16:43:05 <aleth> Yes, it would have to be done in parallel 16:43:05 <flo-retina> currently you would need mochitests to test it as part of the conversation UI 16:43:51 <flo-retina> maybe we should run Fake as part of our UI tests 16:44:00 <flo-retina> so that it stops being broken whenever we need it :-P 16:44:12 <aleth> i.e. move it in a minimum-change way while adding tests, then rewrite it a bit. As is it depends on a lot of stuff from conversation.xml so it would be a bit of a fake module... 16:45:12 <flo-retina> crazy idea: should the people who you mention a lot on IRC be included (and ranked) in the awesometab to start private conversations with them? :-P 16:46:13 <flo-retina> and possibly all active nicks too 16:46:28 <aleth> Hmm, maybe 16:47:38 <dew> the awesometab is going to be ummm awesome! 16:48:42 <aleth> more crazy idea: if we did that, and the awesometab got really good at providing ways to add people, we could eventually just drop the contact list altogether 16:48:44 <flo-retina> I demo'ed it to Boriss 'today'-ish (Friday). 16:48:56 * flo-retina wanted to convince people to adopt a similar UI for Talkilla 16:49:20 <flo-retina> ie. drop the contact list sidebar, and just have a UI with 5 or so top contacts displayed, and a search box at the top. 16:49:46 <flo-retina> aleth: hasn't that always been part of the plan? :-P 16:50:14 <flo-retina> aleth: seriously though, you would still need a UI to 'edit' contacts. 16:50:25 <aleth> flo-retina: I think so, but more or less secretly :P 16:50:26 <flo-retina> aleth: but I don't think the current blist window is a good UI for that. 16:51:08 <flo-retina> aleth: hmm, we would also need to put a status selector somewhere 16:51:18 <aleth> Yeah, the problem is how could you conveniently edit contacts within the awesometab... It may overload the thing 16:51:22 <flo-retina> maybe at the top of the accounts window, like in Tb? 16:51:30 <flo-retina> aleth: you don't want to do it. 16:52:23 <aleth> You could put the status selector somehow close to the conversation editbox 16:52:56 <flo-retina> aleth: the rationale for the awesometab project is that the current blist window serves 3 purposes: 1. Start a specific conversation. 2. Look at the status of my contacts to maybe decide to talk to someone (ie. I'm bored, entertain me...; or I need to ask something from a coworker and need to know who's online right now). 3. Contact management. 16:53:19 <flo-retina> the current blist sucks at each of these points, because it tries to stuff everything in the same UI. 16:53:38 <aleth> flo-retina: Right, and the question is what happens with it when it loses 1+2 16:53:57 <aleth> Do we still want to open it by default, for example. Or should it be more like the account manager... 16:54:01 <flo-retina> the goal of the awesometab is to fully address 1. (it also kind of does 2. but not perfectly), so that the rest of the contact-related UI can be repurposed. 16:54:18 <flo-retina> ah, my train is announced. 16:54:31 <aleth> bon voyage! 16:54:49 <flo-retina> I _may_ be back online in 15 minutes (if the phone plays well). 16:54:53 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 17:09:03 <-- rosonline has quit (Client exited) 17:12:19 --> flo-retina has joined #instantbird 17:12:20 * ChanServ sets mode +qo flo-retina flo-retina 17:14:51 <-- flo-retina has quit (Ping timeout) 17:21:30 --> flo-retina has joined #instantbird 17:21:30 * ChanServ sets mode +qo flo-retina flo-retina 17:29:13 <-- flo-retina has quit (Ping timeout) 18:05:14 <-- clokep_work has quit (Ping timeout) 18:30:28 <-- aleth has quit (Quit: Ciao) 18:37:20 --> aleth has joined #instantbird 18:37:20 * ChanServ sets mode +h aleth 18:45:31 <-- aleth has quit (Quit: Ciao) 19:31:21 --> skeledrew has joined #instantbird 20:02:43 --> clokep_work has joined #instantbird 20:03:31 --> Mook has joined #instantbird 20:05:30 --> EionRobb has joined #instantbird 21:15:50 <-- mconley has quit (Input/output error) 21:32:24 --> gerard-majax has joined #instantbird 21:32:59 --> mconley has joined #instantbird 21:34:47 <-- gerard-majax has quit (Ping timeout) 21:37:20 --> gerard-majax has joined #instantbird 21:47:07 <-- mconley has quit (Input/output error) 21:49:25 <-- gerard-majax has quit (Ping timeout) 21:51:35 --> mconley has joined #instantbird 21:56:28 <-- mconley has quit (Connection reset by peer) 21:56:44 --> mconley has joined #instantbird 21:57:49 <-- mconley has quit (Input/output error) 22:30:11 --> jb has joined #instantbird 22:46:16 <-- jb has quit (Ping timeout) 23:22:38 --> BWMerlin has joined #instantbird 23:45:57 --> rosonline has joined #instantbird