All times are UTC.
00:15:12 <-- Ornthalas has quit (Connection reset by peer) 00:19:34 --> Ornthalas has joined #instantbird 00:36:06 --> stevo has joined #instantbird 01:30:29 <-- [don_gato has quit (Quit: Leaving) 02:11:17 --> stevo_ has joined #instantbird 02:11:23 <-- stevo has quit (Ping timeout) 02:11:32 * stevo_ is now known as stevo 02:11:47 <-- GeekShado_ has quit (Connection reset by peer) 02:18:12 <-- stevo has quit (Ping timeout) 02:20:15 --> stevo has joined #instantbird 02:23:34 <-- stevo has quit (Ping timeout) 02:28:51 <-- Ornthalas has quit (Quit: KTHXBYE) 03:48:05 --> stevo has joined #instantbird 03:56:12 <instantbot> Just appeared in Xinb, site de Mòrian - Category 9 - http://www.bezut.info/ : 03:56:13 <instantbot> http://www.bezut.info/a112/ - IRCParser gives its first results! 06:12:30 <-- stevo has quit (Ping timeout) 07:06:40 --> instantbot has joined #instantbird 07:06:40 topic changed by sand.mozilla.org to "Ask questions about Instantbird here. Official website: http://www.instantbird.com. Latest release: 0.2b1. Read http://blog.instantbird.org/. Nightlies: http://ftp.instantbird.com/instantbird/nightly/latest-trunk/ (testing purpose only), IRC logs: http://log.bezut.info/." 07:06:40 * ChanServ sets mode +v instantbot 10:30:06 --> Troy has joined #instantbird 10:39:56 <-- Troy has quit (Ping timeout) 10:40:35 --> Troy has joined #instantbird 11:20:00 --> Mic has joined #instantbird 11:20:17 <Mic> hi 11:27:44 <flo> hi :) 11:45:03 --> GeekShadow has joined #instantbird 12:00:11 * flo just commented in bug 292 12:00:14 <instantbot> flo: Bug https://bugzilla.instantbird.org/show_bug.cgi?id=292 enh, --, ---, leeraccount, NEW, Enhance log viewer 12:09:04 <Mic> That includes the duplication of entries as in the Firefox history? 12:09:56 <flo> no 12:10:18 <flo> but there's a problem with the wording 12:10:49 <flo> "last 7 days before yesterday" is a bit too long :( 12:11:08 <Mic> Firefox duplicates these entries 12:11:13 <flo> yes 12:11:26 <flo> but Firefox does that as search filters rather than as a hierarchy in a tree 12:12:15 <flo> hmm, or maybe we should duplicate them 12:12:35 <flo> but it would be stupid in the case when you open both "yesterday" and "last 7 days" containers :( 12:13:59 <-- Troy has quit (Quit: See you later!) 12:15:00 <Mic> On the "latest logs might be most interesting" issue: 12:15:33 <Mic> I wanted to try to add a bar on top of new conversation that allows to show the most recent logs in the conversation window (like on Skype chats) 12:16:31 <flo> In the future I'd like to display automatically the last few lines of the previous conversation with the same contact when opening a conversation tab 12:16:47 <flo> that's very useful for people who tend to close their conversation windows often 12:17:16 <flo> the message style system even has a way to display these "history" messages a bit differently 12:17:22 <Mic> Skype has "Show messages from: Today | This week | This month | All" and it's quite useful in my opinion 12:17:36 <flo> the issue I have is that the text logs written to the disk by libpurple are not machine readable 12:17:43 <Mic> Lack of markup on these messages is a serious drawback 12:17:59 <Mic> but well you won't get around that before having a proper log format 12:18:14 <flo> I looked at it several times, and I can't find a way to know things as basic as whether a message was incoming or outgoing. 12:18:34 <Mic> The logger has xml output as well afaik? 12:18:40 <flo> no 12:18:55 <flo> there's txt or html 12:19:09 <Mic> Is it html then .. hmm 12:19:18 <flo> where HTML is unrelated to what Instantbird uses, and would display conversations exactly like pidgin 12:19:28 <flo> and that's probably not even more parsable 12:20:03 <flo> there's also a piece of code related to xml logging in libpurple, but it's commented out, and unlikely to work if we uncommented it 12:20:23 <Mic> I wouldn't use anything that looks like Pidgin *shiver* 12:20:25 <Mic> http://lxr.instantbird.org/instantbird/source/purple/libpurple/log.c#1266 12:20:37 <Mic> Ah, you mentioned that already 12:20:54 <flo> look at the line 1265 ;) 12:21:09 <Mic> I saw 12:24:26 <flo> I don't know if we can try to "fix" the text logger so that we can distinguish messages in future logs made by Instantbird 12:24:46 <Mic> Splitting to Today/Yesterday/.. is not that much of a problem 12:24:52 <flo> or if we should just give up and implement something that works when we get serious about having a decent logging feature 12:25:17 <flo> the issues I have for parsing are: 12:25:27 <flo> can't know if a message is incoming or outgoing, or a system message 12:25:32 <Mic> I can easily filter the list according to timestamps and special case these few .. 12:25:54 <flo> can't know when a message stops. (because there's no way to know if something is the next line of a message, or a new message) 12:26:21 <Mic> I'm not sure if it's worth trying to get anything out of plain text messages 12:26:32 <flo> Mic: yes, the fact that the list is initially sorted helps here 12:26:53 <Mic> "Throwing away all the extra information" is what needs to be fixed in my opinion 12:27:25 <flo> well, yes 12:28:00 <flo> but that's too big for 0.2 at this point ;) 12:28:40 <flo> "can't search efficiently through all the logs at once" also needs to be fixed ;) 12:29:43 <Mic> I just want to make the logs more easy to accessfor the time being 12:32:01 <flo> we already discussed log formats a while ago: http://wiki.instantbird.org/Brainstorm:logs 12:32:09 <Mic> I know .. 12:32:21 <Mic> gtg (lunch) 12:32:50 <flo> bon appétit :) 12:55:26 --> Morian_ has joined #instantbird 12:56:37 <-- Morian has quit (Ping timeout) 13:24:35 <-- Mic has left #instantbird () 13:31:28 --> Mic has joined #instantbird 13:33:58 <Mic> Morian_: Instantbot seems to be suffering from the same problem again (bugzilla) 13:37:31 --> Troy has joined #instantbird 13:50:55 --> Troy_ has joined #instantbird 13:51:21 <-- Troy_ has quit (Connection reset by peer) 13:51:45 --> Troy_ has joined #instantbird 13:52:06 <-- Troy_ has quit (Quit: See you later!) 13:52:18 --> Troy_ has joined #instantbird 13:52:20 <-- Troy_ has quit (Quit: See you later!) 13:56:40 <-- Mic has quit (Quit: Instantbird 0.2b2pre) 13:56:46 --> Mic has joined #instantbird 13:57:21 <flo> do you often need to have several log windows at once? 13:57:25 <-- Mic has quit (Quit: Instantbird 0.2b2pre) 13:58:51 --> DetroitLibertyPenguin has joined #instantbird 14:07:48 --> Mic has joined #instantbird 14:08:17 <Mic> flo: can I if I have to? 14:30:36 <Mic> btw you are right on the "several clicks necessary" for finding a log file with the tree but .. 14:31:25 <Mic> .. the lookup time for any item is nearly constant in the tree case ;) 15:08:43 --> Ornthalas has joined #instantbird 15:09:25 <-- Troy has quit (Ping timeout) 15:10:16 <Morian_> /nick Morian 15:10:21 * Morian_ is now known as Morian 15:16:58 --> Troy has joined #instantbird 15:23:23 <flo> Mic: except that it's not the lookup by a computer :) 15:42:32 <Mic> With "lookup time" I meant the time the user needs to get the log he wants 15:51:28 <flo> if it's very long in all cases, "constant" is not an interesting property ;) 15:52:10 <flo> by the way, should we add buttons or keybindings for "next/preview log"? 15:55:30 <Mic> With 'very long' being '<<<' current time to find a log 15:55:40 <Mic> What do you mean by 'preview'? 15:56:56 <flo> I mean "previous" :) 15:57:02 <Mic> ah 15:57:10 <flo> (sorry) 15:57:58 <flo> Mic: several clicks is much longer than holding the down arrow until the visible logs looks like what I'm looking for 15:59:01 <Mic> I thought of adding an open "log folder" button (similiar behaviour as on the download manager, ie on Windows: it will open the folder and highlight the file in question) 15:59:41 <flo> except if you know the exact date of the conversation you are looking for of course, but I think it's much more common to look for the conversation "about <topic>" or "a few weeks ago before the vacations" than to look for the conversation on november the 9th 16:00:42 <Mic> In such a case we definitely need a proper search 16:00:50 <flo> we need it. 16:01:13 <flo> also, what about displaying all the logs in a single view with an "infinite" scrollbar? 16:02:50 <Mic> Would be neat.. we could still add some separators for sessions/days/month/ .. 16:03:16 <Mic> (in the content window) 16:05:42 <flo> yes, and some markers on the scrollbar 16:06:00 <Morian> ok instantbot should be really fixed about the bugzilla things 16:07:05 <Mic> Which doesn't work easily with standard scrollbars as far as I know 16:07:31 <Mic> With no duplication of entries, we'll get interesting behaviour if the last week overlaps with beginning of a month/year 16:12:17 <Mic> *last 7 days 16:14:47 <flo> so you think we should duplicate them? 16:16:13 <Mic> I think it could be better 16:16:45 <Mic> If the last week overlaps with the beginning of the month, there would be no entries left for the current month (which would just not appear in the list) 16:16:52 <Mic> and some would be missing from the last week .. 16:17:09 <Mic> That's an awkward bahaviour in my opinion 16:18:49 <Mic> I think it wouldn't even break anything on the code.. as it just returns/continues earlier right now (while it is not really necessary to do so) 16:20:53 <Mic> "17:16:52 - Mic: and some would be missing from the last week .. " -> *last month* ofcourse 16:37:51 --> stevo has joined #instantbird 17:25:01 <-- Troy has quit (Client exited) 17:25:21 --> Troy has joined #instantbird 17:25:59 <-- Troy has quit (Client exited) 17:33:05 <-- Mic has left #instantbird () 17:50:14 --> Mic has joined #instantbird 17:55:08 --> Troy has joined #instantbird 18:02:11 <-- Mic has quit (Quit: Instantbird 0.2b2pre) 18:02:20 * stevo is now known as stevo_mtg 18:04:20 --> vicnet has joined #instantbird 18:07:12 --> Mic has joined #instantbird 18:07:26 <Mic> re 18:33:02 --> Troy_ has joined #instantbird 18:34:32 --> Troy__ has joined #instantbird 18:35:01 <-- Troy has quit (Ping timeout) 18:35:23 * Troy__ is now known as Troy 18:36:43 <-- Troy_ has quit (Ping timeout) 18:42:30 --> bittin has joined #instantbird 18:46:38 <-- Troy has quit (Client exited) 18:53:17 <-- Mic has quit (Quit: Instantbird 0.2b2pre) 19:22:16 <-- DetroitLibertyPenguin has left #instantbird () 19:50:22 * stevo_mtg is now known as stevo 20:09:22 --> DGMurdockIII has joined #instantbird 23:07:46 --> Mic has joined #instantbird 23:21:20 <Mic> Morian: on your early results 23:21:36 <Mic> The edges on your graph are they weighted? 23:21:57 <Morian> no :( 23:22:05 <Morian> gephi doesn't support weight on edges ... 23:22:19 <Morian> it will on 0.7 but it's more than unstable now 23:22:36 <Mic> Does IRCParser produce a weighted graph? 23:22:40 <Morian> that's why I am considering using GraphML and other Software 23:22:52 <Mic> gephi is jsut visualization, isn't it? 23:22:54 <Morian> yes it produces weighted graph 23:22:58 <Morian> yes 23:25:20 <Mic> Is the task to filter out conversations or to examine the collected data as well? 23:26:04 <Morian> I don't understand your question, sorry ^^' 23:27:21 <Mic> Do you have to extract information from the collected data? 23:27:44 <Mic> Like the distribution of the number conversations and such? 23:28:03 <Morian> I filter some things, like "Morian: Hey ..." 23:28:23 <Morian> to add weight to the conversation between this person and Morian 23:29:00 <Morian> and when there is no "Mic: ..." I cut the log in small pieces of "conversation" and act as if everyone speak with each other 23:29:14 <Morian> with some "magic" coefficients 23:29:55 <Morian> and some penalties when people keeps flooding so that flooding doesn't improve your "weight" too much 23:30:07 <Morian> increase * 23:30:37 <Morian> this is far from being perfect, but the numeric results I had seem very close to reality :) 23:30:51 <Morian> you tend to speak with flo far more than I am :-D 23:31:16 <flo> Morian: except if you take into account google talk conversations ;) 23:31:21 <Mic> Well, I don't have any private conversation with him 23:31:22 <Morian> and flo speaks more to you by 10% than you speak to him 23:31:46 <Mic> hehe 23:31:58 <Mic> No wonder 23:32:10 <Mic> "flo: do this and that to fix your diff" 23:32:14 <Mic> "Mic: ok" 23:32:28 <Mic> ok, just kidding ;) 23:32:45 <Morian> ah yes I don't take into account the amount of data exchanged in the message 23:32:50 <flo> Mic: by the way, the reason why I said that we should not duplicate entries is that I imagined all groups opened by default (except maybe months and years) 23:33:15 <Morian> I should :), let's add it on my todo list 23:33:16 <Morian> :-D 23:34:04 <Mic> Morian: I meant something different earlier: do you have the number of conversations that someone was participating in? 23:34:24 <Morian> ah no 23:34:27 <Morian> not yet 23:34:33 * Morian adds it on his todo list 23:34:46 <Mic> If yes:you might sort it and plot it and have a look what it looks like 23:35:13 <Mic> Maybe it's got some similarity with number of friends distribution from social networks or somethign like that 23:35:37 <Morian> sounds interresting and "easy to do" 23:35:42 <Mic> Having many people with an average number and a few with very many 23:36:05 <Mic> I think the latter are called "super-spreaders" on social networks 23:36:15 <Mic> (comes freom epidemic models afaik;) 23:36:31 <Morian> My definition of a conversation is special, it happens a lot that someone joins a conversation to say one thing, but we can't consider him as being fully participating in the conversation 23:37:03 <Morian> that's why if someone has not been seen for X seconds (X depending on the density of the conversation ...) the conversation ends and a new one starts 23:37:39 <Mic> What if someone triggers a lot of activity by saying something? 23:38:22 <Morian> if he doesn't participate then it is as I described 23:38:33 <Mic> ok 23:38:59 <Morian> he will be considered as in a conversation for some time, and then considered not anymore as in the conversation 23:39:14 <Morian> (my english sucks ><") 23:39:47 <Morian> same thing if there is already a huge conversation and somebody else join 23:40:12 <Morian> a new conversation will begin when this person joins 23:41:18 <Morian> I just wanted to prevent the following case: One message from C in a conversation between A and B, and then considering A, B and C were in the same conversation equally 23:41:23 <Mic> So you can't join a conversation, it will always start a new one 23:41:49 <Morian> you can join a small conversation without "triggering a new one" 23:42:14 <Morian> for example if flo joins now, I am sure that a new conversation will start 23:43:13 <Morian> same thing if we stop talking for X seconds, the conversation ends 23:43:17 <Mic> Maybe it's not the number of conversations but the amount of text exchanged that is a better gauge in such a case 23:43:34 <Morian> X depending on the frequency of the messages ^^' 23:44:14 <Morian> it is planed to draw some charts about who is talking the more 23:44:25 <Mic> you could e.g. normalize the participation (ie ParticipationA = nbMessagesFromUserA/totalNbOfMessages ) 23:44:26 <Morian> I already have charts on who is ping timeouting the most :-D 23:45:17 <Morian> yes, but the work is due for next week and I still have 2 other projects for the same time ... 23:45:30 <Mic> sure, it was just my 2 cents ;) 23:46:02 <Morian> I'll continue this project after the due date but before I have to make the current things working correctly :) 23:46:10 <Morian> btw I am the winner of ping timeout ;) 23:46:29 <Morian> and Troy is the winner of number of nicknames :-D 23:46:37 <Morian> he has 12 different nicks :) 23:48:20 --> Morian_ has joined #instantbird 23:48:56 <Morian_> so ... I said : I already made charts on percentage of url per message, and percentage of question per message 23:49:10 <Morian_> the winner on URLs is instantbot 23:50:14 <-- Morian has quit (Ping timeout) 23:50:32 * Morian_ is now known as Morian 23:53:12 <Mic> +1 :P 23:54:35 <Morian> :( 23:55:43 <Morian> What is fantastic is that when the output charts or graphs are ready, I just have to code new input modules for each log format, and then it will parse it and apply the same rules to draw a lot of things on a lot of channels 23:55:58 <Morian> Instantbird logs represents ~2MB 23:56:23 <Morian> but I have some others where there are more than 100MB of data :) 23:57:18 <Mic> Not bad 23:58:20 <Morian> and actually the speed is less than 3seconds to parse all the instantbird logs, i am impressed ^^' 23:58:38 <Morian> perl is very powerfull on regex :-)