[00:01] <Saviq> jdstrand, found the issue, qtubuntu reverses the arguments
[00:16] <Saviq> jdstrand, http://pastebin.ubuntu.com/5866645/ is the grep DEN
[00:16] <Saviq> jdstrand, and I'm prepping a fix for qtubuntu
[00:22] <Saviq> jdstrand, https://code.launchpad.net/~saviq/qtubuntu/fix-reversed-arguments/+merge/174313
[00:43] <Saviq> jdstrand, https://chinstrap.canonical.com/~msawicz/phablet/ these two packages should sort you out
[00:59] <Saviq> jdstrand, or you can get the packages from jenkins output.zip https://code.launchpad.net/~saviq/qtubuntu/fix-reversed-arguments/+merge/174313/comments/390384
[01:00]  * Saviq → bed
[07:01] <tvoss_> Saviq, ping
[07:01] <Saviq> tvoss_, pong
[07:02] <tvoss_> Saviq, good morning :) quick one: shared_ptr's and qml, good or bad idea?
[07:02] <Saviq> tvoss_, http://qt-project.org/wiki/SharedPointersAndQmlOwnership ;)
[07:03] <tvoss_> Saviq, so usual QObject* and c'tors with QObject* parent are best
[07:03] <Saviq> tvoss_, yeah, that's what QML expects
[07:04] <Saviq> tvoss_, and even though we're using some shareds here and there and haven't noticed problems
[07:04] <Saviq> tvoss_, YMMV
[07:04] <tvoss_> okay
[07:12] <Saviq> tvoss_, to make things safer, Satoris sents up the data() of a QSharedPointer after having set the object ownership to Cpp
[07:13] <tvoss_> Saviq, ack
[07:13] <Saviq> tvoss_, as described in the wiki, really
[07:13] <tvoss_> Saviq, yeah, bookmarked that one
[07:14] <Saviq> Mirv, hey, glad 5.1 worked for you - the test... must've been something weird with the environment, it should've exported QT_QPA_PLATFORM=minmal so that it doesn't try and connect to X
[07:15] <Saviq> Mirv, otherwise it'd fail everywhere from jenkins to the PPA
[07:18] <Mirv> Saviq: I'm glad as well. sure, something weird it. it'll pop up again if it's something that needs fixing.
[07:18] <Saviq> Mirv, yup
[08:15] <Saviq> let's see, will I make it through the power outage?
[08:20] <nic-doffay> Cimi, can you pastebin me an example of a component using themes/colour pallet’s?
[08:46] <nic-doffay> Saviq, how much battery left?
[08:46] <Saviq> nic-doffay, 1:23
[08:47] <Saviq> nic-doffay, unfortunately it's a dying battery :/
[08:47]  * Saviq needs to finally fix it / get one for the optical drive bay
[08:47] <nic-doffay> Saviq, aren't they all? :P
[08:47] <Saviq> nic-doffay, indeed!
[08:47] <nic-doffay> Took me ages to buy a new one.
[08:48] <Saviq> nic-doffay, this one lasted some disappointing 18 months
[08:48] <Saviq> was nice at the beginning with almost 8hrs life... now it's more like 1:40
[08:54] <nic-doffay> Saviq, mine for ages was 0. haha
[08:54] <Saviq> nic-doffay, ;)
[08:55] <nic-doffay> Cimi, up above dude. <nic-doffay> Cimi, can you pastebin me an example of a component using themes/colour pallet’s?
[08:55] <nic-doffay> At least just the colour pallet for now.
[08:56] <nic-doffay> I'll figure the Ubuntu Shape thing later on.
[08:56] <nic-doffay> That def will need themes.
[09:18] <Cimi> nic-doffay, sorry it's the ping day
[09:18] <Cimi> nic-doffay, got so many pings I am catching up :)
[09:18] <Cimi> your turn
[09:19] <Cimi> nic-doffay, http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/revision/608
[09:27] <nic-doffay> Cimi, what am I looking for?
[09:27] <Cimi> nic-doffay, color: Theme.paletter.normal.background
[09:27] <Cimi> -r
[09:27] <nic-doffay> Cimi, and for labels and all that?
[09:28] <nic-doffay> Colours etc?
[09:28] <Cimi> nic-doffay, the documentation for colours is in the palette file
[09:28] <nic-doffay> Cimi, ok great
[09:28] <Cimi> should be easy, ask if you need
[09:34] <nic-doffay> Cimi, which ones the Pallete file?
[09:34] <nic-doffay> There are two here.
[09:34] <Cimi> nic-doffay, actually
[09:34] <Cimi> https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/color_palette/+merge/173114
[09:34] <Cimi> this is easier to read
[09:35] <Cimi> nic-doffay, modules/Ubuntu/Components/Themes/PaletteValues.qml
[09:37] <nic-doffay> Cimi, what do I need to import?
[09:38] <Cimi> nic-doffay, nothing
[09:38] <nic-doffay> Cimi, and testing this works?
[09:38] <nic-doffay> Just run the the gallery preview in the sdk?
[09:38] <nic-doffay> Any idea?
[09:41] <Cimi> nic-doffay, wait a bit then mumble
[09:50] <Cimi> nic-doffay, mumble?
[09:50] <nic-doffay> Cimi, yeah one sec...
[09:56] <Cimi> nic-doffay, http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/files
[10:05] <sil2100> dednick: hi! Unity unit tests for i386 started failing, strangely
[10:05] <sil2100> dednick: https://launchpadlibrarian.net/144774686/buildlog_ubuntu-saucy-i386.unity_7.0.2%2B13.10.20130712-0ubuntu1_FAILEDTOBUILD.txt.gz
[10:05] <sil2100> dednick: re-running didn't help... do you know maybe what could be wrong?
[10:07] <dednick> sil2100: not really. if you look at the failure output, the expected and actual values are the same.
[10:09] <dednick> sil2100: new version of gtest?
[10:10] <sil2100> dednick: most probably
[10:13] <mhr3> sil2100, there's special template for comparing doubles, i guess it's not used though it should be
[10:13] <mhr3> doubles are rarely equal
[10:14] <sil2100> mhr3: right, I think that needs to be fixed, as by some 'lucky chance' it passed for armhf and amd64 ;)
[10:14] <sil2100> dednick: hm, I checked and there seems to be no new gtest
[10:14] <sil2100> I wonder why suddenly it stopped working
[10:15] <mhr3> sil2100, btw any progress on the hud thing?
[10:23] <mhr3> i suppose dist-upgrade wanting to remove ubuntu-touch is not a good thing
[10:29] <dednick_> sil2100: all tests succeed for me
[10:33] <mhr3> dednick_, it's EXPECT_EQ() on doubles
[10:33] <mhr3> eeek!
[10:38] <nic-doffay> Cimi, where can I get opacity values for the themes?
[10:38] <nic-doffay> or do you just set the whole colour?
[10:41] <nic-doffay> Cimi, and one thing else. Any idea how I can see the themes in action?
[10:41] <Cimi> nic-doffay, colours are rgba
[10:41] <Cimi> nic-doffay, to set theme
[10:41] <nic-doffay> Cimi, right so no separate alpha.
[10:41] <Cimi> nic-doffay, in your main qml file
[10:41] <sil2100> mhr3: didn't hear any info about that...
[10:42] <sil2100> dednick_: hm, are you on i386?
[10:42] <Cimi> Component.onCompleted: Theme.name = "Ubuntu.Components.Themes.SuruGradient"
[10:42] <dednick_> sil2100: 64
[10:42] <Cimi> nic-doffay, ^
[10:42] <sil2100> dednick_: it seems amd64 didn't have that problem
[10:42] <sil2100> dednick_: maybe mhr3 is right and we should expect double values some differently
[10:42] <dednick_> sil2100: possibly
[10:43] <sil2100> dednick_: are you free right now to fix that, or busy and I should try that? :)
[10:44] <dednick_> sil2100: not what i would say "free"
[10:44] <dednick_> sil2100: you on 64
[10:44] <dednick_> or 32?
[10:44] <sil2100> amd64 as well, sadly!
[10:45] <nic-doffay> Cimi, can you not bind it?
[10:45] <Saviq> mhr3, ubuntu-touch is being fixed now
[10:45] <Saviq> mhr3, or is fixed already, just needs to get published
[10:45] <Saviq> mhr3, but it shouldn't matter
[10:46] <mhr3> Saviq, it also wanted to remove indicators
[10:46] <Saviq> mhr3, as it only gets removed because indicators-plugins* are integrated into unity8
[10:46] <Saviq> mhr3, and the seed wasn't updated yet
[10:46] <Cimi> nic-doffay, bind what?
[10:46] <mhr3> Saviq, k, thx for update
[10:46] <Saviq> mhr3, indicators-plugins, not indicators themselves, right?
[10:47] <nic-doffay> Cimi, I just threw that code into The option selector and tried it out in the gallery. No change.
[10:47] <mhr3> Saviq, indicator-client-plugin-*
[10:47] <Saviq> mhr3, yup, that's fine
[10:47] <nic-doffay> Cimi, the onCompleted
[10:47] <Saviq> mhr3, built into unity8 since yesterday
[10:48] <mhr3> coolio
[10:50] <mhr3> sil2100, i have 32bit chroot
[10:51] <dednick_> sil2100: not sure why it's not working though. the values should be the same...
[10:51] <mhr3> cause it's doubles
[10:51] <dednick_> and?
[10:51] <mhr3> :-O
[10:51] <dednick_> 1.00201 != 1.00201
[10:52] <mhr3> printing a double truncates it
[10:52] <dednick_> i've checked the code, they should be the same
[10:52] <mhr3> the reality is that 1.0020100000001 != 1.0020100000003
[10:52] <dednick_> mhr3: it's not
[10:54] <dednick_> sil2100: when did this stop working?
[10:54] <mhr3> dednick_, you can never compare a double for equality, that's a cs fact
[10:55] <dednick_> cs?
[10:55] <Saviq> computer science
[10:56] <dednick_> (should_be_selected ? 1.0f : 0.9f) * progress != (should_be_selected ? 1.0f : 0.9f) * progress
[10:56] <mhr3> damn, he got me
[10:56] <mhr3> ok, in one case you can :P
[10:57] <mhr3> i can't build unity
[10:57] <dednick_> mhr3: saucy update
[10:58] <mhr3> add_subdirectory given source "/usr/src/gmock" which is not an existing
[10:58] <mhr3>   directory.
[10:58] <dednick_> mhr3: yeah. new gmock
[10:58] <mhr3> upgrading then
[10:58] <dednick_> mhr3: there probably should be a check for the version in the configure
[11:00] <dednick_> i wonder if gtest is trunking one of the values going into the test equality function
[11:00] <sil2100> dednick_: I only noticed it failing since like yesterday
[11:01] <dednick_> damn. my laptop is burning. something keeps frying my cpu!
[11:01] <mhr3> dednick_, hud! :)
[11:02] <dednick_> mhr3: really? how do i kill it!?
[11:03] <sil2100> killall hud-service
[11:03] <sil2100> Try that!
[11:03] <sil2100> SHOOT IT
[11:03] <dednick_> process not found
[11:04] <mhr3> pkill -f hud-service
[11:04] <dednick_> killall unity
[11:04] <sil2100> OHSHIT
[11:04] <sil2100> ;)
[11:06] <mhr3> sil2100, anyway, i don't think the hud fix is going to happen anytime soon, hud guys want unity to use the new interface and implementing that will take a while
[11:08] <sil2100> mhr3: *sighs* - since if you say that all the unity AP failures are caused by the DBus issue that is caused by HUD, then hm, we seem to be blocked - just hope the problems are not 100% reproducible
[11:12] <mhr3> sil2100, ehm, how do i run the unit tests these days? make check not make test doesnt' work
[11:13] <Cimi> nic-doffay, in the main qml file
[11:13] <Cimi> nic-doffay, you need updated packages
[11:14] <nic-doffay> Cimi, as of when?
[11:18] <Cimi> nic-doffay, today
[11:18] <mhr3> sil2100, nvm
[12:15] <dandrader> Saviq, Have you seen something like that? http://paste.ubuntu.com/5867928/
[12:15] <dandrader> ^ when running ./build
[12:15] <Saviq> dandrader, you need ppa:ubuntu-unity/next
[12:15] <Saviq> dandrader, https://code.launchpad.net/~saviq/unity8/clean-build-scripts-coding/+merge/173847
[12:34]  * Saviq goes back home looking for power
[12:34] <Saviq> biab
[12:50] <jdstrand> Saviq: hi! thanks for the work on bug #1200437
[12:51] <Saviq> jdstrand, cheers
[12:51] <jdstrand> Saviq: I haven't been able to test it yet because the files in output.zip and your directory don't seem to include the fix
[12:51] <Saviq> jdstrand, oh!
[12:51] <Saviq> jdstrand, that'd be very weird
[12:51] <Saviq> jdstrand, /me tests
[12:52] <jdstrand> Saviq: ie, it didn't work, so I read /usr/share/doc/qthybris/changelog.Debian.gz and it doesn't show your change
[12:52] <Saviq> jdstrand, I didn't add anything to the changelog, though
[12:52] <Saviq> jdstrand, we're relying on daily release to do it for us
[12:52] <jdstrand> http://paste.ubuntu.com/5867991/
[12:52] <jdstrand> ah
[12:52] <Saviq> jdstrand, did you reboot after installing?
[12:52] <jdstrand> I did not reboot
[12:52] <Saviq> jdstrand, you at least needed to restart the shell
[12:52] <jdstrand> I guess I should do that?
[12:53] <jdstrand> I see
[12:53]  * jdstrand restart
[12:53] <Saviq> jdstrand, yeah, it needs to pick up the new lib
[12:53] <jdstrand> ok, that makes sense. not sure why I didn't think of that :)
[12:54] <jdstrand> \o/
[12:54] <jdstrand> it is working now :)
[12:54]  * jdstrand hugs Saviq 
[12:54] <Saviq> jdstrand, awesome
[13:00] <jdstrand> Saviq: the only trick is that the version in output.zip is the same as the one in saucy right now. when do you think saucy will have the fix?
[13:00] <dandrader> greyback, will Shell.qml and Stage.qml (specially the animations code) change much with unity8-mir or will it be essentially about having a new implementation of Ubuntu.Applicaion module
[13:01] <greyback> dandrader: I've a refactoring branch, which just isolates the WM code out of a shell into a more testable condition. I need to update that and figure out why some of the tests failed
[13:03] <greyback> dandrader: the plan has been to limit the amount of changes in unity8, so will still be grabbing screenshot from Mir and animating that - not the surface itself. The new AppManager will need a few code changes, but nothing major. I'm hoping there'll not be too many changes
[13:03] <Saviq> jdstrand, as soon as it's approved / merged / released
[13:10] <dandrader> greyback, ok. do you mind if I take that bug from you? https://bugs.launchpad.net/unity8/+bug/1116207  I'm idle at the moment
[13:10] <greyback> dandrader: go for it
[13:19] <jdstrand> Saviq: oh, can you paste the apparmor denials somewhere?
[13:19] <Saviq> jdstrand, I did, let me scroll up
[13:19] <jdstrand> ah, missed that
[13:20] <Saviq> jdstrand, http://pastebin.ubuntu.com/5866645/
[13:20] <Saviq> jdstrand, that's maguro, btw
[13:20] <jdstrand> thanks! :)
[13:20] <jdstrand> I'll get that adjusted in our policy
[13:20] <Saviq> cheers
[13:26] <seb128> Saviq, dednick: hey, do you know what's the status of using the real indicators in unity8/ubuntu touch?
[13:27] <seb128> Saviq, dednick: we had a couple ported to gmenu in saucy but I think we still don't use them on touch? what is blocking?
[13:27] <Saviq> dednick, I'll leave that to you ↑
[13:30] <dednick> seb128: i believe they don't have phone profiles yet. at the moment i think they're only supportted on desktop
[13:30] <seb128> dednick, is the unity side ready?
[13:30] <seb128> dednick, larsu said they didn't have phone profile because nobody asked for those profiles yet
[13:30] <dednick> seb128: unity8?
[13:30] <dednick> seb128: i've asked for them.
[13:30] <dednick> maybe i dont count
[13:30] <seb128> dednick, is the only piece missing to use them on the touch image the phone profile?
[13:31] <seb128> dednick, where did you ask?
[13:31] <dednick> indicator status meeting
[13:33] <dednick> seb128: indicator status meeting
[13:33] <seb128> dednick, sorry, my session closed
[13:34] <seb128> dednick, ok ... so is everything ready on the unity8 side? (e.g if we can an indicator exporting a phone profile we can use it on unity8)?
[13:34] <seb128> dednick, can you open a bug on launchpad about what you need? that's easier to track
[13:35] <dednick> seb128: yep, should be good to go when we have them.
[13:35] <seb128> excellent
[13:35] <seb128> how can I test that?
[13:35] <seb128> just running an indicator with a phone profile on the current touch image should work?
[13:40] <greyback> kgunn: lol
[13:49] <kgunn> greyback: are you running xmir ?
[13:49] <greyback> kgunn: yes
[13:50] <kgunn> did you pin the ppa ? if so, can you dist-upgrade and see if it tries to remove/uninstall lightdm/u-s-c
[13:50] <kgunn> (assuming you haven't dist-upgraded today)
[13:51] <greyback> kgunn: yep I pinned the PPA. Ok, trying...
[13:51] <om26er> mhr3, ping
[13:52]  * kgunn hopes i have some latent apt-cache issue...
[13:53] <mhr3> om26er, pong
[13:54] <om26er> mhr3, after searching in the dash I see installed scopes along with apps: https://launchpadlibrarian.net/143920097/t.png
[13:54] <om26er> mhr3, I am hoping its something for scopes team (?)
[13:55] <mhr3> om26er, like on desktop, yes
[13:56] <om26er> mhr3, they are appearing alongside installed apps, which looks wrong
[13:56] <om26er> mhr3, is that expected ?
[13:57] <mhr3> atm, yes
[14:00] <greyback> kgunn: u-s-c is being kept back. lightdm untouched
[14:01] <kgunn> greyback: well good...so it didn't remove either in your case....just a failure to update u-s-c
[14:01] <kgunn> ?
[14:01] <greyback> kgunn: yep
[14:03] <kgunn> greyback: f me....why did it uninstall mine?
[14:03] <kgunn> anyone know of a way to clear apt cache just in case something lurking in there?
[14:03] <kgunn> ....oh....nvmd....i think i know
[14:04] <kgunn> greyback: thank you for the interruption....
[14:04] <greyback> kgunn: I'm really not sure how that could've happened. The pin priority is 1002, which should be the highest
[14:05] <greyback> does it let you re-install lightdm? What lightdm package is it?
[14:05] <kgunn> greyback: no...it does the lightdm depends on u-s-c, but can't install u-s-c cause of libmirserver version
[14:05] <kgunn> the classic broken package...
[14:05] <greyback> yay :(
[14:07] <kgunn> kgunn: so its good /bad.....it is broken....but i bet for people already running xmir ( & for most non-stupid people, e.g. !kgunn) then it will just whine
[14:07] <kgunn> but keep working
[14:07] <greyback> kgunn: 0.0.6bzr848saucy0 is what I'm installing now with the dist-upgrade
[14:07] <greyback> ah kgunn syndrome, yet I get that sometimes :)
[14:08] <kgunn> greyback: well..it really sucks when you have it 24/7 ; )
[14:08] <greyback> chronic kgunn, whoa nasty. Gotta be drugs for that
[15:08] <Saviq> kgunn, greyback having fun here, eh? go back to work!
[15:09] <kgunn> Saviq: yes...sorry....no more fun
[15:09] <Saviq> :)
[15:10] <greyback> Saviq: but it's Friiiddaaay
[15:11]  * Saviq always wondered why Friday is called thus... /me never had a free day on Friday
[15:12] <didrocks> JohnLea: I'm afraid I won't have the time in the forseable future for this enhancement TBH
[15:13] <didrocks> JohnLea: my personal load average is 3,02, 2,35, 2,85 ;)
[15:19] <JohnLea> didrocks; no worries, it's not essential because we are already making that differentiation by looking at which bugs are assigned to designers and which are not
[15:19] <JohnLea> didrocks; it only cleans up something we are doing already, so is non-essential
[15:19] <didrocks> ok
[15:19] <JohnLea> didrocks; will you be in IOM for sprint?
[15:19] <didrocks> JohnLea: yep, maybe between 2 meetings, we can have a look :)
[15:20] <JohnLea> didrocks; no, would be good to see you and grab a beer, that's all ;-)
[15:20] <JohnLea> didrocks; it depends if the power stays on this time as well, at the last sprint there we were having power cuts!
[15:21] <didrocks> JohnLea: that will make all that… interesting! ;)
[15:22] <didrocks> JohnLea: will be good to see you too!
[15:22] <JohnLea> didrocks; well have a good weekend, speak soon!
[15:22] <didrocks> JohnLea: thanks, you too!
[15:25] <Saviq> o/ o| o/ guys
[15:25] <Saviq> have a great weekend!
[15:26] <dednick> Saviq: cya
[15:26] <dednick> Saviq: have a good weekend
[15:32] <MacSlow> saviq_ happy weekend-time
[15:38] <sil2100> dednick: btw. since I probably missed something... were you able to resolve the failing unit test on i386 for unity?
[15:38] <sil2100> *unit tests
[15:49] <dednick> sil2100: mhr3 is your man, but i believe so
[15:50] <mhr3> sil2100, Trevinho was on that
[15:50] <sil2100> :D
[15:51]  * sil2100 waits until Trevinho points him to andyrock or someone else
[15:51] <sil2100> ;)
[15:51] <sil2100> Trevinho: any luck?
[15:51] <mhr3> it's pretty simple fix though
[15:51] <Trevinho> andyrock: ^
[15:51] <Trevinho> bschaefer: ^
[15:51] <sil2100> ;)
[15:51]  * bschaefer wonders whats going ong
[15:51]  * Trevinho ping jocking... :D
[15:51] <Trevinho> bschaefer: nothing... Just a ping ^_^
[15:52] <bschaefer> well hello :)
[15:52] <Trevinho> bschaefer: hi! :)
[15:52] <bregma> bschaefer, it's just a finger-pointing circle thing
[15:52] <Trevinho> ping proxy I wanted to write.. but "proxy" got lost
[15:52] <bschaefer> haha, well Ill stop the cycle!
[15:52] <bschaefer> bschaefer, ping
[15:52] <Trevinho> Nooo... deadlock!
[15:53] <bschaefer> haha
[15:53] <Trevinho> sil2100: Im with you now... Let me read backlog :)
[15:56] <sil2100> Trevinho: it's about the unit-tests failing for i386 related to double values ;)
[15:56] <sil2100> Trevinho: any progress?
[15:56] <sil2100> Since it causes FTBFS and blockage of the unity stackz
[15:57] <Trevinho> sil2100: ah, ok... I'll fix it in a branch is coming with other tests as well
[15:57] <Trevinho> sil2100: how much time do I have? :)
[15:57] <mhr3> 175 seconds :P
[15:58] <sil2100> Trevinho: I think there's no haste anymore, Friday releases are a bad idea ;p
[15:58] <sil2100> I understood that with seb128 some time ago when publishing of indicators on a Friday afternoon caused a nasty regression
[15:58]  * sil2100 makes no more Friday afternoon releases
[15:59] <Trevinho> ah I see.. I didn't notice it was blocking something important (and I saw builds ok in builders)
[15:59] <Trevinho> sil2100: didrocks teached you his story? :)
[15:59] <sil2100> Trevinho: the problem is that it's ok for armhf and amd64, but fails for i386 o_O
[16:00]  * didrocks looks at his scarves
[16:00] <didrocks> scares* even
[16:00] <sil2100> Trevinho: https://launchpadlibrarian.net/144774686/buildlog_ubuntu-saucy-i386.unity_7.0.2%2B13.10.20130712-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:02] <Trevinho> sil2100: yeah, I was already on that link
[16:02] <sil2100> \o/
[16:03] <sil2100> Trevinho: so, no hurry, but thanks for working on that ;)
[16:06] <Trevinho> sil2100: I can do one-line fixes :)
[16:36]  * greyback eow
[19:22] <slangasek> ok, so I'm trying to fix bug #1193120
[19:22] <slangasek> but rebuilding the package that's currently in saucy is failing
[19:22] <slangasek> make[5]: *** No rule to make target `../tests/test-gtest-xless', needed by `tests/CMakeFiles/check-headless'.  Stop.
[19:22] <slangasek> does someone know what's going wrong here?
[20:04] <gotwig> hey there
[20:04] <gotwig> why is it C for Scope programming?
[20:04] <gotwig> what is wrong with Vala and C++ ?
[20:16] <gotwig> why c....
[20:16] <gotwig> why
[20:19] <bschaefer> gotwig, ... whats wrong with C?
[20:20] <bschaefer> slangasek, hmm my test-gtest-xless seems to have  compiled fine
[20:21] <bschaefer> though in a make-check i've failing on test-unit...which Trevinho has a branch im reviewing which should fix that...
[20:22] <bschaefer> and make-headless seems to be working as well
[20:22] <Trevinho> bschaefer: make check-headless :)
[20:22] <bschaefer> yeah that one :)
[20:23]  * bschaefer type-o-ed
[20:29] <gotwig> bschaefer: what is wrong with C++ and Vala...
[20:29] <gotwig> bschaefer: programming via C is not the modern approach for programming nowadays.
[20:29] <bschaefer> gotwig, we could be at this all day :)
[20:29] <gotwig> bschaefer: why C , seriously
[20:30] <bschaefer> gotwig, theres nothing wrong with either choice, but theres also nothing wrong with C, and C works very well
[20:30] <gotwig> bschaefer: why have you choosen C as the main language for scopes
[20:31]  * bschaefer did not choose anything
[20:31] <gotwig> Warum habt ihr C genommen
[20:31] <Trevinho> Vala is awesome, but it's also unstable and has missing features... C++11 is fantastic as well, modern and a allows to code quickly and powerfully!
[20:31] <gotwig> because the english language is too bad to distinguish
[20:31] <gotwig> Trevinho: wait... missing features? Do you compare Vala now with C or... what?
[20:32] <gotwig> once, unity scopes were written in Python, than Vala. Why now C? Why not C++?
[20:32] <bschaefer> python was to slow, i remember that switch
[20:33] <gotwig> I cant look at this c code...
[20:33] <gotwig> I began to programm with C... but this hardcore stuff is simply too much for C
[20:33] <bschaefer> learn C :), its a good language to know
[20:33] <gotwig> why can noone say me why there was choosen C
[20:34] <bschaefer> well im not sure who made that choice, im just simply saying that C is not a bad language
[20:34] <gotwig> in the end, Vala is C ABI compatible, so this shouldnt be an issue...
[20:35] <gotwig> I want to program with objects.. not with old prodedural stuff
[20:35] <bschaefer> gotwig, you can think of structs as object :)
[20:35] <bschaefer> objects*
[20:36] <gotwig> if you mean this seriously....
[20:36] <gotwig> well, you must be kidding.
[20:37] <gotwig> maybe they choose C
[20:37] <gotwig> because its so simple
[20:37] <Trevinho> I didn't check the code, but writing a vapi is quite easy generally
[20:37] <bschaefer> no... not really, its the same thing, not the same syntax sugar, mix some function pointers and variables and you've got a class representation
[20:38] <bschaefer> C is simple, expressive and fast
[20:39] <gotwig> there is a reason why C++ is not just a C extension lol
[20:54] <gotwig> so, is there no real reason why we have to use C for our scopes?
[21:05] <bschaefer> gotwig, probably the simplest answer is speed
[21:05] <gotwig> bschaefer: to what
[21:05] <gotwig> I dont understand
[21:05] <bschaefer> the reason to use C
[21:06] <gotwig> in contrast to what
[21:06] <gotwig> I like to see Vala support..
[21:07] <gotwig> or something object orianted programming
[21:07] <bschaefer> yeah, but if you're going for raw speed, C is still the best choice
[21:14] <gotwig> bschaefer: this cant be an argument
[21:15] <bschaefer> gotwig, whats wrong with that argument?
[21:16] <gotwig> bschaefer: I mean... nowadays we dont really care about speed, that much. Vala produces very fast code, as well as C++ code is fast
[21:16] <bschaefer> gotwig, the scopes need to be fast, when you are dealing with 100 scopes... its needs to be as fast as possible...
[21:16] <bschaefer> (i know its not 100 but still)
[21:17] <gotwig> C++ should still be good enough, as well as vala
[21:17] <bschaefer> theres a reason why they went from python -> vala -> C, again im guessing speed was one of those reason but im not sure :)
[21:19] <bschaefer> and yes vala and C++ both produce fast code, but C is still faster :)
[21:22] <slangasek> bschaefer: well, it didn't compile at all here.  So how should I debug this?
[21:22] <bschaefer> slangasek, hmm you're on trunk, updated, and on saucy?
[21:23] <bschaefer> urg..something in my X just blew up.. rebooting
[21:25] <slangasek> bschaefer: I'm on the current version of the package in the saucy archive.  *trunk* fails to build because it depends on a version of libunity that doesn't exist in the archive.
[21:25] <slangasek> bschaefer: I'm on the current version of the package in the saucy archive.  *trunk* fails to build because it depends on a version of libunity that doesn't exist in the archive.
[21:26] <bschaefer> oo
[21:26] <bschaefer> slangasek, yeah, you have to compile it yourself atm...
[21:26] <bschaefer> at lease im having to
[21:26] <slangasek> yeah, I don't want to do that
[21:26] <bschaefer> :(, I don't think its landed in main atm
[21:26] <slangasek> I want to rebuild the package in the archive, which is something that should always work
[21:26] <bschaefer> and another problem is libunity needs to be compiled with .18, but its using 0.20 atm
[21:26] <bschaefer> yes it should
[21:27] <bschaefer> needs to be compiled with vala 0.18*
[21:28] <slangasek> well
[21:28] <slangasek> if nobody knows why the build is failing, I could just apply my patch and push to saucy
[21:28] <slangasek> and hope it builds
[21:28] <slangasek> but I'd rather not do that :P
[21:28] <bschaefer> so right now lp:unity cannot build with the archive...annnd that really should get fixed...
[21:29] <bschaefer> cause there is the wrong version of libunity in main, and libunity isn't building cause its using vala 0.20
[21:29] <bschaefer> which for some reason needs 0.18 to compile atm...
[21:30] <bschaefer> the only way im getting unity to compile atm is compiling/installing libunity my self
[21:30] <slangasek> ok, so is somebody responsible for fixing this?
[21:31] <bschaefer> i would hope its being addressed... but everyone is gone for the day that deals with that, as far as I know...
[21:31] <bschaefer> im just a unity dev :(
[21:31] <slangasek> yeah, it is rather late in the weekend ;)
[21:31] <slangasek> "just a unity dev" - er, but who's responsible for this, if not the unity devs?
[21:32] <bschaefer> well I don't really touch packages that land in main
[21:33] <bschaefer> i would think didrocks or sil2100 or seb would know more about it...
[21:33] <bschaefer> but they are all EOD...so this hopefully will be fix come monday...
[21:34] <bschaefer> fixed*
[22:07] <slangasek> bschaefer: apparently this is bug #1185265, fixed in trunk.
[22:09] <bschaefer> slangasek, yes, compiz still needs to get fixed... which might be blocking things?
[22:09] <slangasek> I have no idea if that would be blocking something
[22:09] <slangasek> but that bug is fixed in trunk, not in saucy
[22:10] <bschaefer> neither would I... the only problem I get when trying to build unity from archive is the libunity problem :(
[22:11] <bschaefer> oo yeah, you are patching  unity...so you'll still run into that...
[22:11] <slangasek> you probably have an out of date version of google-mock installed, then; the new one was uploaded July 4
[22:12] <bschaefer> well I have the new version...but you don't have the unity fix for it
[22:12] <bschaefer> if you are patching unity from archive
[22:13] <bschaefer> im using trunk unity to build thing...
[22:14] <bschaefer> the last entry in my change log:  -- Didier Roche <didrocks@ubuntu.com>  Thu, 04 Jul 2013 09:54:08 +0200
[22:19] <slangasek> ah. you said 'build unity from archive'
[22:19] <slangasek> which certainly would have gmock incompatibilities
[22:20] <bschaefer> opps sorry, ment when I try building from trunk
[22:20] <slangasek> right :)
[23:33] <mhall119> Saviq: did you ever get a chance to look at that unity performance complaint I had
[23:33] <mhall119> ?
[23:33] <mhall119> because it's really bad now
[23:36] <mhall119> Saviq: http://ubuntuone.com/0qP1aYKqdDR8Da6q9qMtZ7
[23:36] <mhall119> that's with no apps open and the screen off
[23:37] <mhall119> it can barely manage to charge it's using so much power
[23:39] <mhall119> but it's fine after a reboot