| psusi | is it an error to try to use gtk code in a thread you create with pthread_create()? isn't there some thread local initialization that needs done so you should use g_thread_new? | 03:39 |
|---|---|---|
| RAOF | psusi: I don't *believe* so, but you obviously need to take the necessary locks. | 03:40 |
| psusi | what locks? | 03:41 |
| RAOF | The gdk lock. | 03:41 |
| psusi | what's that? | 03:41 |
| RAOF | It's an error to call (almost?) any gtk function without the lock held. | 03:41 |
| psusi | I got this: [xcb] Unknown request in queue while dequeuing | 03:41 |
| psusi | [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called | 03:41 |
| RAOF | http://www.gtk.org/api/2.6/gdk/gdk-Threads.html | 03:42 |
| psusi | holy shit, you're kidding? | 03:42 |
| RAOF | Specifically - gdk_threads_enter() and gdk_threads_leave() | 03:42 |
| RAOF | Oh, yeah. You'll need to tell gtk to actually initialise the XCB threads, too :) | 03:43 |
| psusi | how do you do that? is that done automatically by g_thread_new? | 03:43 |
| RAOF | "As always, you must also surround any calls to GTK+ not made within a signal handler with a gdk_threads_enter()/gdk_threads_leave() pair. " | 03:43 |
| RAOF | "You must call g_thread_init() and gdk_threads_init() before executing any other GTK+ or GDK functions in a threaded GTK+ program. " | 03:44 |
| RAOF | Threading and GTK is a bit of a minefield. | 03:44 |
| psusi | so you can't have two threads running their own message loop in parallel with gtk? | 03:45 |
| psusi | it sounds like it | 03:45 |
| RAOF | You mean, have two different gtk mainloops running on different threads? | 03:46 |
| psusi | yea | 03:46 |
| psusi | each thread controlling its own window | 03:47 |
| RAOF | I don't think so; there's no context for any of the gtk calls. How would you distinguish which mainloop to dispatch to? | 03:47 |
| psusi | X takes care of that | 03:47 |
| psusi | the message goes into the queue for the window that corresponds to the thread... thread picks up message, dispatches, etc | 03:47 |
| RAOF | I'm pretty sure there are gtk calls that aren't associated with a Window; how would they be dispatched? | 03:48 |
| psusi | as long as you don't try to bounce the window back and forth between threads, it should be fairly straight forward... it was in windows | 03:48 |
| psusi | well if they don't have anything to do with a window, then they shouldn't be using the message queue should they? | 03:49 |
| RAOF | Why not? The mainloop's not just for X message processing. | 03:50 |
| psusi | well, how does i tknow what message queue to use then? it has to find a queue somehow | 03:51 |
| RAOF | It uses the default, singleton, gtk glib mainloop. | 03:51 |
| psusi | and there's only one? there should be one per thread | 03:52 |
| RAOF | You *can* create other glib mainloops, but as far as I'm aware there's exactly one gtk mainloop. | 03:52 |
| psusi | in windows, every thread has its own message queue/loop | 03:52 |
| RAOF | No, there's definitely not one per thread. | 03:52 |
| psusi | ohh, yea, there's only one initially, sure | 03:53 |
| psusi | but if you want, you can make another one in another thread so it can run concurrently can't you? | 03:53 |
| * psusi is coasting mostly on 10 year old windows programming knowledge trying to debug gparted | 03:54 | |
| RAOF | No; everything I see says "exactly one thread can call a GTK function at a time; protect calls with gdk_threads_enter/leave" | 03:56 |
| psusi | hrm... I guess that's the limitation of using a class toolkit... now that I think about it, I think MFC had the same problem | 04:00 |
| psusi | but I always just used straight winapi | 04:00 |
| RAOF | Yeah. My memory is that Win32 didn't give you a general-purpose mainloop; you just got the window-system events there, and could(?) build a proper mainloop on that if you wanted. | 04:06 |
| RAOF | It's been *some time* since I played with win32, though. | 04:07 |
| psusi | so it's pretty much an error to pthread_create a background thread and have it emit a signal without any of that lock stuff right? | 04:20 |
| psusi | and basically if you want to make any blocking calls while handling events in the background thread, it's pointless since it would block while holding the gtk lock, thus preventing the other threads from doing gui things? | 04:21 |
| RAOF | Well, the background thread could emit a signal - it's ambiguous between gobject signals and posix signals, but I think either are fine - just not call any gtk functions without the lock. | 04:33 |
| broder | does gobject have an equivalent to qt's queued signals? i.e. wait until you hit the main loop and then handle this signal emission? | 04:34 |
| broder | it makes cross-thread signals in qt very easy to reason about | 04:34 |
| RAOF | g_idle_add would do it, roughly speaking. | 04:34 |
| broder | i guess you could take the lame way out and use g_idle_add | 04:34 |
| broder | :) | 04:35 |
| RAOF | Similarly, if you make all your blocking calls in the background thread you can happily rock along, taking the lock as appropriate when the background thread wants to signal completion. | 04:35 |
| * RAOF just notices that psusi has left :( | 04:35 | |
| TiMiDo | lol | 04:40 |
| === Aaron_ is now known as TiMiDo | ||
| === Aaron_ is now known as TiMiDo | ||
| dholbach | good morning | 08:14 |
| micahg | udienz__: hi!, just wanted to point out you have a couple merges where you're the person who touched it last in universe | 08:19 |
| === Aaron__ is now known as TIMiDo | ||
| === Aaron__ is now known as TiMiDo | ||
| udienz__ | micahg, yes, ~3 packages. gstm, clutter-gesture, and lighttpd | 09:08 |
| === almaisan-away is now known as al-maisan | ||
| === DrKranz is now known as DktrKranz | ||
| === DrKranz is now known as DktrKranz | ||
| === udienz__ is now known as udienz | ||
| === dholbach_ is now known as dholbach | ||
| === yofel_ is now known as yofel | ||
| === al-maisan is now known as almaisan-away | ||
| === dholbach_ is now known as dholbach | ||
| jtaylor | maybe we should remove argparse from precise? | 19:06 |
| jtaylor | the current debian version is py 2.6 only which would make all rdepends uninstallable I think | 19:07 |
| ScottK | Yes. It should go now that Ubuntu is 2.7 only. | 19:07 |
| micahg | well, we still have python2.6 in precise | 19:08 |
| jtaylor | but it won't stay? | 19:08 |
| micahg | I don't think so, I've been meaning to ask about it | 19:08 |
| jtaylor | if we remove it we could let python2.7 provide argparse saving us the trouble of fixing the argparse rdepends | 19:09 |
| ScottK | micahg: It's still there, but it's not supported for module building. | 19:09 |
| ScottK | So argparse can go as it's pointless. | 19:09 |
| micahg | it still has a few rdepends, so it can't go yet | 19:09 |
| jtaylor | unless 2.7 provides it instead | 19:10 |
| jtaylor | (on the other hand I still hope the 2.6 only change will be reverted in debian) | 19:10 |
| micahg | jtaylor: I don't see a provides | 19:11 |
| jtaylor | not yet :) | 19:11 |
| jtaylor | 2.7 includes argparse so it could | 19:11 |
| ScottK | I think having 2.7 provide argparse makes sense. | 19:12 |
| ScottK | I'll defer to doko on that though. | 19:12 |
| * ajmitch thought the argparse situation was mostly sorted on the debian-python list | 19:27 | |
| tumbleweed | it's different here, though | 19:28 |
| tumbleweed | debian has 2.6, we don't | 19:28 |
| tumbleweed | (well, it's in the archiv, but that doesn't count) | 19:28 |
| ajmitch | they haven't made 2.7 provide argparse then? | 19:29 |
| tumbleweed | no, that would have the wrong behavior in debian | 19:29 |
| tumbleweed | for $python in `pyversions -v`; do setup.py test; done <- that'd break if 2.7 provided argparse in debian | 19:29 |
| ajmitch | yes, it'd be a pain for a package to depend on python-argparse & pull in 2.7 instead | 19:29 |
| ajmitch | python is such a fun mess | 19:30 |
| * tumbleweed is busy playing with pypy, which adds an extra layer of fun | 19:30 | |
| jtaylor | better than javascript though ._. | 19:30 |
| tumbleweed | I suppose I should send an e-mail saying what I've been doing... | 19:30 |
| ajmitch | jtaylor: that's a pretty low bar :) | 19:30 |
| jtaylor | < now has a package with javascript and python | 19:31 |
| jtaylor | pure joy | 19:31 |
| tumbleweed | is the javascript minified? :) | 19:31 |
| ajmitch | tumbleweed: it'd be interesting to read | 19:31 |
| jtaylor | yes and it has a nice .custom in the file name | 19:31 |
| ajmitch | oh, that one :) | 19:31 |
| jtaylor | so I have no idea if I can even use the packaged one | 19:31 |
| tumbleweed | use it, and wait for bug reports :P | 19:32 |
| ajmitch | since custom jqueryui can mean that a certain subset of it was chosen & minified | 19:32 |
| ajmitch | it was ipython that you were looking at, wasn't it? | 19:33 |
| jtaylor | yes | 19:33 |
| * tumbleweed doesn't want to know why ipython has javascript | 19:33 | |
| * ajmitch is trying to come up with a good reason why it would | 19:33 | |
| jtaylor | it now has a mathematica-like web interface | 19:34 |
| jtaylor | very nice, but I would not dare open that up beyond localhost :/ | 19:34 |
| ajmitch | that makes so much sense to have... | 19:34 |
| jtaylor | it is very useful for data analysis | 19:34 |
| tumbleweed | really? | 19:34 |
| tumbleweed | what does it give you that a console doesn't? | 19:35 |
| jtaylor | you can edit the same cell again | 19:35 |
| jtaylor | so you end up with the end result instead of haviong to sieve through the history and removing the lines that did not work | 19:35 |
| tumbleweed | ah, bpythonish | 19:35 |
| ajmitch | from the look of screenshots on the website, it lets you have images in there? | 19:35 |
| jtaylor | yes | 19:35 |
| jtaylor | but qtconsole also had that feature already | 19:36 |
| micahg | jtaylor: there are only about a 18 or so rdepends of argparse, so quite doable to do away with it | 19:37 |
| micahg | jtaylor: if you get the handful of main rdeps fixed, it'll drop to universe and you can take it from there | 19:40 |
| * ajmitch is sort of glad that we probably won't be switching to php 5.4 for precise | 19:41 | |
| tumbleweed | I assume it isn't as bad as 5.3 was? | 19:41 |
| ajmitch | tumbleweed: it's still php, so a real pain to test with | 19:41 |
| micahg | yeah, don't follow Debian into the take the PHP .0 release black hole | 19:41 |
| ajmitch | micahg: not really my call, I've got an RC in my PPA to test though, so it at least builds :) | 19:42 |
| jtaylor | micahg: k, if it will be removed I'll take care of universe | 19:42 |
| tumbleweed | well, it won't be removed unless we deal with the rdepends | 19:42 |
| micahg | jtaylor: well, I don't see it happening automatically, you probably want to have a conversation with doko, then drive it | 19:42 |
| tumbleweed | (or cpython starts providing it) | 19:42 |
| ajmitch | jtaylor: btw, I was told that the firefox developer tools will allow debugging minified javascript soon, so it may reduce your pain fractionally ;) | 19:49 |
| jtaylor | how will that work? | 19:49 |
| tumbleweed | as long as developers don't start giving that as an excuse for shipping minified js | 19:50 |
| ajmitch | no idea | 19:50 |
| ajmitch | http://www.infoq.com/news/2011/08/debug-languages-on-javascript-vm has some explanation of it | 19:51 |
| jtaylor | mh you need a mapping | 19:52 |
| jtaylor | so it will only work for upstreams that support it | 19:52 |
| bdrung | tumbleweed: can i release u-d-t 0.138? | 19:52 |
| ajmitch | yeah, not quite as useful as first thought | 19:52 |
| tumbleweed | bdrung: sure, it's pretty minor | 19:53 |
| tumbleweed | oh hang on | 19:53 |
| tumbleweed | I meant to look at the open debian bugs | 19:53 |
| bdrung | tumbleweed: do you want to fix lp 904288? | 19:55 |
| ubottu | Launchpad bug 904288 in ubuntu-dev-tools (Ubuntu) "[syncpackage] Mention sponsoree when closing bugs in sponsored syncs" [Undecided,New] https://launchpad.net/bugs/904288 | 19:55 |
| tumbleweed | bdrung: there was debian bug 652000, but that's about sticking it in /usr/local on squeeze... | 19:55 |
| ubottu | Debian bug 652000 in ubuntu-dev-tools "/usr/bin/pbuilder-dist: pbuilder-dist ignores environment and has no way to set a custom pbuilderrc" [Important,Open] http://bugs.debian.org/652000 | 19:55 |
| tumbleweed | I should drop the severity of that... | 19:55 |
| tumbleweed | broder: any thoughts on debian bug 651546? | 20:02 |
| ubottu | Debian bug 651546 in ubuntu-dev-tools "[backportpackage] no way to build for proper release socket without uploading directly" [Normal,Open] http://bugs.debian.org/651546 | 20:02 |
| ScottK | tumbleweed: Invalid. No such thing as a release socket. | 20:03 |
| ScottK | ;-) | 20:03 |
| ajmitch | ScottK: I'm sure one could be added to LP if you really want it | 20:03 |
| ScottK | No, because then it'd be a real bug and we dont' want that. | 20:03 |
| tumbleweed | heh | 20:03 |
| ScottK | Actually I think the bug report makes sense. | 20:04 |
| ScottK | I'd probably tag it help and say patches welcome though. | 20:04 |
| ajmitch | add another option to disable adding -backports to the release name? | 20:04 |
| tumbleweed | yeah, it's something that irritated me (I dput from debian where we can't use ppa:) but it's really trivial to edit the changes file | 20:04 |
| ajmitch | tumbleweed: does it still have -backports in debian/changelog, or just in the .changes file? | 20:05 |
| tumbleweed | ajmitch: yes, it only modifies .changes | 20:05 |
| EvilResistance | anyone know where i can find the precise dev team on irc? someone asked a question in #kubuntu about a specific version of Qt, and would need the dev team to answer their question | 20:19 |
| tumbleweed | EvilResistance: "the precise dev team" ? | 20:20 |
| EvilResistance | tumbleweed: generally speaking the people producing the alpha/beta versions of precise... | 20:20 |
| EvilResistance | if i may copy/paste a line or two into here... | 20:20 |
| tumbleweed | EvilResistance: that's pretty much all ubuntu developers | 20:20 |
| EvilResistance | are there any specific devs assigned to the kubuntu parts? | 20:21 |
| tumbleweed | yes, the kubuntu developers | 20:21 |
| EvilResistance | and they are... where :P | 20:21 |
| tumbleweed | #kubuntu-devel | 20:21 |
| EvilResistance | thanks | 20:23 |
| bdrung | tumbleweed: can you have a look and http://paste.ubuntu.com/777873/ and tell me what i do wrong? | 20:23 |
| bdrung | i found it | 20:25 |
| bdrung | tumbleweed: pushed | 20:44 |
| tumbleweed | bdrung: pushed | 20:49 |
| tumbleweed | eep, wrong bug | 20:49 |
| tumbleweed | I'm crazy tired, so please check that | 20:51 |
| broder | tumbleweed: not sure if there's a better option than a --pocket flag or something | 21:02 |
| tumbleweed | broder: I just committed http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/1264 | 21:05 |
| broder | tumbleweed: sure, lgtm | 21:06 |
| tumbleweed | bdrung: ok? https://bugs.staging.launchpad.net/ubuntu/+source/webkitkde/+bug/848916 | 21:10 |
| ubottu | Ubuntu bug 848916 in webkitkde (Ubuntu) "Sync webkitkde 1.1.0git80efcf77-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] | 21:10 |
| tumbleweed | (ignore the content of that bug) | 21:10 |
| bdrung | tumbleweed: sponsored for me? | 21:12 |
| tumbleweed | sure, :) | 21:12 |
| bdrung | tumbleweed: would it be better to have it at the top (= more prominent)? | 21:12 |
| tumbleweed | yeah, it looks a bit silly there | 21:13 |
| bdrung | tumbleweed: pushed, please check | 21:13 |
| tumbleweed | seems ok | 21:16 |
| tumbleweed | that's prettier: https://bugs.staging.launchpad.net/ubuntu/+source/pygame/+bug/898062 | 21:18 |
| ubottu | Ubuntu bug 898062 in pygame (Ubuntu) "Please sync pygame 1.9.1release+dfsg-2 (universe) from Debian unstable (main)" [Wishlist,Triaged] | 21:18 |
| bdrung | tumbleweed: lgtm | 21:19 |
| tumbleweed | committed it | 21:20 |
| tumbleweed | feel free to upload it, I'm off to bed | 21:21 |
| tumbleweed | we should send a mail to devel-announce about native sync sponsoring (and native syncing in general)... | 21:28 |
| tumbleweed | Laney: I assume you saw bigjools' UI component to native sync sponsoring? It just added an input box on +localpackagediffs, no indication of sponsorship anywhere yet... | 21:29 |
| broder | ScottK: is there a reason you didn't just sync python-pypcap yourself? | 23:52 |
| * micahg was kinda wondering the same thing | 23:53 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!