=== apw` is now known as apw
=== _salem is now known as salem_
=== davidcalle_ is now known as davidcalle
davidcallemhr3, ping?11:55
davidcallemhr3, do you know when kenvandine or didrocks will be back from their holiday?11:56
mhr3do you need like exact date?11:57
davidcallemhr3, thanks :) Nope, it's just to discuss naming/packaging scheme.11:57
=== hggdh_ is now known as hggdh
smspillazbregma: this NVI design is a little icky to use14:33
smspillazdoesn't work well with nux objects14:33
smspillazI can get around it by supplying custom deleters to unique_ptr but14:34
smspillazObviously I don't want to have std::unique_ptr<Impl, NuxDeleter>14:34
bregmalet me experiment a bit with the ideas I had, they may not pan out in practice14:34
smspillazbregma: its a neat idea, but it might only be necessary where you care about ABI stability14:35
smspillazbregma: another potential problem is that especially because of the unique_ptr to Impl, it effectively means that implementing multiple interfaces is out14:35
bregmaI care about testability and ease of reasoning, it just happens that a clear, stable API is the best way to achieve that14:36
smspillazbregma: well, virtual interfaces get you testability and ease of reasoning14:36
smspillaznonvirtual interfaces will get you ABI stability14:37
smspillazbregma: in any case, do you want me to try and make it work with nux objects as the underlying impl ?14:37
smspillazwe can see where it goes from there14:37
bregmaseparating the client interface from the impementationo interface gets you clarity and testability14:37
bregmago ahead and try to make it work;  I'll play with my alternate implementation, we'll see what works and what doesn;t....  we're not in a rush over the next couple of weeks14:39
bregmawhat with everything being shut down and everyone on vacation14:39
smspillazbregma: I'd rather not block some refactoring which is making building unity a total pain on an experiment :(14:39
smspillazI've seen the results of endless-iteration before, its not pretty14:39
bregmawe're not in such a rush to get stuff out the door that we need to further compromise an already tenuously maintainable codebase14:40
bregmanot this time, at least14:40
smspillazbregma: of course. At least what I'm trying to say is that14:40
smspillazthe changes I'm making at the moment are about making the codebase more testable and less coupled14:40
smspillazand I worry that the longer we leave it the more likely it is that we're just going to live with 6 files recompiling every time you do a make, fragile sed scripts etc14:41
smspillazchanging the switcher stuff especially is a total pain because you have to carefully update the sed scripts used for mocking every time14:42
smspillazso I think its kinda important that we get to that first and then look at how we can best do our interfaces14:42
bregmaI agree, that's why I was working on it in the first place14:43
smspillazbregma: oh heh14:43
smspillazbregma: I suggest you give lp:~smspillaz/unity/unity.gesture_tests_no_sed a try then :)14:43
smspillazno recompiles :)14:43
smspillazbregma: I'm not planning on proposing that branch btw, because the changes are massive, but I'm just cherry-picking things out of it14:44
smspillaz(note that right now it crashes, but I'm trying to figure out how best to handle the nux::Object living in-its-own-world-along-side-std::-unique-ptr thing14:47
bregmaone of the goals I'm setting for ongoing maintenance is to try to reduce the learning curve for people not involved with its original development, which means improving the clarity of purpose for all entities, and adding documentation14:48
bregmabeing able to read test cases does both in a useful and productive way14:48
bregmareducing the invisible side effects that seem to cause a lot of problems is another, but that may not happen in my lifetime14:49
smspillazbregma: also agree on both points there :)14:49
bregmawhen I started doing this, every singe standalone test tool crashed on startup, obviously none of the developers used them14:50
smspillazbregma: yep :(14:50
bregmasome days I get frustrated14:50
smspillazbregma: I know about the problems with unity14:50
smspillazits why I hardly ever worked on it back when I was at canonical14:50
smspillazbregma: anyways, I guess what I'm trying to say is that I've got a solution out there for one of the larger code-smells which makes testing and maintainance a pain. I hope we can work together on it :)14:51
bregmaI'm willing to take the time and do it right (but not too much time)14:52
smspillazbregma: likewise14:52
smspillazbregma: anyways, I'll keep looking at whether or not we can get nux objects working with your NVI pattern14:53
smspillazI suspect the first implementation will be quite fragile, but it will be a start14:53
bregmaI'm hoping aggregation instead of inheritance is the right solution14:53
smspillazbregma: by aggregation you mean composition right ?14:54
bregmayeah, the difference is subtle and not always clear to me14:54
smspillazbregma: I guess I'm just curious as to why a non-virtual-interface is the best way to do it in your view14:55
bregmain UMP, one is a solid diamond and one is a hollow diamond14:55
bregmabecause a non-virtual interface forces the client interface and the implemntation interface to be separate14:55
smspillazbregma: separate in form or substance ?14:55
bregmavirtual functions are meant for implemntations to doe their thing differently14:56
bregmathe client interface should be unchanging and solid14:56
smspillaz(as in, does it allow the implementation interface to vary while the client interface stays the same ?)14:56
bregmalike a legal contract14:56
smspillazbregma: yeah, so that form of NVI some people are very opposed to :)14:57
smspillazits basically Sutter v The World there14:57
bregmawell, they can complain to the guy running the Unity maintenance team if they don;t like it14:57
smspillazWell, Sutter. Webb. et al. v The World14:57
smspillazbregma: my suggestion at least if we want to go with nonvirtual interfaces (and honestly I don't care either way) is that instead of std::unique_ptr <Impl> we should have std::shared_ptr <Impl>14:58
smspillazand instead of taking a function to construct someone who implements Interface::Impl, it should just take std::shared_ptr <Interface::Impl> in its constructor14:59
bregmaunique_ptr make it clear there is only one possible implementation, and it belongs to the object of that class...  clarity of purpose and intent14:59
smspillazbregma: the problem is that it doesn't work when you want to implement multiple interfaces14:59
bregmaugh, metting time15:00
smspillazbregma: chat later ?15:00
smspillazbregma: I'll draw up a UML diagram of what I mean15:01
=== ChrisTownsend1 is now known as ChrisTownsend
Trevinhosmspillaz: have you seen https://bugs.launchpad.net/unity/+bug/1092550 ?16:04
ubot5Launchpad bug 1092550 in Unity "Using bleeding edge Mesa drivers causes GL_INVALID_OPERATION error in glDrawBuffer / glReadBuffer" [Medium,Triaged]16:04
smspillazTrevinho: I don't watch the bug reports, so no16:11
Trevinhosmspillaz: :)16:12
smspillazTrevinho: do you know where the offending code is ?16:12
Trevinhosmspillaz: unityshell.cpp16:12
Trevinhosmspillaz: there are two calls in the nuxPrologue16:12
smspillazthose aren't really invalid usages16:12
Trevinhosmspillaz: sorry, nuxEpilogue16:12
Trevinhosmspillaz: wondering why mesa is offended by them16:13
smspillazTrevinho: could be somewhere in nux16:13
Trevinhosmspillaz: you got three or four per second16:13
smspillazTrevinho: could be a bug in mesa's handling of GL_BACK. Try GL_BACK_LEFT16:14
Trevinhosmspillaz: I've removed these calls from unity and the errors stopped.. We have also a couple of these calls in nux but they are not running in this case I think16:14
smspillazin any case those functions are not really necessary16:14
smspillazas long as nux doesn't do anything like16:14
Trevinhosmspillaz: so we can just wipe them?16:14
smspillazglDrawBuffer (GL_COLOR_ATTACHMENT0+n)16:14
Trevinho(I don't see regressions here, but who knows..)16:14
smspillazTrevinho: if I remember correctly calls to glDrawBuffer affect the currently bound framebuffer object anyways16:15
Trevinhosmspillaz: yes, but it's under #ifndef NUX_OPENGLES_20... while in unity we have them in USE_GLES16:15
KaroliinaI didn't know where to ask, and didn't find any relevant results in the web, so here's my question: After uninstalling LXDE in Ubuntu 12.04 (regular Ubuntu, not Lubuntu) Unity disappeared from the Login screen, and I'm only left with LXDE (which despite showing as uninstalled in Software Centre still works) and a handful of GNOME shells that don't start at all. Helps?16:16
smspillazKaroliina: sudo apt-get install unity16:16
smspillazthat will bring in all the deps at least16:17
KaroliinaIt said it's already installed. Actually modifying Unity-2D in /usr/share/xsessions/ brought Unity back, but all other settings and applications recognise it as Unity-2D16:17
Karoliina(ubuntu-2d.desktop file)16:17
smspillazTrevinho: I'd say get rid of those two lines16:18
Trevinhosmspillaz: ok fine16:18
smspillazTrevinho: in fact, they are invalid operations16:18
smspillazthe compiz fbo is still bound16:18
smspillazso setting the buffer to GL_BACK makes no sense anyways16:19
smspillazyou can only change it to a color attachment16:19
smspillazand even then its pointless as the color attachment point never changes16:19
smspillazframebuffer objects are the worst documented part of opengl16:19
smspillazKaroliina: haven't really got any other ideas :( Purge and remove unity and unity-2d and re-install it ?16:20
KaroliinaScary =(16:20
Trevinhosmspillaz: however giving a try to these drivers I get the games a lot faster, but unity and compiz are somewhat slower... The same happened moving from precise->quantal with radeon (open) drivers. It's very hard to use the dash here with a full-hd screen :/16:21
smspillazTrevinho: try my patches16:21
smspillazone of these days at least16:21
Karoliinasmspillaz: Would backing up /home/user and then reinstalling and restoring from the back up help?16:21
smspillazI'm seeing a 70% performance improvement here16:21
smspillazKaroliina: you could do that if you wanted16:21
Trevinhosmspillaz: which branch specifically?16:21
smspillazTrevinho: ppa:smspillaz/compiz-experimental16:21
Trevinhosmspillaz: ok fine  ;)16:22
smspillazTrevinho: My patches will probably never be accepted at this point, so I've effectively forked our stack because I'm sick of it being so slow16:22
smspillazthe joys of not working for canonical - you can fork your own stack and ignore all political fallout16:22
Trevinhosmspillaz: why can't be accepted?16:22
smspillazTrevinho: the patches are massive and change APIs in nux and compiz16:23
Karoliinasmspillaz: Doing it atm, but not sure if that wouldn't bring broken LXDE back and cause the same problems. Unity is pretty and I like it too much to give it up, but I can't give up my files either. ):16:23
smspillazTrevinho: I really can't be bothered going through all the political drama to get them accepted16:23
smspillazTrevinho: the tl;dr version is that I basically re-introduced the regional-damage stuff, but pushed a lot of the logic up into compiz and nux16:23
marsHi all, I've noticed the dash takes a long time to open on my system (12.04).  Is there any way to profile it to find the bottleneck?17:56
smspillazmars: valgrind --tool=callgrind compiz --replace17:57
marssmspillaz, anything less complicated I could try?  Perhaps some way to isolate bottlenecks at a higher system level, like 'lense loading', 'render', etc.?18:02
marsa debug log with timing information might work - maybe strace or something?18:03
popeymars, i found that switching off dash blur speeds up dash loading quite a bit18:06
marspopey, thanks, I'll try it18:08
=== tgm4883` is now known as tgm4883
smspillazmars: well, I guess if you wanted to profile to contribute a fix then callgrind would be useful19:00

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!