#instantbird log on 07 18 2014

All times are UTC.

00:04:36 <-- mconley has quit (Input/output error)
00:05:04 --> mconley has joined #instantbird
00:06:53 <-- mconley has quit (Ping timeout)
00:15:26 --> iamjayakumars has joined #instantbird
00:17:06 <-- clokep has quit (Ping timeout)
00:17:13 --> clokep has joined #instantbird
00:17:14 * ChanServ sets mode +o clokep 
00:30:12 <-- Armada has quit (Connection reset by peer)
00:38:29 <-- iamjayakumars has quit (Client exited)
00:39:02 --> iamjayakumars has joined #instantbird
00:39:40 <-- clokep has quit (Ping timeout)
00:40:44 <-- iamjayakumars has quit (Ping timeout)
00:49:19 <-- wnayes has quit (Ping timeout)
00:49:40 --> wnayes has joined #instantbird
00:52:57 <-- Rym has quit (Ping timeout)
00:53:21 --> Rym has joined #instantbird
01:03:38 <-- Mook_as has quit (Quit: Mook_as)
01:17:41 --> iamjayakumars has joined #instantbird
01:19:32 <-- iamjayakumars has quit (Ping timeout)
01:29:01 <-- rosonline has quit (Client exited)
01:34:49 <-- Rym has quit (Ping timeout)
01:35:20 --> Rym has joined #instantbird
01:55:55 <-- Rym has quit (Connection reset by peer)
01:56:25 --> Rym has joined #instantbird
01:57:51 <-- Rym has quit (Connection reset by peer)
01:58:21 --> Rym has joined #instantbird
02:19:51 <-- Rym has quit (Ping timeout)
02:42:31 <instant-buildbot> build #2274 of macosx-nightly-default is complete: Failure [4failed hg]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2274
02:49:47 <-- wnayes has quit (Ping timeout)
02:50:07 --> wnayes has joined #instantbird
02:51:15 <-- wnayes has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
03:12:36 --> mconley has joined #instantbird
04:12:20 <-- mconley has quit (Input/output error)
04:12:48 --> mconley has joined #instantbird
04:14:38 <-- mconley has quit (Ping timeout)
04:16:01 --> mconley has joined #instantbird
04:16:56 <-- mconley has quit (Input/output error)
04:17:24 --> mconley has joined #instantbird
04:19:10 <-- mconley has quit (Ping timeout)
05:26:35 <-- EionRobb has quit (Quit: Leaving.)
05:38:31 --> mpmc has joined #instantbird
05:59:02 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
07:26:57 --> Bollebib has joined #instantbird
08:03:49 --> mayanktg-ph has joined #instantbird
08:04:21 --> gerard-majax__ has joined #instantbird
08:06:05 <-- gerard-majax__ has quit (Ping timeout)
08:06:46 --> gerard-majax__ has joined #instantbird
08:13:24 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
08:35:04 --> flo-retina has joined #instantbird
08:35:04 * ChanServ sets mode +qo flo-retina flo-retina 
08:35:33 * Fallen|away is now known as Fallen
08:44:17 <flo-retina> bug 791199 could do with an owner
08:44:21 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=791199 maj, --, ---, nobody, NEW, chat-buddy-add notification implicitly assumes that there will be no more than one observer
09:11:17 --> aleth has joined #instantbird
09:11:17 * ChanServ sets mode +o aleth 
09:13:26 * aleth is surprised that hasn't been fixed. Probably because it was reported on BMO not BIO...
09:14:18 <aleth> It's unfortunate this didn't come up a week or two ago, we could have made it for TB31.
09:16:13 <flo-retina> aleth: well...
09:16:23 <flo-retina> I don't think we would have uplifted such a change all the way to beta
09:16:44 <flo-retina> so it would have needed a fix at least a month ago to make TB31
09:16:46 <aleth> I guess not.
09:17:48 <aleth> The equivalent of conversation.xml in TB is way out of date, I wouldn't be surprised if there were a whole bunch of bugs that were fixed in IB but still in TB.
09:19:06 <aleth> Bug 790539 may be more to do with the crazy nicklist switching in TB though.
09:19:09 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=790539 nor, --, ---, nobody, NEW, Participant not always added to the list after entering IRC chat
09:19:22 <flo-retina> aleth: we never got steps to reproduce
09:19:39 <flo-retina> aleth: but my guess was that is has to do with TB potentially showing the same conversation in multiple windows at once
09:19:52 <aleth> It can do that?
09:20:05 <flo-retina> the code wasn't designed for that
09:20:08 <flo-retina> but in practice, yes it can
09:20:13 <flo-retina> you can't detach the chat tab
09:20:24 <flo-retina> but you can open a new mail window, and then open a chat tab from that new window
09:20:34 <flo-retina> and both chat tabs have a list of all the current chat conversations
09:20:40 <flo-retina> and you can select the same conversation in both chat tabs
09:20:51 <aleth> Bah, that's crazy UI.
09:21:04 <flo-retina> TB's tabs are... meh :)
09:31:27 <flo-retina> aleth: I don't think that's necessarily blocking 1.6
09:31:45 <flo-retina> blocking TB38 maybe :)
09:36:56 <aleth> flo-retina: ! would have put 1.6-wanted but the wanted flag never seems to do anything much, so...
09:37:09 <flo-retina> aleth: bah
09:37:20 <flo-retina> aleth: I query for sw:1.6
09:37:45 <flo-retina> aleth: adding a mentor to the bug may make more to find it an owner than adding a whiteboard annotation
09:38:23 <aleth> Good point.
09:38:52 --> chrisccoulson has joined #instantbird
09:39:03 <aleth> I can't actually think of any addons that would be affected, so it does seem TB-only at this point
09:39:18 <flo-retina> aleth: I'm also interested in the potential performance improvement
09:39:56 <flo-retina> although I can't really remember why I was thinking that we are QI'ing the participants too many times
09:40:26 <aleth> That comment is also quite old, I'm not sure if there weren't any changes to that since.
09:40:37 <flo-retina> I don't think we changed it
09:40:46 <flo-retina> that part of the code could use a larger rewrite
09:41:04 <flo-retina> it makes no sense to create listitems for all the 2000 participants of #ubuntu if the user never scrolls ;)
09:41:44 <aleth> Yes... we've said that for a long time ;)
09:44:27 --> Armada has joined #instantbird
09:44:56 <flo-retina> and will keep saying it for a long time until someone fixes it
09:45:32 <aleth> ...
09:45:57 <flo-retina> :-|
09:46:18 <flo-retina> aleth: it all goes in the kind of stuff I would like to try to reduce memory usage
09:46:31 <flo-retina> if I had time to actually code stuff
09:46:35 <aleth> The next time I have a solid block of time for IB, it's tab completion module time.
09:46:39 <aleth> After that...
09:46:50 <flo-retina> I'm tempted by Australis tabs :)
09:47:05 <flo-retina> or including the update stuff in the about dialog.
09:47:15 <aleth> flo-retina: It should reduce memory a bit, but maybe there would be some surprises.
09:47:35 <aleth> Positive ones I mean
09:47:36 <flo-retina> aleth: that's why I would like to start by building reproducible test cases for memory usage
09:48:09 <flo-retina> until we have that, anything we do is just guessing and waving hands at code...
09:48:23 <aleth> We should certainly go Australis at some point, to avoid superficially looking too out of date if nothing else ;)
09:48:30 <aleth> flo-retina: indeed
09:48:53 <flo-retina> aleth: the appearance of the conversation window on Windows is also very frustrating. Each time I see it I feel guilty :-(
09:49:31 <aleth> I want to take a look at Linux in the same way, after 64b builds exist
09:49:59 <aleth> Before that it's never clear how much is potentially due to the libraries.
09:50:12 <flo-retina> our appearance on Linux isn't that bad
09:50:25 <flo-retina> the participant list and some splitters look ugly
09:50:35 <aleth> Yes
09:50:36 <flo-retina> but the tab bar and the top of the window are pretty reasonable
09:51:09 <flo-retina> for the 64bit builds... we should just "make it happen"
09:51:58 <aleth> I think the uglyness I used to see around the tabs is entirely due to the library issue.
09:52:42 <aleth> flo-retina: How would you build a test case for gradual memory use growth?
09:52:56 <aleth> Size after startup doesn't seem too bad for me.
09:53:06 <flo-retina> i would look at the size after startup
09:53:16 <flo-retina> then load a conversation of a few thousand messages.
09:53:18 <flo-retina> then look at the size
09:53:34 <flo-retina> then close the window, minimize memory usage, and look at the size
09:54:01 <flo-retina> that's just a testcase for the conversation window (including the message theme and emoticon stuff)
09:54:10 <aleth> OK
09:54:27 <flo-retina> I would also like to have some test cases that go through the prpls with some fake servers (or even some fake prpls that just return pre-built messages from a file)
09:54:39 <flo-retina> that would also test jsProtoHelper and the convs service
09:55:29 <aleth> That would also help for an "IB starts up OK" xpcshell test.
09:55:35 <flo-retina> I'm not sure how difficult it would be to implement a fake IRC or XMPP server, but I suspect if the expected data is pre-defined, it should be pretty straight forward
09:55:38 <aleth> Which would be really nice to have.
09:55:51 <flo-retina> aleth: you can't have an "ib starts up OK" xpcshell test
09:55:56 <flo-retina> xpcshell doesn't load the UI
09:56:03 <flo-retina> that would be mochitests
09:56:27 <aleth> I'm sure you could get much closer to such a test than what we have at the moment though
09:56:33 <flo-retina> aleth: I think we already have some "purplexpcom is able to load libpurple" xpcshell tests
09:56:52 <flo-retina> aleth: we could get a "js-irc is able to connect" xpcshell test.
09:57:10 <flo-retina> aleth: and yes, that would help us get much closer to being confident we aren't auto-updating nightly users to a busted version
09:57:24 <aleth> I meant a test including imCore
09:58:09 <aleth> Start, js-irc connect, autojoin some channel.
10:00:50 <aleth> Ah, we do have this already like you said. http://mxr.mozilla.org/comm-central/source/chat/components/src/test/test_accounts.js
10:02:02 <flo-retina> aleth: I was thinking about https://hg.mozilla.org/users/florian_queze.net/purple/file/956f01125ef6/purplexpcom/src/test/test_purplexpcom.js
10:03:31 <-- aleth has quit (Ping timeout)
10:14:00 <instant-buildbot> build #1450 of win32-nightly-default is complete: Success [3build successful]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1450
10:19:32 --> clokep has joined #instantbird
10:19:33 * ChanServ sets mode +o clokep 
10:19:45 <-- Bollebib has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
10:20:07 <flo-retina> hmm, we are losing the windows slave now? :-S
10:21:19 <-- clokep has quit (Ping timeout)
10:24:45 --> BWMerlin has joined #instantbird
10:26:47 --> clokep has joined #instantbird
10:26:47 * ChanServ sets mode +o clokep 
10:35:34 --> aleth has joined #instantbird
10:35:35 * ChanServ sets mode +o aleth 
10:40:10 <flo-retina> aleth: would be nice to have memory tests for LIST and the stats service too :)
10:45:30 <-- clokep has quit (Ping timeout)
10:54:30 --> CAKCy has joined #instantbird
11:12:46 --> mpmc has joined #instantbird
11:23:51 --> BillBinkley has joined #instantbird
11:24:40 --> clokep_work has joined #instantbird
11:24:40 * ChanServ sets mode +o clokep_work 
11:40:55 <-- nhnt11 has quit (Ping timeout)
11:40:59 --> nhnt11 has joined #instantbird
11:41:46 <-- Tonnes has quit (Connection reset by peer)
11:55:18 <-- BWMerlin has quit (Quit: BWMerlin)
12:07:27 --> rosonline has joined #instantbird
12:29:56 --> iLobster has joined #instantbird
12:30:05 <iLobster> Greetings
12:30:42 <iLobster> Anyone else have problems with last windows nightly?
12:33:11 <aleth> ^^ clokep_work
12:33:25 --> Bollebib has joined #instantbird
12:33:25 <aleth> What kind of problems?
12:33:30 <iLobster> It crashing right on start mentioning MSVCR100.dll in error deails
12:41:31 <clokep_work> aleth: I'm not running nightlies, the passwords don't work.
12:41:50 <aleth> MSVCR100.dll sounds pretty standard
12:42:09 <aleth> Not obviously related to the recent MOZ_MEDIA_NAVIGATOR=1
12:42:58 <iLobster> well, it's all what windows events error can say about it
12:44:10 <iLobster> and yesterday's nightly work fine
12:45:49 <aleth> Yesterdays? Are you sure?
12:46:43 <aleth> We didn't change anything yesterday, though there may have been m-c changes.
12:47:04 <aleth> Thanks for letting us know.
12:48:26 <iLobster> yes, yesterday's build is working fine, i've just downloaded it from nightly ftp, version 1.6a1pre (20140717041947)
12:49:46 <aleth> OK, sounds like a new regression :(
13:02:39 <clokep_work> aleth: Generally that just means we missed a packaging change or something.
13:08:25 <-- Bollebib has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
13:43:23 <flo-retina> iLobster: can you check if today's nightly works? If it does then your crash was an update that failed.
13:43:44 <flo-retina> iLobster: I'm asking because the log of the build does contain the msvcr100.dll file.
13:53:05 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
13:58:22 --> rosonline has joined #instantbird
14:05:44 <-- mpmc has quit (Connection reset by peer)
14:20:35 --> mconley has joined #instantbird
14:25:18 <-- aleth has quit (Ping timeout)
14:31:35 --> flo-thinkpad has joined #instantbird
14:32:12 <flo-thinkpad> iLobster: actually, I can probably check here if the latest nightly works on my Windows7 machine
14:32:15 <-- flo-thinkpad has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
14:32:24 --> flo-thinkpad has joined #instantbird
14:32:59 <-- flo-thinkpad has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
14:36:31 <iLobster> I too checked on my thinkpad, same error
14:37:06 <flo-retina> doesn't start, and no error on my machine :-/
14:37:44 <flo-retina> I don't have time to "play" with that now :(
14:40:31 <flo-retina> Ithink I've stopped the auto updates
15:10:22 <-- gerard-majax__ has quit (Ping timeout)
15:10:22 --> aleth has joined #instantbird
15:10:22 * ChanServ sets mode +o aleth 
15:12:56 <-- rosonline has quit (Client exited)
15:15:36 <aleth> mayanktg-ph: How is it going?
15:16:45 <aleth> sawrubh: Any progress with the Filelink problems?
15:17:42 <aleth> Just a heads-up that there's less than a month of gsoc time remaining. You really have to get your patches landed asap, because there will usually be regressions and problems you only discover after...
15:18:45 --> mayanktg has joined #instantbird
15:21:22 * clokep_work thought he had patches to review...
15:21:26 <clokep_work> But apparently I don't. :)
15:21:46 <flo-retina> you can take mine if you are bored :)
15:21:57 <mayanktg> aleth: Hi! I have made most of the changes. I know its difficult to change things later. I'll try to complete and update the video call patch by tomorrow. :)
15:23:07 --> rosonline has joined #instantbird
15:24:05 <aleth> mayanktg: Ask if you have any questions about the regex stuff etc
15:26:52 <sawrubh> aleth: right now I'm not clear about how to go about debugging it, last time I tried printing the arguments that being sent to auth and they match the ones being sent in TB (and it works perfectly in TB)
15:27:19 <sawrubh> aleth: clokep said he'll take a look and I had emailed the patch to him, I don't have any ideas to proceed besides that
15:28:36 <-- mayanktg-ph has quit (Quit: )
15:29:26 <-- rosonline has quit (Connection reset by peer)
15:30:04 --> Rym has joined #instantbird
15:30:56 <aleth> sawrubh: clokep_work is the expert on oauth stuff, but you could try using Wireshark to look at what is actually going out and being received
15:32:19 --> rosonline has joined #instantbird
15:34:09 <clokep_work> sawrubh: Btw me saying I'd take a look doesn't mean you shouldn't be thinking baout it still. ;)
15:38:06 * sawrubh will take a look at Wireshark
15:38:20 <sawrubh> so strike1, file transfer doesn't interoperate
15:38:31 * sawrubh goes to investigate what's happenin
15:38:56 <aleth> sawrubh: Are you using mayanktg's capabilities patch?
15:39:09 <sawrubh> aleth: no
15:39:16 <aleth> If you don't advertise you can file transfer, it can't work ;)
15:39:20 <sawrubh> ah
15:40:06 <sawrubh> but Pidgin just keeps on waiting, shouldn't it tell me that the other client doesn't support file transfer (because I didn't advertise my capability)
15:40:19 <clokep_work> sawrubh: Might want to do that as a separate patch, unless you want to go through major reviews again.
15:40:21 <aleth> I can't debug it for you, there may be other issues ;)
15:40:58 <sawrubh> clokep_work: so if I just address your comments and upload a patch, can we land it? (makes a pretty face)
15:41:43 <sawrubh> because I don't see anything else blocking it
15:44:14 <clokep_work> sawrubh: Do you really think I can answer that /before/ I review it?
15:44:38 <clokep_work> Also, didin't I say we need to discuss those error flags?
15:44:42 <aleth> patches generally land when they are r+ ;)
15:44:58 <sawrubh> I just wanted to confirm if there's anything you feel is left that's blocking us
15:45:15 <sawrubh> (not that a review is not required)
15:45:31 <aleth> If it can't talk to Pidgin, I suspect there may be unresolved issues somewhere
15:45:46 <aleth> Assuming Pidgin supports IBB
15:46:06 * Fallen is now known as Fallen|away
15:46:16 <sawrubh> but if we're fine with tackling that in a followup bug, is what I was asking
15:46:45 <sawrubh> clokep_work: http://log.bezut.info/instantbird/140717/#m448
15:47:22 <sawrubh> we can discuss it now, if you and aleth (and probably flo are free)
15:49:14 <clokep_work> sawrubh: It is up to YOU to drive that discussion, not me.
15:49:51 <sawrubh> ok, so I think aleth's point makes sense in that the user might not care if the error happened in the open, close, read or write
15:50:18 <sawrubh> they can be happy knowing it failed in I/O and for the backend, it should be good enough if we don't completely fail
15:50:47 <sawrubh> so I think we should remove the separate error flags and make them probably a single ERROR_IO or something
15:51:18 <aleth> My actual point was that you should check what FX does for UI errors in Downloads, and what error input the download panel expects. And that this was likely all premature because I doubt you have looked at the Download panel yet and so you should focus on the backend error handling not the UI.
15:53:29 <-- clokep_work has quit (Ping timeout)
15:56:45 * sawrubh doesn't find anything in http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/components/jsdownloads/public/mozIDownloadPlatform.idl
15:56:53 * sawrubh goes to find in the .jsm's
15:58:55 <-- nhnt11 has quit (Ping timeout)
16:00:05 --> nhnt11 has joined #instantbird
16:01:57 --> gerard-majax__ has joined #instantbird
16:06:05 --> clokep_work has joined #instantbird
16:06:05 * ChanServ sets mode +o clokep_work 
16:06:24 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
16:06:37 <clokep_work> sawrubh: Did you look at what we do for prpl Accounts errors?
16:07:16 * sawrubh takes a look
16:10:16 --> rosonline has joined #instantbird
16:13:59 <sawrubh> I see a bunch of flags (like multiple flags for CERT errors similar to various flags we have for I/O errors), atleast that's what I see in prplIAccount
16:14:07 * sawrubh goes to check the implementation
16:19:53 <-- aleth has quit (Ping timeout)
16:21:49 --> aleth has joined #instantbird
16:21:49 * ChanServ sets mode +o aleth 
16:22:17 <-- mayanktg has quit (Ping timeout)
16:22:54 --> mayanktg has joined #instantbird
16:24:47 <sawrubh> well I've seen https://mxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#53
16:25:36 <sawrubh> I'm not sure what I should have learnt but what I think I learnt is that prplIAccount handles bad certificate errors in a pretty fine grained manner
16:26:37 <clokep_work> I'm talking about how it separates different strings and error types.
16:27:07 --> ogi has joined #instantbird
16:40:36 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
16:41:02 --> Mook_as has joined #instantbird
16:42:28 --> rosonline has joined #instantbird
16:44:07 <-- gerard-majax__ has quit (Ping timeout)
16:45:13 <sawrubh> ok, so this is what I found (and where I got stuck)
16:45:33 <-- mayanktg has quit (Ping timeout)
16:45:51 --> mayanktg has joined #instantbird
16:46:58 <sawrubh> I started to investigate the CERT errors since they seemed to be fine grained, so going bottom to up: CERT errors are handled in https://mxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#53 which is called by https://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#199 and that is called only once at
16:46:58 <sawrubh> https://mxr.mozilla.org/comm-central/source/chat/modules/socket.jsm#510
16:47:53 <sawrubh> now in order to find out how it separates strings and error types, I need to investigate...nvm, I think I found it
16:57:13 <aleth> sawrubh: http://dxr.mozilla.org/mozilla-central/source/toolkit/components/jsdownloads/src/DownloadCore.jsm#186
17:02:10 <-- mayanktg has quit (Ping timeout)
17:03:03 --> mayanktg has joined #instantbird
17:05:06 <sawrubh> continuting my search in prplIAccount, I ended up at https://mxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/src/NSSErrorsService.cpp#165 which then gets an ID from https://mxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/src/nsNSSErrors.cpp#18 and then fetches the string from the bundle
17:05:36 <sawrubh> I'm looking for the bundle now, but by now I think there would be one error string for all the CERT error types
17:05:46 <sawrubh> let's find the final piece in this puzzle
17:06:30 <clokep_work> sawrubh: Didn't I say already NOT to follow the cert stuff. :-\
17:07:24 <aleth> The CERT stuff is very complicated.
17:07:31 <sawrubh> in order to find how it separates the actual error string from the error types, I thought I had to look at this
17:07:49 <clokep_work> We're not interested in how those strings are generated, we're interested in how they're passed to the UI.
17:07:50 <aleth> I gave you a more pertinent link ;)
17:07:53 <clokep_work> You're following it in the wrong direction.
17:07:54 <sawrubh> only then I would be able to understand how it abstracts or doesn't abstract the actual error string shown to the user
17:08:02 <clokep_work> aleth: No, you didn't.
17:08:03 <clokep_work> That's unrelated.
17:08:11 <aleth> I don't think so.
17:08:24 <aleth> But I do think all this is premature.
17:08:39 <sawrubh> aleth: your link is about FX's Downloads Panel, clokep_work asked me to take a look at prplIAccount
17:08:51 <clokep_work> sawrubh: I think you should look at https://mxr.mozilla.org/comm-central/source/chat/protocols/irc/irc.js#1639
17:09:14 <clokep_work> I think.
17:09:42 <aleth> If you plan to use the Download panel as the UI, then it helps to see how it handles errors ;)
17:09:55 <clokep_work> sawrubh: Well regardless, what it comes down to is I don't think we need all those different file errors.
17:09:59 <clokep_work> I'd add one generic one.
17:10:04 <aleth> Right.
17:10:07 <clokep_work> aleth: Ah, possibly.
17:10:10 <sawrubh> I *totally* agree
17:11:24 * sawrubh goes to remove 'em flags and add a generic error flag
17:11:36 <sawrubh> that shall be called ERROR_IO *drumrolls*
17:12:11 <aleth> Never mind, no doubt you learnt something by looking at all this code...
17:13:33 <clokep_work> sawrubh: FILE_IO please.
17:13:36 <clokep_work> There's lots of IO. :-D
17:13:47 <sawrubh> ERROR_FILE_IO it shall be then
17:14:05 <clokep_work> aleth: If we have to change the error stuff when integrated in the download panel, that's fine by me. ;)
17:14:12 <clokep_work> sawrubh will just have the pleasure of rewriting code. :-D
17:14:27 <sawrubh> -_-
17:15:58 <-- Mook_as has quit (Input/output error)
17:19:49 --> Mook_as has joined #instantbird
17:20:50 <sawrubh> "/* Error during file I/O of the file involved in the file transfer. */" is the comment explaining ERROR_FILE_IO
17:21:06 * sawrubh thinks he can do better, probably remove the second file word
17:21:13 <sawrubh> thoughts?
17:22:09 <nhnt11> sawrubh: "I/O error encountered during file transfer"? 
17:22:23 <sawrubh> that certainly sounds better
17:22:55 <sawrubh> but I wanted to include file before I/O because there are multiple types of I/O
17:23:07 <sawrubh> but then it becomes too much 'file' in a sentence
17:23:29 <sawrubh> bah, I go with what you suggested
17:25:21 <clokep_work> sawrubh: "File I/O error was encountered."
17:25:35 <clokep_work> You don't need file transfer in there, it's obvious it's during a file transfer, it's in the prplIFileTransfer interface!
17:25:44 * sawrubh goes with clokep_work since he's the reviewer
17:25:45 <aleth> "File I/O error" ;)
17:25:56 * aleth hides
17:28:43 --> gerard-majax__ has joined #instantbird
17:28:48 <-- ogi has quit (Ping timeout)
17:28:56 <sawrubh> clokep_work: so for the time being, I show a systemMessage saying "FileTransfer Complete", it's not being fetched from a properties file, are we cool with that (since it's just temporary)
17:29:26 <sawrubh> we'll anyway move to using a Downloads Panel instead of showing a system message
17:30:18 <clokep_work> sawrubh: How about "File transfer of %s complete!"
17:30:24 <clokep_work> Where %s is the file name.
17:30:27 <-- gerard-majax__ has quit (Ping timeout)
17:30:42 <sawrubh> I could do that
17:31:53 <sawrubh> also right now when you send say 2 files, you get asked twice about accepting each of it, that sounds fine?
17:32:04 <sawrubh> (I just tested and multi-file transfer works sweetly)
17:32:47 <aleth> Yes
17:32:54 <sawrubh> cool
17:33:03 <aleth> Sounds like it works well :)
17:41:45 --> mpmc has joined #instantbird
17:48:49 <-- aleth has quit (Ping timeout)
17:49:00 <clokep_work> sawrubh: Yes, that's reasonable for now!
17:57:40 <clokep_work> sawrubh: Btw once we land that I'll probably add DCC support.
18:10:30 <-- mayanktg has quit (Ping timeout)
18:10:51 --> mayanktg has joined #instantbird
18:15:39 <-- clokep_work has quit (Ping timeout)
18:17:17 <-- mayanktg has quit (Ping timeout)
18:17:48 --> mayanktg has joined #instantbird
18:26:15 * Fallen|away is now known as Fallen
18:29:43 <-- mayanktg has quit (Client exited)
18:33:30 --> mayanktg has joined #instantbird
18:38:51 --> clokep_work has joined #instantbird
18:38:51 * ChanServ sets mode +o clokep_work 
18:38:56 <-- mayanktg has quit (Ping timeout)
18:39:15 --> mayanktg has joined #instantbird
18:40:15 <-- rosonline has quit (Ping timeout)
18:43:50 * sawrubh had just realized he hadn't handled and error case of ignoring the transfer and closing it when an out of sequence data packet comes and is adding that
18:45:20 --> rosonline has joined #instantbird
18:46:46 <clokep_work> sawrubh: Also do you have to handle things during shut down?
18:47:02 <-- rosonline has quit (Ping timeout)
18:47:04 --> rosonline has joined #instantbird
18:49:18 <-- clokep_work has quit (Ping timeout)
18:51:04 <sawrubh> clokep_work: no
18:51:44 <sawrubh> what the spec says is to wait for the other guy to acknowledge your desire to close the transfer and until you get the ack, sender isn't supposed to consider it closed
18:53:01 <sawrubh> this is to prevent any data that the receiver might still have left to send
18:53:56 <sawrubh> since IBB supports BiDirectionality
18:54:44 <sawrubh> but in my implementation, each transfer is key'ed by the sessionId, and the sessionId of the transfer where the receiver is sending is different from the one which the sender wants to close
18:54:51 <sawrubh> hence I don't need to wait for the ack
18:55:07 <sawrubh> and hence, no I don't have to handle things during shut down
19:02:03 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
19:27:08 --> flo-retina has joined #instantbird
19:27:08 * ChanServ sets mode +qo flo-retina flo-retina 
19:30:42 --> Tonnes has joined #instantbird
19:34:09 <-- mayanktg has quit (Ping timeout)
19:35:56 --> mayanktg has joined #instantbird
19:36:18 --> Hadi has joined #instantbird
19:37:44 <-- CAKCy has quit (Quit: Have a great day everyone!)
19:40:57 <-- mayanktg has quit (Ping timeout)
19:41:58 --> mayanktg has joined #instantbird
19:43:39 <-- mayanktg has quit (Ping timeout)
19:44:04 --> mayanktg has joined #instantbird
19:47:34 <-- mayanktg has quit (Ping timeout)
19:48:18 --> mayanktg has joined #instantbird
19:54:28 <-- mayanktg has quit (Ping timeout)
19:55:23 --> mayanktg has joined #instantbird
19:55:51 <-- Tonnes has quit (Ping timeout)
19:58:51 <-- mayanktg has quit (Ping timeout)
19:59:38 --> mayanktg has joined #instantbird
20:01:48 <-- iLobster has quit (Quit: ChatZilla [Firefox 30.0/20140605174243])
20:04:48 <-- mayanktg has quit (Ping timeout)
20:05:53 --> mayanktg has joined #instantbird
20:10:21 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
20:11:04 <-- mayanktg has quit (Ping timeout)
20:12:01 --> mayanktg has joined #instantbird
20:13:47 <-- mayanktg has quit (Ping timeout)
20:14:54 --> mayanktg has joined #instantbird
20:16:35 <-- mayanktg has quit (Ping timeout)
20:19:33 --> mayanktg has joined #instantbird
20:21:16 <-- mayanktg has quit (Ping timeout)
20:22:41 --> mayanktg has joined #instantbird
20:24:26 <-- mayanktg has quit (Ping timeout)
20:25:19 --> mayanktg has joined #instantbird
20:28:43 <-- mayanktg has quit (Ping timeout)
20:29:23 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died)
20:29:40 --> mayanktg has joined #instantbird
20:29:42 --> chrisccoulson has joined #instantbird
20:33:11 --> mpmc has joined #instantbird
20:34:27 <-- mayanktg has quit (Ping timeout)
20:34:47 --> mayanktg has joined #instantbird
20:36:31 <-- mayanktg has quit (Ping timeout)
20:37:22 --> mayanktg has joined #instantbird
20:39:03 <-- mayanktg has quit (Ping timeout)
20:39:29 --> mayanktg has joined #instantbird
20:44:42 <-- mayanktg has quit (Ping timeout)
20:45:03 --> mayanktg has joined #instantbird
20:50:25 <-- mayanktg has quit (Ping timeout)
20:51:14 --> mayanktg has joined #instantbird
20:58:45 <-- mayanktg has quit (Ping timeout)
21:02:40 --> EionRobb has joined #instantbird
21:04:56 --> mayanktg has joined #instantbird
21:06:55 <-- Mook_as has quit (Quit: Mook_as)
21:09:16 <-- mayanktg has quit (Ping timeout)
21:10:10 --> mayanktg has joined #instantbird
21:18:27 <-- mayanktg has quit (Ping timeout)
21:19:13 --> mayanktg has joined #instantbird
21:23:36 <-- mayanktg has quit (Ping timeout)
21:25:31 --> mayanktg has joined #instantbird
21:30:30 <-- mconley has quit (Input/output error)
21:33:13 --> Tonnes has joined #instantbird
21:34:04 <-- mayanktg has quit (Ping timeout)
21:35:55 --> mayanktg has joined #instantbird
21:43:54 <-- mayanktg has quit (Ping timeout)
21:48:49 --> Bollebib has joined #instantbird
21:50:00 --> mayanktg has joined #instantbird
21:51:12 <-- Bollebib has quit (Client exited)
21:51:43 <-- mayanktg has quit (Ping timeout)
21:52:02 --> BWMerlin has joined #instantbird
21:52:19 --> mayanktg has joined #instantbird
21:54:54 <-- mayanktg has quit (Ping timeout)
21:55:15 --> mayanktg has joined #instantbird
21:58:28 --> mconley has joined #instantbird
22:06:57 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
22:13:40 <-- mconley has quit (Input/output error)
22:14:08 --> mconley has joined #instantbird
22:15:54 <-- mconley has quit (Ping timeout)
22:18:38 <-- mayanktg has quit (Ping timeout)
22:18:38 <-- Rym has quit (Ping timeout)
22:20:14 --> Rym has joined #instantbird
22:21:06 * Fallen is now known as Fallen|away
22:28:47 --> mayanktg has joined #instantbird
22:30:28 <-- mayanktg has quit (Ping timeout)
22:30:55 --> mayanktg has joined #instantbird
22:37:15 <-- BillBinkley has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
22:43:00 <-- mayanktg has quit (Ping timeout)
22:43:56 --> mayanktg has joined #instantbird
22:59:24 --> clokep has joined #instantbird
22:59:25 * ChanServ sets mode +o clokep 
23:04:02 <clokep> sawrubh: You totally have to handle things on shutdown.
23:04:15 <clokep> You need to send a message canceling the transfer, I assume.
23:04:22 <clokep> And possible clean up references in your objects to files.
23:04:33 <clokep> E.g. canceling any pending writes/reads.
23:08:05 <clokep> sawrubh: Can transfer continue after a reconncetion? If not you have to clear the list
23:10:25 <-- Armada has quit (Connection reset by peer)
23:32:46 <-- mayanktg has quit (Ping timeout)