=== asac_ is now known as asac [01:18] <[reed]> fta: a ton of Mozilla people hate Hg [01:18] <[reed]> if something else came along that was better [01:18] <[reed]> we'd totally switch [01:19] i'm surprised you didn't jump on git. what was it ? win support ? [01:20] <[reed]> yeah, win support [01:21] it seems it improved a lot recently [06:05] anyone around yet? [06:20] Jazzva: do we really need to package chatzilla since you packaged the other extension thar is pretty much same (as far as i can tell) [09:02] hi ! [09:20] asac ? [09:23] hi XioNoX [09:25] good weekend ? [09:25] yep [09:26] went to an island where a friend is living now ;) [09:29] nice [09:29] what is the program for today ? [09:29] :D [09:35] i didnt work anything out yet [09:35] did you think about what i ment? [09:36] like activating the menu entry when we the event comes from current selected tab? [09:38] I've think about it [09:39] but I don't really understand it [09:39] :) [09:42] this : XioNoX: sure. ... remind me that i wanted to tell you something about that [09:42] XioNoX: once you implemented that events from the current active tab automatically active the menu ? [09:42] XioNoX: right. so i already said what I wanted to tell you [09:42] the last line should make it clear [10:00] seem to work [10:00] :) [10:01] cool [10:01] so where are we now? [10:01] XioNoX: we have a working menu entry? [10:02] that - once clicked - can gather the current mime types? [10:02] and open the "plugin wizard" with those plugin infos? [10:02] not yet [10:02] but soon :) [10:02] XioNoX: i think getpluginInfo is nice, but its not reall what we want [10:02] from the mime-type perspective [10:02] ? [10:02] e.g. now we get _all_ mime-types the plugin supports [10:03] but what we want is just the mime-type that the content of the website uses [10:03] but if there are many different mimetypes ? [10:04] XioNoX: what do you mean? [10:04] XioNoX: the idea is to gather the mime-types used on the tab [10:04] I agree [10:04] not the mime-types supported by all plugins used on the tab [10:05] with getPluginInfo we do the latter [10:05] I don't get it [10:06] what in particular isnt clear? [10:06] XioNoX: the idea is to gather the mime-types used on the tab [10:07] it is what we do, no ? [10:07] no [10:07] you use getPluginInfo [10:07] which gives you all mime-types supported [10:07] look at about:plugins [10:07] when you look at that page in firefox you see that every plugin can support many mime-types [10:08] ok [10:08] not 100% sure [10:08] XioNoX: have you tried a page with just flash on? [10:08] is there still the "director" mime-type? [10:08] but getPluginInfo return mimetype of content who are not supported [10:08] if so, getPluginInfo is wrong [10:08] he? [10:08] no no [10:08] "not supported"? [10:08] yes [10:09] if you don't have flashplugin installed [10:09] and you go on youtube [10:09] he will give you he mimetype of flash stuff [10:10] youtube return only flash [10:10] mimetype [10:12] yes [10:12] and since getPluginInfo also gives you the "director" mime-type [10:13] we would ask the user to select alternatives for a mime-type he doesnt care about [10:16] but it is because director is present on the page [10:16] if you go on youtube the only mimtype present is flash stuff [10:22] director mimetype is because there are director content on the adobe testpage [10:29] the point is I'm not sure that the "plugin wizard" can handle many différent mimetypes [10:29] if there are different content on the page [10:35] XioNoX: ah... cool [10:36] XioNoX: so next is to open the plugin finder wizard (the old and rotten one) with the mimeInfo Array [10:36] rotten? [10:36] XioNoX: scratch that [10:36] ok [10:36] the original pluginfinderwizard that is currently implemented in ubufox [10:38] Jazzva: i wanted to upload nspluginwrapper to intrepid [10:40] asac, ok... I think there's still the problem with popping-out of nsviewer [10:40] but maybe that's just me ;). [10:40] but, it's there in the older version too, so I don't think we will have a real regression [10:44] I'm having troubles with threads in the school project. Some of them are still sleeping, even after they should be woken up :). [11:05] anyone else have issues with the latest kernel "-5" (file system is read only?) also lose the system beep? [11:06] which in turn makes it impossible to configure X so now there is no X with -5 [11:09] Jazzva: threads are easy to deadlock ;) [11:09] gnomefreak: hmm ... i had issues with file-system [11:09] gnomefreak: but that was just for one boot [11:09] since then its working [11:11] gnomefreak, related to chatzilla... I hadn't get snowl to work, when I was packaging it... neither from package, nor from xpi [11:11] asac, apparently :) [11:11] asac: ah i only tried one boot the second boot i got a ncurses screen with repair, boot, config X and one other dont remember [11:12] Jazzva: threads in Java, python, C? [11:12] Jazzva: ah ok. and is chatzilla gonna be a special build since it is in a java dir and due to XUL? [11:12] Jazzva: does snowl have native components? [11:13] asac, Java... [11:13] asac, native components? [11:13] i would assume its same set up as chatzilla [11:13] or atleast close [11:14] asac, actually, I'm still investigating why it blocks. The receive in that socket works great, and the send just started blocking for some reason... [11:15] i will look for source for chatzilla today but i have a feeling the XUL is gonna cause this to be something where XPI.TEMPLATE [11:15] doesnt work [11:15] sound juicer needs a kick in arse [11:20] Jazzva: why do you want to do threads? [11:20] Jazzva: native components == components/*.so files exist [11:21] asac, well, I need a thread for that listens for new connections, and then threads that will do the communication with clients and workstations (thats on server-side)... something like that [11:22] s/for that/that/ [11:23] asac, seems that snowl doesn't have native components [11:28] Jazzva: the modern way of doing this is using nio [11:28] e.g. non-blocking IO [11:28] for that you dont need threads [11:28] will read a bit about that :) [11:30] Jazzva: anyway. what you need to do if you want to do multiple threads [11:31] is implement a work queue that the clients poll on and where the server puts the work received from the clients [11:31] in that way you shouldnt dead lock [11:33] e.g. new Client() { public void run() { while(workQueue.isntDead()) { Work work = workQueue.nextWork(mytimeoutinms); } } [11:33] e.g. new Client() { public void run() { while(workQueue.isntDead()) { Work work = workQueue.nextWork(mytimeoutinms); processWork(work); } } [11:33] ;) [11:33] well actually ;) [11:34] e.g. new Runnable() { public void run() { while(workQueue.isntDead()) { Work work = workQueue.nextWork(mytimeoutinms); sendWorkToClient(work, client); } } [11:34] and then Thread t = new Thread(runnable); t.start(); [11:35] workQueue needs to be a threadsafe mutex obviously [11:35] right... but now that's not a problem :) [11:36] server thread regularly checks for new messages from client and it fetches them fine... [11:36] the problem is when I try to send a message from that thread... that's when everything locks... and I got another idea now :) [11:36] well s/client/workstation/ [11:37] Jazzva: from which thread are you trying to send? [11:37] maybe your "send" method is synchronized and when that send blocks everything else is waiting for it? [11:38] hmm... let me see... might be... i was experimenting with wait()/notify() and maybe I forgot to remove synchronized, when I found out where I need to use wait() and notify() [11:39] that actually might be the problem... but then I don't know how to solve it :) [11:40] I made my SocketCommunicator class that has methods for sending/receiving strings/Objects, and I kept getting NullPointerExceptions when I tried to send as soon as I started the server, because the SocketCommunicator still wasn't initialized [11:40] s/wasn't initialized/didn't finish initialization/ [11:40] hmm... let's se [11:40] see [11:41] Jazzva: you should use preexisting thread safe work queues [11:41] instead of reinventing and trying to implement a mutex on your own [11:41] though its fun to actually do it ;) [11:42] Jazzva: the code snippet about is basically the "work dispatcher" code that should work [11:42] the server socket will be read from another thread, which puts new Work(....) into that work queue [11:43] I think the thread where it reads/writes from/to socket is the problematic one :) [11:43] let's see if it will work now [11:44] sounds shaky [11:45] Jazzva: personally i would use a tiny embedded http server [11:45] err, servlet engine [11:45] I'm still not that much expirienced :) [11:45] jetty ;) [11:45] you can start that and implement the "job accept code" in a servlet then [11:46] jetty? [11:46] but well [11:46] Jazzva: http://docs.codehaus.org/display/JETTY/Embedding+Jetty [11:47] http://www.mortbay.org/jetty-6/ [11:47] but well. maybe the idea of that school project is to learn about how to use socket on the low-level ;) [11:47] not sure [11:48] maybe... :) [11:48] I suppose it would be, since they thought us with using threads and sockets and the rest... [11:50] asac, synchronized was the problem... [11:51] But I'm still not sure why it was messing up... all the initialization is done in the constructor, so it shouldn't call a method, until a constructor is done. by that time, all attributes should be initialized, but I still got null pointers for some... [11:52] ah no... I was stupid :) [11:53] The problem wasn't there... It was in the sendMsg method, that was always sending to fixed client (for testing purposes), but didn't check if the client exists... [11:53] Thanks for the help :) [11:53] Once I put up that check no more null pointers [11:54] if using .xpi i unpack it but do i push bleh.xpi to .upstream branch? [11:54] gnomefreak, no... you should just push the source of the unpacked xpi [11:54] ok thought so [11:54] Jazzva: thanks [11:55] i will see what i can do with chatzilla than [11:57] no problem :) [12:00] Jazzva: just removing synchronized will probably cause concurrency issues [12:00] Jazzva: you ned to use thread safe work queue ;) [12:01] but this is just for sending/receiving. each thread has it's own socket communicator, so there shouldn't be problems :) [12:01] each thread has it's own input and output streams, so that should be fine... right? [12:04] what does -d do for cvs? cvs --help dpesnt well help [12:04] -d cvs_root_directory [12:04] Use cvs_root_directory as the root directory pathname of the repository. Overrides the setting of the $CVSROOT environment variable. See node `Repository' in the CVS manual. [12:04] that's what man cvs says [12:05] gnomefreak ^ [12:05] its telling me i didnt set the CVSROOT environment variable. and i did with CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot [12:05] Jazzva: well ... but how do you get the input to the output stream? [12:05] there should be some inter-thread boundary which you need to pass using proper synchronization [12:05] in almost all cases. [12:05] (because you onlyhave one serversocket thread and multiple client socket threads) [12:05] hmm [12:07] hmm.. probably. I didn't think of that... [12:07] I thought of sending clientId before message when I start testing with multiple clients [12:10] I assumed that serverSocket.accept() returns a Socket and that some underlying code will take care that it sends to the right client on the other side, and not to all of them :) [12:14] i'll assume it really does that. If it fails in multi-client environment, I'll start sending client ID before message :) [12:18] should i remove CVS dir before pushing or even CVS in any dir [12:21] I think you should... [12:22] those are just used for cvs management, not for the extension [12:22] gnomefreak ^ [12:23] Jazzva: ok thanks [12:23] makes life easier [12:24] np :) [12:34] shhhhhh dont tell anyone but im kind of liking doing extensions [12:35] hehe :)... you have my full support [12:40] ok will work the dirty part of these in a few [12:41] asac: hey there [12:42] asac: so i've been trying your NM07 branch, you're pretty much syncing against upstream at this point, right? [12:42] asac: i have had one problem in general, you probably did not stumble upon that yet [12:44] asac: NetworkManager-0.7.0_pre/system-settings/src/org.freedesktop.NetworkManagerSystemSettings.service.in is too long of a filename, tar ignores it (at make dist) [12:47] rbu: hmm ... sounds wierd [12:47] rbu: i am synching regularly [12:47] rbu: which branch are you tracking [12:47] ? [12:47] main.eni [12:47] ? [12:47] asac: yep [12:47] asac: well, it's not a problem in your branch [12:47] rbu: the packages i built work [12:48] asac: yeah, i know. you do bzr export or something? [12:48] yes. i dont want the autotools files anyway as i recreate them during package built [12:48] asac: i'm editing configure.in to add a '_pre' at the version number, which makes the directory name longer [12:48] rbu: well. i doubt that the problem is the 4 more letters [12:49] probably there is something hardcoded somewhere which makes the tarball forget about that service file [12:49] asac: it is! tar in dump mode only allows 99 characters in path [12:49] rbu: how do you edit configure.in? [12:50] asac: well, edit the "AC_INIT(NetworkManager, 0.7.0", ./autogen.sh and make dist [12:51] rbu: how can tar be dumber than tar cvzf? [12:51] http://paste.ubuntu.com/38478/ [12:51] asac: http://rafb.net/p/1azELZ79.html [12:51] that path must be much longer as it prefixes Development/ubuntu/network-manager/ ... [12:51] and it works as you can see in the paste [12:52] asac: mind the last two lines [12:52] asac: have you heard of anyone other than Matt G being email bombed yet? [12:52] rbu: yeah [12:52] rbu: strange. looks like a problem in make dist then [12:53] asac: yeah, it is. i wonder if i should ignore it and not change the name, or bug upstream to shorten the filename [12:54] rbu: use bzr export ;) [12:54] well ... but that doesnt add you the autotools things [12:54] not sure [12:55] i dont read anything of the 99 constraint in manpage of tar [12:56] is it automake that complains about that? maybe they check for 99 because BSD tar cannot do more? [12:58] asac: it is tar that complains, but it is automake that tells tar to use "o" [12:59] --old-archive ... like --format=v7; -o exhibits this behavior when creating an archive (deprecated behavior) [12:59] hmm.. telling it to use a newer tar format works [12:59] yay [13:00] asac: as here http://www.cygwin.com/ml/automake/2004-11/msg00118.html [13:03] argh [13:04] what a pain [13:04] not my problem :) [13:04] rbu: i think you could just repack the "normal" make dist thing [13:04] and rename the top level dir [13:04] once upstream hits the 99 char boundary, they will probabyl think what to do [13:05] if you want, you can send an email to networkmanager-list of course [13:05] asac: all hacks! i'll prepare that one line patch and send it upstream [13:06] yep [13:06] breave [13:06] brave ;) [13:07] asac: why? bad experience with accepting patches? [13:08] asac: otherwise, i'll harrass you to apply it in your branch :-P [13:09] no [13:09] go upstream [13:10] brave == appreciated ;) [13:22] Jazzva: what version is the following [13:22] # 12/03/01, ChatZilla 0.8.5, [13:22] Shipped with 0.9.7. [13:23] asac: mail is out, i'll go on testing then [13:24] good [13:24] XioNoX: managed to open plugin finder wizard? [13:25] there seems to be a 0.9.83 as well but the above came from upstream changelog [13:26] yes [13:26] asac [13:26] gnomefreak, paste it somewhere.. [13:26] XioNoX: rock ;) [13:26] XioNoX: please commit it as an intermediate checkpoint ;) [13:26] but there are a problem :( [13:26] what is it? [13:26] 2problems [13:27] if there are many mimetypes, the progressbar get stuck... [13:27] huh? [13:27] which progressbar? [13:27] Jazzva: ok http://pastebin.mozilla.org/519226 and 0.9.83 is mentioned at http://www.hacksrus.com/~ginda/chatzilla/ [13:27] of the plugin finder [13:27] 0.9.83 isnt from CVS nor can be gotten from it [13:28] secondly, it don't save the mimetypes in the tab [13:28] weird, because it was working before [13:28] ah its a nightly build [13:28] gnomefreak, use 0.8.5 [13:28] Jazzva: ok thanks [13:29] In the previous changelog entry it said "Shipped with Mozilla 0.9.4, 0.9.5, and 0.9.6", so I suppose that's what 0.9.7 means [13:29] np :) [13:29] thats what i pushed it as but just needed to make sure [13:30] gnomefreak, did you download from cvs or a xpi file? [13:31] XioNoX: ok maybe the broken progressbar is because of the empty mime-type array? [13:31] (which probably is an untested special case) [13:32] gnomefreak, on that site you can download chatzilla 0.9.83. maybe you downloaded from old cvs? (just a thought) [13:33] maybe [13:35] asac, normally there are only the mimetype in the array ? [13:37] Jazzva: it seems CVS wasnt updated [13:37] so i guess .xpi it is [13:37] maybe... if it's really 0.8.5, then it's really old [13:37] (and I was confused why they mention mozilla 0.9.7 :)) [13:37] me too [13:38] XioNoX: no. its an array of pluginInfo iirc [13:38] XioNoX: look in the pluginfinder wizard code [13:38] (e.g. what does it do witih the window argument) [13:38] maybe you also are missing another window argument [13:38] maybe error console spits out anything [13:38] no missing window argument [13:38] error console didn't work [13:39] how do you see the error if there are an error in the error console ? :) [13:39] err ... cant parse that. [13:43] :) [13:43] rephrase? [13:44] nevermind [13:48] XioNoX: window.arguments[0].plugins[item] [13:48] thats the element that we need to set ;) [13:48] (i guess you figured that) [13:48] I think I've find my error [13:49] I'me doing : var pluginInfo = getPluginInfo(aEvent.target); [13:49] pluginsArray[pluginInfo.mimetype] = pluginInfo; [13:49] and then extracting the mymetype form the array [13:49] and then putting it in another array [13:50] ok [13:50] isnt pluginsArray the array that needs to be accessible through window.arguments[0].plugins ? [13:50] cool [13:50] it works [13:51] ;) [13:51] yay. [13:51] commit it as a milestone :) [13:51] but window.arguments[0].plugins can't be an array of array [13:51] XioNoX: after that commit, maybe you could do some code cleanup? [13:52] if it is like house cleanup, i'll not like it [13:52] e.g. like using the proper case for variables (e.g. not .PluginUsed, but .pluginUsed), making indentation consistent and also removing any commented code that was added for testing? [13:52] bug 244366 [13:52] Launchpad bug 244366 in cairo "cairo fails to build against fontconfig 2.6.0-1ubuntu2" [Undecided,Fix released] https://launchpad.net/bugs/244366 [13:52] XioNoX: yeah. but dirty code is just ugly :( [13:52] is flock in our repos? [13:52] in my ppa only [13:52] ah that would be why [13:52] asac, I agree, i'm just kidding ;) [13:53] problem ? [13:53] fta: no just working out depends [13:53] asac, cleanup before or after the push ? [13:54] XioNoX: first push [13:54] XioNoX: then do a cleanup commit [13:54] test that and push ;) [13:54] okay ! [13:55] asac, i proposed a branch merge 3 days ago using the lp feature. it's easy to use. https://code.edge.launchpad.net/~fta/apport/apport/+merge/758 [13:55] yep [13:56] fta: maybe ask pitti whether he got a mail. problem is that the merge request mail might not go out if the user explicitly selected mail from that branch before the feature landed [13:56] yet, it didn't get any attention [13:57] seems he's not here right now [13:57] pushed [13:59] fta: hmm. pitti is usually super-responsive [13:59] (i dont know anyone who better follows up on his tasks then him) [13:59] would be nice if they included a License somewhere either on website or in package :( [14:00] fta: maybe he is on holiday ... or travelling is my guess [14:00] and over weekend doesnt really count for "getting" attention [14:01] asac, hello [14:02] asac, https://bugs.edge.launchpad.net/ubuntu/+source/diggler/+bug/254614 [14:02] Launchpad bug 254614 in diggler "Please merge diggler 0.9-16 (universe) from Debian unstable (main)." [Wishlist,Incomplete] [14:04] ? [14:06] asac, just one thing, how can I replace the onclick='"" of the menuitem ? because even if it is gray I can clic on it [14:07] XioNoX: huh? how do you grey it? [14:07] disabled="true" [14:08] XioNoX: well. i think you should us a proper command [14:08] and not onclick [14:08] XioNoX: maybe use "oncommand=..:" [14:08] that might work as well [14:08] (not 100% sure though) [14:08] asac, you told to discuss in this channel about the dependencies [14:09] ok [14:17] asac, important question, chat text (or image) can I put in the statusbar ? [14:18] err what text [14:19] XioNoX: try the puzzle piece [14:19] (image) [14:20] where it is ? [14:20] not sure ;) [14:20] XioNoX: just use something for now ... we replace it later [14:20] ok [14:21] np [14:21] http://pastebin.mozilla.org/519258 [14:21] anything to change ? [14:26] XioNoX: maybe make tabSelected a prototype function as well (for consistency) ... and use a different var name for "stuffy" :-P [14:26] otherwise that file looks quite clean [14:26] ok [14:26] XioNoX: consider to write a short instruction on top of the file (e.g. whats the idea) [14:26] just two or three sentences [14:26] but not high prio [14:26] add license header please [14:26] the xul ? the js ? [14:26] look at other files [14:27] the commit ? [14:27] XioNoX: the file you pasted was .js, right? [14:27] XioNoX: the .xul/xml files need proper cleanup as well [14:27] yes [14:27] ;) [14:27] please paste them as well [14:29] ok [14:32] is anyone on irc.mozilla.org by chanec? [14:32] chance* [14:33] yes [14:33]