| === MacSlow is now known as MacSlow|lunch | ||
| Satoris | Four finger gestures are still broken for me. Are they working for anyone? | 11:17 |
|---|---|---|
| === MacSlow|lunch is now known as MacSlow | ||
| Satoris | Unity 2D still works with swipe a couple of times. Then it crashes. | 13:48 |
| cnd | Satoris, they are still going to be broken until I get some touch accounting fixes in | 14:15 |
| cnd | Satoris, bregma_, dandrader, tvoss: standups! | 14:15 |
| dandrader | Proposed fix for "2. UGEvent::Unref()" issue from "[Systems-team] Grail fixes" e-mail sent by cnd. Now I'll start looking into the issue described in "3. Recognizer::AcceptGesture()". | 14:15 |
| bregma_ | did the standups gets moved by an hour, or am I confused? | 14:15 |
| dandrader | bregma_, yep. timezone shifts cased it | 14:16 |
| cnd | bregma_, yes, europe just entered DST | 14:16 |
| tvoss | chromium and bug work, jenkins work | 14:16 |
| cnd | I'm going to be doing code reviews and cleaning up touch accounting fixes in grail to propose it | 14:16 |
| Satoris | Tried to work on bugs and stuff but turned out unproductive. In a fit of rage rewrote evemu's build system in CMake. It's a proof of concept that took maybe an hour. | 14:16 |
| bregma_ | that doesn't make sense, my timezone hasn't changed | 14:16 |
| Satoris | Chromium finalisation too. | 14:16 |
| Satoris | Which touch bugs are fixed and worked on and which ones are not? | 14:17 |
| dandrader | Satoris, you mean from that "Grail fixes" e-mail? | 14:18 |
| Satoris | That, but anywhere really. | 14:18 |
| cnd | bregma_, this is getting some attention on #ubuntu-devel: https://bugs.launchpad.net/unity/+bug/963500 | 14:18 |
| bregma_ | yet another duplicate | 14:19 |
| bregma_ | I will tackle that today then | 14:19 |
| cnd | ok | 14:19 |
| dandrader | Satoris, from that e-mail the only item that no one worked on yet is "6. All tests", I think | 14:19 |
| Satoris | It's not causing any bugs (yet). cnd, what should we focus on next? | 14:21 |
| cnd | Satoris, that would still be very helpful to have done | 14:21 |
| cnd | I can get you a diff | 14:22 |
| Satoris | There are no crashers or usability issues (apart from nothing working at all)? | 14:22 |
| dandrader | cnd, do you recall the bug that caused that output? https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/964135 | 14:25 |
| cnd | Satoris, I'm not sure what you want? | 14:25 |
| cnd | you can test things, find bugs, and try to resolve them | 14:26 |
| cnd | but it will be hard for another day or two until I can get the touch accounting stuff fixed | 14:26 |
| cnd | dandrader, that's also due to the touch accounting issues | 14:26 |
| dandrader | ah, ok | 14:27 |
| dandrader | maybe you could make it a duplicate or something | 14:27 |
| Satoris | cnd: should I work on 6 or some other issue tomorrow? | 14:28 |
| cnd | Satoris, 6 would be helpful if it's not fixed by then | 14:28 |
| cnd | dandrader, I don't think we have a bug for touch accounting yet, so I may just use it | 14:31 |
| dandrader | even better | 14:31 |
| cnd | Satoris, http://paste.ubuntu.com/900536/ | 14:32 |
| cnd | it's a hand edited diff, so it may need some massaging to apply | 14:32 |
| bregma_ | was someone working on porting Unity to GEISv2? | 14:32 |
| dandrader | bregma_, o/ | 14:33 |
| bregma_ | what's the status of that? | 14:33 |
| dandrader | bregma_, done. but not proposed yet as it doesn't fix any bug | 14:33 |
| bregma_ | well, actually I have a list of at least 6 bugs it would fix | 14:33 |
| dandrader | in reality it does fix | 14:33 |
| dandrader | but it's not a proper fix for the bugs | 14:34 |
| dandrader | a proper fix being fixing GEISv1 | 14:34 |
| bregma_ | well, the problem is that GEISv1 is incompatible with the new grail architecture, so the solution is to move to GEISv2 and be done with | 14:34 |
| cnd | bregma_, ? | 14:35 |
| cnd | it's really really late to be moving to geis v2 | 14:35 |
| Satoris | Should someone want to play with it: https://code.launchpad.net/~jpakkane/utouch-evemu/cmake | 14:36 |
| Satoris | Not proposing for merge for obvious reasons. | 14:36 |
| bregma_ | can you describe what problems you were having with the utouch-evemu build as it currently exists? | 14:36 |
| Satoris | It is implemented in autogarbage. | 14:36 |
| bregma_ | I find your attitude unprofessional in this regard | 14:37 |
| Satoris | tvoss: please tell how many hours you have lost due to said build system. | 14:37 |
| bregma_ | I asked for a problem desription, not a politicl rant | 14:37 |
| === dandrader is now known as dandrader|afk | ||
| tvoss | Satoris, bregma_ it is indeed more cumbersome to adjust the auto* build systems for automatic building and testing, at least: that's my experience with it | 14:38 |
| Satoris | I have made my point several times (more than I should have, probably). Autotools is a poor system, which is fragile, hard to use, unreliable, and causes lost productivity. | 14:39 |
| bregma_ | _is_ there a problem description? | 14:39 |
| tvoss | bregma_, not in terms of a description that one could put in a bug report | 14:40 |
| bregma_ | <Satoris> Tried to work on bugs and stuff but turned out unproductive. In a fit of rage rewrote evemu's build system in CMake | 14:40 |
| tvoss | bregma_, it's more like papercuts to me that add up to decreased efficiency | 14:41 |
| bregma_ | surely those bugs have descriptions? | 14:41 |
| Satoris | They are bugs (and design decisions) of autotools, not our projects. | 14:41 |
| Satoris | Time lost fighting the system rather than working on real issues is the main thing for me. | 14:42 |
| bregma_ | what were you trying to do in utouch-evemu that caused the fits of rage? Surely something that bad can be described in words. | 14:42 |
| bregma_ | Given that there are zero bugs against that project | 14:42 |
| Satoris | The fit of rage came elsewhere. I chose evemu, because it was the easiest and thus makes a good proof of concept. | 14:42 |
| bregma_ | ah, I see, purely political then | 14:43 |
| Satoris | Loss of productivity is political? | 14:43 |
| bregma_ | I have not loss of productivity with that project | 14:44 |
| bregma_ | I builds, it runs, it has zero bugs | 14:44 |
| bregma_ | that's why I was asking | 14:44 |
| Satoris | There have been issues raised that possibly CMake could not do some things that we need. This was made to show that it can do what is required. | 14:45 |
| === dandrader|afk is now known as dandrader | ||
| cnd | biab | 15:05 |
| cnd | dandrader, I'm going to propose the fix to the tests for subscription deactivate before slice unreferencing | 16:16 |
| cnd | just fyi | 16:16 |
| dandrader | cnd, | 16:16 |
| dandrader | ok | 16:16 |
| cnd | that's the last thing necessary before I can look into proposing the touch accounting fixes | 16:17 |
| dandrader | cnd, btw, should that practice be documented somewhere in grail.h? | 16:17 |
| dandrader | (the slice before subscription thing) | 16:17 |
| cnd | dandrader, maybe... | 16:17 |
| cnd | I'd actually rather fix it for real | 16:18 |
| cnd | I think if UGEvent held a shared_ptr reference to the subscription, it would work | 16:18 |
| cnd | it's a bit of a corner case | 16:18 |
| cnd | the user normally shouldn't be closing down a subscription while still processing events | 16:18 |
| dandrader | I find it a bit confusing that a gesture can be active and ended at the same time | 16:24 |
| dandrader | cnd, could the code in gesture.cpp:202 be simply a call to End()? | 16:28 |
| cnd | dandrader, End() is a method that does ends a gesture, line 202 is an if conditional | 16:31 |
| cnd | did you mean something else? | 16:31 |
| dandrader | I meant calling End() from inside that if(){} | 16:32 |
| dandrader | cnd, ^ | 16:32 |
| dandrader | instead of replicating the code. One difference is that End() also clears some lists. I don't know if that matters | 16:33 |
| dandrader | that's why I asked | 16:33 |
| cnd | dandrader, yeah, we should call End() there | 16:33 |
| cnd | good catch | 16:33 |
| dandrader | cool. I'll add this change to a branch along with some other simple refactoring commits | 16:36 |
| cnd | sounds good | 16:36 |
| cnd | dandrader, I just proposed the test fixes, btw | 16:37 |
| dandrader | ok, I'll check them after lunch | 16:38 |
| === dandrader is now known as dandrader|lunch | ||
| cnd | dandrader|lunch, I filed a bug for the fact that UGSlice does not have a reference to UGSubscription | 16:41 |
| cnd | so it's a documented issue | 16:41 |
| === dandrader|lunch is now known as dandrader | ||
| * cnd wishes grail and gcc had C11 _Generic support | 18:30 | |
| cnd | I just spent 20 minutes tracking down a bug where I was passing a pointer to a c++ bool instead of an int | 18:31 |
| cnd | which are of different sizes on i386 at least | 18:31 |
| bregma_ | hint: don't do that | 18:34 |
| cnd | bregma_, you're always so helpful :) | 18:42 |
| bregma_ | np | 18:42 |
| cnd | dandrader, bregma_: I just proposed a utouch-grail branch that will make gestures work properly | 19:37 |
| cnd | it should fix all the grail warnings people see in their .xsession-errors and when running apps on the command line | 19:38 |
| cnd | I'm going to get some lunch, biab | 19:38 |
| bregma_ | I'm waiting for MR mail to come through | 19:38 |
| bregma_ | whups, there it is.... | 19:39 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| cnd | dandrader, help me understand why signals and slots is a better architectural solution | 21:24 |
| cnd | the reason I'm hesitant about it is because it replaces a strong linkage between two objects with a weaker dynamic linkage | 21:24 |
| cnd | while signals and slots look better aesthetically, to me at least, I worry that it opens us up to less maintainable architectures because it won't be quite as obvious how objects interact with each other | 21:25 |
| dandrader | it's just about having better or true encapsulation. A Touch is shouldn't know that a Recognizer exists. It's the other way around | 21:31 |
| dandrader | s/Touch is/Touch | 21:31 |
| dandrader | it's a big enabler of unit testing, for instance. | 21:32 |
| dandrader | if you have hard links between objects it gets very difficult to use them individually or to use them in different parts of the system | 21:33 |
| cnd | hmm... that's a good point | 21:35 |
| cnd | dandrader, I'm hesitant to make a change to using a new library at this point though | 21:35 |
| cnd | merely because of how close we are to release | 21:36 |
| cnd | it adds a huge new variable to everything | 21:36 |
| cnd | though after 12.04 is released we can look into using signals | 21:36 |
| cnd | dandrader, what do you think? | 21:36 |
| dandrader | I think if you have objects calling each other you can easily end up with an entanglement of relationships that makes the system more complex. | 21:36 |
| dandrader | but sure | 21:36 |
| dandrader | at this point it might be risky to add this dependence | 21:37 |
| cnd | I do agree about the tangled relationships | 21:38 |
| cnd | it does make me cringe having the all_touches_ array and the Recognizer::DeleteTouch method | 21:38 |
| cnd | dandrader, maybe we don't need Recognizer::DeleteTouch... | 21:39 |
| cnd | maybe we can just delete it from all_touches_ when the TouchEnd is seen | 21:39 |
| cnd | we're guaranteed not to receive any more events for that touch | 21:39 |
| cnd | we're also guaranteed to receive the TouchEnd | 21:40 |
| cnd | we could put a check at the end of ProcessEvent to reap all ended touches from all_touches_ | 21:40 |
| dandrader | yeah, that sounds good | 21:44 |
| dandrader | gotta go. I'll continue reading your patch tomorrow morning. see you tomorrow | 21:45 |
| cnd | bregma_, it dawned on me that the resolution to our aclocal m4 script daily build issue is that we should be checking in a copy of xorg-gtest.m4 into our upstream m4/ directory | 22:47 |
| cnd | the aclocal system uses serial numbers to keep track of newer macro scripts, so it shouldn't be harmful | 22:48 |
| cnd | and our distributed tarball includes the scripts anyways, so it's not as though the real upstream distribution will be any different | 22:48 |
| cnd | merely the upstream source code repository will contain one more file | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!