All times are UTC.
00:00:46 <-- mconley has quit (Ping timeout) 00:06:35 --> BWMerlin1 has joined #instantbird 00:07:41 <-- BWMerlin has quit (Ping timeout) 00:08:08 --> BWMerlin has joined #instantbird 00:08:19 <-- BWMerlin1 has quit (Ping timeout) 00:16:35 --> Mook_as has joined #instantbird 00:32:54 --> mconley has joined #instantbird 00:40:53 <-- wnayes has quit (Ping timeout) 00:44:13 --> wnayes has joined #instantbird 00:52:32 <-- EionRobb has quit (Connection reset by peer) 00:55:45 <-- Suiseiseki has quit (Ping timeout) 00:56:43 --> Suiseiseki has joined #instantbird 01:13:26 <-- Mook_as has quit (Quit: Mook_as) 01:21:22 --> EionRobb has joined #instantbird 01:29:00 --> rosonline has joined #instantbird 02:14:08 <-- wnayes has quit (Quit: wnayes) 02:15:19 <-- rosonline has quit (Client exited) 02:16:06 <-- mconley has quit (Input/output error) 03:10:55 --> mconley has joined #instantbird 03:24:55 --> nhnt11-testing has joined #instantbird 03:25:05 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:30:26 --> nhnt11-testing has joined #instantbird 03:30:58 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:38:43 <-- mconley has quit (Input/output error) 03:39:54 --> nhnt11-testing has joined #instantbird 03:40:19 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:40:46 --> nhnt11-testing has joined #instantbird 03:40:59 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:41:19 --> nhnt11-testing has joined #instantbird 03:41:26 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:43:06 --> mconley has joined #instantbird 03:45:28 --> nhnt11-testing has joined #instantbird 03:45:37 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:46:52 --> nhnt11-testing has joined #instantbird 03:47:05 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 03:50:03 <nhnt11> Yay, new patches 03:50:22 * nhnt11 is grateful for aleth's patience as a reviewer 03:54:51 <-- Rym has quit (Ping timeout) 03:56:48 <nhnt11> I'm curious why system message times are shown in 12 hour am/pm format, but normal messages are shown in 24h format 04:00:03 <-- mconley has quit (Input/output error) 04:07:32 <-- nhnt11 has quit (Ping timeout) 04:08:39 --> nhnt11 has joined #instantbird 04:09:46 --> Mook has joined #instantbird 04:41:25 --> mpmc has joined #instantbird 04:45:40 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 04:46:44 --> mconley has joined #instantbird 05:09:40 <-- mconley has quit (Input/output error) 05:38:23 --> jb has joined #instantbird 06:58:16 <-- jb has quit (Ping timeout) 07:00:50 --> Mic has joined #instantbird 07:00:50 * ChanServ sets mode +o Mic 07:43:31 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 07:45:32 <nhnt11> instantbot: uuid 07:45:33 <instantbot> 2ab5f8ac-4b89-4954-9a4a-7c167f1e3b0d (/msg instantbot cid for CID form) 08:13:42 <nhnt11> Wow 08:13:55 <nhnt11> I just refactored the log sweeping code to use a Task and moved it to logger.js 08:14:10 <nhnt11> New callback interface et al, and updated the stats service to use it 08:14:16 <nhnt11> And it worked on the first run :D 08:16:25 --> nhnt12 has joined #instantbird 08:17:19 <-- nhnt12 has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 08:17:26 --> nhnt12 has joined #instantbird 08:17:43 <-- nhnt12 has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 08:18:04 <nhnt11> Alright, just copied over my daily-use profile and tested it on that, stats seem to be identical. 08:18:09 * nhnt11 files a bug and uploads a patch :) 08:22:27 <-- Mook has quit (Quit: Mook) 08:24:16 <instantbot> New Instantbird - Other bug 1025464 filed by nhnt11@gmail.com. 08:24:19 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1025464 nor, --, ---, nhnt11, NEW, Refactor log sweeping code to use Task.jsm and move it to logger.js 08:30:33 <-- clokep has quit (Connection reset by peer) 08:31:37 --> clokep has joined #instantbird 08:31:37 * ChanServ sets mode +o clokep 08:58:44 --> jb has joined #instantbird 09:37:54 <-- jb has quit (Ping timeout) 09:42:27 --> jb has joined #instantbird 09:54:27 <-- jb has quit (Ping timeout) 09:54:40 --> Mic has joined #instantbird 09:54:40 * ChanServ sets mode +o Mic 09:58:58 --> Armada has joined #instantbird 10:02:55 --> jb has joined #instantbird 10:09:48 --> mayanktg has joined #instantbird 10:41:33 <-- jb has quit (Connection reset by peer) 10:41:38 --> jb has joined #instantbird 10:44:50 --> rosonline has joined #instantbird 10:50:54 <-- jb has quit (Connection reset by peer) 10:51:12 --> jb has joined #instantbird 10:53:46 <-- Armada has quit (Ping timeout) 11:10:26 <-- EionRobb has quit (Quit: Leaving.) 11:10:42 <-- rosonline has quit (Client exited) 11:24:00 --> aleth_web has joined #instantbird 11:27:54 <-- gerard-majax has quit (Ping timeout) 11:30:18 <-- mayanktg has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 11:31:25 --> gerard-majax has joined #instantbird 11:44:23 <-- jb has quit (Ping timeout) 11:51:44 --> Armada has joined #instantbird 12:28:30 <nhnt11> aleth_web: Hello 12:29:01 <nhnt11> "In case the binding doesn't exist yet" is that even possible? Since we're getting the item using getElementById 12:29:16 <aleth_web> Yes 12:29:17 <nhnt11> But I shouldn't try to predict what XBL does, I'll change it :) 12:31:55 <nhnt11> aleth_web: "logMessage will fail to write the file if it doesn't exist" This isn't true, in the current code 12:32:03 <nhnt11> Do you want me to add an {existing: true} option there? 12:32:40 <nhnt11> The way it is now, it avoids spamming the error console in the case where a lot of logMessage calls have already been queued before writing the header fails 12:32:51 <aleth_web> Ah, I somehow thought existing:true was the default 12:33:17 <aleth_web> Right. I don't know what the better solution is here. 12:33:28 <nhnt11> also, I've not closed the LogWriter somewhat on purpose 12:33:43 <nhnt11> Because if we have write errors, it's not likely they're going to go away 12:33:46 <aleth_web> You can't close it if you want to prevent further writing... 12:33:51 <nhnt11> So again, avoid spamming the error console 12:33:55 <nhnt11> Yeah 12:34:06 <nhnt11> brb 12:38:37 <nhnt11> re 12:40:09 <nhnt11> aleth_web: The reason SystemLogWriter doesn't need _initialized to be a promise is because there's nothing else that may want to wait on it 12:40:14 <nhnt11> But it should probably be consistent 12:41:07 <nhnt11> Hmm, just saw your point about network drives coming back online. 12:41:11 <aleth_web> There's nothing that (should) want to wait on it in the logWriter either. 12:41:16 <aleth_web> Pick your favourite solution. I think existing:true for logMessage is probably a good idea either way though. 12:41:50 <nhnt11> hmm 12:41:57 <nhnt11> Okay 12:41:58 <aleth_web> Doesn't that cover your initialized check too really? 12:42:06 <nhnt11> It does. 12:42:06 <aleth_web> Just thinking aloud. 12:43:48 <aleth_web> "There's nothing that (should) want to wait on it in the logWriter either." well, unless you need it to avoid spamming the error console or whatever. 12:44:08 <aleth_web> Anyway, I think the patch should be r+ on the next cycle. 12:44:25 <nhnt11> I was just about to say that maybe we want to prioritize attempting to log stuff over spamming the error console. 12:44:49 <nhnt11> :) 12:47:36 <aleth_web> Hmm, or is existing:true expensive in some way? 12:47:56 <nhnt11> Why would it be? 12:48:08 <nhnt11> It just throws if the file doesn't exist 12:55:41 <nhnt11> aleth_web: So for the next patch, I'm going to close the log writer if initialization failed, and remove the initialized check from logMessage by adding an existing:true option. 12:56:06 <nhnt11> Just to confirm that I'm going with that solution 12:56:21 <aleth_web> OK 12:57:18 <nhnt11> aleth_web: Hmm, what if /creating/ the file worked, but writing the header didn;t? 12:58:08 <nhnt11> I think we want to avoid "bad" log files as much as possible.. 12:59:24 <aleth_web> I don't really know if that could happen. 12:59:51 <nhnt11> Yeah... 13:00:49 <aleth_web> One reason for your current implementation is that it avoids piling up dead logwriter objects for gc to take care of. Not sure how much of a concern that is though. 13:01:23 <aleth_web> Probably not much. 13:01:26 <nhnt11> My current implementation is much less spammy for the error console too for most scenarios 13:01:44 <aleth_web> That's certainly true. 13:01:48 <nhnt11> It's just the network drive scenario that makes me think it's worth retrying to create the file 13:02:10 <aleth_web> But even there, it's only an issue if the network drive is down just at the time we are opening the file. 13:02:52 <aleth_web> Always these edge cases... ;) 13:03:12 * nhnt11 is now tempted to keep it how it is 13:03:28 <nhnt11> Are network drives a common use case? 13:05:09 <aleth_web> Hard to say. 13:06:15 <aleth_web> As I said, I'm OK with keeping it as it is too, there seem to be advantages/drawbacks either way. 13:06:48 <nhnt11> ok, I'm keeping it as it is. 13:07:11 <nhnt11> And about getLogFileForOngoingConversation, I think creating the file is the best way to go 13:07:35 <nhnt11> aleth_web: Partly because when the log file is created, the filename is based on the time at creation 13:07:47 <aleth_web> Does that matter? 13:07:50 <nhnt11> So if you return a path now, the path may change later 13:07:55 <aleth_web> Oh, I see. 13:08:10 <aleth_web> Yeah, returning the path only makes sense if the calling code does an existence check. 13:08:26 <aleth_web> As I said in my comment ;) 13:08:48 <nhnt11> Even if it /does/ do an existing check, what's the point? 13:09:00 <nhnt11> the point of returning a path that can never be used* 13:09:04 <aleth_web> I don't know how this is used in that indexing code. 13:09:18 <nhnt11> I'm referring to any potential consumer 13:09:24 <aleth_web> You could argue there's no point in returning a path to an empty file either 13:09:54 <aleth_web> I haven't looked at the calling code, so I'll leave it up to you. 13:10:19 <nhnt11> Hmm, but at least it's guaranteed to exist, and possibly not be empty in the near future 13:10:26 <aleth_web> Yes. 13:10:41 <nhnt11> I'm going to leave it as it is. 13:11:17 <nhnt11> aleth_web: The reason I don't use the path queue there is so that I don't have to wait for pending logMessage calls to finish before returning the path 13:23:29 <nhnt11> aleth_web: For the context menu item, I'll remove it completely from getNickActions and add a special case for it in initMenu. Is that fine? 13:23:57 <nhnt11> \o/ r+ 13:25:12 <nhnt11> Hmm "Add a showLogs item only if we're over a nick" - we're not dynamically creating the item (it's in instantbird.xul) so maybe this isn't what we want? 13:25:35 <nhnt11> Did you mean make it visible but disabled if we're over a nick? 13:26:09 <aleth_web> I'd prefer |addAction("ShowLogs", this.onNick)| and then later enable/disable it when the menuitem is actually added. 13:26:12 <aleth_web> Yes 13:26:15 <nhnt11> Cool. 13:26:37 <aleth_web> It's better than the current behaviour where the Logs entry is simply absent if there are no logs. 13:28:48 --> nhnt11-testing has joined #instantbird 13:29:03 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 13:30:33 --> nhnt11-testing has joined #instantbird 13:30:42 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 13:31:05 --> nhnt11-testing has joined #instantbird 13:31:20 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 13:35:52 <nhnt11> Hmm, maybe we need the "Start disabled, then enable if we have logs." comment in nsContextMenu.js too.. 13:35:54 * nhnt11 adds it 13:45:12 <-- nhnt11 has quit (Input/output error) 13:45:50 --> nhnt11 has joined #instantbird 13:46:02 --> jb has joined #instantbird 13:50:06 --> iamjayakumars has joined #instantbird 13:53:48 <-- gerard-majax has quit (Ping timeout) 13:55:17 <-- BWMerlin has quit (Quit: BWMerlin) 13:55:38 --> gerard-majax has joined #instantbird 14:02:47 <-- gerard-majax has quit (Ping timeout) 14:16:02 <aleth_web> nhnt11: I'm assuming you've tested the context menus ;) 14:17:54 <clokep> =-o That's a lot of bugmail. 14:28:04 <-- jb has quit (Connection reset by peer) 14:28:11 --> jb has joined #instantbird 14:36:38 --> nhnt11-phone has joined #instantbird 14:36:52 <nhnt11-phone> aleth_web: yup, tested them. 14:40:14 --> gerard-majax has joined #instantbird 14:43:43 --> flo-retina has joined #instantbird 14:43:44 * ChanServ sets mode +qo flo-retina flo-retina 14:44:57 <-- nhnt11-phone has quit (Input/output error) 14:49:25 <aleth_web> Bah, if you reply to review comments in splinter, the context is wrong in the bug comment. 14:49:38 * aleth_web goes to file a bug 14:51:59 --> wnayes has joined #instantbird 14:53:23 <Mic> aleth_web: yes, afaik each of the comments gets the same context from the diff? 14:54:09 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 14:55:02 <aleth_web> Yes 14:56:54 <clokep> aleth_web: It's not for replying, it's to allow multiple people to review. 14:57:48 <aleth_web> clokep: There should be a distinction between two reviews of the same line of code and a reply to an existing comment. 15:02:55 <clokep> Sure. 15:03:56 <aleth_web> I guess we'll see when someone responds to the bug ;) 15:07:30 --> sawrubh|ib has joined #instantbird 15:10:33 <flo-retina> aleth_web: I need to open splinter ;) 15:11:53 <flo-retina> aleth_web: so I'm still confused about when this stuff is created/cleaned up 15:17:21 <aleth_web> flo-retina: It's created when the constructor is called, which is when the context menu of which the tagmenu is a submenu is shown (popupshowing). 15:17:51 <aleth_web> Cleanup is up to the context menu that contains it. 15:18:27 <flo-retina> so if the context menu isn't dynamically generated (eg. in the blist), the stuff generated stays around until the window is closed? 15:19:08 <aleth_web> Yes. 15:19:25 <flo-retina> then I don't like all these .bind calls 15:19:35 <aleth_web> They're gone, aren't they? 15:20:23 <aleth_web> Ah, I forgot to remove one. 15:21:18 <clokep> sawrubh|ib: Btw I don't think we need to uplift this to Earlybird or Beta, I see it unrelated to bug 1021684. 15:21:20 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1021684 nor, --, ---, clokep, ASSI, Update box.com Filelink implementation to new APIs 15:21:23 <sawrubh|ib> clokep: does it make sense to push to try again, because there isn't much different between the version I tested on try (and it passed) and the version m-conley reviewed 15:21:44 * sawrubh|ib just doesn't want to waste resources is all 15:22:08 <clokep> sawrubh|ib: Didn't you fix a bunch of TB bugs though? :P 15:22:34 <sawrubh|ib> yeah....ok I'll push it then :) 15:23:38 <flo-retina> aleth_web: suggestion posted in the bug 15:32:49 * sawrubh|ib takes a look at the drag and drop patch too while he's at it 15:34:01 <sawrubh|ib> well, I read the DataTransfer docs and it didn't seem to help much 15:34:08 --> mconley has joined #instantbird 15:34:22 <sawrubh|ib> guess I'll start by reviewing my code from scratch 15:37:20 <-- mconley has quit (Input/output error) 15:38:03 --> mayanktg has joined #instantbird 15:38:20 <aleth_web> sawrubh|ib: You should reduce it to only the bits that touch datatransfer, then add bits back in once it's working. 15:47:06 <sawrubh|ib> aleth_web: do you how to go back to where I started the search from, after I'm done with a search in ST 15:47:24 * clokep doesn't understand that question. 15:47:37 <aleth_web> I don't understand it either 15:47:48 <aleth_web> Almost cetainly offtopic ;) 15:56:05 <flo-retina> aleth_web: how much do you like that .bind removing suggestion? 15:58:01 <-- jb has quit (Connection reset by peer) 15:58:07 --> jb has joined #instantbird 15:58:12 <aleth_web> I'm wondering if there's a prettier alternative 16:04:52 <aleth_web> flo-retina: I'm not sure I completely understand actually. Wouldn't handleEvent have to be on the respective DOM element? 16:08:43 <aleth_web> I don't see how your suggestion would work. 16:14:29 <flo-retina> aleth_web: addEventListener takes either a function, or an object implementing a 'handleEvent' property 16:15:23 <flo-retina> when you use a function, the 'this' value points to the DOM node that received the event. When you use an object, the this value points to the object. 16:15:38 <aleth_web> I see. That's neat. 16:15:56 <-- iamjayakumars has quit (Client exited) 16:16:16 <aleth_web> I can't think of any other way to get rid of the bind calls. 16:18:24 <aleth_web> flo-retina: It'll make the code harder to read though (the "command" case will have to figure out the DOM node it was called on....) 16:20:52 <flo-retina> aEvent.target 16:22:56 <aleth_web> Sure. 16:23:30 <aleth_web> Anyway, I'll put it up to see what it looks like. 16:49:37 <-- wnayes has quit (Ping timeout) 16:52:54 --> wnayes has joined #instantbird 16:53:06 --> iamjayakumars has joined #instantbird 17:24:09 <-- jb has quit (Connection reset by peer) 17:24:15 --> jb has joined #instantbird 17:32:41 <-- sawrubh|ib has quit (Ping timeout) 17:34:39 --> sawrubh|ib has joined #instantbird 17:36:11 <-- iamjayakumars has quit (Quit: ) 17:47:48 <-- sawrubh|ib has quit (Ping timeout) 17:50:44 <-- gerard-majax has quit (Connection reset by peer) 17:50:49 --> gerard-majax has joined #instantbird 17:53:51 --> sawrubh|ib has joined #instantbird 17:58:24 <-- gerard-majax has quit (No route to host) 17:58:30 --> gerard-majax has joined #instantbird 17:59:00 <-- gerard-majax has quit (Client exited) 17:59:06 --> gerard-majax_ has joined #instantbird 18:02:32 <-- jb has quit (Ping timeout) 18:08:02 <nhnt11> aleth_web: Btw, did you see the Taskified log sweeping patch? Tasks make life easy! :D 18:08:35 <aleth_web> nhnt11: yes, nice cleanup! :) 18:08:54 <nhnt11> That should also take care of some of the intermittent errors in the ucrrent code 18:09:24 <nhnt11> There should be a return in this if block: https://mxr.mozilla.org/comm-central/source/im/components/ibConvStatsService.js#99 18:09:46 <nhnt11> Same goes for the corresponding ones in _sweepAccounts and _sweepLogFolders 18:10:23 <nhnt11> The shift() on the next line is undefined and it results in a lot of "Uncaught exception in promise blabla" errors 18:10:59 <aleth_web> Right. 18:11:35 <-- nhnt11 has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 18:11:41 --> nhnt11 has joined #instantbird 18:11:49 <aleth_web> That's the nice thing about Tasks, you're much less likely to miss stuff like that. 18:12:08 <nhnt11> aleth_web: Tbh, that's the nice thing about not having 3 recursive functions :S 18:12:30 <aleth_web> Yeah, but that's what Tasks let yu do ;) 18:12:38 <nhnt11> I was about to say that :) 18:12:46 <nhnt11> Hmm, I should write another blog post... 18:12:48 <aleth_web> Btw please file a followup bug for starting a new log file at midnight 18:12:55 * nhnt11 is very tired. 18:12:55 <nhnt11> Okay 18:16:57 <flo-retina> aleth_web: aren't you doing aEvent.stopPropagation for all the events you handle? 18:17:24 <aleth_web> Not quite I think. 18:17:25 <flo-retina> ah, there's a test before it from the command event :-S 18:18:39 <flo-retina> aleth_web: r+ 18:19:07 <aleth_web> I didn't know about that handleEvent trick, I wonder if there are other places we should be using it (tabbrowser)? 18:19:18 <instantbot> New Instantbird - Other bug 1025522 filed by nhnt11@gmail.com. 18:19:20 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1025522 nor, --, ---, nobody, NEW, Start a new log file at midnight 18:19:45 <flo-retina> aleth_web: looks like tabbrowser already uses it quite a bit: http://lxr.instantbird.org/instantbird/search?string=handleevent ;) 18:20:00 * nhnt11 notices flo-retina still uses lxr 18:20:11 <flo-retina> nhnt11: yeah 18:20:19 <aleth_web> So it does :D 18:20:48 <nhnt11> I wonder what dxr stands for 18:20:55 <nhnt11> I'm assuming m stands for mozilla in mxr.. 18:21:05 <nhnt11> offtopic, sorry 18:21:08 <flo-retina> I guess I should rather lxr for addEventListener and then search for bind 18:21:12 * nhnt11 goes to bed. Night! 18:21:15 <flo-retina> nhnt11: could be dehydra 18:21:30 <nhnt11> Ah, you're right 18:22:13 * flo-retina isn't excited about switching the log file at midnight... but can't immediately come up with a better plan 18:22:17 <aleth_web> Good night! 18:22:56 <aleth_web> flo-retina: It seems a bit arbitrary, but yeah. Since we hardcode the time in the filename, what else is there... 18:23:04 <flo-retina> maybe because of http://integral-options.blogspot.fr/2007/08/ted-talks-is-4-am-new-midnight.html :-D 18:24:06 <aleth_web> bah, the tree is all orange again 18:24:13 <flo-retina> :( 18:24:33 <flo-retina> I was hoping you could checkin that patch before I change my mind on the review :-D 18:27:04 <aleth_web> flo-retina: Let me change my mind for you: I think no harm is done if I simply stopPropagate for all the handled events 18:27:18 <flo-retina> lol 18:27:49 <flo-retina> if you make that change, check it :) 18:28:21 * flo-retina would feel bad about a regressing fix due to a last minute change to address a review comment that wasn't really made :) 18:49:47 <-- wnayes has quit (Ping timeout) 18:51:03 --> Rym has joined #instantbird 18:53:11 --> wnayes has joined #instantbird 18:58:44 --> mpmc has joined #instantbird 19:08:26 --> jb has joined #instantbird 19:15:36 <-- jb has quit (Ping timeout) 19:23:10 <-- Even has quit (Ping timeout) 19:42:03 --> Even has joined #instantbird 19:42:03 * ChanServ sets mode +o Even 20:23:06 <-- aleth_web has left #instantbird () 20:46:18 --> jb has joined #instantbird 20:49:45 <-- wnayes has quit (Ping timeout) 20:50:04 <-- mayanktg has quit (Ping timeout) 20:52:32 --> mayanktg has joined #instantbird 20:53:12 --> wnayes has joined #instantbird 20:59:28 <flo-retina> bah, ./mozilla/mach build has been reticulating splines in a loop for 35 minutes 20:59:33 <flo-retina> I should have stopped it before :-/ 21:01:26 --> Usul has joined #instantbird 21:01:42 <Usul> I wonder why IB and Thunderbird arenât mentionned on https://wiki.mozilla.org/IRC#Connect_to_the_Mozilla_IRC_server 21:10:03 <flo-retina> Usul: feel free to fix it! :) 21:10:21 * Usul is lazy - screenshots etc .... 21:16:34 --> EionRobb has joined #instantbird 21:21:33 <clokep> sawrubh|ib: You had a question? 21:23:16 <sawrubh|ib> clokep: in https://bugzilla.mozilla.org/show_bug.cgi?id=1014644#c37, the 2nd and 3rd question that you ask, are they meant for me? 21:23:18 <instantbot> Bug 1014644 nor, --, ---, saurabhanandiit, ASSI, Make FileLink work in Instantbird 21:23:30 <clokep> sawrubh|ib: Questions are meant for whoever can answer them. 21:23:45 * sawrubh|ib doesn't think he can 21:23:55 <clokep> sawrubh|ib: Btw I think all of those can be done as follow ups. 21:24:37 <-- jb has quit (Ping timeout) 21:25:42 <sawrubh|ib> and regarding m-conley's comment to use a lazyGetter, I remember you asking me to use the lazyGetter in my equivalent uploadListener function in conversation.xml and then asking me not to do it 21:25:57 <sawrubh|ib> what was the reason you later thought not to do it? does that apply here? 21:26:17 <clokep> mconley asked you to do that, I'm not going to override him. 21:38:00 <-- mayanktg has quit (Ping timeout) 21:38:02 --> mayanktg has joined #instantbird 21:41:40 <-- mayanktg has quit (Ping timeout) 21:44:34 <clokep> sawrubh|ib: http://lxr.instantbird.org/instantbird/source/chat/components/src/imConversations.js#14 21:45:02 <clokep> That's all tha tmconley meant. 21:45:20 <sawrubh|ib> I was just figuring out how to do that ;) 21:45:25 <sawrubh|ib> thanks 21:51:47 <-- Usul has left #instantbird () 21:51:49 --> mayanktg has joined #instantbird 21:56:45 <flo-retina> clokep: ah, I see you have the same concerns as I do about the log splitting at midnight :-/ 21:57:09 <flo-retina> I'm tempted to suggest a more complicated algorithm, but that may be overkill :-] 22:00:44 <-- mayanktg has quit (Ping timeout) 22:01:31 --> mayanktg has joined #instantbird 22:03:01 <clokep> flo-retina: Suggest it. :) 22:03:08 <clokep> we can't make a good assessment unless we talk it through. 22:03:51 <flo-retina> I think we should split lots when there's more than some amount of time of inactivity (20 minutes? an hour?) 22:04:14 <clokep> s/lots/logs/? 22:04:22 <flo-retina> and then, if the conversation has been ongoing for a long time, we should split at midnight 22:04:23 <flo-retina> yes, logs 22:04:36 <flo-retina> that will avoid splitting private conversations happening near midnight 22:04:42 <clokep> OK. :) (Split lots kind of makes sense in that sentences too...) 22:04:44 <flo-retina> but will ensure busy IRC channels are split at least once a day 22:07:36 <clokep> That sounds reasonable, yes. 22:08:26 <flo-retina> that's more difficult to implement ;) 22:08:43 <flo-retina> but we've got students to keep busy! :-P 22:08:53 <sawrubh|ib> :) 22:09:40 <clokep> Would that also solve the issue of people closing the conv after every message? 22:10:13 <flo-retina> possibly 22:10:19 <flo-retina> depending on how you implement it 22:10:50 <clokep> If it's fairly easy to include that, we should think about that. 22:14:55 <flo-retina> a downside of the algorithm I suggested is that it makes it much harder to search logs by date (I think that's why nhnt11 wanted to always split at midnight) 22:15:45 <flo-retina> but that's likely an issue we can address (we would just need the database to have a column for the timestamp of the first message of a conv and a column for the timestamp of the last message) 22:33:21 * flo-retina shrugs 22:33:27 <flo-retina> updating my local ib build failed to compile: 22:33:29 <flo-retina> comm-central/mozilla/extensions/purple/libpurple/protocols/qq/buddy_opt.c:334:27: error: cast to 'guint8 *' (aka 'unsigned char *') from smaller integer type 'guint32' (aka 'unsigned int') [-Werror,-Wint-to-pointer-cast] 22:33:41 <sawrubh|ib> flo-retina: this looks correct : http://pastebin.instantbird.com/735802 (I mean the getter right) 22:34:53 <-- mayanktg has quit (Ping timeout) 22:35:18 <flo-retina> that looks strange 22:35:39 <flo-retina> no, it doesn't look correct 22:35:44 --> mayanktg has joined #instantbird 22:35:47 <flo-retina> I don't know what you are trying to do, but it probably doesn't work 22:36:58 <sawrubh|ib> so getComposeBundle used to fetch L36, I want to instead fetch L37 now, so I'm defining a lazy getter to do that 22:37:43 <flo-retina> a lazy getter to fetch a DOM element makes no sense 22:38:53 <sawrubh|ib> a XUL element and here is what getComposeBundle looks like https://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#82 22:39:21 <sawrubh|ib> I initially had a similar function, but then I was asked to use XPCOMUtils's defineLazyGetter instead 22:40:24 <sawrubh|ib> http://pastebin.instantbird.com/735803 is what I had earlier 22:42:14 <flo-retina> there's a large comment explaining why it's done that way 22:43:34 <flo-retina> why not just let bundle = document.getElementById("bundle_cloudfile"); ? 22:44:28 <sawrubh|ib> m-conley suggested using that in https://bugzilla.mozilla.org/show_bug.cgi?id=1014644#c38 22:44:30 <instantbot> Bug 1014644 nor, --, ---, saurabhanandiit, ASSI, Make FileLink work in Instantbird 22:45:27 <-- mayanktg has quit (Ping timeout) 22:47:06 --> mayanktg has joined #instantbird 22:47:28 <flo-retina> sawrubh|ib: mconley wasn't asking you to use a lazy getter. He was asking you to not hand write a custom lazy getter. 22:48:16 <sawrubh|ib> hmm, I'll use let bundle = document.getElementById("bundle_cloudfile"); then, sounds simple 22:48:18 <sawrubh|ib> :) 22:49:48 <-- wnayes has quit (Ping timeout) 22:52:08 <-- Rym has quit (Ping timeout) 22:52:26 --> Rym has joined #instantbird 22:52:39 --> wnayes has joined #instantbird 23:00:51 <sawrubh|ib> flo-retina: so I've addressed all the comments (which were trivial) from mconley, do you think I should ask him for review again? 23:04:23 <flo-retina> no, he r+'ed 23:04:44 <flo-retina> he wants to see a green try push though ;) 23:04:50 <flo-retina> but you can do that once I'll have r+'ed too 23:05:29 <sawrubh|ib> I just pushed to try without your r+ :( 23:06:36 <sawrubh|ib> however it was green last time too so I don't think it should make a difference, unless you propose huge changes ;) 23:08:16 --> mconley has joined #instantbird 23:10:06 <flo-retina> so why did you push it to try again if there's no significant change? :-P 23:10:20 <flo-retina> note: it's easy to cancel try jobs you don't actually want 23:10:52 <sawrubh|ib> because clokep said we should do it (there were a few minor changes which I didn't feel would've affected try output) 23:11:49 <flo-retina> I think what Mike wants to see is a run with the stuff you are about to get checked in to comm-central. 23:12:10 <flo-retina> whether you "feel it will affect try" isn't really relevant. Nobody feels like his patch should bust the tree, right? ;) 23:12:47 <sawrubh|ib> :) 23:15:07 <-- mconley has quit (Input/output error) 23:22:07 <-- Armada has quit (Quit: Leaving) 23:23:32 --> mconley has joined #instantbird 23:27:09 <-- mconley has quit (Ping timeout) 23:27:43 --> mconley has joined #instantbird 23:59:05 --> BWMerlin has joined #instantbird