#instantbird log on 11 17 2011

All times are UTC.

00:01:48 <-- ecaron has quit (Quit: Instantbird 1.1)
00:03:18 <-- clokep has quit (Quit: Instantbird 1.2a1pre)
00:03:32 --> clokep has joined #instantbird
00:03:32 * ChanServ sets mode +h clokep 
00:27:06 <-- Tomek has quit (Quit: Instantbird 1.1)
00:45:21 <-- jb has quit (Ping timeout)
00:52:42 <-- wesj has quit (Input/output error)
00:59:11 <-- aleth has quit (Quit: Instantbird 1.2a1pre)
01:11:50 --> jb has joined #instantbird
01:12:59 <-- hunsly has quit (Ping timeout)
01:21:15 --> wesj has joined #instantbird
01:52:33 <-- Mook_as has quit (Quit: ChatZilla 0.9.87-rdmsoft [XULRunner])
02:18:51 <-- jb has quit (Ping timeout)
02:33:50 <-- douglaswth has quit (Connection reset by peer)
02:35:19 --> douglaswth has joined #instantbird
02:44:49 --> jb has joined #instantbird
02:49:12 <clokep> Hmmm...so I have a mostly working IRC now I think. Just need to figure out where to put the modules...
02:50:53 <clokep> flo: This is what I get when I attempt to compile SIPE now: http://pastebin.instantbird.com/1077
02:51:02 <clokep> You were right, it's during the linking of purple.dll.
02:54:01 <EionRobb> eww... why is it linking all the protocols into one dll
02:54:03 <EionRobb> :)
02:58:20 --> BlueMaxima has joined #instantbird
03:05:49 <-- clokep has quit (Quit: Instantbird 1.2a1pre)
03:16:29 <-- jb has quit (Ping timeout)
03:37:37 <-- SM0TVI has quit (Ping timeout)
03:38:48 --> SM0TVI has joined #instantbird
04:33:01 --> jb has joined #instantbird
05:24:11 <-- jb has quit (Ping timeout)
05:29:53 --> Mook has joined #instantbird
05:34:44 <-- EionRobb has quit (Quit: Leaving.)
07:22:57 <-- devfil has quit (Client exited)
07:47:23 <-- Mook has quit (Quit: zzz)
07:50:37 --> flo has joined #instantbird
07:50:38 * ChanServ sets mode +qo flo flo 
07:51:28 <flo> hello :)
08:02:07 <flo> clokep: you should check if simple/sipmsg.c and sipe/sipmsg.c are the same. If they are the same (or are easily mergeable), then you should avoid compiling sipe/sipmsg.c if both Simple and SIPE are linked statically into purple.dll (I can help you for the makefile change if needed).
08:02:47 <flo> If they are significantly different, I'm afraid you will have to change the name of these 6 functions with #define s in sipmsg.h
08:11:51 <flo> clokep: I think this (http://pastebin.instantbird.com/1078) should fix the other warnings (warning LNK4049: locally defined symbol <symbol name> imported) in your pastebin (we also have them in buildbot logs)
08:12:21 <flo> would be great if you could test it (I don't have a usable Windows compile VM at the moment)
08:51:32 --> Mic has joined #instantbird
08:51:32 * ChanServ sets mode +h Mic 
08:58:53 --> gerard-majax has joined #instantbird
09:18:32 <-- Mic has quit (Quit: Instantbird 1.2a1pre)
09:20:47 --> MadWookiee has joined #instantbird
09:31:03 --> Mic has joined #instantbird
09:31:03 * ChanServ sets mode +h Mic 
09:32:02 <Mic> hi
09:32:08 <flo> Mic: hello :)
09:33:14 <Mic> flo, what is getAccount in override protocols for? I've inserted reportError there and it seems the function was never called.
09:33:31 --> aleth has joined #instantbird
09:33:55 <flo> does the override otherwise work?
09:34:07 <Mic> Yes
09:34:30 <-- aleth has quit (Quit: Instantbird 1.2a1pre)
09:34:39 --> aleth has joined #instantbird
09:34:58 <Mic> That was before bug 759 btw
09:35:02 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=759 min, --, ---, florian, ASSI, Reorganize purplexpcom
09:35:14 <Mic> I think the parameter for getAccount was changed iirc?
09:35:18 <flo> I'm almost sure getAccount was called before, and is still called after that change
09:35:27 <flo> overwise gtalk accounts wouldn't connect
09:35:33 <flo> yes, the parameter was changed
09:53:21 --> mmkmou has joined #instantbird
09:56:22 <-- chrisccoulson has quit (Connection reset by peer)
09:56:49 --> chrisccoulson has joined #instantbird
10:10:46 <Mic> flo, do you have any idea about this error: http://pastebin.instantbird.com/1079 ?
10:12:14 <Mic> It occurs when opening the account wizard (and seems to be when my component is read and run (I put a debug output at the beginning of the file and it is printed).
10:15:06 <flo> Mic: there are 2 different problems
10:15:46 <flo> http://pastebin.instantbird.com/1080 fixes one of them
10:17:47 <flo> Mic: the other problem is that the id property of your protocol plugin doesn't match the id registered with the category manager
10:18:24 <Mic> Thanks :) 
10:19:42 <Mic> So I need the "prpl-" prefix there, bah.
10:20:02 <flo> or just remove the id property
10:20:10 <flo> jsProtoHelper generates it automatically from the name
10:20:39 <flo> http://lxr.instantbird.org/instantbird/source/chat/modules/jsProtoHelper.jsm#618
10:21:49 <Mic> I don't have "id" but getters for name and normalizedName like gTalk has it
10:23:51 <Mic> It's working now, thanks.
10:23:56 <-- Suiseiseki has quit (Ping timeout)
10:24:05 --> Kagami has joined #instantbird
10:24:23 <Mic> It would taken me ages to figure this out :(
10:24:29 <Mic> *would have
10:25:03 --> hunsly has joined #instantbird
10:25:56 <flo> really?
10:26:04 <flo> there was a clear line number in the error message
10:26:39 <Mic> I meant my actual problem, the manifest thing with the id
10:27:03 <flo> can we document this better? Or make similar problems easier to figure out?
10:27:33 <flo> Another great comment: /* Base 664 encoding and decoding */ const b64 = {
10:31:23 <Mic> Where could we put a comment on this? In jsProtoHelper: "Make sure that the name that your component registers with the category manager is the same as the id (that might be automatically generated for you if you haven't overridden it" ?
10:31:46 <flo> you can throw a descriptive text
10:32:02 <flo> containing both ids
10:32:54 <flo> throw "Creating an instance of " + aId + " but this plugin implements " + this.id;
10:32:57 <Mic> "Mismatching id's between component and category manager regsitration. Expected: ... Found: ..."
10:33:01 <flo> instead of       throw Cr.NS_ERROR_NOT_IMPLEMENTED;
10:33:47 <flo> s/plugin/object/ in my sentence
10:43:11 --> GeekShadow has joined #instantbird
10:46:30 <instantbot> New purplexpcom - General bug 1172 filed by benediktp@ymail.com.
10:46:33 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1172 nor, --, ---, nobody, NEW, Change error message for mismatching id's of a protocol
10:50:58 <Mic> Now the thing I really wanted to do:
10:51:08 <Mic> The german social networks require your email address to log in and "@" needs to be encoded as "\40" in a XMPP user name.
10:52:05 <Mic> I want to automatically replace it. Is getAccount the place to do that by creating and returning a new ImAccount object with a changed name?
10:52:31 <flo> you probably need to create a fake imAccount that replaces the name, yes :(
10:53:02 <flo> (and forwards all other useful calls to the real imAccount instance)
11:03:14 <Mic> All of the override protocols so far were XMPP overrides, maybe we could create an extra helper for those? Ideally reducing the work for each override to setting a few fields in an object (Network/Service name, default domain, connect server, .. ) and feeding it into it?
11:06:26 <flo> the JS XMPP code will be much more extensible
11:06:56 <flo> so I think in the future you won't want to create an override, but instead integrate and reuse some of the XMPP code
11:07:34 <flo> I would prefer if I could get it to connect though :-/
11:14:42 --> clokep has joined #instantbird
11:14:42 * ChanServ sets mode +h clokep 
11:16:30 <-- chrisccoulson has quit (Quit: Ex-Chat)
11:17:42 <flo> clokep: do you remember if JS-XMPP connected successfully to facebook before bug 759?
11:17:45 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=759 min, --, ---, florian, ASSI, Reorganize purplexpcom
11:18:17 <clokep> flo: I don't know. I think it was only tested with GTalk and maybe jabber.org.
11:18:25 <clokep> I thought Facebook requires some special auth dance?
11:18:34 <flo> it doesn't
11:18:43 <flo> DIGEST-MD5 should be enough
11:18:50 <flo> (and that's what I'm trying to debug right now)
11:19:27 <clokep> Ah, OK.
11:21:13 <clokep> Download an old nightly + his extension and try it? :-D
11:21:33 <flo> the 1.1 release should work, right?
11:22:36 <clokep> Yes.
11:23:02 <flo> O_o
11:23:05 <flo> I'm connected to google talk
11:23:39 <flo> I thought something was broken there during my testing yesterday :-S
11:23:53 <flo> I still get Error: [Exception... "'JavaScript component does not have a method named: "getInterface"' when calling method: [nsIInterfaceRequestor::getInterface]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "<unknown>"  data: no] errors
11:25:05 <clokep> :-/
11:25:21 <flo> It's not completely clear either why I don't have a certificate issue
11:25:36 <clokep> I think the socket code just accepts all certs.
11:25:46 <flo> :(
11:28:26 <clokep> flo: https://github.com/vpj/xmpp-js/blob/master/xmpp-js/modules/socket.jsm#L407
11:29:33 <clokep> I think that returning true means "accept the cert".
11:29:37 <flo> so I'm supposed to see "Bad Certificate" logged somewhere
11:29:41 <flo> I don't
11:29:52 <clokep> Is the log function defined as anything?
11:29:53 <flo> (but my term is a mess obviously, so I could be missing something)
11:30:11 <flo> https://github.com/vpj/xmpp-js/blob/master/xmpp-js/modules/socket.jsm#L477 ah lol
11:30:23 <clokep> https://github.com/vpj/xmpp-js/blob/master/xmpp-js/modules/xmpp-connection.jsm#L71
11:30:45 <clokep> flo: It's meant to be overridden by the child socket class, which it is.
11:31:07 <flo> so https://github.com/vpj/xmpp-js/blob/master/xmpp-js/modules/utils.jsm#L106
11:31:16 <flo> = I should see it in my term
11:31:23 <clokep> Looks like it.
11:31:36 <clokep> Doesn't dump only work with the proper prefs flipped?
11:31:42 <flo> dump works.
11:31:58 <flo> I use it all the time ;)
11:32:08 <clokep> Ok.
11:32:22 <flo> have you read the log this morning?
11:33:30 --> mistraven has joined #instantbird
11:33:39 <clokep> Yes.
11:33:56 <clokep> Your fix got rid of the warnings. :)
11:34:04 <flo> cool :)
11:34:08 <flo> so I guess I should commit it :)
11:34:28 <clokep> I don't have time to check if those are the same right now. But I'll check it this afternoon / tonight in between games of Halo Anniversary. ;)
11:35:25 <flo> hmm, I guess my best bet to debug the facebook auth is to add printfs in the relevant parts of the libpurple plugin, and dumps in the JS code, and compare the values
11:36:58 <clokep> Facebook didn't work with his extension either?
11:37:16 <flo> I don't know
11:37:29 <flo> but it clearly didn't work with his code "out of the box"
11:37:50 <flo> his latest commit (https://github.com/vpj/xmpp-js/commit/501e1400d41fc2a9fb62d55d93da86fd51e690d8) obviously broke it
11:38:24 <flo> as MD5.hash throws "undefined variable chrsz"
11:40:19 <clokep> That was one of those late review comments we gave him. :-/
11:40:50 <flo> the review comment wasn't to break everything before leaving...
11:41:10 <flo> it's totally obvious that he has never tried the code he has commited
11:43:51 <clokep> Right.
11:44:45 <clokep> Mic: I remember you saying I had issues w/ LJ Talk...do you remember what they were? :-/ Or is your code available somewhere that has them fixed?
11:55:06 * aleth is reading about JS closures in his lunchbreak. How nice, the ability to return customized functions :)
11:55:36 <clokep> Yes. I used to do crazy things with them in auto-link.
11:55:47 <clokep> (I had closures returning closures and such.)
11:55:57 <clokep> It was interesting. :) You can do powerful (confusing) things!
11:56:02 <clokep> Anyway, time to work.
11:56:03 <-- clokep has quit (Quit: Instantbird 1.2a1pre)
11:57:06 <aleth> It seems like an interestingly different approach to OOP from the C++ one
11:57:07 <instantbot> c++ is evil
12:00:19 <Mic> clokep, clokep_work: http://pastebin.instantbird.com/1081
12:01:13 <Mic> Here's my currently working overrides. It's both the manifest and the component itself
12:01:14 <aleth> Mic: what are those protocols?
12:01:36 <Mic> For german social networks
12:01:51 <aleth> They all have their own protocol?
12:02:00 <aleth> Or are you "just" adding a wrapper
12:02:15 <Mic> They don't do much more then setting the correct server/domain and should fix the user's login name one day
12:02:21 <aleth> cool
12:02:26 <Mic> Same as Google Talk and Facebook
12:02:33 <aleth> all XMPP inside ;)
12:03:55 <aleth> Having those as protocols should be attractive to many German users then :)
12:04:10 <Mic> Hopefully. If they work fine ;)
12:09:57 <-- aleth has left #instantbird ()
12:20:18 --> chrisccoulson has joined #instantbird
12:28:10 <-- Mic has quit (Quit: Instantbird 1.2a1pre)
12:34:37 --> aleth has joined #instantbird
12:36:57 <-- mistraven has quit (Ping timeout)
12:37:42 --> mistraven has joined #instantbird
12:39:12 <-- mistraven has left #instantbird ()
12:41:30 --> Tomek has joined #instantbird
12:44:11 --> clokep_work has joined #instantbird
12:44:12 * ChanServ sets mode +h clokep_work 
12:52:34 <clokep_work> flo: we have a nice abstraction of username splits for jsProtoHelper new protocols (i.e. http://hg.instantbird.org/experiments/file/46279bad5c7c/irc-js%40patrick.cloke/components/ircProtocol.js#l443 ), shouldn't we use that in overrides to avoid line 42 of http://pastebin.instantbird.com/1081
12:52:46 <clokep_work> (line 74 rather)
12:53:17 <clokep_work> So we would just create a full new username split instead of pulling the one from the base and modifying it.
12:53:22 <clokep_work> Or is there a problem w/ that somehow?
12:55:53 <clokep_work> I've never really understood the reasoning behind the way we do that.
12:56:46 <clokep_work> Is it just to replace the server, but keep the second username split that has the resource in it?
12:57:34 <clokep_work> (Thanks Mic. :))
12:59:37 <clokep_work> I guess it allows reuse of all the labels and stuff too. :-/
13:02:14 <-- SM0TVI has quit (Ping timeout)
13:02:49 <flo> yes, it reuses the localized labels
13:05:04 <clokep_work> Although for things like Facebook...should we even have a field for server?
13:05:06 --> SM0TVI has joined #instantbird
13:05:29 <clokep_work> (And I'm just assuming the resource should never be part of the account name. :))
13:06:18 <flo> yeah...
13:06:37 <flo> Things wouldn't be like this if I had designed them ;)
13:07:36 <clokep_work> I know. :) Just wondering if we can "fix" it in the overrides somehow.
13:07:53 <clokep_work> But maybe I should wait to scratch that after we're done integrating the new XMPP code.
13:13:44 <flo> I'm not sure how soon we can be done
13:13:58 <flo> can it land in nightlies if we know there are *lots* of regressions?
13:15:12 <clokep_work> I think that depends on how bad the regressions are.
13:15:29 <aleth> Yeah, since if the nightly becomes effectively unuseable you won't get the regressions spotted as quickly
13:15:35 <clokep_work> (Do they crash? Do they cause people to stop connecting? Do they cause a small annoyance.)
13:16:45 <flo> currently doesn't work (AFAIK) :  bad certs dialog, changing one's buddy icon, adding buddies, removing buddies, joining a MUC, buddy tooltips, displaying buddies in their correct group.
13:16:53 <flo> + everything I haven't noticed yet
13:17:59 <clokep_work> flo: Also something to consider is whether it'll destroy someone's contact list (buddies being displayed in the wrong group mostly is the one I'm thinking of.)
13:18:35 <flo> there are things I can fix ;)
13:19:06 <flo> I haven't even bothered to list "can't login to facebook", as it's pretty obvious I'm gonna fix that before checking it in
13:19:16 <flo> also, DNS SRV queries aren't supported :(
13:20:52 <aleth> So this JS-XMPP code was in worse condition than you expected? :(
13:21:05 <clokep_work> :( Is that an issue w/ the socket code or...?
13:21:15 <flo> Mozilla has never supported DNS SRV queries
13:21:22 <flo> it's https://bugzilla.mozilla.org/show_bug.cgi?id=14328
13:21:36 <flo> and the patch there, which has been rotting for several years, seems quite good.
13:21:52 <clokep_work> Ah.
13:22:00 <clokep_work> That's something we definitely need?
13:22:10 <flo> yes
13:22:23 <flo> the alternatives are attempting to do it with jsctypes
13:22:33 <clokep_work> Using what library?
13:22:42 <flo> or having a C++ XPCOM component to expose something similar to what's in that patch
13:22:52 <flo> clokep_work: the system libraries
13:23:16 <clokep_work> Leaving patches several years waiting for a review always turned me off from contributing to Mozilla btw. :( One of the reasons I always felt it was "too big". :-/
13:23:18 <flo> there are functions in all the 3 OSes we support to do DNS SRV queries
13:23:36 <flo> WinCE didn't support it, but heh... at this point I couldn't care less about it :)
13:23:57 * clokep_work wonders if we should file a "remove WinCE support" bug. ;)
13:24:20 <flo> only if someone is interested in attaching the patch at the time of the bug creation ;)
13:25:53 <flo> I wonder if it would be a good use of my time to update that patch
13:26:12 <flo> or if I should go straight to the "bundle an XPCOM component for it" approach
13:29:12 <clokep_work> flo: Maybe ask someone who would review support for that?
13:30:01 <flo> if we give up on having it supported in necko, there's some C++ XPCOM code that seems reusable (would need to check the license though) here https://github.com/processone/oneteam/tree/master/src/components/src/dns
13:32:49 <clokep_work> flo: MPL/GPL https://github.com/processone/oneteam/blob/master/LICENSE
13:33:00 <clokep_work> (Not LGPL though?)
13:33:06 <flo> the current code tells XMPP servers that we are Pidgin: http://lxr.instantbird.org/instantbird/source/purple/libpurple/protocols/jabber/jabber.h#83 :-S
13:33:15 <flo> clokep_work: yeah, I also wonder about the LGPL
13:33:50 <flo> contacting someone at processone to ask if they agree with us using their code is also an option of course :)
13:34:07 <clokep_work> Yup! :) I wonder if other stuff in there is usable. :-X
13:34:21 <flo> likely :)
13:34:51 <flo> it seems they have figured out a fair bit of voice/video stuff
13:37:55 <flo> they also have a mac dock badge implementation (I'm trying to upstream one)
13:37:59 <flo> and a systray implementation
13:39:16 <clokep_work> Hmm...I almost wonder if we should just use their code for XMPP. :-X
13:41:06 <flo> I'm afraid it's not clearly separated from their UI code
13:41:11 <clokep_work> Ah, OK. 
13:41:27 <clokep_work> I wonder if they know of Instantbird. And hwo is ProcessOne...I've heard them before...
13:41:39 <flo> they know.
13:41:43 <flo> but I don't think they follow us
13:42:31 <flo> (to simplify a lot, which makes things a bit inexact) ProcessOne is a French company whose business is to develop and sell/install the ejabbered XMPP server.
13:42:36 <-- hunsly has quit (Ping timeout)
13:43:07 <clokep_work> Ah, I see.
13:43:16 <clokep_work> Eek I don't like the UI much. :-/
13:44:05 <clokep_work> Btw https://git.process-one.net/oneteam seems more up to date.
14:04:20 <-- debor has quit (Ping timeout)
14:05:24 --> debor has joined #instantbird
14:12:14 --> mistraven has joined #instantbird
14:12:20 <-- mistraven has left #instantbird ()
14:12:50 <flo> clokep_work: does the socket.jsm code work with proxies?
14:13:30 <flo> I'm surprised it doesn't use the port to resolve which proxy to use
14:13:46 <flo> but maybe it's just the Ci.nsIProtocolProxyService.RESOLVE_PREFER_SOCKS_PROXY that is taken into account :-S
14:16:26 <flo> hmm, timeouts of 30000s seem super excessive :-S
14:45:13 <aleth> nice MDN interface http://instacss.com/
14:50:57 --> ecaron has joined #instantbird
15:06:21 <-- chrisccoulson has quit (Client exited)
15:06:27 --> chrisccoulson has joined #instantbird
15:10:38 <-- chrisccoulson has quit (Ping timeout)
15:12:55 <-- BlueMaxima has quit (Connection reset by peer)
15:18:35 --> chrisccoulson has joined #instantbird
15:28:07 --> mistraven has joined #instantbird
15:28:44 <-- mistraven has left #instantbird ()
15:46:13 <-- clokep_work has quit (Quit: http://www.mibbit.com ajax IRC Client)
15:49:14 <-- gerard-majax has quit (Ping timeout)
16:01:54 --> clokep_work has joined #instantbird
16:01:54 * ChanServ sets mode +h clokep_work 
16:02:24 <clokep_work> flo: Idk if socks proxies work.
16:11:04 <flo> clokep_work: what is this test for http://lxr.instantbird.org/instantbird/source/chat/modules/socket.jsm#354 ?
16:12:15 <flo> why is onConnectionTimedOut never called?
16:12:37 <clokep_work> flo: I believe it's supposed to be "if the connection was reset, then actually reset the connection (or do whatever the user wants to do in that case)"
16:12:59 <clokep_work> It's not? :-/
16:13:21 <flo> if the server closed the connection (because my code has sent it some junk), how am I supposed to be notified currently?
16:13:57 <flo> when this happens, onStopRequest is called with aStatus = 0 (I see this in my terminal), and then I can't get that info to mark the account as disconnected in the account manager
16:14:33 <clokep_work> I'm not sure if I ever ran into that case.
16:14:50 <flo> you would have complained and/or fixed it if you did ;)
16:15:59 <clokep_work> Yup. :P
16:17:04 <flo> next question is: what's the correct fix?
16:23:35 <flo> clokep_work: http://pastebin.instantbird.com/1082
16:32:28 <clokep_work> flo: That looks OK, does "" work as null did for the delimiter?
16:33:44 <flo> null didn't work
16:34:06 <flo> in a test !"" evaluates to true, so like !null
16:34:26 <flo> but there's a place in the code where we do this.delimiter.length without testing that this.delimiter is non null
16:34:28 <clokep_work> OK.
16:34:39 <clokep_work> Ah, got it. :)
16:34:42 <clokep_work> Yes I see that.
16:35:37 * flo doesn't understand well how an XMPPConnection object differs from an XMPPSocket object
16:38:24 <flo> there are too many listeners in that code
16:39:15 <clokep_work> I would think that they should be the same thing.
16:39:27 <clokep_work> the socket code is supposed to be general enough that you can wrap it up however you want by just adding to the object.
16:39:31 <clokep_work> At least that's what I hope. :)
16:40:00 <flo> XMPPSession and XMPPConnection also seem to have the same lifetime, and only one XMPPConnection per XMPPSession, so I don't really see why they are different either
16:41:46 <flo> and I'm always struggling to remember in which file which code is, so I guess I'm really confused between all these similar but different objects
16:43:07 <clokep_work> :( Merge them if possible I'd say.
16:43:20 <flo> and then they all have a this._state variable
16:43:26 <flo> with similar but not identical values
16:43:53 <flo> the value of XMPPConnection._state is set in several places, but never read :-S
16:44:09 <clokep_work> Do they all change together though? (The similar states.)
16:45:55 <flo> I think they are supposed to.
16:46:02 <flo> I would be surprised if they actually did though :)
16:51:25 <clokep_work> :P
16:51:32 <clokep_work> Have you started fully modifying code yet or no?
16:51:50 <flo> does "trying to get it to work" count as "fully modifying"? :-P
16:51:53 <clokep_work> Not sure if you were doing an iteration of fixing to just "get it working" first.
16:51:56 <clokep_work> Hahah.
16:52:06 <clokep_work> I meant are you rewriting parts that seem OK but inefficinet, etc.
16:52:16 <flo> I've just fixed the XML pretty printer so that it outputs correct-looking XML in my terminal
16:52:24 <flo> I think that will help further debugging
16:52:55 <flo> when something seems inefficient/poorly indented/whatever and I can rewrite it without changing the overall logic, I do
16:53:23 <flo> I would like to get something that actually works before starting the significant refactorings (merging similar objects, simplifying chains of listeners, ...)
16:53:40 <flo> and I would also like to have a good understanding of the current code before changing everything
16:56:27 <clokep_work> OK, That answers my question. :)
17:16:55 <flo> hmm, my build is completely broken :-S
17:17:22 <flo> broken conversation window, account wizard and add buddy dialogs :-/
17:18:05 <flo> surprising that the account manager still works fine
17:22:20 * flo rebuilds from scratch :(
17:31:36 <-- MadWookiee has quit (Quit: Instantbird 1.1)
17:35:47 --> igorko has joined #instantbird
17:41:00 --> hunsly has joined #instantbird
17:45:12 <flo> clokep_work: someone else has had your shutdown crash, and without any extension installed: http://crash-stats.instantbird.com/report/index/5a1d1bfa-53ec-4063-b887-3cfd62111113
17:46:11 <-- hunsly has quit (Ping timeout)
17:46:54 --> Mook_as has joined #instantbird
17:48:08 --> devfil has joined #instantbird
17:48:54 <-- GeekShadow has quit (Ping timeout)
17:49:22 <clokep_work> Yup, on Windows XP too.
17:54:18 <clokep_work> Defnitely not me. :)
17:55:09 --> Guido has joined #instantbird
17:55:17 <clokep_work> I wish I could reproduce on my debug build so I could try your patch though. :(
18:06:21 <flo> I wish rebuilding didn't take so long
18:06:24 --> hunsly has joined #instantbird
18:06:31 <flo> or maybe I should just buy a newer laptop :-S
18:23:38 <flo> ah, finished. 59minutes and 55secondes.
18:24:48 <flo> and it doesn't work better :(
18:28:16 <flo> arg, I had just missed a ! in a change I made to a file related to xbl to reduce the amount of warnings in my terminal :(
18:38:19 --> GeekShadow has joined #instantbird
18:41:08 --> gerard-majax has joined #instantbird
18:46:39 <-- Guido has quit (Quit: Instantbird 1.1)
18:50:03 <-- chrisccoulson has quit (Quit: Ex-Chat)
19:06:43 --> chrisccoulson has joined #instantbird
19:07:41 <-- flo has quit (Quit: Instantbird 1.2a1pre)
19:39:43 --> EionRobb has joined #instantbird
19:42:41 <-- SM0TVI has quit (Ping timeout)
19:43:57 --> SM0TVI has joined #instantbird
19:51:28 <-- mmkmou has left #instantbird ()
19:52:12 --> igorko1 has joined #instantbird
19:52:31 <-- igorko has quit (Ping timeout)
20:01:24 --> Guido has joined #instantbird
20:02:32 <Guido> i just tryed to move my contacts and history from instantbird windows to instantbird linux, but it does not work
20:04:13 <Guido> if i have a look at the maps by windows and linux they are different. the linux version dos not contin any folder caled "profile"
20:06:57 <Guido> what can i do?
20:12:29 <aleth> On Linux, the profiles folder is called .instantbird, a subdirectory of your home directory
20:12:58 <Guido> http://www.instantbird.com/faq.html#profilefolder
20:13:22 <aleth> Yes
20:13:25 <Guido> so i copied everything from profile to the map instandbird
20:13:36 <aleth> To have it easy, just run IB once before attempting to transfer any profiles
20:13:50 <aleth> This will set up the directory structure and might make it more obvious where to put things
20:13:59 <Guido> what is IB?
20:14:05 <aleth> instanbird ;)
20:14:50 <Guido> with adding a account?
20:15:03 <clokep_work> It doesn't matter.
20:15:04 <clokep_work> Just run it.
20:15:26 <clokep_work> It's better to do it that way anyway, otherwise you'll hvae to change the reference to your default profile.
20:15:40 <Guido> okee, i will try it. i have to change on this computer so i will be offline
20:16:56 <Guido> oh and by linux is a map "defaults", but by windows is a submep from profiles "default" with some letters in front
20:17:12 <Guido> have i to replace them?
20:18:02 <Guido> i will try
20:18:13 <-- Guido has quit (Quit: Instantbird 1.1)
20:18:50 <aleth> You could just leave the default profile as it is and then open your transferred profile by starting Instantbird with the -P option
20:20:11 <aleth> clokep_work: Is it actually known to work, transferring profiles between OS?
20:21:19 <clokep_work> aleth: I've done it with Thunderbird.
20:21:22 <clokep_work> I don't see why it wouldn't work.
20:21:38 <aleth> As long as there are no explicit paths...
20:22:34 <aleth> The usual Win->Linux issue is \ to / in paths
20:22:56 <aleth> But it's good to know that it works
20:23:14 <-- igorko1 has quit (Ping timeout)
20:25:00 <clokep_work> What paths are there in the profile at all...?
20:25:26 <aleth> Hopefully none :)
20:26:05 <aleth> I just never actually checked.
20:26:20 <clokep_work> I don't see what path there would be...
20:26:25 <clokep_work> They should all be based on the profile dir anyway.
20:26:45 <aleth> And extensions should use chrome uris
20:27:27 --> igorko has joined #instantbird
20:28:51 <clokep_work> I think they have to in most cases.
20:41:13 --> flo has joined #instantbird
20:41:13 * ChanServ sets mode +qo flo flo 
20:43:22 <flo> in most cases / works on Windows too as a folder separator in paths
20:47:12 <-- ecaron has quit (Quit: Instantbird 1.1)
20:47:19 --> ecaron has joined #instantbird
20:53:18 --> timA has joined #instantbird
20:54:59 --> Guido has joined #instantbird
20:55:08 <-- timA has quit (Quit: Instantbird 1.1)
20:55:38 <Guido> i just tryed again moving my profile from windows to linux, but without succes
20:56:56 <Guido> it is very strange. i deleated al maps from instandbird on linux and downloaded it again. and started it. again one account i added earlyer was to see
20:57:36 <aleth> Just copy the whole folder into .instantbird
20:57:45 <aleth> Then run instantbird with "instantbird -P"
20:58:04 <flo> aleth: both profiles will have the name "default"
20:58:14 <flo> but with a different hexadecimal prefix
20:58:25 <aleth> flo: I thought he said he had deleted the original default profile
20:58:48 <flo> aleth: even if he has, he needs to have a valid profile.ini file for the profile to be found at startup
20:59:03 <Guido> at first i started instantbird on linux - no accounts
20:59:29 <Guido> than i just added one account (msn) to se if some new maps apear
21:00:03 <Guido> after that i delited the compleat map "instantbird" en download file
21:00:43 <aleth> Guido: When you say "map", do you mean "directory"?
21:01:31 <Guido> i downloaded instantbird again, started it again and ther weher the informations about my msn account.
21:01:57 <Guido> yes
21:01:58 <aleth> Probably you did not delete the .instantbird directory
21:02:24 <Guido> i downloaded it on the desktop and unpaked it there
21:02:39 <Guido> and run it from there
21:02:48 <aleth> But the profiles are stored in .instantbird, a subdirectory of your home directory
21:03:11 <-- gerard-majax has quit (Ping timeout)
21:03:35 <Guido> so there is a new directory made
21:03:47 <aleth> Yes, if it's not already there.
21:04:19 <aleth> That is where you should copy your profile folder from Windows. Then start instantbird with "instantbird -P profilename", where you replace profilename with the exact name of the profile folder you copied.
21:04:29 <aleth> That should add it to profiles.ini, flo, right?
21:04:59 <flo> no
21:05:32 <flo> you should either edit profiles.ini, or use the one from Windows, or use the newly created <something>.default folder, and copy there the files you had on Windows.
21:06:20 <Guido> okee, i wil have a look again.
21:06:21 <flo> aleth: |-P <profilename>| only works if the profile <profilename> is already listed in profiles.ini
21:07:49 <aleth> flo: good to know.
21:08:04 <Guido> so coppy the directory profile with the profil.ini in the same directory
21:08:04 <aleth> Probably the second option is the easiest one to take for Guido
21:08:53 <Guido> do you mean this " use the one from Windows"?
21:09:27 <Guido> i will try it
21:09:37 <aleth> Guido: Yes. You can delete everything in .instantbird and then transfer your profile folder from Windows into it. This should consist of a file profiles.ini and a directory <something>.default
21:10:22 <-- Guido has quit (Quit: Instantbird 1.1)
21:10:39 <clokep_work> When I was doing this with Thunderbird I had symlinked the auto created profile on Linux (i.e. xxxxxx.default) to my windows one of (i.e. yyyyyy.default).
21:10:52 <clokep_work> But I let both of them make the account first and shared the contents.
21:10:59 <clokep_work> "make the profile first" rather
21:11:18 <flo> yeah, whatever. With some common sense it's easy to figure it out.
21:11:54 <flo> But the previous discussion left me wondering if Guido really understands the difference between the application and profile folders.
21:12:13 <aleth> flo: exactly. If he knew precisely what he was doing he wouldn't be asking
21:12:25 <EionRobb> don't ask, don't tell
21:13:13 <clokep_work> At least he's not asking to do it with a binary extension. ;) I don't want to have to explain that one.
21:13:22 <flo> EionRobb: hey, why wouldn't we be linking the prpls we ship by default statically into purple.dll?
21:15:29 <aleth> General question: I'm looking at bug 1169 and the request for being smart about previous pings. How about filling in the previous ping nick when Tab is pressed in an empty box? I ask because of course it would break shifting focus from the textbox in some circumstances
21:15:32 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1169 enh, --, ---, nobody, NEW, Make tab completion smarter
21:16:06 --> Guido has joined #instantbird
21:16:17 <Mook_as> do people expect tab-focus-change in tab-autocomplete textboxes? I wouldn't...
21:16:43 <flo> Mook_as: do people expect tab-autocomplete in a textbox when it's known that tab is used to change the focus?
21:16:53 <Mook_as> (might be nice to make sure there's _some_ response on pressing tab, though, even when nothing can be completed.)
21:17:31 <Mook_as> ah, I guess then it's really about "should tab completion exist"
21:18:07 <aleth> I already have a patch that treats active nicks preferentially
21:18:08 <Guido> Yes, it's working :-)
21:18:09 <flo> Mook_as: doing it only when the textbox wasn't empty (and the user was obviously typing, and not just moving focus around) seemed a good compromise between the two expected behaviors
21:18:17 <aleth> Guido: good :)
21:19:37 <Mook_as> flo: ah; I feel like changing behaviours is just weirder.
21:19:54 <aleth> So the question is whether treating the sender of the last ping specially is necessary, as he will always be active.
21:19:54 <Mook_as> (i.e. I'd rather it's one or the other, and not dependent on things like "is there text in the box")
21:20:33 <Mook_as> aleth: not if you pong after three hours...
21:21:15 <aleth> Mook_as: But after such a gap you wouldn't necessarily expect completion to be that smart either
21:21:25 <flo> aleth: I think how recent the activity is is more important than pinged or not
21:21:30 <aleth> I am trying to avoid solutions that are "too smart"
21:21:42 * Mook_as agrees that no special treatment is probably more useful
21:22:01 <aleth> flo: In that case I will submit my current patch, which should cover that
21:22:02 <Mook_as> (you wouldn't expect the person to still be around, but that's why it's a pong instead of just start talking)
21:22:10 <flo> aleth: just deciding on whether the nick is currently active in the nicklist sounds ok
21:22:26 <flo> at least, it would already be a very nice improvement compared to what we have now!
21:23:15 <aleth> flo: Yes, it's surprisingly helpful :)
21:23:41 <flo> Mook_as: I think completing an empty string is non sense. If the software knows what I will say, it would as well type the whole message for me and send it :-P
21:24:03 <Mook_as> flo: I'm not saying it should actually complete anything, just that it shouldn't change focus
21:24:10 <Mook_as> (it should, however, do _something_)
21:24:19 <flo> write an add-on to disable the focus change? :)
21:25:17 <aleth> It's possible completely breaking focus change is bad for accessibility reasons too
21:25:41 <flo> aleth: it's the reason why I wanted the behavior we have now ;)
21:26:38 <flo> an interdiff between the patch I attached yesterday and what I have now gives this diffstat: 12 files changed, 214 insertions(+), 372 deletions(-)
21:27:00 <aleth> flo: proving to be a larger rewrite than expected then?
21:27:30 <flo> the whole patch: 15 files changed, 2365 insertions(+), 5 deletions(-)
21:27:40 <flo> so I've touched only ~10% of it for now :)
21:28:22 <flo> I'll keep editing (improving?) it until I'm satisfied with it, so there are more changes to come ^^
21:29:35 <-- Guido has quit (Quit: Instantbird 1.1)
21:30:01 <flo> I've already fixed the typing notification behavior, and fixed the default status (Varuna's code used to set the user as Chatty when the selected status was just Available)
21:30:20 <-- clokep_work has quit (Quit: http://www.mibbit.com ajax IRC Client)
21:30:54 --> Guido has joined #instantbird
21:34:14 <Guido> okee, is it possible to fix IB on the right side and not on the left?
21:36:47 <aleth> Seems instantbot no longer posts review requests
21:36:54 <aleth> Guido: What do you mean?
21:37:54 <Guido> perhaps the reason is the integration addon for linux. if i start instantbird it always apears on the left, but i would like to have it on the right
21:38:00 <flo> nor attachments
21:39:05 <aleth> Guido: It could be. There is unfortunately a long-standing bug - the position of various windows is not correctly remembered even within a session sometimes.
21:39:08 <flo> Morian: it seems Instantbot no longer tells us about new bugzilla attachments/review requests
21:40:00 <-- igorko has quit (Quit: Instantbird 1.1)
21:40:02 <Guido> i see
21:41:49 <flo> aleth: I don't understand what you are doing with this patch
21:42:46 <aleth> flo: When there is only one possible completion, nothing need change. When there are multiple possible completions, but only one of them is an active nick, complete with that nick.
21:43:05 <aleth> How else would you give active nicks preferential treatment?
21:43:06 <flo> why are you printing a system message in that case?
21:43:46 <aleth> That is arguable. I kept it because it is conceivable that the active nick was not the one the user wanted to complete.
21:44:01 <-- Guido has quit (Quit: Instantbird 1.1)
21:44:11 <aleth> E.g., off the top of my head, if she just joined the conversation and not that many nicks are active yet.
21:44:22 <flo> bleah, no. Either you can make the right decision and you complete the nick, or you can't and you print the message. Not both :).
21:45:12 <aleth> So, ditch the system message in that case? I don't mind either way
21:45:48 <flo> if you have 3 nicks, aaab [active], aaac [active], and abbb, the user types "a<tab>", which behavior do you think is right?
21:46:33 <aleth> Show all possible completions.
21:46:51 <flo> and no prefix at all?
21:47:04 <flo> ok
21:47:05 <aleth> I think so.
21:47:40 <aleth> The question is what is the expected behaviour? My thinking was to err on the side of not trying to guess too much.
21:48:25 <flo> I think if I press <one letter><tab>, I expect the software to know which nick I mean
21:48:51 <aleth> But in your example, it's not unique anyway.
21:49:15 <aleth> Would you prefer it to complete to "aaa" in that case?
21:50:38 <flo> I'm not sure
21:51:02 <aleth> Neither am I, so I went with the conservative option for now
21:51:42 <flo> there are 2 possible ways to behave: 1. If there's only one active nick in the list of possible completions, use it, otherwise treat active an inactive nicks the same. 2. If at least one nick is active in the list of possible completions, ignore the inactive nicks.
21:51:59 <aleth> Yes.
21:52:07 <flo> aleth: putting a system message (= warning) in front of me isn't conservative from my point of view :).
21:52:35 <aleth> flo: it was there before :) but I take your point
21:54:02 <flo> sure, it was there before. I thought removing it was the reason why the bug was filed :)
21:55:42 <flo> the approach 1. may be a bit more "conservative" (from your point of view) I guess :)
21:57:17 <aleth> I personally don't mind which approach is taken.
21:59:49 <aleth> 2) will work better as long as you have been in the channel for a while already.
22:01:23 <flo> it will save more time I think / give partial completions more often
22:01:29 <aleth> This might be a good way of thinking about it: Is there ever a circumstance where you want to complete a nick of someone who isn't already visibly speaking?
22:01:47 <aleth> If not, 2) is better
22:02:00 <flo> Morian a few minutes ago to talk about instantbot. And Mook was active.
22:02:40 <Mook_as> and if you're NeilAway, whoever pinged you 3 hours ago :p
22:03:24 <flo> Mook_as: whoever pinged you 3 hours ago's nick is still active, isn't it?
22:03:39 <Mook_as> hmm, what's "active" determined by?
22:03:43 <flo> Mook_as: by the way, it seems saying Mook works as well as pinging your full nick ;)
22:03:58 <Mook_as> flo: well, yes, because I stalk it :P
22:04:00 <flo> Mook_as: has talked at least once since the conversation is in the tab I think
22:04:05 <Mook_as> ah
22:04:17 <Mook_as> then, yes, anybody I might ever be interested in replying to will always be active
22:04:33 <Mook_as> (it just won't be useful if you kept the view open for a week)
22:04:37 <flo> yeah, if you want to reply to someone, that person is very likely with an active nick
22:04:56 <flo> but when pinging someone, that doesn't work as well
22:05:24 <flo> Mook_as: hmm, not sure. I would bet less than 10% of people in #developers talk during a given week.
22:05:26 <aleth> For your example above, since Mook was active, you'd get m completed to Mook even with option 1)
22:05:58 <flo> aleth: yeah, I would need to type Mor<tab> anyway
22:06:10 <flo> but with the current behavior, M<tab> shows the 2 possible completions
22:06:22 <aleth> yes, that's why I kept the system message ;)
22:06:44 <flo> if I need to find the backspace key, you've already messed up my train of thoughts ;)
22:07:26 <aleth> If you never allow false positives, no added smartness seems possible ;)
22:08:53 <flo> I think it's relatively safe to expect that people pay more attention to what has been completed when they are pinging someone than when they are replying
22:10:34 <-- devfil has quit (Client exited)
22:10:43 <aleth> True.
22:11:37 <aleth> Both 1) or 2) will be most useful for rapid replying in channels with many inactive nicks.
22:12:20 <flo> I think we should try 1) first.
22:12:48 <flo> With 2, we would be showing in system messages incomplete lists of possible completions, that would probably seem strange to the user
22:13:29 <aleth> 2 is quite close to "only complete from active nicks"
22:13:45 <flo> aleth: hmm, if someone pings timeout and comes back, he's marked back as inactive, right? :-/
22:14:06 <aleth> Which is too extreme imho
22:14:36 <flo> I would like us to complete on all previously used words
22:14:46 <flo> and show the completion like OpenOffice does :)
22:14:55 <-- chrisccoulson has quit (Quit: Ex-Chat)
22:15:32 <aleth> flo: You mean if someone leaves the room and comes back?
22:15:35 <flo> (that is, the most likely completion is put in the input box, with the completed part selected, so that typing ahead without caring about the completion just overwrites it)
22:16:02 <aleth> What do you mean by "all previously used words"
22:16:07 <flo> aleth: I was thinking specifically of the case of someone with a flacky connection, who's leaving and entering frequently without any user action.
22:16:36 <flo> aleth: any word you have ever typed before in the conversation, or even in any conversation.
22:17:16 <flo> I think OOo does it only for words that are more than 4 or so characters long
22:17:29 <aleth> flo: Right, they won't remain active (currently), but maybe that should be handled in the code when people leave/join channels to check if they were previously present and active
22:17:58 <aleth> flo: hmm isn't that a bit too much of a good thing?
22:18:12 --> debor_ has joined #instantbird
22:18:19 <-- debor has quit (Ping timeout)
22:18:19 <flo> aleth: maybe for an add-on (first)
22:18:22 * debor_ is now known as debor
22:20:54 <aleth> I see what you mean though - do without having to press Tab altogether, instead press a key if you like the completion on offer.
22:21:47 <flo> I think it would still require pressing tab to move the cursor to the end of the selection
22:21:59 <flo> (otherwise continuing to type replaces the completion)
22:22:20 <aleth> Yes, that's what I meant with press a key if you like it
22:22:41 <aleth> The problem is as every word starts with a single letter and would hence be completed to some nick, it might look quite noisy
22:23:48 <flo> except if we complete only words that already have at least 4 letters
22:24:00 --> chrisccoulson has joined #instantbird
22:24:44 <flo> the problem I see is: what show we do when the user presses the enter key and there's a selected completion?
22:25:13 <aleth> oh dear. 
22:25:22 <aleth> It's not obvious at least.
22:25:25 <flo> if I've typed "This is awesome" and I have in the textbox "This is awesome[ness]" and press enter.
22:25:47 <flo> should it becomes "This is awesomeness" (= validate the completion, so that I can backspace it? -> annoying)
22:26:03 <flo> or just send "This awesome" and discard the completion AND send?
22:26:19 <aleth> yeah.
22:26:32 --> instantbot has joined #instantbird
22:26:32 topic changed by gravel.mozilla.org to "Ask questions about Instantbird (http://www.instantbird.com) here|Get Instantbird 1.1 while it's hot! :) |News: http://blog.instantbird.org/ |Nightlies: http://nightly.instantbird.im/ (testing purpose only) |IRC logs: http://log.bezut.info/ |Pastebin: http://pastebin.instantbird.org/"
22:26:32 * ChanServ sets mode +v instantbot 
22:26:33 <aleth> I think the whole thing is an interesting idea but would need a lot of testing to discover what is "natural"
22:26:46 <flo> (obviously it shouldn't remove the "is" in the middle of the sentence :-D)
22:26:56 <flo> hence the start as an add-on :)
22:28:23 <aleth> A possible solution would be to show the guessed completion not as a selection but in light gray, and require a key press (cursor right?) to "turn black" and accept.
22:29:06 <flo> yeah, right arrow, or tab key to accept
22:29:15 <aleth> That's also possibly less 'blinky' than selections flashing up
22:29:15 <flo> then pressing enter should just ignore the ongoing completion
22:29:19 <aleth> yes
22:29:39 --> instantbot has joined #instantbird
22:29:39 topic changed by gravel.mozilla.org to "Ask questions about Instantbird (http://www.instantbird.com) here|Get Instantbird 1.1 while it's hot! :) |News: http://blog.instantbird.org/ |Nightlies: http://nightly.instantbird.im/ (testing purpose only) |IRC logs: http://log.bezut.info/ |Pastebin: http://pastebin.instantbird.org/"
22:29:40 * ChanServ sets mode +v instantbot 
22:29:43 <flo> (OOo uses enter to accept a completion, which is annoying when the user presses enter to insert a new line)
22:30:57 <aleth> (Some code editors do the same, with the completions in a drop down menu)
22:31:45 <aleth> But since nick completion is usually wanted for <4 letters given, it's possibly an orthogonal feature anyway
22:32:17 <aleth> (Forgot to mention the dropdown menu thing is even worse, as it breaks cursor up/down)
22:32:55 <flo> popups are bad ;)
22:33:12 <flo> the light grey idea seemed interesting to try
22:33:28 <flo> the next thing we need is a motivated add-on author ;)
22:41:42 --> instantbot has joined #instantbird
22:41:42 topic changed by gravel.mozilla.org to "Ask questions about Instantbird (http://www.instantbird.com) here|Get Instantbird 1.1 while it's hot! :) |News: http://blog.instantbird.org/ |Nightlies: http://nightly.instantbird.im/ (testing purpose only) |IRC logs: http://log.bezut.info/ |Pastebin: http://pastebin.instantbird.org/"
22:41:43 * ChanServ sets mode +v instantbot 
22:41:58 <Morian> instantbot: hi
22:41:59 <instantbot> hi Morian
22:42:03 <Morian> instantbot: status
22:42:04 <instantbot> Morian: I have 0 factoids in my database and 1 bot friend to help me answer questions. Since the last reload, I've been asked 0 questions, performed 0 edits, and spoken with other bots 0 times.
22:42:05 <instantbot> Morian: I've been up 23 seconds.
22:42:13 <flo> aleth: I usually see obvious mistakes just after someone submits a patch too :-P
22:42:21 <flo> (even when that someone is me)
22:44:01 <flo> aleth: is the behavior of the new patch really different?
22:44:36 <flo> I think you need to move that whole block of code using the activeNick variable above the "          // Only one possible completion? Apply it! :-)" comment
22:45:11 <flo> and "if (activeNick) completions = [activeNick];" needs a \n after )
22:45:20 <aleth> flo: Yes, I am just doing that
22:45:59 <aleth> flo: It would have worked, but it would not have been pretty, and it would still have displayed a system message (with a single nick in it)
22:46:39 <aleth> That's what I meant by obvious mistake...
22:47:05 <flo> the missing \n was already obvious in the previous attachment ;)
22:49:50 <aleth> True ;)
22:50:46 <aleth> There is something wrong with the way the bugzilla diff viewer handles blank lines sometimes
22:50:48 <flo> can't if (this.buddies.hasOwnProperty(c)) and if (!this.buddies[c].hasAttribute("inactive")) be the same test, with an && ?
22:51:04 <flo> that will reduce the indentation level
22:51:53 * Mook_as wonders what the difference is between hasOwnProperty and (c in this.buddies) is in this case
22:51:55 <flo> and please add {} for the for loop and the outer if
22:51:56 <aleth> Depends on how the interpreter works - won't it possibly try to evaluate both before doing the if? Not sure how optimized it is
22:52:12 <Mook_as> aleth: it's short-circuiting, just like in C/C++
22:52:21 <flo> Mook_as: really? I thought you had done some JS work in the past :-P
22:52:27 <aleth> OK good.
22:52:38 <aleth> Was being cautious.
22:53:04 <flo> aleth: if (a && b) <-- if a is false, b will never be evaluated
22:53:34 <flo> Mook_as: ("watch" in {}) returns true.
22:53:44 <aleth> I agree that's the way it _should_ be... but I wasn't sure
22:54:06 <flo> Mook_as: the in operator looks for properties both in the object and in its prototype chain
22:54:30 <Mook_as> flo: ah, I wasn't expecting funnily-named properties :)
22:54:44 <flo> watch isn't that funny for an IRC nick
22:55:03 <flo> __defineGetter__ would be, admittedly :)
22:55:05 <Mook_as> ah, they're IRC nicks. (I'm not actually looking at the patch, since instantbot helpfully didn't mention where it is)
22:55:17 <flo> Mook_as: https://bugzilla.instantbird.org/attachment.cgi?id=1004
22:55:27 <Mook_as> great, now you have me wondering how badly that would break chatzilla
22:55:31 <aleth> __defineGetter__ ;)
22:57:39 <-- micahg has quit (Quit: Ex-Chat)
22:58:01 <flo> Mook_as: enough to make you switch to Instantbird would be a great answer :-D
22:58:29 * Mook_as thinks about /nick hasOwnProperty
22:59:00 <flo> :(
22:59:19 <Mook_as> try using Object.getOwnPropertyNames() instead?
22:59:50 <flo> Object.prototype.hasOwnProperty.call(this.buddies, c) ? :'(
23:00:29 <Mook_as> Object.getOwnPropertyNames(this.buddies).indexOf(c) != -1 ? :(
23:00:50 <Mook_as> (and that's... all over that file)
23:01:03 <flo> we have at least 5 this.buddies.hasOwnProperty occurences in that file
23:01:33 <flo> anyway, that should prevent aleth from improving the completion
23:01:38 <flo> but someone should really file a bug
23:01:44 <Mook_as> that shouldn't, you mean :)
23:01:59 <flo> sure, shouldn't (arrg, stupid typos :'()
23:02:27 <aleth> And there I was wondering whether the "for each" was excessive for an array ;)
23:02:30 <flo> (or we should write some code to automatically kick out or rename people with the "hasOwnProperty" nick :-P)
23:02:50 <Mook_as> that assumes you're an op
23:03:11 <flo> we can rename locally :-D
23:03:20 <flo> _hasOwnProperty :-D
23:03:33 --> hasOwnProperty has joined #instantbird
23:03:41 <-- flo has kicked hasOwnProperty from #instantbird
23:03:41 --> hasOwnProperty has joined #instantbird
23:03:45 <-- flo has kicked hasOwnProperty from #instantbird
23:03:46 --> hasOwnProperty has joined #instantbird
23:03:52 <aleth> hadOwnProperty :D
23:03:52 --> micahg has joined #instantbird
23:03:56 <Mook_as> or just prepend ___ to all nicks
23:04:14 <aleth> hadOwnProperty :D
23:04:15 <Mook_as> (alternatively, use something like http://mxr.mozilla.org/mozilla-central/source/toolkit/content/Dict.jsm )
23:04:42 <aleth> heh
23:04:50 * flo sets mode +b hasOwnProperty!*@* 
23:05:03 <aleth> oh dear
23:05:15 <Mook_as> flo: don't forget to kick too
23:05:20 <flo> hmm, it's the username but not the nick? If so ban is so useless...
23:05:24 <-- aleth has quit (Quit: Instantbird 1.2a1pre)
23:05:32 <Mook_as> oh?
23:05:36 <flo> hmm, it's the username but not the nick? If so ban is so useless...
23:05:54 <-- flo has kicked hasOwnProperty from #instantbird
23:06:01 <Mook_as> and now both flo and aleth are repeating themselves XD
23:06:05 --> aleth has joined #instantbird
23:06:42 --> prototype has joined #instantbird
23:06:58 <Mook_as> prototype: no, you want __proto__
23:07:07 <-- prototype has quit (Quit: Leaving.)
23:07:21 <aleth> fun for all the family...
23:08:30 <flo> Mook_as: would __proto__ really be annoying?
23:08:41 <Mook_as> probably not, actually, just weird
23:08:59 <flo> it's an object without anything in the prototype
23:09:08 <flo> so it wouldn't replace something useful
23:09:17 <Mook_as> it would, however, add a bunch of "new" buddies
23:09:18 <flo> and we don't access .__proto__ anywhere
23:09:35 <Mook_as> (I'm assuming this.buddies[c] has properties on it)
23:10:11 <flo> Mook_as: if it's in the prototype, it hasOwnProperty (ahem) doesn't evaluate to true
23:10:19 <Mook_as> ah, right
23:10:52 <aleth> Can't think of any other nasty nicks
23:12:18 <-- ecaron has quit (Quit: Instantbird 1.1)
23:12:30 <Mook_as> _maybe_ __iterator__, though I'm not certain
23:12:41 <flo> what would it do?
23:13:03 <Mook_as> I'm trying to figure out it screws with Object.keys (it overrides for...in loops)
23:15:12 --> clokep has joined #instantbird
23:15:13 * ChanServ sets mode +h clokep 
23:15:34 <-- clokep has quit (Quit: Instantbird 1.2a1pre)
23:15:37 --> clokep has joined #instantbird
23:15:37 * ChanServ sets mode +h clokep 
23:15:48 <flo> is the ban really banning that nick? Or can someone come in and than change nick into it?
23:16:04 <clokep> So if I set myself "Offline" then "Available" the text gets prefilled w/ "undefined". :-/
23:16:08 <clokep> Can anyone confirm?
23:16:38 <-- aleth has quit (Quit: Instantbird 1.2a1pre)
23:16:43 --> aleth has joined #instantbird
23:17:04 <clokep> And you guys talk a lot. :P
23:17:12 <aleth> clokep: The status message? Can't reproduce that.
23:17:31 <aleth> clokep: Mook_as discovered a way to hack IB ;)
23:18:13 <flo> and EionRob discovered a way to get a nick banned
23:18:44 <clokep> aleth: Yes, from the little picker on the buddy list.
23:19:07 <aleth> flo: there's addBuddy and updateBuddy, you'd have to modify both
23:19:31 <aleth> clokep: I changed status via the tray icon, let me try again just in case
23:19:37 <-- aleth has quit (Quit: Instantbird 1.2a1pre)
23:19:42 --> aleth has joined #instantbird
23:19:43 --> __proto__ has joined #instantbird
23:19:52 <-- __proto__ has quit (Quit: Instantbird 1.1)
23:19:58 <aleth> clokep: Now I can reproduce. :(
23:20:03 <-- Mook_as has quit (Input/output error)
23:20:32 --> Mook_as has joined #instantbird
23:20:34 <aleth> clokep: To be clear, if you change status via the tray icon it doesn't happen.
23:21:43 <Mook_as> so, yeah, that broke chatzilla pretty badly
23:21:57 <flo> aleth: there are at least 5 this.buddies.hasOwnProperty calls, + 1 you are adding
23:22:06 <flo> Mook_as: ah?
23:22:13 <clokep> aleth: Yeah, OK. I'll file a bug.
23:22:14 * flo feels a very little bit less bad about it
23:22:24 <flo> clokep: likely a regresison from 759
23:22:32 <Mook_as> flo: __proto__
23:23:03 <aleth> flo: I misunderstood, I thought you were serious about simply not allowing that particular nick to be set without modification, rather than replacing hasOwnProperty.
23:25:19 <flo> lol
23:25:36 <aleth> I was a little surprised...
23:26:54 <flo> Mook_as: Object.prototype.hasOwnProperty.call({hasOwnProperty: 42}, "hasOwnProperty") works
23:27:18 <Mook_as> \o/
23:27:20 <flo> aleth: I guess you would prefer that I commit your patch before fixing that?
23:27:51 <aleth> Probably cleaner that way.
23:27:53 <clokep> Was the decision to use the Dict.jsm or to prefix or something else funky?
23:28:04 <aleth> But up to you...
23:28:26 <clokep> (also, do we have a similar situation with like room names?)
23:28:50 <aleth> Or buddy names in the contact list?
23:29:02 <flo> clokep: http://lxr.instantbird.org/instantbird/search?string=hasOwnProperty check...
23:29:32 <flo> commands named hasOwnProperty would be annoying
23:29:44 <flo> but I hope Even would deny the review for such an add-on :)
23:29:46 <clokep> flo: Twitter has it too.
23:29:53 <clokep> _participants.hasOwnProperty
23:33:09 <aleth> flo: What's the role of {hasOwnProperty: 42} in your fix?
23:35:15 <flo> it's not a fix, just a test for the error console
23:35:56 <aleth> ok :)
23:36:11 <clokep> (And I believe 42 is the answer to life, the universe and everything?)
23:36:27 <aleth> (or at least 6*7)
23:37:46 <flo> I control http://twitter.com/#!/hasOwnProperty to there's nothing to be scared of on that side.
23:38:39 <flo> *so
23:39:50 <-- chrisccoulson has quit (No route to host)
23:40:10 <flo> hmm, can we decide we don't need to fix twitter?
23:40:18 --> chrisccoulson has joined #instantbird
23:40:39 <flo> that username can't ever appear in anybody's twitter participant list until that username (which I've secured) says anything, right?
23:41:03 <Mook_as> until your password gets stolen :p
23:41:46 <flo> the password isn't hasOwnProperty (or any other JS keyword :-P)
23:41:49 <-- chrisccoulson has quit (Quit: Ex-Chat)
23:41:56 --> chrisccoulson has joined #instantbird
23:43:41 --> instantbot has joined #instantbird
23:43:41 topic changed by gravel.mozilla.org to "Ask questions about Instantbird (http://www.instantbird.com) here|Get Instantbird 1.1 while it's hot! :) |News: http://blog.instantbird.org/ |Nightlies: http://nightly.instantbird.im/ (testing purpose only) |IRC logs: http://log.bezut.info/ |Pastebin: http://pastebin.instantbird.org/"
23:43:41 * ChanServ sets mode +v instantbot 
23:44:50 <flo> Mook_as: only if you put them on hold by hand, right?
23:44:54 <flo> or is there a bug somewhere?
23:45:08 <flo> (I know the twitter code doesn't handled the |left| attribute currently)
23:54:21 --> instantbot has joined #instantbird
23:54:21 topic changed by gravel.mozilla.org to "Ask questions about Instantbird (http://www.instantbird.com) here|Get Instantbird 1.1 while it's hot! :) |News: http://blog.instantbird.org/ |Nightlies: http://nightly.instantbird.im/ (testing purpose only) |IRC logs: http://log.bezut.info/ |Pastebin: http://pastebin.instantbird.org/"
23:54:21 * ChanServ sets mode +v instantbot 
23:54:28 --> DGMurdockIII has joined #instantbird
23:55:35 <Mook_as> clokep: you're clearly not evil enough.
23:56:44 <clokep> Mook_as: Oh?
23:56:53 <clokep> Well then whoever wrote that code needs a smacking. :P
23:57:26 <clokep> We could use the md5 hash of everything as keys. ;)
23:57:27 <Mook_as> no _built-in_ properties start with :, which makes it safe
23:57:43 <Mook_as> because it's all about unintended consequences, and things on Dict's proto chain are known to be fine
23:57:46 <clokep> Mook_as: Yes, but who's silly enough to use that as a property starter. ;)
23:58:13 <Mook_as> people who hate themselves and don't want to use the foo.bar syntax? :p
23:58:27 <clokep> :P
23:58:53 <flo> how do you feel about http://pastebin.instantbird.com/1085 ?