Merge lp:~compiz-team/compiz/compiz.fix_1063617.8 into lp:compiz/0.9.9
| Status: | Merged |
|---|---|
| Approved by: | Daniel van Vugt on 2012-12-10 |
| Approved revision: | 3513 |
| Merged at revision: | 3518 |
| Proposed branch: | lp:~compiz-team/compiz/compiz.fix_1063617.8 |
| Merge into: | lp:compiz/0.9.9 |
| Prerequisite: | lp:~compiz-team/compiz/compiz.fix_1063617.7 |
| Diff against target: |
1565 lines (+692/-261) 4 files modified
compizconfig/libcompizconfig/include/ccs.h (+57/-48) compizconfig/libcompizconfig/src/main.c (+120/-119) compizconfig/libcompizconfig/tests/compizconfig_test_ccs_setting.cpp (+445/-36) compizconfig/mocks/libcompizconfig/compizconfig_ccs_setting_mock.h (+70/-58) |
| To merge this branch: | bzr merge lp:~compiz-team/compiz/compiz.fix_1063617.8 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel van Vugt | 2012-12-07 | Approve on 2012-12-10 | |
| PS Jenkins bot | continuous-integration | 2012-12-07 | Approve on 2012-12-07 |
| Sam Spilsbury | Pending | ||
|
Review via email:
|
|||
This proposal supersedes a proposal from 2012-12-07.
Commit Message
Actually instantiate the CCSSetting test cases, change ccsSet* to provide more detailed information on what actually happened during the set operation.
Description of the Change
This is about preparing a fix for (LP: #1063617).
(LP: #1063617) is really complicated. The problem is that there is a feedback loop between integrated keys and normal keys which can cause the integrated keys to read from normal keys which will be out of date or incorrect because they were never updated.
A part of that problem is that we need to have more information in the backends as to why setting a key to a particular value failed or succeeded.
| Daniel van Vugt (vanvugt) wrote : | # |
| Sam Spilsbury (smspillaz) wrote : | # |
On Wed, Dec 5, 2012 at 2:10 PM, Daniel van Vugt
<email address hidden> wrote:
> Proposal #8, really? Where is the end?
For this set, #9
I can squash them into one big one if you want, but it would be over
8000 lines change.
Testing woo!
> --
> https:/
> Your team Compiz Maintainers is requested to review the proposed merge of lp:~compiz-team/compiz/compiz.fix_1063617.8 into lp:compiz.
--
Sam Spilsbury
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:3507
http://
Executed test runs:
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:3508
http://
Executed test runs:
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Daniel van Vugt (vanvugt) wrote : | # |
There's a 131 line function (macro) call. In some cultures that would be too long for even a function. :)
1151 +INSTANTIATE_
More practically, have you considered the possible future need for multiple error codes in CCSSetStatus? Normally you would have 0 for success and a bunch of non-zero error codes. You've got the opposite. I think you should consider supporting multiple error codes too. Something like:
<0 is an error code
0 is unknown
>0 is a success code
might be more future proof. Then you can generalize in your code and say: if (x < 0) error; if (x > 0) success.
Finally, needs fixing:
The following tests FAILED:
200 - SetSemantics/
202 - SetSemantics/
203 - SetSemantics/
Errors while running CTest
| Sam Spilsbury (smspillaz) wrote : | # |
On Fri, Dec 7, 2012 at 11:49 AM, Daniel van Vugt
<email address hidden> wrote:
> Review: Needs Fixing
>
> There's a 131 line function (macro) call. In some cultures that would be too long for even a function. :)
> 1151 +INSTANTIATE_
>
There's not much I can do about that, other than #defining an alias
for INSTANTIATE_
Google Test.
We really ought to reconsider the 80 character limit, its highly
impractical for C++ where you have heavy use of templates, namespaces
and the like.
> More practically, have you considered the possible future need for multiple error codes in CCSSetStatus? Normally you would have 0 for success and a bunch of non-zero error codes. You've got the opposite. I think you should consider supporting multiple error codes too. Something like:
> <0 is an error code
> 0 is unknown
> >0 is a success code
> might be more future proof. Then you can generalize in your code and say: if (x < 0) error; if (x > 0) success.
Yes, future branches are based on the current status codes.
The whole point of these changes isn't about having descriptive
/error/ codes, its about telling the caller what actually happened as
a result of the ccsSet operation. In future branches, the callers will
need to know if ccsSet just took the existing default value and used
that, or set it to a new value etc.
Also, returning an enum is a far better descriptor of what actually
happened than relying on "convention", which I find happens to be very
inconsistent amonst multiple libraries I've used (some use -1 for
success, others > 1 etc etc.
>
> Finally, needs fixing:
> The following tests FAILED:
> 200 - SetSemantics/
> 202 - SetSemantics/
> 203 - SetSemantics/
> Errors while running CTest
Is this just on your machine?
>
> --
> https:/
> Your team Compiz Maintainers is subscribed to branch lp:~compiz-team/compiz/compiz.fix_1063617.7.
--
Sam Spilsbury
| Sam Spilsbury (smspillaz) wrote : | # |
>>
>> Finally, needs fixing:
>> The following tests FAILED:
>> 200 - SetSemantics/
>> 202 - SetSemantics/
>> 203 - SetSemantics/
>> Errors while running CTest
> Is this just on your machine?
Seems like it. Can you run the test binary through valgrind?
its in build/compizcon
| Sam Spilsbury (smspillaz) wrote : | # |
Ah, nevermind I found the problem.
| Sam Spilsbury (smspillaz) wrote : | # |
> More practically, have you considered the possible future need for multiple
> error codes in CCSSetStatus? Normally you would have 0 for success and a bunch
> of non-zero error codes. You've got the opposite. I think you should consider
> supporting multiple error codes too. Something like:
> <0 is an error code
> 0 is unknown
> >0 is a success code
> might be more future proof. Then you can generalize in your code and say: if
> (x < 0) error; if (x > 0) success.
Actually, I see what you mean here.
I think an enum like this makes sense in light of this suggestion:
typedef enum _CCSSetStatus
{
SetFailed = -1,
SetToDefault = 1,
SetIsDefault = 2,
SetToSameValue = 3,
SetToNewValue = 4
} CCSSetStatus;
(so SetFailed is -1 instead of 0).
Though that means that you can't do if (!ccsSetInt (...))
Thoughts?
>
> Finally, needs fixing:
> The following tests FAILED:
> 200 - SetSemantics/
> 202 - SetSemantics/
> 203 - SetSemantics/
> Errors while running CTest
Fixed :)
| Daniel van Vugt (vanvugt) wrote : | # |
It's only a state of mind that false means error. The history of C APIs shows that zero usually means success. You get used to it. As you would get used to "status < 0".
I know a bool makes the most intuitive sense but it's not an option if you need multiple error codes. And having a separate bool and error code would just be worse.
| Daniel van Vugt (vanvugt) wrote : | # |
Work In Progress... till you're sure you want "SetFailed = 0".
| Sam Spilsbury (smspillaz) wrote : | # |
OK, I've done what I could to reduce the line size in the test case instantiations.
| Sam Spilsbury (smspillaz) wrote : | # |
(SetFailed has been changed to -1)
I note that we're not really writing an OS here.
(Even though compiz has a pretty big second system effect)
| Daniel van Vugt (vanvugt) wrote : | # |
Actually I'm concerned about this now. Not leaving room or being inadequately prepared for multiple error codes can create a real headache in future. Normally you don't care /how/ something succeeded. But you do care how something failed, because it determines how you recover and respond.
You said r3510 "Make the error status -1" but it seems to be missing from the commit.
Please make sure the code is capable and ready to handle multiple different error codes.
| Daniel van Vugt (vanvugt) wrote : | # |
Crap. I just realized that request could make the proposal massive to adjust all other callers. Maybe that's better to consider separately.
| Sam Spilsbury (smspillaz) wrote : | # |
On Fri, Dec 7, 2012 at 2:14 PM, Daniel van Vugt
<email address hidden> wrote:
> Review: Needs Fixing
>
> Actually I'm concerned about this now. Not leaving room or being inadequately prepared for multiple error codes can create a real headache in future. Normally you don't care /how/ something succeeded. But you do care how something failed, because it determines how you recover and respond.
>
> You said r3510 "Make the error status -1" but it seems to be missing from the commit.
Yep, you're right, I might have accidentally reverted it when I was
cleaning up the diff.
Fixed.
I checked the other callers, nobody seems to be checking it like this:
if (ccsSet* (..))
So we should be fine.
>
> Please make sure the code is capable and ready to handle multiple different error codes.
> --
> https:/
> Your team Compiz Maintainers is subscribed to branch lp:~compiz-team/compiz/compiz.fix_1063617.7.
--
Sam Spilsbury
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:3509
http://
Executed test runs:
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:3510
http://
Executed test runs:
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
Unapproved changes made after approval.
http://
Executed test runs:
UNSTABLE: http://
UNSTABLE: http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:3512
http://
Executed test runs:
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
http://
Executed test runs:
UNSTABLE: http://
UNSTABLE: http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:3513
http://
Executed test runs:
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Daniel van Vugt (vanvugt) wrote : | # |
Looks OK now. And we have countless negative integers available for future error codes.


Proposal #8, really? Where is the end?