All times are UTC.
00:04:01 <-- dionisos has quit (Ping timeout) 00:25:38 <qheaden> Hello everyone. 00:26:37 <qheaden> clokep: Thanks for setting up which bugs are blocking turning on JS-Yahoo by default. 00:28:29 <-- rosonline has quit (Quit: Instantbird 1.4 -- http://www.instantbird.com) 00:29:07 <clokep> qheaden: No problem. 00:29:12 <clokep> We might find more too. ;) 00:29:50 <qheaden> While I have you on, I need to get your approval on ways to fix these bugs. I have an idea on how to fix them, but I want to avoid any silly r-'s. :) 00:30:02 <clokep> Ask away. 00:30:12 * clokep is going to play a game. 00:30:19 <clokep> But I have my speakers on, so ping me 00:31:06 <qheaden> clokep: First, with bug 2089, how are we to log the incoming/outgoing packets? I say we list the packet info (status, type, etc), and then list the key/value pairs. 00:31:10 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2089 nor, --, ---, nobody, NEW, Debug logs are binary only 00:33:12 <clokep> qheaden: That's probably reasonable, yes. Just make sure it's readable and I'll probably r+ it. :) 00:33:20 <qheaden> Okay. :) 00:33:23 <clokep> Please include some examples of how it looks. 00:33:30 <qheaden> OK. 00:34:07 <qheaden> clokep: Next, how about bug 2111? Should we just end the "typing" notification when a message is received? That would imply that the typing stopped? I think if the person continues to type, another typing notification will be sent behind the message. 00:34:11 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2111 nor, --, ---, nobody, NEW, Yahoo Web Client Causes Endless Typing Notification 00:34:37 <clokep> qheaden: That most likely seems reasonable, did you check to see if we're getting a different type of packet or something? 00:34:41 <clokep> ( / what libpurple does) 00:35:22 <qheaden> I'll check into libpurple. 00:36:42 <clokep> OK. :) 00:36:45 <clokep> More questions? 00:38:10 <qheaden> clokep: No, that seems to be it for now. Thanks. :) 00:38:25 <qheaden> Game on. ;) 00:38:48 <clokep> qheaden: OK, let me know when you have questions about the socket one. :P 00:39:14 <qheaden> clokep: Oh yeah, speaking of sockets, I do have one more question. :) 00:40:12 <qheaden> clokep: When sending keepalive packets, libpurple sends them once every minute. The code in socket.jsm seems to be hard coded to send pings every two minutes if you use that system. I guess I can try the socket.jsm code, and see if it matters sending every two minutes. 00:40:27 <qheaden> Should I add the ability to adjust the ping time socket.jsm uses? 00:41:19 <clokep> qheaden: Bingo. ;) 00:41:28 <qheaden> :) 00:41:31 <qheaden> Okay. 00:41:36 <clokep> I think flo-retina and I had a disagreement about whether prpls should be able to override that time. 00:41:46 <clokep> So you can leave it for two minutes if you want (for now). 00:41:50 <clokep> Or make it so it can be overridden. 00:42:11 <qheaden> Okay. I do think it should be overridable. Not all protocols prefer the same ping timing. 00:42:31 <qheaden> And I still can't figure out why Yahoo uses pings and keepalive packets. 00:45:09 <clokep> Isn't one the server pinging us and the other us pinging the server? 00:48:07 <qheaden> clokep: In the libpurple source code, both ping and keepalive are sent by the client. Keepalive once a minute, and ping once an hour. 00:48:16 <qheaden> Not sure if it is a mistake in libpurple's source. 00:49:23 <clokep> qheaden: We should probably just do the same thing. ;) 00:49:36 <qheaden> I concur. :) 00:51:26 <Mook_as> or do one and see if yahoo kicks you off :p 00:52:21 <clokep> qheaden: So the way our keep-alive socket code is set up, by the way, is that we DON'T send it...unless we haven't received data in xxx minutes. 00:52:54 <qheaden> Hmm, okay. 00:53:05 <clokep> And maybe that won't work. ;) 00:53:17 <clokep> But people had mentioned this code to you on IRC...and then we got a patch not using it. :) 00:53:22 <clokep> You need to at least justify WHY that is. 00:58:45 <qheaden> clokep: Okay, I'll discuss it with flo-retina tomorrow. 00:59:00 <-- Mook_as has quit (Quit: Mook_as) 00:59:54 <clokep> OK. 01:00:01 <clokep> I'd prefer if you discuss it in the ubg. :) 01:03:08 <qheaden> OK. 01:38:36 --> dew has joined #instantbird 01:39:32 <-- dew1 has quit (Ping timeout) 01:47:36 <-- dew has quit (Ping timeout) 01:53:30 --> dew has joined #instantbird 02:05:11 --> mconley has joined #instantbird 02:24:41 --> Mook has joined #instantbird 02:34:46 <-- wnayes has quit (Quit: wnayes) 02:36:08 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 03:05:26 <-- mconley has quit (Input/output error) 03:26:06 <-- FireFly_TB has quit (Ping timeout) 03:31:47 --> FireFly_TB has joined #instantbird 03:34:16 <instant-buildbot> build #976 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/976 03:51:25 --> mconley has joined #instantbird 04:04:38 <-- FireFly_TB has quit (Quit: FireFly_TB) 04:13:19 --> FireFly_TB has joined #instantbird 04:24:35 <-- Mook has quit (Quit: Mook) 04:44:15 <-- mconley has quit (Input/output error) 04:56:59 <-- micahg has quit (Ping timeout) 05:07:49 --> micahg has joined #instantbird 05:09:23 <-- micahg has quit (Max SendQ exceeded) 05:10:08 --> micahg has joined #instantbird 05:21:13 --> mconley has joined #instantbird 05:38:58 <-- EionRobb has quit (Quit: Leaving.) 05:44:05 --> nhnt11 has joined #instantbird 05:44:15 * nhnt11 is now known as nhnt11_lab 06:07:04 <instant-buildbot> build #960 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/960 06:10:50 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 06:18:36 <-- mconley has quit (Quit: Leaving...) 06:25:31 <-- FireFly_TB has quit (Ping timeout) 06:39:27 <instant-buildbot> build #1060 of win32-nightly-default is complete: Failure [failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1060 07:06:59 <-- nhnt11_lab has quit (Ping timeout) 07:09:53 --> nhnt11_lab has joined #instantbird 07:19:38 <instant-buildbot> build #1061 of win32-nightly-default is complete: Failure [failed shell] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1061 07:22:19 <instantbot> florian@instantbird.org granted review for attachment 2815 on bug 2066. 07:22:24 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2066 enh, --, ---, nhnt11, NEW, New conversation tab should suggest chat rooms 07:31:21 <-- nhnt11_lab has quit (Ping timeout) 07:33:13 <instantbot> florian@instantbird.org denied review for attachment 2810 on bug 2142. 07:33:15 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2142 enh, --, ---, aleth, ASSI, Allow tab completion of nicks which have left the room 07:39:10 --> nhnt11_phone has joined #instantbird 07:40:50 <-- nhnt11_phone has quit (Connection reset by peer) 07:59:45 --> jb has joined #instantbird 08:08:32 <-- chrisccoulson has quit (Ping timeout) 08:17:51 --> chrisccoulson has joined #instantbird 08:28:09 --> nhnt11_lab has joined #instantbird 08:28:39 <instantbot> florian@instantbird.org denied feedback for attachment 2812 on bug 2143. 08:28:41 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 08:35:51 * nhnt11_lab is now known as nhnt11 08:38:58 <nhnt11> flo-retina: The log files are only opened if the database doesn't already exist 08:39:18 <nhnt11> i.e. it's the first time the user is opening Instantbird with the database code. 08:53:04 --> qlum has joined #instantbird 09:09:12 --> dionisos has joined #instantbird 09:18:54 <-- jb has quit (Ping timeout) 09:35:18 --> jb has joined #instantbird 09:36:42 <-- dionisos has quit (Ping timeout) 09:40:26 --> dionisos has joined #instantbird 09:51:14 --> novabyte has joined #instantbird 09:54:02 <-- jb has quit (Ping timeout) 09:54:17 --> aleth has joined #instantbird 09:54:17 * ChanServ sets mode +h aleth 10:04:02 --> clokep has joined #instantbird 10:04:03 * ChanServ sets mode +o clokep 10:04:21 <aleth> nhnt11: Note all my questions about indexing/search were not intended as reasons against the ranking patch - it might make sense to land /ranking/ (using whatever) first and a patch speeding up search second 10:04:31 <aleth> I just wanted to make sure you were considering these issues ;) 10:05:38 <aleth> It's up to you how you parcel the work up... 10:05:51 --> jb has joined #instantbird 10:17:44 --> gerard-majax has joined #instantbird 10:20:26 <-- jb has quit (Ping timeout) 10:29:34 --> jb has joined #instantbird 10:41:47 <instantbot> New Instantbird (UI) bug 2152 filed by amsin21@gmail.com. 10:41:47 <clokep> Good morning. :) 10:41:50 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2152 maj, --, ---, nobody, UNCO, Messages appearing twice 10:42:05 * clokep guesses Facebook is screwing up. ;) 10:42:21 <aleth> Good morning ;) 10:42:30 * aleth just had lunch 10:43:24 <aleth> clokep: How can you tell it's Facebook? 10:43:51 <clokep> aleth: I wrote that w/o looking at the bug. 10:44:02 <aleth> ah :D 10:44:14 <clokep> After looking, I'm guessing it's Twitter. 10:44:40 <aleth> There doesn't seem to be a twitter user of that name. 10:44:49 <clokep> Ah, good idea. 10:45:02 <clokep> .s aren't legal characters anyway. 10:45:28 <nhnt11> Hmm, rupee rates :D 10:45:37 <nhnt11> Er, I mean :( 10:45:38 <aleth> I guess the user expects us to have psychic protocol powers ;) 10:45:49 * clokep guesses it's a server issue... 10:45:53 <clokep> Doesn't mean we shouldn't try to handle it. 10:45:57 <clokep> But still frustrating. 10:46:12 <nhnt11> aleth: I think stats first and then search would be a good order 10:46:32 <nhnt11> But it's definitely a good idea to think about the database choice properly before going ahead 10:46:47 * aleth hopes Even will have time for the Windows VM soon so we can land things again... 10:47:09 <nhnt11> I did more research on sqlite, and it doesn't seem like it would be too much of a performance boost, since we would probably want to use LIKE with wildcards.. 10:47:15 <nhnt11> And that wouldn't really make much use of the index 10:47:39 <nhnt11> I'm about to dig into the awesomebar code 10:48:02 <aleth> That might be a good idea, to get a baseline to compare options to 10:48:25 <aleth> Obviously places.sql is much more complicated than what you will need 10:48:39 <-- jb has quit (Ping timeout) 10:53:34 <aleth> nhnt11: Another possibility for the filtering is to make it return results in an async fashion 10:53:46 <nhnt11> aleth: Yeah I've been talking about that 10:54:09 <nhnt11> Mostly I've said "I want to look at that after ranking" but it seems I may want to look at it before.. 10:54:32 <aleth> Ah right 10:54:42 <aleth> It seems independent of ranking though? 10:54:54 <nhnt11> It could affect the choice of database 10:55:56 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 10:56:45 <nhnt11> aleth: How about, I go ahead with ranking but cache stuff in JSON for now, and get that stuff right so that we can land bug 2143, and then look into optimization? 10:56:49 --> flo-retina has joined #instantbird 10:56:49 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 10:56:49 * ChanServ sets mode +qo flo-retina flo-retina 10:57:27 <aleth> nhnt11: Sounds fine to me. (But if it's temporary, it doesn't matter if you cache it in indexdb or json...) 10:58:00 <nhnt11> I figured JSON would mean the least amount of bitrot in case we want to change our choice of database 10:58:10 <aleth> If you do it that way, make sure you label the parts of the code which you expect to change later 10:58:41 <aleth> (or even better, put that part in separate functions) 10:59:31 <nhnt11> So my tasks in order now would be 1) Finish ranking, caching stats in JSON but keeping stuff in memory as it is now. 2) Major optimization, mostly looking at querying a database at filter-time and thereby reducing memory usage, as well as much better/faster filtering 10:59:34 <nhnt11> Ok. 10:59:53 <nhnt11> What flo-retina said in his feedback about smaller patches makes sense 11:00:02 <aleth> Yes, sounds good 11:00:50 <nhnt11> aleth: Have you tried the bug 2066 patch? 11:00:54 <-- novabyte has quit (Quit: bye bye) 11:00:54 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2066 enh, --, ---, nhnt11, NEW, New conversation tab should suggest chat rooms 11:01:25 <aleth> nhnt11: I've not tried it, I was expecting it to be in nightlies by now :-/ 11:02:34 <nhnt11> I did some work on bug 2146 btw, but it was pretty slow so I'm leaving it for now. 11:02:38 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2146 nor, --, ---, nobody, NEW, Awesometab should have smarter filtering 11:03:09 <aleth> So it told you what you needed to know for now, that's the main thing :) 11:03:30 <nhnt11> Yeah. It worked fine until I connected to freenode 11:06:13 * aleth wonders if efnet is even bigger 11:10:02 <nhnt11> :O 11:10:16 <nhnt11> I just opened a newtab with the error console open 11:10:22 <nhnt11> and it did a LIST on freenode 11:10:31 <nhnt11> And my UI is frozen 11:10:36 <nhnt11> because of all the UTF-8 warnings 11:11:08 <aleth> nhnt11: File a bug about that: it's not the fault of your code 11:11:40 <nhnt11> true 11:11:55 <aleth> Thankfully it shouldn't freeze if the error console isn't open ;) But it's not great either 11:12:24 <nhnt11> aleth: But I don't like this. I hadn't noticed before, but opening a newtab when there isn't already a conversation window is painfully slow after a LIST on freenode 11:12:34 <nhnt11> And this is after the LIST is done 11:12:54 <aleth> "when there isn't already a conversation window" matters why? 11:13:15 <nhnt11> I guess because the UI has to be drawn? 11:13:37 <aleth> It sounds to me like you will have a use for the profiler ;) 11:13:38 <nhnt11> Making this async is making more sense now 11:14:03 <nhnt11> It's noticeably less speedy even with a conv window already open 11:14:04 <aleth> For now, you could use dump()s to see which part of the code is reached when 11:14:20 <nhnt11> I'm doing that already 11:14:26 <aleth> Use Date.now() and temporary variables to time things etc 11:14:27 <nhnt11> (in the process of adding dumps) 11:19:19 <nhnt11> aleth: So it looks like the culprit is returning that huge list from the stats service to the newtab 11:20:02 <aleth> I thought you only transferred 10 items at a time? 11:21:12 <nhnt11> getFilteredConvs takes <5ms before returning, but the newtab sees it as 100ms 11:21:14 <aleth> Or do you transfer all of them but only add 10 listitems 11:21:18 <nhnt11> aleth: What? yeah 11:21:24 <nhnt11> Transfer all and add only 10 ui items 11:21:51 <aleth> nhnt11: It sounds like that is not optimal then... 11:21:54 <nhnt11> With no conversation window already open, it took 800ms 11:21:57 <nhnt11> This is bad. 11:22:16 <nhnt11> Looks like I should make this async /now/ 11:22:51 <nhnt11> The alternative is to not return so many conversations at all 11:23:08 <nhnt11> Once we have ranking, we could return only the top 20 for a given filter string? 11:23:20 <aleth> Didn't you want to do that anyway for other reasons yesterday? 11:23:40 <aleth> Only return what is needed, filter again what has already been filtered, etc 11:23:42 <nhnt11> aleth: Make it async or return fewer conversations? 11:23:45 <nhnt11> Yeah... 11:24:07 <nhnt11> Right now, since everything is alphabetical, it's weird to return only 20 or so conversations 11:24:12 <nhnt11> but once we have ranking it makes a lot of sense 11:24:23 <aleth> Well, you can return what is needed and request more when the user scrolls 11:24:55 <aleth> (as is currently the case for the DOM side of things) 11:25:07 <nhnt11> Yeah 11:25:29 <aleth> I'm not surprised there's plenty of optimization left to be done ;) It's great you're taking a look at all the intersecting issues before making your plan of attack. 11:26:10 <nhnt11> Yeah, at this point I think it's wise to know what problems I have left to tackle before deciding what to do first 11:26:40 <nhnt11> I vote for ranking first, then returning fewer conversations at a time. 11:26:48 <aleth> Sounds fine to me. 11:27:40 <nhnt11> That would leave things at a state where it's usable (probably better than "usable" :P), and then from there make it awesome. 11:28:01 <nhnt11> But that would mean /not/ landing 2066 before ranking, which I have no problems with 11:28:21 <aleth> I think we should land 2066 as it's r+ and it will generate followups on the UI side 11:28:36 <aleth> It doesn't matter if it's a bit slow while it's only in nightlies. 11:28:39 <nhnt11> Hmm. It's kinda unusable if you use freenode though. 11:28:41 <nhnt11> Ok 11:28:43 <nhnt11> 800ms is bad though. 11:29:16 <aleth> Extra incentive for followups :D 11:29:25 <nhnt11> :) 11:29:46 * nhnt11 wants to do this right, and not rush something and land in a mess 11:30:23 <aleth> The benefit of landing it is that then all the different listitems are in nightlies and we can tune the design of them and the a11y aspects in parallel to you spending most of your time on optimization 11:30:48 <nhnt11> Alright 11:32:37 <aleth> I'm really not surprised at all that it's a bit slow at this point... as long as it doesn't completely freeze the UI (worse than say, joining #ubuntu used be anyway) if you haven't got the error console open 11:33:26 <aleth> Still think you should file a bug on those UTF-8 warnings though... it seems we could possibly optimize that and only display it once 11:33:29 <nhnt11> It lags only while opening 11:33:32 <nhnt11> opening a newtab* 11:34:28 <aleth> nhnt11: Right, as expected as we paid attention to the other aspects during the review cycles 11:34:39 <nhnt11> Yeah 11:34:48 <nhnt11> I'm going to get to work on the ranking patch now 11:45:06 <-- dionisos has quit (Ping timeout) 11:48:11 --> clokep_ has joined #instantbird 11:49:36 <clokep_> nhnt11: http://log.bezut.info/instantbird/today/#m181 What is this about? 11:50:53 <nhnt11> clokep_: There are tons of "prpl-irc: This message doesn't seem to be UTF-8 encoded: :asimov.freenode.net 322 nhnt11 blabla" 11:51:22 <clokep_> ... from what? 11:51:25 <nhnt11> (RPL_LIST) 11:51:27 <clokep_> Did you change your encoding or something? 11:51:29 <nhnt11> They're dumped 11:51:31 <nhnt11> No I haven't 11:51:47 <nhnt11> This is from my freenode account when LIST is going on 11:52:01 <nhnt11> I haven't changed any settings 11:52:25 <aleth> clokep_: The issue is that there are so many such warning messages that displaying them if the error console is open causes serious lag. When the console is closed you don't notice. 11:53:02 <nhnt11> clokep_: Try doing a /list with your error console open 11:53:07 <nhnt11> or actually don't 11:53:10 <nhnt11> :P 11:53:43 <clokep_> aleth: nhnt11 You're totally misunderstanding what I'mt rying to get at. 11:53:49 <clokep_> WHY is there a warning being thrown in the first place? 11:53:58 <nhnt11> Because the error isn't utf-8 encoded? 11:53:59 <nhnt11> I don't know 11:54:09 <nhnt11> s/error/message 11:54:23 <nhnt11> It should be though... 11:54:33 <aleth> I guess there are lots of channels with umlauts or cyrillic etc in their topic 11:55:02 <aleth> nhnt11: Can't you tell from the message? 11:55:05 <nhnt11> Yeah.. 11:55:10 <nhnt11> There are some messages that seem fine though 11:55:30 <nhnt11> Most of them have special chars.. 11:55:44 <nhnt11> But some seem fine.. 11:55:51 <aleth> Is this something we should tell freenode about? 11:55:54 <nhnt11> Let me pastebin a few 11:56:07 <clokep_> aleth: IRC servers don't know anything about character encodings. 11:56:11 <clokep_> They just treat things as bytes. 11:56:36 <aleth> clokep_: Oh, so it's up to whoever set the topic :-/ 11:57:32 <nhnt11> Ah, the ones that I thought seemed fine aren't fine 11:57:47 <nhnt11> Just that my terminal didn't display them at all.. 11:58:05 <nhnt11> but when I paste it in pastebin I get “ and stuff like that 12:00:57 * clokep_ wonders what character that is. 12:01:00 <clokep_> aleth: Yes. 12:01:21 <nhnt11> clokep_: I think it's the opening double quotes character 12:01:23 <nhnt11> dunno what it's called 12:01:47 <nhnt11> Seeing as there's a ” a few words after, and the phrase is "knowledge is power" :P 12:02:12 <nhnt11> I'm also seeing "today’s", which I'm guessing is an apostrophe 12:05:14 <clokep_> :( apostrophes are ASCII.... 12:09:26 <nhnt11> clokep_: The accented one 12:10:09 <nhnt11> Er, the closing single quotes character I guess 12:33:19 --> jb has joined #instantbird 12:41:03 --> dionisos has joined #instantbird 12:44:33 <-- jb has quit (Ping timeout) 12:53:04 --> jb has joined #instantbird 13:38:53 --> dew1 has joined #instantbird 13:39:42 <-- dew has quit (Ping timeout) 13:50:20 <nhnt11> Well, returning only 20 conversations is a huge improvement 13:50:37 <nhnt11> I don't see any difference from how it is in the current nightly 13:54:05 <aleth> Quick work :) 14:00:31 * aleth hopes that improvement will be in a separate patch following up on 2066 14:01:03 <-- dionisos has quit (Ping timeout) 14:01:13 <nhnt11> aleth: Do we want this improvement without ranking? 14:01:15 --> dionisos has joined #instantbird 14:01:27 <nhnt11> Note that more convs aren't returned while scrolling.. 14:01:27 <aleth> nhnt11: The order is up to you 14:01:35 <aleth> Why not> 14:01:36 <nhnt11> (yet, at least) 14:01:48 <nhnt11> I was re-doing the stats patch with a JSON cache 14:02:07 <aleth> Ah, so you are doing both WIPs at the same time :D 14:02:43 <-- jb has quit (Ping timeout) 14:02:52 <aleth> I would suggest you file patches in the order in which you think they should land (taking into account how long reviews are likely to take) 14:02:55 <-- dionisos has quit (Ping timeout) 14:03:00 <nhnt11> Yeah 14:03:06 --> dionisos has joined #instantbird 14:04:46 <-- dionisos has quit (Ping timeout) 14:05:00 --> dionisos has joined #instantbird 14:05:16 <nhnt11> aleth: Btw, I was thinking more along the lines of the awesomebar where only 10 hits are displayed 14:05:24 <nhnt11> Er, 12 14:06:07 <aleth> nhnt11: Right, the idea is to combine that with being able to fetch more results on demand 14:06:25 <nhnt11> OK. I've been thinking about how to do that 14:06:26 <aleth> You already have the code for this - it likely just means moving some of the logic from the UI to the stats service 14:06:37 <aleth> (or am I missing something?) 14:07:12 <nhnt11> aleth: The stats service would have to keep the filtered convs list for each newtab 14:07:32 <nhnt11> I'll try this.. 14:07:37 <aleth> At the moment it's kept in the newtab, so that is no extra overhead afaik 14:07:49 <nhnt11> (I suppose this was what Mic was suggesting a while back) 14:07:51 <nhnt11> yeah 14:08:06 <aleth> Right, we said at the time it might have to be considered depending on performance 14:08:19 <aleth> What you want to avoid is passing large wrapped arrays around 14:08:24 <nhnt11> yeah 14:08:48 <-- dionisos has quit (Ping timeout) 14:09:13 --> dionisos has joined #instantbird 14:14:28 --> mconley has joined #instantbird 14:16:22 <nhnt11> aleth: I think just making the API async is a better idea 14:16:25 <aleth> The reason it makes sense not to optimize too much before having ranking is that as someone (you? flo?) pointed out earlier, when you can search in the order of ranking you can return early after you have found 20 items (as long as you have searched all items of equal rank), and then continue in the background (in case there are further requests) or on demand... 14:16:38 <nhnt11> Yeah 14:16:47 <nhnt11> I'm not doing too much more on this right now 14:17:04 <nhnt11> Focusing on getting a good patch ready for ranking 14:17:09 <aleth> Whether the best way to do that is to go async or to move stuff to the stats service is up to you ;) 14:17:36 <nhnt11> Moving stuff with the stats service would involve rewriting a bit more UI code than I'd like :P 14:18:00 <nhnt11> And making it async would work well for consumers other than newtabs, though I guess that's not too important 14:18:31 <aleth> Yes, we shouldn't optimize for hypothetical use cases... 14:32:16 --> jb has joined #instantbird 14:42:02 <instantbot> aleth@instantbird.org granted feedback for attachment 2813 on bug 2147. 14:42:04 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2147 nor, --, ---, nobody, NEW, Bubbles' last message sometimes doesn't auto-scroll 14:45:04 --> jamesw has joined #instantbird 14:45:18 <-- jamesw has quit (Client exited) 14:47:33 --> jamesw has joined #instantbird 14:50:42 --> wnayes has joined #instantbird 14:56:09 <-- dionisos has quit (Ping timeout) 14:56:29 --> dionisos has joined #instantbird 14:59:06 <-- jb has quit (Ping timeout) 15:23:52 --> vaguerant has joined #instantbird 15:25:38 <vaguerant> Hi folks. Extremely new to Instantbird, so apologies for the dumb question, but how do I move the popup message notification that's currently in the top right? I'm on Windows XP, and Instantbird version 1.4 (20130516232436). 15:26:15 <clokep_> aleth: flo-retina ^ 15:26:24 * clokep_ isn't sure we even control that or if it's just part of our toolkit... 15:26:34 <clokep_> I thought it appeared int he bottom left though. :) 15:27:01 <aleth> I thought it was the bottom right, but then I'm not on Windows ;) 15:27:04 <vaguerant> Maybe it's theme-based? I'm using the Simple theme right now. 15:27:10 <aleth> Mic would be the most likely person to know more. 15:27:24 <aleth> vaguerant: It doesn't depend on the message theme. 15:28:30 <clokep_> Yes, Mic would know. :( 15:28:39 * clokep_ summons Mic. 15:29:20 <aleth> Hmm, the update notifications appear in the top left for me as well. 15:29:26 <aleth> s/left/right 15:29:48 * clokep_ wonders if it depends on taskbar location. 15:29:57 <clokep_> vaguerant: So looking at the code it doesn't seem like we specify a location.. 15:30:06 <clokep_> http://lxr.instantbird.org/instantbird/source/instantbird/modules/ibNotifications.jsm#67 15:30:46 <aleth> The screenshot in https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIAlertsService shows it on Windows in the bottom right ;) 15:30:48 <clokep_> Actually https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIAlertsService says that it comes from the bottom of the screen. :-S 15:32:44 * clokep_ wonders if vaguerant has his taskbar on the top of his screen? 15:33:00 <nhnt11> it appears at the top right for me on mac 15:33:34 <vaguerant> I don't, but I do use Litestep as a desktop replacement for Explorer, so perhaps it doesn't like that? 15:36:42 <aleth> vaguerant: Your best chance is to stick around until Mic shows up ;) 15:36:57 <vaguerant> Sure, that's no problem. 15:39:16 <clokep_> (And complain about other issues you have. :P) 15:39:49 <aleth> (for example, why you not use IB for IRC :P) 16:10:38 <-- dionisos has quit (Ping timeout) 16:37:27 --> jb has joined #instantbird 16:54:02 --> Mook_as has joined #instantbird 17:07:38 <-- Even has quit (Input/output error) 17:07:51 <-- gerard-majax has quit (Ping timeout) 17:08:31 <nhnt11> aleth: You were a bit skeptical about having such long id's for conversations. What kind of id's would you expect? 17:09:06 <nhnt11> (I'm mainly wondering if I missed something and there's a much easier way to identify conversations) 17:09:46 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 17:12:35 <-- jb has quit (Ping timeout) 17:13:06 <aleth> nhnt11: I wasn't so much skeptical as that I didn't understand the reason/what the id is for 17:13:21 <nhnt11> Ok. 17:14:03 --> jb has joined #instantbird 17:16:51 <-- jb has quit (Ping timeout) 17:19:19 <aleth> nhnt11: Partly I wonder how with a key like that you can efficiently query for e.g. "all the entries for account x which just came online" (if that's the kind of thing you need?) 17:20:11 <nhnt11> aleth: The id isn't used for filtering 17:20:30 <aleth> I'm not referring to filtering 17:20:55 <nhnt11> A conversation's stats are mapped to its id. So when the sort comparator is called for two conversations, it uses their id's to look up their stats 17:21:01 <nhnt11> that's pretty much the main purpose of the id 17:21:14 <nhnt11> I couldn't think of a better way to uniquely identify a conversation 17:21:21 <aleth> So you only ever query for individual entries? 17:21:46 <nhnt11> it's also required to translate what we store in the cache/logs to PossibleConversation objects 17:21:48 <nhnt11> Huh? 17:22:00 <nhnt11> Right now, stats are kept in memory 17:22:36 <aleth> I think I'll wait until I've looked at your next patch, I'm probably just confusing you as I don't know your approach 17:22:54 <aleth> i.e. I'm probably confused ;) 17:22:55 <nhnt11> Yeah I think we may be talking about different things 17:23:51 <nhnt11> aleth: What I'm doing right now is mapping conversation id's to ConversationStats objects 17:24:13 <nhnt11> ConversationStats objects have message count properties and so on 17:24:23 <nhnt11> These are cached to a JSON file 17:24:36 <aleth> Ah, so things have changed already :D I'll definitely wait 17:24:56 <nhnt11> Right, I've gotten rid of IndexedDB for now 17:25:13 <nhnt11> I figured it was the best way to go for smaller patches that do fewer things 17:25:32 <aleth> Small patches definitely are a good idea. 17:25:51 <aleth> Easier to review and also easier to understand later in the hg log 17:37:34 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2817 on bug 2142. 17:37:37 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2142 enh, --, ---, aleth, ASSI, Allow tab completion of nicks which have left the room 17:42:37 --> Mic has joined #instantbird 17:42:38 * ChanServ sets mode +h Mic 17:43:52 --> flo-retina has joined #instantbird 17:43:52 * ChanServ sets mode +qo flo-retina flo-retina 17:44:19 * flo-retina is catching up with today's log (I've been in meetings all day). 17:45:12 --> gerard-majax has joined #instantbird 17:46:30 <clokep_> Mic: vaguerant had a question about location of the pop up windows you might be able to help w/, can you check the log? 17:46:33 <clokep_> (And hello! :)) 17:47:17 <-- aleth has quit (Quit: Ciao) 17:47:26 * nhnt11 wonders how to format this better: http://pastebin.instantbird.com/318782 17:47:42 <flo-retina> http://log.bezut.info/instantbird/today#m32 I don't remember anything about this. I don't see any good reason to prevent prpls from changing the time 17:48:26 <Mic> Hi 17:48:56 <nhnt11> Mic: Good evening :) 17:49:49 <flo-retina> qheaden: do we expect a reply from the server for both keep alive and pings? (On other protocols, keep alive are just some meaningless whitespace sent over the socket, and no reply/acknowledgment is expected (apart from what happens at the TCP level of course)) 17:50:15 <clokep_> flo-retina: That's not true, we get a reply for IRC PINGs. 17:51:05 --> gerard-majax_ has joined #instantbird 17:51:05 <-- gerard-majax has quit (Quit: Ex-Chat) 17:51:29 <-- flo-retina has quit (Ping timeout) 17:51:47 <qheaden> Hello everyone. 17:51:55 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 17:52:02 --> nhnt11 has joined #instantbird 17:52:47 <-- gerard-majax_ has quit (Ping timeout) 17:52:50 <qheaden> flo-retina: No, keepalive packets do not expect a reply. 17:53:47 --> dionisos has joined #instantbird 17:54:32 <nhnt11> clokep_, Mic: Do you have any suggestions on how to format this better? http://pastebin.instantbird.com/318782 17:54:44 <qheaden> Hey nhnt11. 17:54:51 * nhnt11 waves at qheaden 17:55:19 <clokep_> nhnt11: Maybe http://pastebin.instantbird.com/318783 ? 17:55:23 <clokep_> But I'm not your reviewer. ;) 17:55:38 <qheaden> clokep_: I'm going to start some work on logging packets. 17:56:03 <Mic> There's leading indentation missing, most likely? 17:57:00 --> Even has joined #instantbird 17:57:01 * ChanServ sets mode +o Even 17:57:19 <nhnt11> Mic: Here it is with the leading indentation: http://pastebin.instantbird.com/318784 17:57:26 <nhnt11> 5 tabs I think 17:57:33 <nhnt11> (2 space tabs of course) 17:57:46 <Mook_as> temporary variable? 17:58:00 <nhnt11> Ok :P 17:59:00 <nhnt11> This does look better I guess.. pastebin.instantbird.com/318785 17:59:52 <Mook_as> let stats =; 18:00:06 <nhnt11> Mook_as: stats already exists :P 18:00:57 <Mic> It definitely looks better with the temporary variable. 18:01:26 <instantbot> clokep@gmail.com denied review for attachment 2817 on bug 2142. 18:01:30 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2142 enh, --, ---, aleth, ASSI, Allow tab completion of nicks which have left the room 18:05:09 <Mic> vaguerant: do you have your taskbar at the top edge of the screen? 18:05:55 <vaguerant> Nope, at the bottom, but I use Litestep instead of Explorer, so that may be confusing it. 18:06:31 <Mic> With a default desktop, they always appear near the taskbar. 18:07:51 <qheaden> clokep_: What do you think about me adding a toString method on YahooPacket(), and I can pass the text given by that method into the LOG method? 18:08:05 <qheaden> I'm working on bug 2089 FWIW. 18:08:09 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2089 nor, --, ---, nobody, NEW, Debug logs are binary only 18:08:49 <-- Even has quit (Input/output error) 18:12:05 --> FireFly_TB has joined #instantbird 18:12:41 <Mic> vaguerant: I don't see an easy way to change the position of the popups. 18:13:25 <vaguerant> Fair enough. Thanks for the interest. 18:14:24 <nhnt11> Mic, clokep_: How often do you think the stats cache needs to be flushed to disk? 20 minutes or so? 18:14:25 --> Even has joined #instantbird 18:14:26 * ChanServ sets mode +o Even 18:15:06 <nhnt11> Actually a lot of chatting can happen in that much time, so I'm inclined to go for 10 minutes. 18:15:33 * nhnt11 thinks it may nearly be time for a new patch 18:20:07 <Mic> Make it 10 minutes if you think that's appropriate, it can still be tweaked later if there's reason for it. 18:25:35 --> gerard-majax__ has joined #instantbird 18:36:58 <qheaden> clokep_: Here is an example log message for an incoming packet with my new patch : http://pastebin.instantbird.com/318848 18:37:08 <qheaden> It is the buddy status packet. 18:37:22 <qheaden> Just let me know what you think of the format. 18:42:13 <clokep_> qheaden: OK, one second. 18:42:53 <Mook_as> can the keys repeat? (say, have two 47 keys, whatever they are)? 18:43:10 <clokep_> Mook_as: Yes. 18:43:18 <clokep_> qheaden: Adding a toString method seems the correct thing to do, yes. 18:43:42 <clokep_> qheaden: That format seems OK, I kind of wish the data in the key, value pairs lined up, but that's not a big deal. :) 18:44:18 <Mic> You could use \t's maybe? 18:44:37 <clokep_> That was my thought. ;) 18:44:44 <qheaden> That sounds good. 18:44:56 <clokep_> Are the keys in the right order? 18:45:17 <qheaden> They keys are printed in the order they were pushed into the key array. 18:45:29 <qheaden> They keys are in the same order the packet sent them. 18:45:33 <qheaden> *The 18:46:24 <clokep_> OK. :) Cool. 18:46:32 <clokep_> Want to make the logging for IRC better now? :P 18:47:02 <Mic> Adding labels for the numbers with the type of data would be difficult most likely? 18:47:05 * qheaden hides 18:47:10 <qheaden> Mic: Very. 18:47:24 <Mic> You'd seem to have a map from packet type name to the numbers already at least. 18:48:27 <clokep_> That's excessive, I think. 18:48:39 <clokep_> You don't want to slow down processing too much either. 18:48:44 <qheaden> I'd just leave the numbers for the developers to interpret. 18:49:07 <qheaden> FWIW, this is kind of how WireShark logs the packets. 18:50:17 <instantbot> nhnt11@gmail.com cancelled review?(aleth@instantbird.o rg) for attachment 2815 on bug 2066. 18:50:18 <instantbot> nhnt11@gmail.com requested review from florian@instantbird .org for attachment 2818 on bug 2066. 18:50:21 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2066 enh, --, ---, nhnt11, NEW, New conversation tab should suggest chat rooms 18:50:52 <qheaden> clokep_: Using \t, the values line up in different indentations depending on how many digits on the the key number. 18:53:37 <Mic> Strange, \t seems to be four spaces wide in my error console. One, two or three digit numbers should all lead to the same tabstop then... 18:54:32 <Mic> Scratch that, it seems to be even eight characters. 18:55:04 <qheaden> :-S 18:57:15 <qheaden> clokep_, Mic: This is my YahooPacket.toString() method - http://pastebin.instantbird.com/318889 18:57:22 <qheaden> Notice line 9 where I use \t. 18:58:16 <Mic> Looks good. 18:58:56 <qheaden> Not sure why the tabs aren't lining things up completely. 19:00:31 <-- qlum has quit (Quit: Getting the <censored> out.) 19:02:48 <qheaden> clokep_: You expected similar logging on outgoing packets right? 19:03:14 <qheaden> It seems that Socket prints binary logs by default when using sendBinaryData 19:03:49 --> qlum has joined #instantbird 19:04:32 * qheaden realizes his plug-in is the only one to make use of Socket.sendBinaryData. 19:05:24 <Mook_as> the error console isn't meant to be a text editor, don't expect tabs to do anything sensible. 19:06:33 <qheaden> Instead of having Socket.sendBinaryData do the logging, I think we should add a Socket.onBinaryDataSent callback that can be overridden to log the data. 19:06:42 <qheaden> Different protocols have different information to log. 19:06:52 --> unghost has joined #instantbird 19:07:28 <Mook_as> why wouldn't it be something like an addObserver then? 19:07:47 <instantbot> nhnt11@gmail.com cancelled feedback?(benediktp@ymail.c om) for attachment 2812 on bug 2143. 19:07:48 <instantbot> nhnt11@gmail.com requested review from aleth@instantbird.o rg for attachment 2819 on bug 2143. 19:07:52 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 19:08:03 <qheaden> Socket doesn't have any observer methods that fire I think. 19:08:13 * nhnt11 hopes that's a much better patch to review for Mic, aleth, and flo-retina :) 19:11:42 <instantbot> nhnt11@gmail.com cancelled review?(aleth@instantbird.o rg) for attachment 2819 on bug 2143. 19:11:43 <instantbot> nhnt11@gmail.com requested review from aleth@instantbird.o rg for attachment 2820 on bug 2143. 19:11:45 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 19:16:49 --> flo-retina has joined #instantbird 19:16:49 * ChanServ sets mode +qo flo-retina flo-retina 19:17:16 <flo-retina> bah, I'm again in the state where all accounts are disconnected with errors, and don't attempt to reconnect themselves automatically :( 19:18:00 <flo-retina> I saw in the log that this didn't go through: 19:18:00 <flo-retina> 19:50:18 - clokep_: flo-retina: That's not true, we get a reply for IRC PINGs. 19:18:00 <flo-retina> 19:50:33 * flo-retina had XMPP in mind 19:18:01 <flo-retina> 19:50:52 - flo-retina: clokep_: and I was thinking about _keep alive_. Pings of course expect a reply 19:18:01 <flo-retina> 19:51:23 - flo-retina: clokep_: the ping checks the server is still here. The keep alive just tell the routers in the way that the socket isn't dead and shouldn't be dropped. 19:18:51 * nhnt11 needs to go study for a quiz soon :( 19:27:03 <instantbot> nhnt11@gmail.com cancelled review?(aleth@instantbird.o rg) for attachment 2820 on bug 2143. 19:27:04 <instantbot> nhnt11@gmail.com requested review from aleth@instantbird.o rg for attachment 2821 on bug 2143. 19:27:06 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 19:27:41 <nhnt11> Ok, I have to go now 19:27:49 <qheaden> Bye nhnt11. 19:27:52 * nhnt11 had a productive day, he thinks 19:27:53 <nhnt11> Good night. 19:28:36 <-- nhnt11 has quit (Input/output error) 19:30:17 <Mic> bye 19:36:31 <flo-retina> nhnt11: btw, if you think the LIST patch may have a significant performance impact, what about adding a way to pref it off? 19:42:32 <qheaden> clokep_: I think I better create a YahooSession.sendPacket method that will not only call sendBinaryData, but will also log the outgoing packet. 19:43:33 <Mic> Bye 19:43:37 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 19:46:26 --> nhnt11 has joined #instantbird 19:48:52 <nhnt11> flo-retina: That may be a good idea. 19:49:23 <nhnt11> flo-retina: The next thing on my list is to make the getFilteredConvs api async 19:49:54 <nhnt11> That should fix the performance issues with the current patch. 19:50:19 <flo-retina> nhnt11: replacing the array passed through xpconnect by an enumerator may fix it too, with less work ;) 19:50:42 <nhnt11> flo-retina: That wouldn't speed up filtering though 19:50:55 <flo-retina> why is filtering slow? 19:51:17 <flo-retina> making it async wouldn't speed it up; it would just avoid freezing the UI 19:51:20 <nhnt11> It will be if we want to filter by statuses etc, but I just realized we'll want to do that from a database anyway 19:51:44 <nhnt11> flo-retina: Right, by speed up I mostly meant eliminate UI lag 19:51:58 <flo-retina> ok 19:53:41 <flo-retina> something I was thinking about in the train... how would you feel about taking advantage of parsing all the conversation logs to also build a full text index of them at the same time? 19:54:52 <flo-retina> how attractive is fixing bug 1584 to you? 19:54:54 <nhnt11> Should that be done in the stats service? 19:54:56 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1584 enh, --, ---, nobody, NEW, Indexed logs & efficient search 19:55:19 <nhnt11> Not very as of now, but it would be a nice thing to work on in a few weeks 19:55:29 <flo-retina> maybe not, but I don't think we should traverse the log tree twice. So the code should be the same, wherever it lives. 19:56:49 <flo-retina> would this be more attractive if I offered to write half the code with/for you? 19:58:03 <nhnt11> flo-retina: ok, I don't mind working on it 19:58:09 <nhnt11> As long as you don't mind :P 19:58:22 <flo-retina> well, you should get ranking done before that. 19:58:56 <flo-retina> but if our plan is to get the stats data stored that way, then you shouldn't worry about caching at this point, and we will do something correct with an sqlite database "soon" 19:59:42 <nhnt11> flo-retina: "stored that way" - what way? 19:59:54 <flo-retina> btw, there should also be a way to preff off the log crawling code. I suspect it could cause significant performance issues on machines with very poor disk I/O 20:00:38 <flo-retina> that way -> in an sqlite database designed not only to fetch stats about previous conversations, but also to find any string in the message contents. 20:01:06 <nhnt11> Interesting, so combine everything into one database 20:01:24 <flo-retina> well, not "everything". But all the info we gather from log files. 20:01:28 <nhnt11> Instantbird's conversations to Firefox's places 20:01:30 <nhnt11> I get it. 20:02:16 <flo-retina> nhnt11: and if we start getting ourselves familiar with full text index, we may have a solution to your searching problem about finding words in thousands of topics ;) 20:02:39 <nhnt11> :) 20:03:10 --> jb has joined #instantbird 20:03:45 <nhnt11> flo-retina: Well if this is how we want to do it, I suspect the new patch I submitted should do for now. 20:04:33 <nhnt11> It caches everything to a json file but I don't see how ranking would be useful with no caching at all. Unless you mean crawl the logs every time, which is impractical imo considering how long it took for you guys. 20:07:37 <clokep_> qheaden: No. 20:07:49 <clokep_> qheaden: Just add a second parameter to the sendBinaryData method that can take a string. 20:07:53 <clokep_> I'd be surprised if it doesn't do this already. 20:09:01 <qheaden> clokep_: It doesn't. :( 20:09:08 <flo-retina> nhnt11: I don't remember it taking more than a few seconds for me 20:09:13 <qheaden> clokep_: So the second parameter will be the log string? 20:09:22 <clokep_> qheaden: Then add one? 20:09:35 <qheaden> I am going to. 20:09:39 <nhnt11> flo-retina: You have an ssd.. it took a few minutes for aleth 20:09:55 <nhnt11> And the json caching works and is pretty simple, and I already wrote it, so why not :P 20:10:05 <flo-retina> nhnt11: he's using a network drive. That's one of the cases I mentioned where disk I/O is awfully expensive. 20:10:11 <flo-retina> nhnt11: we are at the two extremes I guess ;) 20:10:18 <nhnt11> Ah yeah I forgot about that... 20:10:24 <nhnt11> It takes about 10 seconds for me. 20:10:33 <flo-retina> your profile is new though 20:10:34 <nhnt11> Or was it 1 second.. I can't remember 20:10:38 <nhnt11> yeah. 20:11:14 <flo-retina> nhnt11: but yeah, json cache may be fine for now (my only worry is: how will we get rid of it? will it stay around in the profile forever? Will we need some code to delete it?) 20:11:48 <nhnt11> Hmm, good point 20:12:31 <flo-retina> maybe offering to write a significant part of the code wasn't a great idea; I'm not sure how much free time to spend on Instantbird I'll have in the near future. 20:13:05 <qheaden> "I'm not sure how much free time to spend on Instantbird I'll have in the near future." :( 20:13:12 <qheaden> We need you! 20:13:50 <nhnt11> This may be clokep_'s chance to take over :P 20:14:07 <qheaden> :P 20:18:46 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 20:19:40 * clokep_ has no interest in taking over. ;) 20:25:03 <qheaden> clokep_: What do you think about adding a parameter to YahooPacket.toString to denote whether or not the packet is outgoing or incoming? 20:25:38 <qheaden> That will prevent us from having to append Outgoing Packet or Incoming Packet manually each time we pass in the log message. 20:25:39 <clokep_> qheaden: Why? 20:25:50 <clokep_> You don't need to do that. 20:26:00 <clokep_> It should already be in the message. 20:26:15 <clokep_> The logging logs that it's STATUS_MESSAGE_SENDING or STATUS_MESSAGE_RECEIVING or something like that. 20:27:11 <clokep_> qheaden: Have you looked at the debug logs? It shouldn't really be necessary.... 20:27:21 <clokep_> I need to go for a few hours. 20:27:26 <clokep_> I'll be back when I get home. 20:27:28 <qheaden> Oh I see. 20:27:41 <qheaden> The onTransportStatus messages. 20:27:46 <clokep_> Yes 20:27:55 <qheaden> Okay, great. :) 20:28:02 <qheaden> OK, see you later clokep_. 20:28:07 <clokep_> Although...I think for IRC we prepend "Sending: " or something... 20:28:41 <clokep_> qheaden: Ah, the socket does that automatically: http://lxr.instantbird.org/instantbird/source/chat/modules/socket.jsm#224 20:28:51 <clokep_> So the logging for this stuff probably needs to be made a bit prettier. 20:28:55 <clokep_> For a binary prpl. 20:29:40 <qheaden> Okay. 20:29:48 <clokep_> http://lxr.instantbird.org/instantbird/source/chat/modules/socket.jsm#252 can be changed to |this.LOG("Sending binary data: <" + (aLoggedData || ArrayBufferToHexString(aData)) + ">");| 20:29:54 <clokep_> tata 20:30:00 <-- clokep_ has quit (Quit: http://www.mibbit.com ajax IRC Client) 20:32:24 <-- FireFly_TB has quit (Ping timeout) 20:33:46 <flo-retina> nhnt11, qheaden: what I meant is that I already have plans of things to do during the next week-end, and I'll spend the 2 week-ends after that traveling before/after a Talkilla work week in San Francisco. 20:34:09 <flo-retina> so the hopes of finding a rainy week-end to code plenty of stuff are low ;). 20:34:23 <qheaden> Ahh okay. :) 20:34:49 <flo-retina> (and chances of coding useful stuff during airport connection waiting times are low too, as I booked direct flights) 20:35:33 --> FireFly_TB has joined #instantbird 20:35:59 <flo-retina> and I can't really pretend I'll have plenty of free time during the evenings to code stuff, as dealing with my review queue already takes ~1 hour (or 3 sometimes) every day 20:37:30 <-- unghost has quit (Quit: Ð£Ñ Ð¾Ð¶Ñ Ñ Ð¾Ñ Ð²Ð°Ñ (xchat 2.4.5 или ÑÑаÑÑе)) 20:40:49 <qheaden> I could imagine. 20:41:27 <-- jb has quit (Ping timeout) 20:45:11 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 20:49:53 <instantbot> qheaden@phaseshiftsoftware.com requested review from clokep@gmail.com for attachment 2822 on bug 2089. 20:49:56 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2089 nor, --, ---, qheaden, ASSI, Debug logs are binary only 20:54:25 --> EionRobb has joined #instantbird 21:28:18 <-- mconley has quit (Input/output error) 21:34:17 <-- spiffytech has quit (Ping timeout) 21:38:20 --> spiffytech has joined #instantbird 21:59:04 <instantbot> florian@instantbird.org denied review for attachment 2821 on bug 2143. 21:59:07 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 22:02:08 <-- qlum has quit (Client exited) 22:11:21 <-- EionRobb has quit (Ping timeout) 22:14:06 --> EionRobb has joined #instantbird 22:33:43 --> nhnt11 has joined #instantbird 22:34:00 <nhnt11> flo-retina: It's ok to JSON.stringify on a Map? 22:34:24 <flo-retina> I don't know. 22:34:27 <flo-retina> Why is it a map? 22:34:51 <nhnt11> I guess I should make it an object. It was a Map before I switched to JSON 22:36:02 <flo-retina> if the keys all contain ',' or '/', there's no risk of conflicting with a built-in property of Object.prototype 22:36:58 <nhnt11> They all contain commas, yes. 22:43:18 <-- dionisos has quit (Ping timeout) 22:43:48 <nhnt11> flo-retina: "...if we used 'gLogParser' instead of 22:43:48 <nhnt11> this in logs of places" I don't understand what "logs of places" means 22:44:00 <flo-retina> lots 22:44:11 <nhnt11> Ah 22:44:51 <nhnt11> I prefer just using bind, but if you like using gLogParser I'll change it. 22:46:07 <flo-retina> I don't have a strong preference 22:46:39 <nhnt11> flo-retina: What do you think about having a method that takes strings for the protocol, account, and name of a conversation and returns the id? 22:46:50 <nhnt11> And should such a method be in the global scope? 22:47:15 <flo-retina> let's avoid the duplication of that code, yes 22:50:07 <nhnt11> flo-retina: I prefer using the comma separated id, but that's mostly because I wouldn't like it if conv id's looked like directory paths :P I don't really mind either though. 22:51:09 <flo-retina> my thought was that in the future we may want to have the id be a column in an sqlite table, to give us the info about where to fetch the logs 22:52:14 <nhnt11> I would think that if we had an sqlite table, it would contain our stats so we wouldn't need to look at the logs again 22:54:40 --> clokep has joined #instantbird 22:54:40 * ChanServ sets mode +o clokep 22:58:48 <flo-retina> nhnt11: We will need the logs to display them 22:58:58 <flo-retina> the index will tell us which log file contains the keyword the user searched 22:59:26 <nhnt11> Ah the logs index 23:00:12 <nhnt11> flo-retina: I'll have to take care of os specific file separators then.. 23:00:20 <nhnt11> And if we do that later, I might as well use commas :P 23:00:39 <flo-retina> '/' works on all the OSes we care about 23:03:57 <flo-retina> Good night 23:05:16 <nhnt11> Night 23:06:43 <clokep> Bye! 23:06:56 --> dionisos has joined #instantbird 23:12:37 <nhnt11> Hmm, it seems I can't use for..of on an object obtained from JSON.parse 23:12:44 <nhnt11> for..in works, as does for each..in 23:13:14 <Mook_as> you can with arrays, not objects (dictionaries) 23:13:39 <nhnt11> hmm ok 23:13:42 <nhnt11> thanks 23:20:21 <instantbot> nhnt11@gmail.com requested review from the wind for attachment 2823 on bug 2143. 23:20:24 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 23:20:48 <nhnt11> Something weird ahppened... sigh. 23:23:24 <instantbot> nhnt11@gmail.com requested review from benediktp@ymail.com for attachment 2823 on bug 2143. 23:23:31 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2143 enh, --, ---, nhnt11, NEW, Stats service should maintain statistical data for conversations and use it for sorting. 23:24:14 <instantbot> nhnt11@gmail.com cancelled review?(aleth@instantbird.o rg) for attachment 2821 on bug 2143. 23:24:58 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)