#instantbird log on 09 01 2013

All times are UTC.

00:39:43 <-- dionisos has quit (Ping timeout)
01:38:15 --> dew1 has joined #instantbird
01:39:22 <-- dew has quit (Ping timeout)
02:20:59 --> mconley has joined #instantbird
03:08:18 <-- EionRobb has quit (Quit: Leaving.)
03:17:11 <-- mconley has quit (Input/output error)
04:02:29 --> mconley has joined #instantbird
04:26:10 <instant-buildbot> build #969 of macosx-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/969
04:45:25 <-- mconley has quit (Input/output error)
04:47:29 <instant-buildbot> build #957 of linux-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/957
04:48:10 --> mconley has joined #instantbird
05:07:15 <-- mconley has quit (Input/output error)
05:37:58 --> EionRobb has joined #instantbird
05:59:27 --> eson57 has joined #instantbird
06:07:41 <eson57> Good morning guys! Just want to draw your attention to the fact that there is something wrong with translation build bot.
06:07:41 <eson57> "compile failed" is the message...
06:07:41 <eson57> http://buildbot-l10n.instantbird.org/builders/translate/builds/697/steps/compile/logs/stdio
06:08:39 <-- eson57 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
06:08:55 --> eson57 has joined #instantbird
06:11:49 <-- eson57 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
06:27:12 --> dionisos has joined #instantbird
07:21:36 <instant-buildbot> build #1056 of win32-nightly-default is complete: Failure [failed compile]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1056
07:31:15 --> nhnt11 has joined #instantbird
08:35:54 --> eson57 has joined #instantbird
09:09:23 <-- eson57 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
10:10:30 <-- flo-retina has quit (Connection reset by peer)
10:10:32 --> flo-retina has joined #instantbird
10:10:32 * ChanServ sets mode +qo flo-retina flo-retina 
10:14:58 <-- EionRobb has quit (Quit: Leaving.)
10:27:21 --> qlum has joined #instantbird
11:41:33 --> rosonline has joined #instantbird
11:54:29 --> clokep has joined #instantbird
11:54:30 * ChanServ sets mode +o clokep 
12:34:14 <-- nhnt11 has quit (Ping timeout)
12:40:48 <-- rosonline has quit (Client exited)
12:57:11 <-- clokep has quit (Ping timeout)
14:19:59 --> aleth has joined #instantbird
14:19:59 * ChanServ sets mode +h aleth 
14:54:02 --> nhnt11 has joined #instantbird
14:55:03 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
14:55:51 --> nhnt11 has joined #instantbird
14:56:38 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
15:06:11 --> Mnyromyr has joined #instantbird
15:54:30 --> nhnt11 has joined #instantbird
15:54:44 * nhnt11 has been seeing NickServ messages today
15:59:56 <aleth> nhnt11: I guess you know this, but you can't assume all chatrooms will be found by LIST (eg passworded ones, or protocols which don't have a LIST equivalent, or no implemented one)
16:00:35 <nhnt11> aleth: I do, are you referring to the ranking patch?
16:00:43 <aleth> Yes
16:03:07 <aleth> Btw I think you're right that chatrooms we can join should be status=available for the purpose of sorting (or maybe unavailable if we want to give preference to all online contacts)
16:04:00 <nhnt11> aleth: It works well with status unknown. That way, if they have a stats score, then that will be used to sort. Otherwise, they'll end up at the bottom as they are now.
16:04:15 <aleth> But status unknown is below offline contacts
16:05:12 <aleth> I guess that kind of tweaking can be left for a followup...
16:05:38 <aleth> Maybe what you have now is exactly what is wanted
16:05:40 <-- nhnt11 has quit (Ping timeout)
16:06:48 --> nhnt11 has joined #instantbird
16:07:40 <nhnt11> aleth: Yeah I figure this will need followups to get the sorting perfect
16:08:11 <nhnt11> The scoring algorithm works pretty well as of now, I'm not sure how much tweaking it will require.
16:08:43 <aleth> None if you're lucky, but I'd expect edge cases
16:11:17 <nhnt11> aleth: I wonder if loading chat rooms from the indexed db could be a follow up too, along with non-contact buddies
16:11:37 <nhnt11> Both will require similar work
16:12:22 <aleth> Sounds OK, as long as the underlying structure is sound so you don't have to rewrite everything to allow it
16:12:53 <nhnt11> aleth: Some rewriting may be required, but not on the database side.
16:13:04 <aleth> I like your db name :P
16:13:18 <nhnt11> :P
16:13:29 <nhnt11> I realized a few minutes ago I forgot to change it before uploading a patch
16:13:41 <nhnt11> I kept adding random letters to force the db to rebuild while testing :P
16:15:09 <nhnt11> Hmm, I see the onupgradeneeded function has some unnecessary code that probably doesn't work very well either.
16:17:09 <aleth> You might want to add a mechanism to force-rebuild (eg via a pref that is read on restart)
16:18:25 <nhnt11> Good idea
16:25:51 <nhnt11> I wonder if I could just set the prototype of stats to ConversationStats.prototype at line 183, instead of a new ConversationStats object
16:30:21 <aleth> How do you handle the change in the id of a contact whenever the preferredaccountbuddy changes?  this._id = buddy.normalizedName + buddy.preferredAccountBuddy.account.name + buddy.protocol.id.replace(/^prpl-/, "");
16:31:01 <aleth> Do you really need the regex here (slow)?
16:31:56 <aleth> Why such a long id in the first place?
16:36:03 <aleth> This code needs more comments :-/
16:36:11 <nhnt11> aleth: Right, I'm working out a mechanism a contact's id is not based on the preferred buddy, and the preferred buddy with the highest score is used at sort time
16:36:29 <nhnt11> aleth: Yeah, you may not want to give this a closer look until I get a patch up with comments in it
16:37:24 <aleth> You probably want to add the scores of all the buddies merged into a contact
16:38:09 <nhnt11> Yeah ok, makes sense
16:39:14 <aleth> I mean, who cares if I don't talk often to nhnt12 if I talk a lot to nhnt11, but nhnt12 is online, etc
16:40:18 <nhnt11> Yeah
16:41:21 <aleth> The only reason you need to keep separate stats for the subbuddies is in case they get de-merged I suppose
16:41:42 <nhnt11> Yep. Or merged with another contact, or something
16:41:55 * aleth wonders if there are buddy-merged notifications yet
16:42:17 <nhnt11> I suppose slice("prpl-".length) would be better than replacing the regex..
16:42:30 <aleth> Either slice or just keep the prpl-, who cares
16:42:47 <nhnt11> aleth: The prpl- is cut off in the logs
16:42:50 <aleth> But I do wonder why the id really needs to be that long and complicated
16:43:06 <nhnt11> The reason I'm using that format for the id's is so that it's easy to get the id from parameters in the logs
16:43:40 <nhnt11> Also I need to join the separate parts with a delimiter rather than just concatenating, that will be done in the next patch
16:44:03 <aleth> Another way would be to have a function you can call that returns the id
16:44:30 <aleth> I'm sure you've thought this through, but I don't understand it atm
16:44:50 <nhnt11> aleth: I'll be sure to add comments for the next patch
16:45:02 <nhnt11> This patch took more thinking time than coding time :-/
16:46:22 <aleth> That often happens for new features ;)
16:47:59 * nhnt11 is in a friend's room and misses his monitor
16:48:42 <aleth> Maybe you decided to leave it for later, but I'm surprised you still use filter() on the whole list of entries, and then sort(), rather than a DB query of some sort
16:48:56 <aleth> Wouldn't the latter be faster?
16:49:15 <aleth> (in getFilteredConvs)
16:49:24 <nhnt11> aleth: Yeah, I left that for later because it's async, so it'll require me to make the getFilteredConvs process async too
16:49:37 <nhnt11> Also the next patch should get rid of the sort() there.
16:49:40 <aleth> OK, maybe add a TODO in a comment
16:50:21 <aleth> We'll also hope for a better filterFn ;)
16:51:05 <nhnt11> aleth: Btw, filtering an existing list is probably faster than querying the DB
16:51:36 <aleth> Have you tried a simple testcase to find out?
16:51:36 <nhnt11> Yep better filtering will be a followup of high priority
16:52:05 <nhnt11> No I haven't, I'm just guessing considering that the array here is already in memory :)
16:52:10 <aleth> "IndexedDB is an API for client-side storage of significant amounts of structured data and for high performance searches on this data using indexes."
16:52:30 <aleth> You may be right, but on the other hand they have already optimized searches ;)
16:53:05 <nhnt11> aleth: Right, but when you have the same data already sorted in memory, I would think filtering the data in memory would be faster than db operations..
16:53:06 <aleth> How does the awesomebar do the searching?
16:53:35 <aleth> nhnt11: It's possible, but it depends on how quick the filterfn is which gets rerun every single time.
16:54:03 <aleth> i.e. it depends on how well the data can be indexed.
16:55:51 <aleth> Just to be clear, I don't think this kind of thing blocks landing ranking
16:56:17 <aleth> But it should be at the back of the mind so the design doesn't block you in the future
16:56:28 <nhnt11> aleth: It definitely is.
16:56:50 <nhnt11> aleth: I need to discuss my schedule the next 2 weeks 
16:56:54 <nhnt11> er let me finish that
16:57:05 * aleth hopes Mic will return soon :D
16:57:17 <nhnt11> I need to discuss my schedule the next 3 weeks with you and Mic and flo-retina and clokep when all of you are around
16:59:31 <nhnt11> I want to get the project to a state where it meets the requirements of my proposal, and then focus on my first test (sept. 14th) after which I can return my focus to follow ups and so on.. so I basically need to discuss the meaning of "meets the requirements of my proposal"
17:00:05 <aleth> Right.
17:00:31 <aleth> You should definitely not cut corners in your university work because of gsoc.
17:00:37 * nhnt11 does not want to fail his final evaluation, but nor does he want to fail college tests :S
17:01:29 <aleth> I doubt there'll be a problem as long as it's discussed in advance ;)
17:02:37 <aleth> There's another discussion which will happen eventually, namely "what needs to be done before the next IB release" assuming we want the awesometab to be in it :)
17:02:53 <nhnt11> Perhaps I should write an email to team@ib on this...
17:03:00 <nhnt11> I think that's a safe assumption :D
17:03:31 <aleth> Feel free to send an email - I'm sure they'll see it in the logs but I don't know how long Mic is away for so an email sounds good
17:04:38 <aleth> The ranking results were pretty cool based on the addon so that part seems to work well alread
17:06:02 <aleth>     let file = Services.dirsvc.get("ProfD", Ci.nsIFile);
17:06:02 <aleth>     file.append("logs");
17:06:02 <aleth>     this._logsPath = file.path;
17:06:02 <aleth> Is that really how we get the log path in the existing code?!
17:06:42 <nhnt11> aleth: I'm not sure, flo wrote that bit and I didn't change it.
17:06:59 <aleth> Yeah, but if it was for an add-on it might have been a quick hack
17:07:11 <aleth> Look for the code in the logger
17:07:16 <nhnt11> Alright.
17:08:47 <aleth> I mean, that might be the right code, but isn't there an API?
17:09:47 <aleth> How do you handle system files, hidden files etc in this patch?
17:10:07 <nhnt11> aleth: They're just skipped
17:10:19 <aleth> Is that the big try-catch in sweepLogFolder?
17:10:31 <nhnt11> Yeah.. kinda hacky
17:11:05 <nhnt11> aleth: I'll improve the log reading code, don't worry :)
17:11:06 <aleth> You probably want to log skipped files/dirs to the error console as warnings
17:11:57 <aleth> Errors only if you guess there was a real problem
17:12:39 <aleth> "sweeping log files" should be more explicit (sweeping means what, and for what?)
17:14:06 <nhnt11> aleth: I'm not sure if there's a better way than that huge try-catch to detect bad log files
17:14:11 <aleth> Can you include folders with only txt logs in the results (maybe with a low stats score, but lets not pretend they dont exist)
17:14:29 <nhnt11> Ok. I have no idea how they're formatted though
17:14:36 <nhnt11> (Could you give me a sample of some sort?)
17:14:37 <aleth> Don't parse them
17:14:59 <aleth> Just don't ignore contacts which only have txt logs
17:15:16 <aleth> (i.e. they should appear)
17:15:26 <nhnt11> So what do I do with them? :S
17:15:37 <nhnt11> What if a stray unrelated text file gets in the log dir?
17:15:46 <aleth> Ignore it
17:16:02 <aleth> I'm just thinking of the case where a log folder exists, but it only has txt logs.
17:16:28 <nhnt11> aleth: I'll need some way to ensure that these txt files are indeed log files though
17:16:52 <aleth> I think we can just assume that as long as you don't parse them.
17:16:56 <nhnt11> after that I can just count the number of newlines or something.
17:17:09 <aleth> Oh, if you parse them maybe the header is enough
17:17:20 <aleth> (I mean, to check it's a log file)
17:17:25 <nhnt11> Yeah that's enough
17:17:33 <aleth> But I don't think it's a good idea to spend any time on txt logs
17:17:53 <nhnt11> If I don't parse them at all, I don't really understand what to do with them other than ignore them :S
17:18:22 <aleth> Count them as "a conversation happened" in some generic way?
17:18:34 <aleth> Doesn't matter if the score is low as those will be old anyway.
17:18:48 <nhnt11> aleth: They'll still have a 0 score, so what's the point?
17:18:54 <nhnt11> They'll still appear
17:19:05 <aleth> (apart from the odd user that force-enables them)
17:19:31 <nhnt11> All contacts still appear in the awesometab regardless of the score
17:19:40 <aleth> But only if they are contacts.
17:19:42 <nhnt11> So even if I ignore these text files, they'll still appear in the list
17:19:43 <nhnt11> ah
17:19:54 <nhnt11> Yeah ok for buddies that aren't contacts I'll keep this in mind
17:19:54 <aleth> Ditto for MUCs
17:20:23 <aleth> Right, other than that it doesn't matter, like you say. I forgot you weren't handling that case yet.
17:20:47 <aleth> You could also give a .txt file some generic minimal score of course.
17:21:21 <aleth> (The date info is in the filename and that should be enough to verify it's a log)
17:21:36 <nhnt11> I would say the number of newlines in it is fine :)
17:21:39 <flo-retina> aleth: "Is that really how we get the log path in the existing code?!" There's a shorter/better way using OS.File. (for some reason it didn't seem to work when I tried though; but we updated Mozilla a couple times since that).
17:21:40 <aleth> That would be even nicer, but only if it doesn't take too much time
17:22:19 <flo-retina> nhnt11: you don't need to have all of us around at once to discuss your schedule.
17:22:41 <nhnt11> flo-retina: That's why I was going to write a mail, but I can discuss it now too if that's ok :)
17:22:59 <flo-retina> (especially as it's currently difficult to predict when Mic will be around; last time I heard from him, he was recovering from some illness, and had just spent a week in bed).
17:23:13 <flo-retina> nhnt11: email seems better.
17:23:20 <nhnt11> Sure.
17:23:25 * nhnt11 didn't know Mic was ill
17:23:51 <flo-retina> nhnt11: propose something you think is reasonable (both in the sense that it lets you 'reach the objectives' and that it is realistic given your other commitments)
17:24:11 <nhnt11> flo-retina: Ok.
17:26:48 <flo-retina> nhnt11: also, reaching a state where you think we can happily ship the awesometab in a release is more important than matching exactly your objectives written down during the GSoC application period.
17:28:10 <nhnt11> I understand.
17:28:26 <nhnt11> flo-retina: When do you expect to start planning out the next release?
17:28:55 <aleth> For example the proposed non-list 'look' of the awesometab before scrolling can easily be postponed
17:29:28 <aleth> (if that was in your original proposal, I don't remember)
17:30:00 <nhnt11> Yeah, I don't think there's time for that in the next couple weeks
17:30:16 <aleth> Definitely not...
17:30:39 <nhnt11> I think the most important thing is to get the ranking stuff done and follow ups that will undoubtedly appear
17:30:43 <aleth> But also it's not a priority for shippability
17:31:06 <nhnt11> Users so far seem to like the list view just fine ;)
17:31:26 <aleth> The next release will happen pretty much when it's ready I guess (probably after upgrading to moz24, enabling yahoo, and ironing out awesometab bugs ;)
17:34:30 <flo-retina> nhnt11: we haven't discussed a schedule yet for the next release, but I think starting to think seriously about it (and to plan) in a month is likely, and shipping in ~6 weeks would be nice.
17:34:58 <aleth> The awesometab will have to be fast enough, accessible, and ranked, with item design nits fixed
17:35:20 <flo-retina> aleth, nhnt11: "non-list 'look' of the awesometab" If this is the grid view for the top conversations, I don't think we really need it.
17:35:44 <flo-retina> I would like some thoughts to be given to "what would it take to kill the 'add buddy' and the 'join chat' dialogs?" though :)
17:35:49 <aleth> flo-retina: I think we're pretty much all agreed on that. I just took it as an example for something on the original schedule that may have changed under fire ;)
17:36:03 <aleth> nhnt11: What happened to your etherpad?
17:36:06 <nhnt11> flo-retina: Yeah, the list view is perfectly fine imo
17:36:11 <flo-retina> :)
17:36:16 <nhnt11> aleth: It hasn't been updated since midterm..
17:36:20 <aleth> I think there is some thoughts about join chat that on it 
17:36:24 <nhnt11> Yeah
17:36:39 <nhnt11> Basically adding a dummy item to create a new chat/buddy/whatever when there were no results
17:36:52 <flo-retina> :)
17:36:53 <aleth> You could convert what's left there to bugs now
17:37:13 <nhnt11> will do
17:37:14 <aleth> And then refer to bugs in your schedule.
17:37:17 <flo-retina> how do we handle the case of 'there are plenty of results, but none matches what I want' ? :)
17:37:53 <flo-retina> maybe we need to hide a button in a corner to force that dummy item to appear :-S
17:38:26 <-- nhnt11 has quit (Input/output error)
17:38:50 --> nhnt11 has joined #instantbird
17:40:04 <nhnt11> aleth, flo-retina: Realistically, I may not be able to finish all these followup bugs by the gsoc deadline (the 19th of this month I believe?)
17:42:09 <aleth> Right, so pick out the core functionality.
17:42:45 <aleth> Such a prioritized todo list would be helpful for you after gsoc too...
17:43:42 <instantbot> New Core - General bug 2144 filed by aleth@instantbird.org.
17:43:44 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2144 nor, --, ---, nobody, NEW, Packaging incorrect on Linux since moz23
17:44:10 <nhnt11> Actually, I should probably say "won't be able". I want to get ranking completely done in the next week or two, finish up my tests, and then continue with the followups (all this is in my email).
17:44:49 <nhnt11> But if there's any chance this won't be enough to pass the final evaluation, I'll give more priority to GSoC over the next two weeks.
17:49:40 <instantbot> New Instantbird (UI) bug 2145 filed by nhnt11@gmail.com.
17:49:42 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2145 enh, --, ---, nobody, NEW, Awesometab should provide a way to create chats and buddies.
17:54:15 <instantbot> New Instantbird (UI) bug 2146 filed by nhnt11@gmail.com.
17:54:19 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2146 nor, --, ---, nobody, NEW, Awesometab should have smarter filtering
17:55:55 * nhnt11 set a dependency on the wrong bug
17:56:07 <-- gerard-majax has quit (Ping timeout)
17:56:42 --> gerard-majax has joined #instantbird
17:59:09 <aleth> flo-retina: So there is no solution to the Windows build issue until Even does major work on the build slave?
18:00:49 <-- gerard-majax has quit (Ping timeout)
18:01:05 --> gerard-majax has joined #instantbird
18:03:43 <aleth> nhnt11: So if indexedDB is only indexed by key... it won't be possible to do fast searches by queries for substrings of the topic. Isn't that a problem?
18:04:37 <aleth> (the topic as an example of one of the strings we filter on)
18:05:39 <aleth> Or is the id not the key?
18:06:07 * aleth is going to wait for the commented patch
18:06:12 <nhnt11> aleth: A database can be indexed on any object property
18:07:04 <aleth> What I'd like to know is how the awesomebar does its rapid filtering and whether you can replicate that with the structure you have in place.
18:07:43 <nhnt11> Hmm
18:07:45 <aleth> Or if you think it that it's not needed.
18:08:23 <nhnt11> aleth: With the way it works currently, a simple filter would suffice, but yes it's a problem if we switch to querying the database at filter-time
18:09:28 <aleth> nhnt11: The current filter function is very restrictive (startsWith etc). If you look at our wishlist for filtering, will it still be performant after it's made more flexible? That's the question.
18:10:20 <nhnt11> I don't think we have enough items that it wouldn't be, but I have no data/proof to back this claim up.
18:11:11 <nhnt11> Firefox uses an sql database to store its places data..
18:11:22 <aleth> A simple test would be to connect to a whole bunch of IRC servers, complicate the filterfunction to be more permissive, and then see if it still performs on a somewhat slower machine ;)
18:11:47 <aleth> I know it uses sql, but how is it indexed?
18:12:34 * nhnt11 doesn't know
18:13:00 <aleth> The awesometab should ultimately feel as snappy as the awesomebar, that's all I'm saying ;)
18:13:22 <nhnt11> I'm going to do this test
18:13:40 <nhnt11> I'll make a VM with limited resources and test it out on it
18:15:09 <-- nhnt11 has quit (Input/output error)
18:15:24 --> nhnt11 has joined #instantbird
18:17:32 <nhnt11> aleth: Would a 2.1GHz Core 2 Duo with 4GB of ram suffice for a test machine or do we need something slower? :P
18:17:48 <aleth> Less RAM for sure ;)
18:18:05 <aleth> Look at our system requirements page?
18:18:17 <nhnt11> Good idea
18:20:09 <aleth> There will be plenty of users with computers that are 5-8 years old or so
18:20:20 * nhnt11 doesn't have access to any computers with such low specs so a VM it is :P
18:32:24 * nhnt11 has to go
18:33:25 <-- nhnt11 has quit (Input/output error)
18:35:14 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.19/2010030105])
18:40:47 <-- aleth has quit (Quit: Ciao)
18:43:56 --> Mic has joined #instantbird
18:43:56 * ChanServ sets mode +h Mic 
18:44:15 <Mic> aleth: wish granted :)
18:44:20 <Mic> Hi, I hope I'm kind of back now :)
18:45:46 <Mic> Sorry for being away so long ... I was pretty busy around mid of august and got ill after that.
18:48:54 <Mic> nhnt11: I even saw your WIP already! I hope you only split that constant into nice factors before attaching the patch here:
18:49:01 <Mic> |get daysBefore() Date.now() - this.lastDate / 24 * 60 * 60 * 1000|
18:50:42 <Mic> Would be unfortunate if you had tested with this as it directly goes into one of the factors for the score...
19:11:15 <flo-retina> Mic: hey, welcome back! :)
19:15:37 <Mic> Thanks \o/
19:16:24 <flo-retina> aleth: If we find stuff to disable in the windows mozconfig, maybe we can get nightlies without creating another Windows VM
19:16:38 <Mic> Could have been two days earlier if I didn't had this great idea of running errands in town for two hours last friday when I *thought* I had already recovered enough ;)
19:18:11 --> nhnt11 has joined #instantbird
19:18:21 <nhnt11> Hi Mic
19:18:22 <Mic> There's been no nightly today by the way - I was updated to 30th of august instead
19:19:12 <nhnt11> Before the patch, there was a ONE_DAY constant that I was using.
19:19:14 <flo-retina> Mic: We updated to Mozilla 23, which requires a Windows 64 bit to build :(.
19:19:31 <Mic> Hi nhnt11, how are you doing? Sorry for neglecting you so much...
19:19:45 <Mic> So we need a win 64 build VM now?
19:19:49 <Mic> :S
19:20:01 <nhnt11> Mic: That's all right, I hope you're well :)
19:20:02 <flo-retina> Mic: we need a 32bit compiler running on a 64bit Windows, yes.
19:20:05 <Mic> I guess Even will like these news a lot.
19:20:30 <flo-retina> Mic: I'm sure he'll enjoy these news, yes ;).
19:21:12 <Mic> Yes, I'm fine again. Thanks for attaching a patch recently!
19:21:33 <Mic> I've left you a comment about a line in it a bit earlier.
19:21:51 <Mic> (that is in the chat logs)
19:22:39 <nhnt11> Mic: I just responded to that ;) I was using a ONE_DAY constant before the patch
19:22:52 <nhnt11> Thanks for catching that though, it's a really bad mistake :P
19:24:00 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
19:24:04 --> nhnt11 has joined #instantbird
19:24:42 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
19:24:55 --> nhnt11 has joined #instantbird
19:25:40 <Mic> Good, I was hoping you only did that to make it look nicer ;)
19:28:30 --> squib has joined #instantbird
19:33:20 <-- nhnt11 has quit (Ping timeout)
19:34:33 --> nhnt11 has joined #instantbird
19:39:58 <squib> are there any docs about importers for instantbird? i was going to write a miranda im importer if one doesn't already exist
19:41:43 <Mic> squib: let me check.
19:41:48 <flo-retina> squib: bug 1495
19:41:52 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1495 enh, --, ---, wnayes, ASSI, Create an account import wizard - GSoC 2012
19:42:56 <flo-retina> unfortunately, the code of that GSoC project hasn't been merged yet. We need to look into it again.
19:43:19 <squib> flo-retina: alright, thanks. i'll keep an eye on that bug.
19:43:44 <flo-retina> if you want to help finishing these patches, that will be very appreciated of course ;)
19:44:36 <flo-retina> I don't remember if a miranda importer was written as part of the GSoC project, but the project definitely put in place the infrastructure required for importing from other clients
19:45:29 <Mic> flo-retina, squib: I can't find any reference to "miranda" in the patch.
19:47:20 <Mic> I'll be back later.
19:50:52 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
19:51:05 --> nhnt11 has joined #instantbird
19:51:25 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
19:52:25 --> nhnt11 has joined #instantbird
19:52:33 <-- nhnt11 has quit (Input/output error)
19:53:05 --> nhnt11 has joined #instantbird
19:53:53 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
19:57:29 --> nhnt11 has joined #instantbird
19:57:44 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
19:58:28 --> nhnt11 has joined #instantbird
19:59:26 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
20:00:04 --> nhnt11 has joined #instantbird
20:00:32 * nhnt11 just fixed 3 bugs in a row :)
20:04:47 <nhnt11> flo-retina: Do you think it's important for chats to be sorted? I'm referring to the ones that don't have stats/rank
20:04:53 <nhnt11> Mic ^
20:05:08 <flo-retina> sorted by what?
20:05:11 <nhnt11> By anything
20:05:24 <flo-retina> yes :-P
20:05:25 <nhnt11> I think they can just be appended to the end of the list after receiving from the account
20:05:31 <nhnt11> they're currently sorted by name
20:05:52 <nhnt11> but I think there's a lot of performance to gain if they're just appended and sorted only if stats are available
20:06:23 <flo-retina> I think the user is more likely to join popular channels (with lots of participants), and sorting by name is a good idea
20:06:41 <nhnt11> Ok
20:06:43 <flo-retina> so I think I would sort first by round(log(participantCount)) and then alphabetically by name.
20:07:20 <nhnt11> hmm ok
20:07:33 <nhnt11> they're no longer sorted at filter time so ok I guess.
20:09:05 <flo-retina> btw, "first by round(log(participantCount)) and then alphabetically by name" is just a suggestion (the first thing that came to mind), so feel free to suggest something else if it doesn't seem a good idea.
20:11:41 * nhnt11 has go to finish a report
20:11:42 <nhnt11> bye
20:11:44 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
20:30:11 --> EionRobb has joined #instantbird
20:33:15 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
20:33:19 --> flo-retina has joined #instantbird
20:33:19 * ChanServ sets mode +qo flo-retina flo-retina 
20:56:42 --> nhnt11 has joined #instantbird
21:00:58 <Mic> Good night!
21:02:03 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com)
21:08:59 --> clokep has joined #instantbird
21:09:00 * ChanServ sets mode +o clokep 
21:09:02 <-- clokep has quit (Connection reset by peer)
21:09:16 --> clokep has joined #instantbird
21:09:16 * ChanServ sets mode +o clokep 
21:25:11 <flo-retina> If anybody's curious, I put online photos from the Braderie de Lille: http://queze.net/goinfre/mamie/braderie2013/ (the first set is photos of stuff I saw, taken from my smartphone. The second set is stuff I brought home :-]).
21:42:16 <-- nhnt11 has quit (Input/output error)
21:54:15 <qheaden> Hello everyone.
21:55:44 <clokep> Hello qheaden.
21:55:54 <qheaden> clokep: Next week I am going to implement server pings in JS-Yahoo
21:56:12 <qheaden> I have to look to see what else I'm going to work on.
21:56:18 <clokep> OK. :)
21:56:39 <qheaden> I'm also going to look more into the mobile status stuff.
22:01:15 <clokep> :)
22:02:52 <qheaden> I would love it if my university sponsored me to work on Instantbird. :)
22:13:04 <flo-retina> qheaden: what do you mean by "sponsor"?
22:13:18 <flo-retina> do you mean pay you, or give you credits for working on it?
22:17:00 <qheaden> flo-retina: Pay me.
22:17:30 <flo-retina> that seems difficult to arrange :-/
22:17:57 <qheaden> flo-retina: Not sure if clokep mentioned it, but I'm going to be employed at my university after GSoC to work with their system admin group and software development research group.
22:18:14 <flo-retina> but maybe paying you to teach other students to start contributing to free software could be discussed with them :).
22:18:16 <qheaden> I'd be nice if I could work on Ib as a project.
22:18:44 <flo-retina> ah, you can try asking them (nothing to lose I guess :))
22:18:55 <flo-retina> (and no, I didn't know)
22:19:11 <qheaden> Yeah. Regardless, I still want to contribute to Ib after GSoC is over, with whatever extra time I have. :)
22:23:16 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
22:31:20 <-- qlum has quit (Connection reset by peer)
22:35:25 <flo-retina> qheaden: :)