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 1.9.2.13/20101203074205]) 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 ?