[00:13] This is what I am looking for to print : prinf(" /proc/%u/task/%u/stat", myPid, myTid), How could I get the myTid value which is the Thread id? thx [00:15] bizhanMona: gettid(2)? [00:55] sarnold: I get compilation error as gettid() is not defined ? thx [00:56] haha [00:56] bizhanMona: ooof, I always forget this part of that stpuid manpage: "Glibc does not provide a wrapper for this system call; call it using syscall(2)." [01:00] sarnold: that did it thanks [01:00] bizhanMona: somehow I'm not surprised that SYS_gettid is the example chosen in syscall(2) :) [01:01] Question, I would like to print the backtrace of a running program when i meet a certain condition, not using gdb, is there a library call or system call I can call from within my program? thx [01:02] bizhanMona: iirc, google published a backtrace-dumper a few years back. it may still be maintained... [01:02] sarnold: thanks so much for all your help [01:03] bizhanMona: you're welcome :) [02:30] Is Raring surprisingly slow for anyone else? *Everything* seems to be generally slow, even when not under particular load. [02:33] RAOF: I have suspected a regression in Unity calling paintDisplay more often than it should on regular Compiz frames, based on Nexus 7 observations [02:34] I'm not sure it's that; even compiling seems to be slower than I'd expect. [02:34] RAOF: I noticed battery life is much improved. Is it stuck at a low performance level? :) [02:36] Powertop doesn't think so. [02:36] Ah, hello Firefox and your 600Hz wakeups. [02:36] Heh [02:36] Yeah I don't use Firefox much [02:37] Browsers are a bit of a pain for Compiz, because so many web pages animate on timers... [02:37] People think their desktop is idle but actually not at all [02:38] Interestingly, Firefox is currently at 550 of my 400 wakups/sec. [02:38] I'm curious as to how Powertop thinks that :) [02:38] Heh [02:39] RAOF: What if you close all tabs? Is it a page to blame? [02:39] compiz should never wake up at > 60Hz, right? [02:39] RAOF: Umm, yes 60 Hz should be about the normal limit [02:39] Because we use proper XDamage reporting now [02:39] If an app is rendering too fast it will only impact Xorg and not Compiz any more [02:40] Yeah, I suspect that powertop is just being inaccurate. [02:40] RAOF: I think there may be exceptions. 60Hz is a limit for damage handling but it wakes up for all sorts of other X events too [02:41] So can be higher [02:55] Bah. What was the magic incantation to get USB keyboards to work in a pandaboard's initramfs? === Ursinha is now known as Ursinha-afk [07:16] RAOF: I'm guessing loading more modules into the initramfs? [07:18] mlankhorst: Yeah, but what? [07:18] Also, difficult to do when it's dropping to the initramfs failing to mount / ☺ [07:19] RAOF: well what I personally do is just booting through serial in that case, if you have a cable for it :-) [07:20] then you can tell it to boot through serial needing usb [07:20] without* [07:23] Yeah, 'twould be nice :) [07:24] http://www.omappedia.com/wiki/Booting_Android#PandaBoard_-_To_boot_kernel_and_filesystem_from_SD_Card for the magic incantation through a serial console [07:39] Good morning [07:41] hey pitti! [07:42] bonjour didrocks [09:19] happy friday! [09:21] happy friday Laney! === duflu is now known as duflu|vacation [09:28] hey Laney, didrocks, desktopers, happy friday! [09:29] suppose this is the last day of the year for a few people ;-) [09:29] hey seb128! [09:30] Laney: well, last working day. I still want to enjoy my holidays as "day of this year" :) [09:30] until the 21st of course :p [09:30] haha [09:30] nah, we all know you don't exist when not working [09:31] ahah, some kind of true! :) === vrruiz_ is now known as rvr_ === tkamppeter_ is now known as tkamppeter [12:21] seb128 ping, pm [12:40] ritz, hey, I was at lunch [12:40] :) [12:41] seb128 aah, sorry. I did not realise [12:43] ritz, no worry ;-) === Ursinha-afk is now known as Ursinha === Quintasan_ is now known as Quintasan === Ursinha_ is now known as Ursinha [15:01] erk, what happened to the appearance capplet? [15:04] good mornin [15:07] hey cyphermox, already up? [15:07] empathy sets all my accounts to "online", even though they are disabled in UOA. Even removing them from UOA doesn't help... [15:07] is this a known issue? [15:07] Laney, install gnome-control-center-unity if you don't have it [15:07] didrocks: yeah already up ;) and it does sound too early but life must go on [15:07] larsu, UOA: not that I know about... [15:07] heh ;) [15:08] it's *really* annoying. I set up facebook once and now all those people I never chat with are in empathy [15:08] seb128: oho, indeed [15:08] I even completely removed facebook from UOA! [15:11] * larsu deleted the account by calling Remove() on the account manager on the bus [15:11] d-feet ftw [15:11] larsu, you should still open a bug and tell #webapps about it [15:11] stupid gtk question [15:12] seb128, will do [15:12] does anyone know if typeahead can work though multiple columns in a GtkTreeView? [15:13] seb128, not as far as I know, you have to explicitly set the search column for gtktreeview [15:15] larsu, I blame you btw, that's for a printing issue :p [15:15] * larsu hides [15:15] what's the issue? [15:16] larsu, the gtkfileselector sucks when you get tons for printers [15:16] yeah... [15:16] those people need a way to filter on the location [15:16] the current dialog only do typeahead on the printer name [15:16] having typeahead on the location as well would be an acceptable workaround for them [15:16] but I don't think we can do that on 2 columns [15:16] no, gtktreeview doesn't seem to support that [15:17] this has been a long-standing issue unfortunately [15:17] was there any idea to address it? [15:17] I can't even find an upstream GTK bug [15:17] the best solution would be the ability to "star" (or "favorite") printers [15:17] and make those always appear first [15:18] do you know if that has been discussed or is a thing? [16:10] my problem with printer ordering is that is should show them in "last used printer order" cause if i just printed something to printer X it is very lickely that (a) i want to print there again (b) i want to open & look up queue errors... === sil2100_ is now known as sil2100 [16:45] xnox, that's a good point [16:45] larsu, ^ list first the printer the most recently used (same as file selector does with the recently used list) would be cool [16:46] hey seb128, how are you? [16:47] chrisccoulson, hey, I'm good thanks, almost the W.E and holidays! [16:47] chrisccoulson, what about you? did you get over your flu? [16:47] seb128, yeah, i'm better now, thanks [16:50] how are your holidays? [16:50] did you manage to spend some time away from the screen? ;-) [16:54] seb128, yeah, i've spent a bit of time away from the screen ;) [17:17] hi seb128 === gatox_ultra is now known as gatox [17:18] attente, hey, how are you? [17:19] pretty good :) yourself? [17:21] I'm good thanks [17:21] i have the PPA ready, i'm just wondering if you have the time to give it a try? [17:22] https://launchpad.net/~attente/+archive/unity-gtk-module [17:23] attente, oh, nice, maybe not today (it's 6:23pm on a friday evening ;-) but I will play with it in the next day and let you know how it works for me [17:24] seb128: heh, ok, have a good weekend :) [17:24] attente, thanks, you too! [17:49] * didrocks waves good evening, week-end, and see you next year! Enjoy your end of year holidays :) [17:52] It's not bad if (in top) a program's VIRT count climbs but it's RES count stays roughly steady, right? That just means it's allocating and freeing a bunch of stuff? [17:54] mterry: depends on a lot -- if the process is just running around mmapping the world, the virt count would go up and res would increment slowly.. until the program started _using_ that memory, then it could jump quite rapidly [17:54] mterry: or, perhaps the memory is getting fragmented, and new memory allocations cannot be made from existing address space.. eventually the new allocations will fail, but on 64 bits it ought to take a while... :) [17:55] sarnold, yeah if it were simply alloc/free'ing a bunch, VIRT wouldn't go up, right? It would have to fragment memory in order for more space to be made available? [17:55] (and the resulting loss of locality may slightly slow the system; a long-lived process should probably be looked at to avoid this kind of growth, a short-lived process it probably doesn't matter much) [17:56] mterry: yes [17:56] sarnold, hmm... Thanks === Ursinha is now known as Ursinha-afk === Sweetshark is now known as UbuntuRocksMOAR === UbuntuRocksMOAR is now known as Sweetshark === hggdh_ is now known as hggdh