#instantbird log on 12 28 2009

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 :-)