All times are UTC.
01:09:52 <-- Mook_as has quit (Quit: Mook_as) 02:04:53 <-- clokep_work has quit (Ping timeout) 02:04:54 --> clokep_work has joined #instantbird 02:04:55 * ChanServ sets mode +o clokep_work 02:09:20 <-- clokep_work has quit (Ping timeout) 02:12:56 <instant-buildbot> build #2290 of macosx-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2290 02:14:45 <instant-buildbot> build #1467 of win32-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1467 02:15:39 <-- clokep has quit (Ping timeout) 02:27:45 <-- mconley has quit (Input/output error) 02:38:54 --> Mook has joined #instantbird 03:31:31 --> BillBinkley has joined #instantbird 03:42:52 <-- BillBinkley has quit (Ping timeout) 03:44:44 --> mconley has joined #instantbird 03:56:59 <-- Mook has quit (Ping timeout) 04:14:44 <-- nhnt11 has quit (Ping timeout) 04:15:46 <-- mconley has quit (Input/output error) 04:16:14 --> mconley has joined #instantbird 04:18:04 <-- mconley has quit (Ping timeout) 04:29:03 --> nhnt11 has joined #instantbird 04:31:47 <-- sawrubh has quit (Ping timeout) 04:35:11 --> sawrubh has joined #instantbird 04:40:40 <-- mayanktg has quit (Ping timeout) 04:46:27 --> mayanktg-ph has joined #instantbird 05:00:24 --> mayanktg has joined #instantbird 05:19:06 --> Bollebib has joined #instantbird 05:26:17 --> aleth has joined #instantbird 05:26:17 * ChanServ sets mode +o aleth 05:27:37 <aleth> nhnt11: I didn't follow that forEachDay discussion, but keep in mind that assembling the log tree should remain fast and not involve actually building the log clusters (or whatever they are called now) 05:34:33 <-- aleth has quit (Quit: exit stage left) 05:41:41 --> BillBinkley has joined #instantbird 05:43:24 <-- BillBinkley has quit (Ping timeout) 05:49:40 --> aleth has joined #instantbird 05:49:40 * ChanServ sets mode +o aleth 05:49:56 <-- aleth has quit (Quit: exit stage left) 05:50:29 <-- nhnt11 has quit (Ping timeout) 05:59:57 <-- Bollebib has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 06:04:07 <-- EionRobb has quit (Quit: Leaving.) 06:10:33 <-- mayanktg has quit (Ping timeout) 06:21:24 --> mayanktg has joined #instantbird 06:21:53 <-- Rym has quit (Ping timeout) 06:55:29 --> mpmc has joined #instantbird 07:02:34 <-- jb has quit (Ping timeout) 07:16:22 * Fallen|away is now known as Fallen 07:26:43 --> nhnt11 has joined #instantbird 07:43:57 <-- nhnt11 has quit (Ping timeout) 08:03:39 --> jb has joined #instantbird 08:14:10 --> gerard-majax__ has joined #instantbird 08:19:43 <-- gerard-majax__ has quit (Ping timeout) 08:21:52 <-- mayanktg has quit (Client exited) 08:39:37 --> aleth has joined #instantbird 08:39:37 * ChanServ sets mode +o aleth 09:02:34 --> Armada has joined #instantbird 09:23:07 --> EionRobb has joined #instantbird 09:23:57 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 09:24:24 --> chrisccoulson has joined #instantbird 09:41:40 <-- flo-retina has quit (Ping timeout) 09:43:39 --> clokep has joined #instantbird 09:43:40 * ChanServ sets mode +o clokep 09:46:36 --> nhnt11 has joined #instantbird 09:50:54 <-- nhnt11 has quit (Ping timeout) 09:59:59 --> flo-retina has joined #instantbird 10:00:00 * ChanServ sets mode +qo flo-retina flo-retina 10:00:09 --> nhnt11 has joined #instantbird 10:01:11 <clokep> flo-retina: So that patch looks reasonable, but I'd like to vaguely understand it before pushing. :) 10:01:42 <flo-retina> how can I ensure your understanding stays vague? :-P 10:01:56 --> gerard-majax__ has joined #instantbird 10:03:11 <clokep> I'm pretty sure it's guaranteed. ;) 10:03:28 <flo-retina> ah! 10:03:37 <flo-retina> feel free to ask questions :) 10:06:53 <flo-retina> clokep: which part do you not understand enough? :) 10:07:19 <clokep> flo-retina: Well, I haen't looked this morning but last night I wasn't understanding the move of prpls. 10:08:01 <flo-retina> you mean moving around some of the code related to building the dynamic prpls? 10:08:09 <clokep> I believe so, yes. 10:09:03 <flo-retina> before we were building the static prpls in the PARALLEL_DIRS variable of the libpurple folder, and the dynamic prpls from the purplexpcom folder 10:09:16 <flo-retina> the reason for that was that purplexpcom needs to be built before we can link the dynamic prpls 10:10:25 <flo-retina> so the existing split between the two was a hack 10:11:03 <flo-retina> that hack no longer works, because the build system doesn't take into account the order of things anymore, and computes an "optimal" order itself by looking at what library needs what to be linked. 10:11:38 <flo-retina> so moving stuff around is actually just removing the previous hack that no longer works 10:12:17 <clokep> I see. 10:12:20 <flo-retina> then I added a new hack to enforce that libpurplexpcom.dylib is built before we link dynamic prpls. For that I made xpcomModule.o depend on libpurplexpcom.dylib. 10:13:12 <clokep> flo-retina: That's createing xpcomModule.cpp with PUPLREXPCOM_LIBS? 10:13:14 <flo-retina> that's arbitrary, and I would have preferred to just make target:: depend on libpurplexpcom.lib... except that gets executed in parallel, which means that libpurplexpcom.dylib is guaranteed to exist when we leave the folder, but not when we attempt to link libnull.dylib 10:13:39 <flo-retina> clokep: that question doesn't make sense 10:13:52 <clokep> flo-retina: Line 48 of http://pastebin.instantbird.com/783759 10:14:15 <flo-retina> clokep: in gmake syntax, |foo: bar boo| means that bar and boo need to exist and be older than foo if foo already exists 10:14:27 <flo-retina> if not, the rules for bar and boo run before the rule for foo 10:16:13 <clokep> Yes. 10:16:44 <flo-retina> of course, I would have preferred if I could just have made this clean, instead of adding a new hack. The clean solution would be to add "purplexpcom" in the USE_LIBS list in prpl.py for dynamic prpls. But that doesn't work, because moz.build doesn't want the same library to be an xpcom component and a dynamic library :( 10:17:06 <clokep> Right. :-\ 10:17:23 <clokep> So is this still linking purplexpcom every time like you mentioned on IRC? 10:17:45 <flo-retina> it's doing it once for each dynamic prpl 10:18:04 <aleth> I wonder if some of that should be in a comment, for the next time this breaks ;) 10:18:24 <flo-retina> maybe only because we build several dynamic prpls in parallel. If we had finished linking the first one before linking the second one, I think we would link purplexpcom only once. 10:19:01 <flo-retina> aleth: I wondered if that should be in a bug, to request the changes so that we could just USE_LIBS += ['purplexpcom'] and avoid the hackery 10:19:34 <aleth> flo-retina: That would be even better of course! Maybe glandium would take pity on us 10:19:36 <flo-retina> but at this point I would prefer to have the attention of build peers directed to the issues we can't workaround rather than to the ugliness we can workaround 10:19:46 <aleth> yeah... 10:19:50 <clokep> flo-retina: So I think the patch looks good, I definitely think we should comment either in the code or in a bug. 10:20:09 <flo-retina> clokep: I also think we should make it work on Windows 10:21:24 <flo-retina> clokep: the likely problem for Windows is this hack: https://hg.mozilla.org/users/florian_queze.net/purple/file/8e825c68b4a7/purplexpcom/src/Makefile.in#l86 10:21:29 <flo-retina> I'm pretty sure it's now broken. 10:23:20 <clokep> The moving of the library? 10:24:10 <flo-retina> the rename of the *fake* import library to the final library name, in time so that we can link against it 10:24:45 <flo-retina> this is again a hack because we are not supposed to link against xpcom components :-/ 10:25:16 <clokep> :( 10:26:05 <flo-retina> statically linking libpurple into purplexpcom has always been a hack :) 10:26:33 <clokep> I see. 10:26:45 <clokep> Is this something I should create a build for to test w/? 10:26:46 <flo-retina> but a hack that overall seems better than the previous hack, which was a fake xpcom component that was forcing a load of the libpurple binary and then forcing the real purplexpcom and forwarding the calls to it... 10:26:52 * clokep dosen't think all the patches are in mc yet ghouh 10:27:15 <flo-retina> I'm not sure how many times you plan to ask about the m-c patch 10:27:32 <flo-retina> I already told you twice yesterday about it, and someone else did too in #maildev yesterday evening. 10:27:46 <clokep> I don't understand why you're annoyed. 10:27:51 <clokep> It landed in m-i, not in m-c. 10:28:00 <flo-retina> really? 10:28:06 <clokep> Yes. 10:28:20 <flo-retina> ooooh! 10:28:26 <flo-retina> I guess I missed the bugmail, sorry 10:29:01 <flo-retina> uh, I was sure I was cc'ed :( 10:29:58 <clokep> flo-retina: https://hg.mozilla.org/integration/mozilla-inbound/rev/0d3520e9f0fb 10:29:58 <flo-retina> clokep: ok, so once that reaches m-c, landing that purple patch should be enough to give us Linux nightlies (if I remember to re-plug the slaves tonight) 10:30:23 <clokep> (Sorry, I couldn't remember where m-i was on the website. :() 10:30:24 <flo-retina> clokep: yeah, saw it in the bug; sorry. 10:55:20 <-- clokep has quit (Ping timeout) 10:58:40 --> Bollebib has joined #instantbird 11:35:09 --> clokep_work has joined #instantbird 11:35:09 * ChanServ sets mode +o clokep_work 11:36:44 <clokep_work> flo-retina: So r+ on that patch by mebtw. ;) 11:38:15 <-- aleth has quit (Ping timeout) 11:41:40 <-- jb has quit (Connection reset by peer) 11:41:41 --> jb1 has joined #instantbird 12:01:21 --> BillBinkley has joined #instantbird 12:03:40 <-- BillBinkley has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 12:03:53 --> BillBinkley has joined #instantbird 12:06:23 <-- nhnt11 has quit (Ping timeout) 12:07:58 --> nhnt11 has joined #instantbird 12:17:45 <-- EionRobb has quit (Quit: Leaving.) 12:30:35 <-- Armada has quit (Connection reset by peer) 12:31:05 <flo-retina> clokep_work: cool :) 12:42:58 <-- mayanktg-ph has quit (Quit: Connection closed for inactivity) 12:47:02 <-- nhnt11 has quit (Ping timeout) 12:51:35 --> mayanktg has joined #instantbird 13:02:43 <-- mayanktg has quit (Ping timeout) 13:03:08 --> mayanktg has joined #instantbird 13:03:26 --> mconley has joined #instantbird 13:04:00 <-- mpmc has quit (Connection reset by peer) 13:05:29 --> mpmc has joined #instantbird 13:07:14 <-- mpmc has quit (Connection reset by peer) 13:08:22 --> mpmc has joined #instantbird 13:20:37 <-- mayanktg has quit (Ping timeout) 13:20:57 --> mayanktg has joined #instantbird 13:21:04 <-- mconley has quit (Input/output error) 13:21:33 --> mconley has joined #instantbird 13:23:21 <-- mconley has quit (Ping timeout) 13:26:16 <-- mayanktg has quit (Ping timeout) 13:26:30 --> mayanktg has joined #instantbird 13:30:26 <clokep_work> flo-retina: So how often is m-i merged to m-c? I know the sheriffs do it...but is their a schedule or something? 13:32:54 <flo-retina> clokep_work: when they feel like it 13:33:03 <flo-retina> clokep_work: usually 1-3 times a day. 13:34:05 <clokep_work> flo-retina: Cool, wasn't sure if it was more formal than that. :) 13:35:00 <flo-retina> clokep_work: I think the expectation is that there's at least a merge everyday 13:38:12 <clokep_work> Got it! 13:41:47 --> aleth has joined #instantbird 13:41:47 * ChanServ sets mode +o aleth 13:43:03 <aleth> For some reason, IB on OSX often seems to restart in hidden mode, so the windows only appear when you click on the dock icon 13:43:23 <clokep_work> That's never happened to me. 13:43:45 <clokep_work> I have seen on Windows that the tabs I always keep open aren't there...(nor in the on hold list), but if I open a new conversation the window appears with all the convs in it. 13:45:36 <-- aleth has quit (Quit: exit stage left) 13:45:45 --> aleth has joined #instantbird 13:45:45 * ChanServ sets mode +o aleth 13:46:19 <aleth> It's certainly intermittent, I don't know what causes it 13:47:00 <flo-retina> aleth: passing a -foreground command line parameter is required for the application to be visible after startup 13:47:09 <flo-retina> applications started from the dock have it automatically 13:47:29 <flo-retina> it's possible the updater doesn't give that parameter when restarting, for some reason 13:55:29 <-- mayanktg has quit (Ping timeout) 13:55:52 --> mayanktg has joined #instantbird 13:59:40 --> mconley has joined #instantbird 14:00:28 <clokep_work> mayanktg: I was hoping to see a new patch yesterday, what's going on? 14:02:30 <mayanktg> clokep_work: I'm stuck with the converting the UI to the XBL. I need to add the call interface created in the HTML Document to the <xul:browser/> . I'm trying that only. 14:02:51 <aleth> If you're stuck, you should ask ;) 14:03:14 <aleth> You shouldn't add it to the browser element. 14:03:34 <aleth> Just to the conversation binding. 14:04:10 <-- BillBinkley has quit (Ping timeout) 14:04:25 --> iamjayakumars has joined #instantbird 14:04:39 <flo-retina> https://www.mail-archive.com/dev-tech-js-engine-internals@lists.mozilla.org/msg00918.html seems very interesting. I don't see a bug number though :-/ 14:05:59 <aleth> mayanktg: flo meant that instead of adding the video element to the browser content via JS, add it directly to the chrome here http://mxr.mozilla.org/comm-central/source/im/content/conversation.xml#27. <html:video> or whatever you need. 14:06:19 <mayanktg> aleth: Ok. So Just like I have added the video and buttons in html document I will need to add it in the XUL. (Like I did in user icon patch)! 14:06:51 <mayanktg> Yup 14:06:56 <-- jb1 has quit (Ping timeout) 14:07:10 <aleth> Yes. 14:09:52 --> nhnt11 has joined #instantbird 14:10:53 <nhnt11> Hi 14:11:34 <aleth> Hello 14:11:59 --> BillBinkley has joined #instantbird 14:12:52 <clokep_work> flo-retina: That looks neat! :) 14:12:52 <aleth> flo-retina: that does look interesting :) 14:18:10 <flo-retina> bug 972712 seems close :). Unfortunately the interesting part got backed out due to intermittent failures, and bug 1023719 is about relanding it. 14:18:14 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=972712 nor, P2, mozilla30, n.nethercote, REOP, Report more notable stuff in the JS memory reporter 14:18:15 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1023719 nor, P2, mozilla33, n.nethercote, REOP, Report notable classes in the JS memory reporter 14:18:29 <-- mayanktg has quit (Ping timeout) 14:18:51 --> mayanktg has joined #instantbird 14:38:39 <-- mayanktg has quit (Ping timeout) 14:40:28 --> mayanktg has joined #instantbird 14:59:14 <-- iamjayakumars has quit (Client exited) 15:06:08 <-- aleth has quit (Ping timeout) 15:06:13 --> rosonline has joined #instantbird 15:06:31 --> aleth has joined #instantbird 15:06:31 * ChanServ sets mode +o aleth 15:08:20 <-- aleth has quit (Ping timeout) 15:11:05 --> Rym has joined #instantbird 15:21:18 * Fallen is now known as Fallen|away 15:25:22 <-- mayanktg has quit (Ping timeout) 15:41:37 --> mayanktg-ph has joined #instantbird 15:49:46 --> aleth has joined #instantbird 15:49:46 * ChanServ sets mode +o aleth 15:58:38 <-- gerard-majax__ has quit (Ping timeout) 15:59:48 --> iamjayakumars has joined #instantbird 16:09:46 --> mayanktg has joined #instantbird 16:30:15 <-- aleth has quit (Quit: exit stage left) 16:30:24 --> aleth has joined #instantbird 16:30:24 * ChanServ sets mode +o aleth 16:30:30 <-- mayanktg has quit (Client exited) 16:30:49 --> mayanktg has joined #instantbird 16:35:25 --> sonny has joined #instantbird 16:38:28 --> gerard-majax__ has joined #instantbird 16:40:26 --> Mook_as has joined #instantbird 16:43:42 <-- gerard-majax__ has quit (Ping timeout) 16:45:12 <-- iamjayakumars has quit (Client exited) 16:46:47 <-- rosonline has quit (Ping timeout) 16:46:56 <flo-retina> clokep_work: ah, the important patch is now on central! :) 16:47:35 <aleth> Great! So with the purple patch, at least Linux should be OK :) 16:49:22 <-- mayanktg has quit (Ping timeout) 16:49:39 --> mayanktg has joined #instantbird 16:54:27 <flo-retina> aleth: indeed. 16:54:32 <flo-retina> If I start the builders again :) 16:54:37 --> gerard-majax__ has joined #instantbird 16:59:51 <-- sonny has quit (Ping timeout) 17:02:21 --> sonny has joined #instantbird 17:03:29 <clokep_work> flo-retina: Yep! Did you push your purple patch? 17:05:39 <-- mayanktg has quit (Ping timeout) 17:06:07 --> mayanktg has joined #instantbird 17:08:20 <flo-retina> clokep_work: nope 17:08:41 <-- gerard-majax__ has quit (Ping timeout) 17:19:54 --> gerard-majax__ has joined #instantbird 17:20:43 <-- mayanktg has quit (Ping timeout) 17:21:06 --> mayanktg has joined #instantbird 17:32:02 <-- gerard-majax__ has quit (Ping timeout) 17:32:07 <-- sonny has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 17:32:58 --> rosonline has joined #instantbird 17:46:44 <-- mayanktg has quit (Client exited) 17:46:47 --> mayanktg has joined #instantbird 17:46:51 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 17:48:41 --> qheaden has joined #instantbird 17:53:59 <-- mayanktg has quit (Ping timeout) 17:54:20 --> mayanktg has joined #instantbird 17:56:54 <-- mayanktg has quit (Ping timeout) 17:57:39 --> mayanktg has joined #instantbird 18:02:38 <-- aleth has quit (Ping timeout) 18:04:49 <instantbot> New Instantbird - Other bug 1047537 filed by philip.chee@gmail.com. 18:04:50 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1047537 nor, --, ---, philip.chee, ASSI, Remove the old Content Security Policy component from package-manifest.in (Port Bug 994782) 18:07:12 <-- mayanktg has quit (Ping timeout) 18:07:36 --> mayanktg has joined #instantbird 18:09:35 <nhnt11> flo-retina: So I think aleth has a point here: http://log.bezut.info/instantbird/today/#m27 18:10:01 <clokep_work> That was fun. I just attached a patch to that w/o ever opening the bug. :) 18:10:03 * nhnt11 investigates a bit. 18:10:24 <flo-retina> nhnt11: yes. He seems to agree that we shouldn't build day clusters before someone calls forEachDay, which is what I said yesterday; isn't it? 18:11:54 <nhnt11> Huh? Assembling the log tree == calling forEachDay :S 18:13:32 <nhnt11> (however, I do not think that the forEachDay changes will change the speed of doing this) 18:14:03 <flo-retina> ah, we are displaying logs by day on Ib too now 18:14:07 <flo-retina> I didn't remember that 18:14:50 <flo-retina> nhnt11: anyway, please figure out a way to make things fast and use as little memory as reasonable possible :) 18:14:57 <nhnt11> I'm on it 18:18:42 <-- mayanktg has quit (Ping timeout) 18:18:56 --> mayanktg has joined #instantbird 18:20:40 <-- mayanktg has quit (Ping timeout) 18:21:02 --> mayanktg has joined #instantbird 18:24:08 <-- Tonnes has quit (Connection reset by peer) 18:27:56 <-- mayanktg has quit (Ping timeout) 18:28:20 --> mayanktg has joined #instantbird 18:30:53 <-- mayanktg has quit (Ping timeout) 18:31:14 --> mayanktg has joined #instantbird 18:33:51 <-- mayanktg has quit (Ping timeout) 18:33:54 --> Armada has joined #instantbird 18:34:17 --> mayanktg has joined #instantbird 18:36:13 <instantbot> philip.chee@gmail.com changed the Resolution on bug 1047537 from --- to FIXED. 18:36:15 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1047537 nor, --, 1.6, clokep, RESO FIXED, Remove the old Content Security Policy component from package-manifest.in (Port Bug 994782) 18:36:55 <-- mayanktg has quit (Ping timeout) 18:37:13 --> mayanktg has joined #instantbird 18:39:47 <-- mayanktg has quit (Ping timeout) 18:40:09 --> mayanktg has joined #instantbird 18:45:20 <-- mayanktg has quit (Ping timeout) 18:45:46 --> mayanktg has joined #instantbird 18:46:39 --> Tonnes has joined #instantbird 18:48:55 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 18:58:49 <-- mayanktg has quit (Ping timeout) 18:59:13 <-- mpmc has quit (Connection reset by peer) 18:59:19 --> mayanktg has joined #instantbird 19:08:39 --> aleth has joined #instantbird 19:08:39 * ChanServ sets mode +o aleth 19:09:43 <-- mayanktg has quit (Ping timeout) 19:10:33 --> mayanktg has joined #instantbird 19:12:59 <-- mayanktg-ph has quit (Quit: Connection closed for inactivity) 19:12:59 --> flo-retina has joined #instantbird 19:12:59 * ChanServ sets mode +qo flo-retina flo-retina 19:19:22 <-- aleth has quit (Ping timeout) 19:20:55 --> aleth has joined #instantbird 19:20:55 * ChanServ sets mode +o aleth 19:22:37 <-- aleth has quit (Ping timeout) 19:26:46 --> aleth has joined #instantbird 19:26:46 * ChanServ sets mode +o aleth 19:34:46 <-- mayanktg has quit (Ping timeout) 19:35:05 --> mayanktg has joined #instantbird 19:39:31 <-- BillBinkley has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 19:39:34 <-- mayanktg has quit (Ping timeout) 19:39:53 --> mayanktg has joined #instantbird 19:46:23 * nhnt11 just hit somewhat of a roadblock. 19:46:57 <nhnt11> For the log sets which represent entire folders, storing just the folder names seems like a good idea 19:47:28 <nhnt11> But, this means iterating over the directory contents later, and the thing is, we'll have to get all the paths anyway, since we need to sort them 19:48:20 <nhnt11> We'd only really just be putting off storing these paths in memory, which isn't very useful imo because consumers do a forEach almost immediately after obtaining a LogSet anyway 19:49:10 <flo-retina> are we really sorting the logs if someone gets all logs and does a forEach? 19:49:12 <aleth> You mean, because paths (filenames) are proxies for dates? 19:49:28 <nhnt11> flo-retina: Yes, we iterate them in order. 19:49:29 <nhnt11> aleth: Yeah 19:49:38 <nhnt11> Well, maybe not "because"? 19:50:11 <aleth> I'd suggest putting dates in the database too but that wouldn't work for TB 19:50:21 <nhnt11> I'm just wondering if it's worth putting off the DirectoryIterator.nextBatch() call 19:50:41 <nhnt11> aleth: I'm not talking about the database here.. 19:50:47 <nhnt11> Oh 19:50:50 <nhnt11> Nvm 19:50:59 <nhnt11> You mean we can use the database for that too 19:51:00 <flo-retina> nhnt11: is sorting the logs really important? 19:51:24 <flo-retina> I can't think of any use case where we would want ALL the logs and have them sorted by date 19:51:25 <nhnt11> flo-retina: It wouldn't make sense if the log tree showed you dates in a random order, would it? :S 19:51:57 <flo-retina> if you are talking about the logs of a single conversation history... I don't see a problem with sorting once you do a .forEach 19:52:14 <aleth> I think you're talking past each other. 19:52:21 <nhnt11> flo-retina: It's not a problem, it's just that it wouldn't really be useful 19:52:21 <aleth> There is no current UI to search *all* the logs. 19:52:41 <nhnt11> Indeed, I'm not talking about the /all/ logs case... 19:53:20 <nhnt11> Were you thinking of a separate LogSet implementation only for the all logs case? 19:53:24 <flo-retina> nhnt11: the /all/ case is the only edge case where I can see sorting as a problem. That's why I'm asking 19:54:10 * nhnt11 was thinking we'd have an implementation where we wanted all the files from a folder, and one for when we had a specific set of files (i.e. search results) 19:54:12 <nhnt11> Hmm 19:55:34 <aleth> All these things may be more of a performance concern if we constantly reiterate over the directory to get the logset for the latest search string 19:56:28 <flo-retina> nhnt11: and is that a problem? 19:56:48 <nhnt11> aleth: The current implementation does directory iteration only once for a log set, and the paths are "recycled" which is good I think 19:57:52 <nhnt11> flo-retina: It's not a problem, but I think it's not useful, except for the all-logs case. 19:58:06 <aleth> nhnt11: that sounds ok 19:58:19 <aleth> i.e. once per log viewer ;) 19:58:33 <nhnt11> Yeah. 20:00:16 * nhnt11 wonders if it's useful even for the all-logs case 20:00:53 * aleth would like to avoid premature optimisation, logger.js is complicated enough as it is 20:02:04 <aleth> A halfway sane API would be nice though ;) 20:03:13 <aleth> Bah, TB still looks completely busted. 20:03:19 <nhnt11> Getting rid of aGroupByDay is certainly an improvement :) 20:03:48 <aleth> Is there actually anything that didn't set it to true? 20:04:46 <aleth> Hmm, maybe infinite scroll won't want to use grouped logs. We'll see. 20:05:45 <nhnt11> aleth: https://mxr.mozilla.org/comm-central/source/mail/components/im/content/chat-messenger-overlay.js#630 is the only place I can see 20:06:15 <aleth> and that looks like a bug of sorts 20:06:17 <nhnt11> aleth: Also the hasLogs checks used to exclude aGroupByDay, but the new LogSets have an isEmpty flag 20:06:21 <nhnt11> Yeah 20:06:38 <aleth> ie. that line doesn't care about grouped or not, it just wants a boolean 20:07:21 <nhnt11> What? 20:07:28 <nhnt11> Looks like it wants logs to me 20:07:38 <aleth> I mean you should probably fix that to group the logs in your next TB patch 20:07:44 <nhnt11> Yeah.. 20:08:12 <nhnt11> It will get fixed "automatically" since aGroupByDay will be gone :) 20:08:20 <aleth> OK :) 20:09:56 <aleth> Would it simplify things if the code didn't use the filename of the first log to as an entry for a day of logs, but simply used a date? 20:10:38 <nhnt11> You mean the path of a Log that actually represents more than one path? 20:10:45 <aleth> Right. 20:10:56 <nhnt11> I can't see how that would simplify anything, no 20:10:56 <aleth> I don't remember the surrounding code well enough to say whether it would make things less confusing 20:11:00 <nhnt11> I'm not even sure where that's even used 20:11:18 <nhnt11> Oh wait 20:12:01 <nhnt11> Right, it's used by consumers to organize things. 20:12:54 <nhnt11> I don't think making it a Date would simplify anything, apart from being more "correct" 20:13:15 <aleth> i.e. would it help if a logset simply contained a list of dates for which there are logs 20:13:21 <aleth> Well, I'll leave it to you 20:14:15 <nhnt11> I don't think any present consumers care /which/ dates have logs, but simply want the dates of all the logs available. 20:16:35 <aleth> ah, I forgot we already pass dates http://mxr.mozilla.org/comm-central/source/im/content/viewlog.js#281 20:17:23 <nhnt11> time? 20:17:24 <nhnt11> yep 20:19:19 <-- mayanktg has quit (Ping timeout) 20:19:33 <aleth> What I really meant was that that code only cares about log.time, until the point at which you select a log. 20:19:41 --> mayanktg has joined #instantbird 20:20:07 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 20:23:24 <-- clokep_work has quit (Ping timeout) 20:30:41 <-- mayanktg has quit (Ping timeout) 20:31:04 --> mayanktg has joined #instantbird 20:34:30 <-- mayanktg has quit (Ping timeout) 20:34:53 --> mayanktg has joined #instantbird 20:36:46 <-- mayanktg has quit (Ping timeout) 20:37:11 --> mayanktg has joined #instantbird 20:38:38 --> nhnt11-testing has joined #instantbird 20:39:12 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 20:39:51 <-- mayanktg has quit (Ping timeout) 20:40:09 --> mayanktg has joined #instantbird 20:44:34 <-- mayanktg has quit (Ping timeout) 20:45:10 --> mayanktg has joined #instantbird 20:57:09 <-- mconley has quit (Input/output error) 20:57:37 <-- mayanktg has quit (Ping timeout) 20:58:01 --> mayanktg has joined #instantbird 21:01:12 --> BWMerlin has joined #instantbird 21:01:31 <-- mayanktg has quit (Ping timeout) 21:01:47 --> mayanktg has joined #instantbird 21:04:47 <-- Mook_as has quit (Ping timeout) 21:04:59 <-- aleth has quit (Ping timeout) 21:05:04 * nhnt11 tries to figure out what he did that broke imILog.time (NaN :-/) 21:10:13 --> Mook_as has joined #instantbird 21:15:13 <nhnt11> *head-desk* 21:15:21 <nhnt11> I had LogSet.prototype defined twice :'( 21:17:21 --> clokep has joined #instantbird 21:17:22 * ChanServ sets mode +o clokep 21:18:31 --> nhnt11-testing has joined #instantbird 21:18:55 <nhnt11-testing> Hmm, all appears to be fine 21:18:56 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 21:26:27 <clokep> flo-retina: So when I did a build w/ your patch I think I ended up w/ no InstantbirdDebug.app, is that what you expected? 21:26:37 <clokep> (I know you said it completes but "doesn't start" or something...) 21:27:23 <flo-retina> yes 21:27:31 <clokep> OK 21:27:35 <flo-retina> that's exactly what needs to be fixed 21:33:53 * Fallen|away is now known as Fallen 21:36:28 <nhnt11> flo-retina: So I've got a patch ready, which addresses all of your comments except the case of the all-logs LogSet. I'd like your final opinion on this - it will likely save some memory and some processing (since we won't be doing any sorting) but only in 2 cases that should occur very very rarely - a full re-index and a rebuild of the stats cache. 21:37:37 * nhnt11 thinks hard to see if there's any other benefit he's missing. 21:38:27 <-- mayanktg has quit (Ping timeout) 21:39:08 <flo-retina> "very very rarely" is "for all users who update Instantbird", right? 21:39:48 --> mconley has joined #instantbird 21:39:55 <nhnt11> flo-retina: yeah, but only once. I guess I see your point though... 21:43:00 <flo-retina> nhnt11: I don't see yours. 21:43:05 <flo-retina> What are you _really_ asking? 21:45:36 --> clokep_work has joined #instantbird 21:45:37 * ChanServ sets mode +o clokep_work 21:45:53 <nhnt11> I'm asking if it's worth writing a whole implementation of LogSet for likely a single use case (two cases if there are a lot of people updating from 1.4) 21:46:58 <-- mconley has quit (Ping timeout) 21:47:14 <nhnt11> flo-retina: What about just keeping the old forEach and not bothering with a LogSet for the all-logs case? 21:47:24 <flo-retina> nhnt11: I still don't understand the quesiton 21:47:53 <clokep> flo-retina: So do you want me to just push that patch any commit message? 21:47:54 --> mconley has joined #instantbird 21:47:56 <flo-retina> you are making "a whole implementation of LogSet" sound like it's a huge piece of code. In my mind you need about 5 lines to special case something. 21:48:22 <flo-retina> nhnt11: that could work. 21:48:24 <nhnt11> I don't mean that writing it is a big deal, I just think it's unnecessary clutter in logger.js 21:48:27 <-- qheaden has quit (Input/output error) 21:48:31 <flo-retina> nhnt11: the old forEach wouldn't sort? 21:48:43 <nhnt11> flo-retina: No. The old forEach just iterated and parsed as it did so 21:48:54 <nhnt11> s/parse/called the callback/ 21:48:54 <flo-retina> sounds OK 21:49:16 * nhnt11 wonders why he didn't think of this earlier 21:49:34 <flo-retina> nhnt11: wasn't this an nsISimpleEnumerator rather than a forEach that we had? 21:50:41 <nhnt11> flo-retina: We never had an nsISimpleEnumerator for the all-logs case 21:50:56 <nhnt11> Bug 1025464 moved that code from the stats service to logger.js 21:50:59 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1025464 nor, --, 1.6, nhnt11, RESO FIXED, Refactor log sweeping code to use Task.jsm and move it to logger.js 21:51:03 <nhnt11> https://mxr.mozilla.org/comm-central/source/chat/components/src/logger.js#750 21:51:08 <flo-retina> ok 22:16:48 * nhnt11 can't figure out why he's getting http://pastebin.instantbird.com/787616 22:17:45 <clokep> In what code? ;) 22:18:16 <nhnt11> I can give you context, but I'm really curious at the moment about what that error message means 22:18:29 <nhnt11> (give me a minute...) 22:18:36 <clokep> IDK. 22:19:43 <flo-retina> nhnt11: that means the first parameter you gave to that method is of the wrong type 22:19:53 <flo-retina> eg. an object was expected and you gave a string 22:21:38 <nhnt11> aaaah 22:21:43 <nhnt11> flo-retina: thanks 22:23:41 <flo-retina> np 22:26:36 <-- mconley has quit (Ping timeout) 22:36:40 --> mconley has joined #instantbird 22:39:33 <-- Bollebib has quit (Connection reset by peer) 22:48:29 <-- mconley has quit (Input/output error) 22:48:58 --> mconley has joined #instantbird 22:49:03 <-- Rym has quit (Ping timeout) 22:50:50 <-- mconley has quit (Ping timeout) 22:51:15 --> Rym has joined #instantbird 22:52:59 <flo-retina> bah, I should have replied to your question about the commit message 22:53:16 <flo-retina> that patch isn't very related to the PARALLEL_DIRS -> DIRS change :-/ 22:54:01 <flo-retina> in some ways it was closer to https://bugzilla.mozilla.org/show_bug.cgi?id=1044460 22:54:05 <instantbot> Bug 1044460 blo, --, ---, iann_bugzilla, ASSI, Port relevant changes from Bug 1043344 for moving libraries and programs build to the compile tier 22:54:25 <flo-retina> I need to unplug my modem to change the splitter, brb 22:54:26 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 22:55:38 --> EionRobb has joined #instantbird 23:01:41 --> flo-retina has joined #instantbird 23:01:41 * ChanServ sets mode +qo flo-retina flo-retina 23:02:12 <flo-retina> the two minis are starting 23:05:59 <flo-retina> clokep: linux nightlies are compiling 23:06:22 <clokep> flo-retina: Thanks. :) 23:06:23 <flo-retina> probably not very useful given that another set of nightlies will start 3 hours from now 23:06:51 <clokep> Hopefully we can fix Mac and Windows "soon" 23:07:10 * clokep is glad we fixed the Linux nightlies soon enough to have....just them. ;) 23:08:33 <flo-retina> clokep: I think Windows is fixable. 23:08:37 <flo-retina> clokep: Mac... meh 23:09:10 <-- clokep_work has quit (Ping timeout) 23:09:22 <flo-retina> we _may_ be able to hack around it, but I don't think that would make sense given that TB shares the same bustage 23:09:52 <clokep> I agree. :-D 23:26:41 <-- clokep has quit (Ping timeout) 23:36:04 <flo-retina> clokep: so if you want to do some local development, you know which patch you need to apply ;)