| === apw` is now known as apw | ||
| === _salem is now known as salem_ | ||
| === davidcalle_ is now known as davidcalle | ||
| davidcalle | mhr3, ping? | 11:55 |
|---|---|---|
| mhr3 | pong | 11:56 |
| davidcalle | mhr3, do you know when kenvandine or didrocks will be back from their holiday? | 11:56 |
| mhr3 | january | 11:57 |
| mhr3 | do you need like exact date? | 11:57 |
| davidcalle | mhr3, thanks :) Nope, it's just to discuss naming/packaging scheme. | 11:57 |
| mhr3 | ok | 11:58 |
| === hggdh_ is now known as hggdh | ||
| smspillaz | bregma: this NVI design is a little icky to use | 14:33 |
| smspillaz | doesn't work well with nux objects | 14:33 |
| bregma | hmm | 14:34 |
| smspillaz | I can get around it by supplying custom deleters to unique_ptr but | 14:34 |
| smspillaz | Obviously I don't want to have std::unique_ptr<Impl, NuxDeleter> | 14:34 |
| bregma | let me experiment a bit with the ideas I had, they may not pan out in practice | 14:34 |
| smspillaz | bregma: its a neat idea, but it might only be necessary where you care about ABI stability | 14:35 |
| smspillaz | bregma: another potential problem is that especially because of the unique_ptr to Impl, it effectively means that implementing multiple interfaces is out | 14:35 |
| bregma | I care about testability and ease of reasoning, it just happens that a clear, stable API is the best way to achieve that | 14:36 |
| smspillaz | bregma: well, virtual interfaces get you testability and ease of reasoning | 14:36 |
| smspillaz | nonvirtual interfaces will get you ABI stability | 14:37 |
| smspillaz | bregma: in any case, do you want me to try and make it work with nux objects as the underlying impl ? | 14:37 |
| smspillaz | we can see where it goes from there | 14:37 |
| bregma | separating the client interface from the impementationo interface gets you clarity and testability | 14:37 |
| bregma | go 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 weeks | 14:39 |
| bregma | what with everything being shut down and everyone on vacation | 14:39 |
| smspillaz | bregma: I'd rather not block some refactoring which is making building unity a total pain on an experiment :( | 14:39 |
| smspillaz | I | 14:39 |
| smspillaz | erm | 14:39 |
| smspillaz | I've seen the results of endless-iteration before, its not pretty | 14:39 |
| bregma | we're not in such a rush to get stuff out the door that we need to further compromise an already tenuously maintainable codebase | 14:40 |
| bregma | not this time, at least | 14:40 |
| smspillaz | bregma: of course. At least what I'm trying to say is that | 14:40 |
| smspillaz | the changes I'm making at the moment are about making the codebase more testable and less coupled | 14:40 |
| smspillaz | and 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 etc | 14:41 |
| smspillaz | changing the switcher stuff especially is a total pain because you have to carefully update the sed scripts used for mocking every time | 14:42 |
| smspillaz | so I think its kinda important that we get to that first and then look at how we can best do our interfaces | 14:42 |
| bregma | I agree, that's why I was working on it in the first place | 14:43 |
| smspillaz | bregma: oh heh | 14:43 |
| smspillaz | bregma: I suggest you give lp:~smspillaz/unity/unity.gesture_tests_no_sed a try then :) | 14:43 |
| smspillaz | no recompiles :) | 14:43 |
| smspillaz | bregma: I'm not planning on proposing that branch btw, because the changes are massive, but I'm just cherry-picking things out of it | 14: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 thing | 14:47 |
| bregma | one 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 documentation | 14:48 |
| bregma | being able to read test cases does both in a useful and productive way | 14:48 |
| smspillaz | ++ | 14:48 |
| bregma | reducing the invisible side effects that seem to cause a lot of problems is another, but that may not happen in my lifetime | 14:49 |
| smspillaz | bregma: also agree on both points there :) | 14:49 |
| bregma | when I started doing this, every singe standalone test tool crashed on startup, obviously none of the developers used them | 14:50 |
| smspillaz | bregma: yep :( | 14:50 |
| bregma | some days I get frustrated | 14:50 |
| smspillaz | bregma: I know about the problems with unity | 14:50 |
| smspillaz | its why I hardly ever worked on it back when I was at canonical | 14:50 |
| smspillaz | bregma: 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 |
| bregma | I'm willing to take the time and do it right (but not too much time) | 14:52 |
| smspillaz | bregma: likewise | 14:52 |
| smspillaz | bregma: anyways, I'll keep looking at whether or not we can get nux objects working with your NVI pattern | 14:53 |
| bregma | yep | 14:53 |
| smspillaz | I suspect the first implementation will be quite fragile, but it will be a start | 14:53 |
| bregma | I'm hoping aggregation instead of inheritance is the right solution | 14:53 |
| smspillaz | bregma: by aggregation you mean composition right ? | 14:54 |
| bregma | yeah, the difference is subtle and not always clear to me | 14:54 |
| smspillaz | bregma: I guess I'm just curious as to why a non-virtual-interface is the best way to do it in your view | 14:55 |
| bregma | in UMP, one is a solid diamond and one is a hollow diamond | 14:55 |
| bregma | *UML | 14:55 |
| bregma | because a non-virtual interface forces the client interface and the implemntation interface to be separate | 14:55 |
| smspillaz | bregma: separate in form or substance ? | 14:55 |
| bregma | virtual functions are meant for implemntations to doe their thing differently | 14:56 |
| bregma | the client interface should be unchanging and solid | 14:56 |
| smspillaz | (as in, does it allow the implementation interface to vary while the client interface stays the same ?) | 14:56 |
| bregma | like a legal contract | 14:56 |
| smspillaz | okay | 14:56 |
| smspillaz | hmm | 14:56 |
| smspillaz | bregma: yeah, so that form of NVI some people are very opposed to :) | 14:57 |
| smspillaz | its basically Sutter v The World there | 14:57 |
| bregma | well, they can complain to the guy running the Unity maintenance team if they don;t like it | 14:57 |
| smspillaz | Well, Sutter. Webb. et al. v The World | 14:57 |
| smspillaz | bregma: 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 |
| smspillaz | and instead of taking a function to construct someone who implements Interface::Impl, it should just take std::shared_ptr <Interface::Impl> in its constructor | 14:59 |
| bregma | unique_ptr make it clear there is only one possible implementation, and it belongs to the object of that class... clarity of purpose and intent | 14:59 |
| smspillaz | bregma: the problem is that it doesn't work when you want to implement multiple interfaces | 14:59 |
| bregma | ugh, metting time | 15:00 |
| smspillaz | bregma: chat later ? | 15:00 |
| smspillaz | bregma: I'll draw up a UML diagram of what I mean | 15:01 |
| === ChrisTownsend1 is now known as ChrisTownsend | ||
| Trevinho | smspillaz: have you seen https://bugs.launchpad.net/unity/+bug/1092550 ? | 16:04 |
| ubot5 | Launchpad bug 1092550 in Unity "Using bleeding edge Mesa drivers causes GL_INVALID_OPERATION error in glDrawBuffer / glReadBuffer" [Medium,Triaged] | 16:04 |
| smspillaz | Trevinho: I don't watch the bug reports, so no | 16:11 |
| Trevinho | smspillaz: :) | 16:12 |
| smspillaz | Trevinho: do you know where the offending code is ? | 16:12 |
| Trevinho | smspillaz: unityshell.cpp | 16:12 |
| Trevinho | smspillaz: there are two calls in the nuxPrologue | 16:12 |
| smspillaz | those aren't really invalid usages | 16:12 |
| Trevinho | smspillaz: sorry, nuxEpilogue | 16:12 |
| Trevinho | smspillaz: wondering why mesa is offended by them | 16:13 |
| smspillaz | Trevinho: could be somewhere in nux | 16:13 |
| Trevinho | smspillaz: you got three or four per second | 16:13 |
| smspillaz | Trevinho: could be a bug in mesa's handling of GL_BACK. Try GL_BACK_LEFT | 16:14 |
| Trevinho | smspillaz: 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 think | 16:14 |
| smspillaz | in any case those functions are not really necessary | 16:14 |
| Karoliina | Hello! | 16:14 |
| smspillaz | as long as nux doesn't do anything like | 16:14 |
| Trevinho | smspillaz: so we can just wipe them? | 16:14 |
| smspillaz | glDrawBuffer (GL_COLOR_ATTACHMENT0+n) | 16:14 |
| Trevinho | (I don't see regressions here, but who knows..) | 16:14 |
| smspillaz | Trevinho: if I remember correctly calls to glDrawBuffer affect the currently bound framebuffer object anyways | 16:15 |
| Trevinho | smspillaz: yes, but it's under #ifndef NUX_OPENGLES_20... while in unity we have them in USE_GLES | 16:15 |
| Karoliina | I 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 |
| smspillaz | Karoliina: sudo apt-get install unity | 16:16 |
| smspillaz | that will bring in all the deps at least | 16:17 |
| Karoliina | It 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-2D | 16:17 |
| Karoliina | (ubuntu-2d.desktop file) | 16:17 |
| smspillaz | Trevinho: I'd say get rid of those two lines | 16:18 |
| Trevinho | smspillaz: ok fine | 16:18 |
| smspillaz | Trevinho: in fact, they are invalid operations | 16:18 |
| smspillaz | the compiz fbo is still bound | 16:18 |
| smspillaz | so setting the buffer to GL_BACK makes no sense anyways | 16:19 |
| smspillaz | you can only change it to a color attachment | 16:19 |
| smspillaz | and even then its pointless as the color attachment point never changes | 16:19 |
| Trevinho | ok | 16:19 |
| smspillaz | framebuffer objects are the worst documented part of opengl | 16:19 |
| smspillaz | Karoliina: haven't really got any other ideas :( Purge and remove unity and unity-2d and re-install it ? | 16:20 |
| Karoliina | Scary =( | 16:20 |
| Trevinho | smspillaz: 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 |
| smspillaz | Trevinho: try my patches | 16:21 |
| smspillaz | one of these days at least | 16:21 |
| Karoliina | smspillaz: Would backing up /home/user and then reinstalling and restoring from the back up help? | 16:21 |
| smspillaz | I'm seeing a 70% performance improvement here | 16:21 |
| smspillaz | Karoliina: you could do that if you wanted | 16:21 |
| Trevinho | smspillaz: which branch specifically? | 16:21 |
| smspillaz | Trevinho: ppa:smspillaz/compiz-experimental | 16:21 |
| Trevinho | smspillaz: ok fine ;) | 16:22 |
| smspillaz | Trevinho: 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 slow | 16:22 |
| smspillaz | the joys of not working for canonical - you can fork your own stack and ignore all political fallout | 16:22 |
| Trevinho | smspillaz: why can't be accepted? | 16:22 |
| smspillaz | Trevinho: the patches are massive and change APIs in nux and compiz | 16:23 |
| Karoliina | smspillaz: 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 |
| smspillaz | Trevinho: I really can't be bothered going through all the political drama to get them accepted | 16:23 |
| smspillaz | Trevinho: 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 nux | 16:23 |
| mars | Hi 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 |
| smspillaz | mars: valgrind --tool=callgrind compiz --replace | 17:57 |
| mars | smspillaz, anything less complicated I could try? Perhaps some way to isolate bottlenecks at a higher system level, like 'lense loading', 'render', etc.? | 18:02 |
| mars | a debug log with timing information might work - maybe strace or something? | 18:03 |
| popey | mars, i found that switching off dash blur speeds up dash loading quite a bit | 18:06 |
| mars | popey, thanks, I'll try it | 18:08 |
| === tgm4883` is now known as tgm4883 | ||
| smspillaz | mars: well, I guess if you wanted to profile to contribute a fix then callgrind would be useful | 19:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!