#instantbird log on 06 14 2014

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