#instantbird log on 09 04 2013

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 &#147; 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 &#148; a few words after, and the phrase is "knowledge is power" :P
12:02:12 <nhnt11> I'm also seeing "today&#146;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)