Searched refs:We (Results 1 – 25 of 2646) sorted by relevance
12345678910>>...106
| /third_party/ltp/testcases/kernel/controllers/freezer/ |
| D | 00_description.txt | 3 We initially try to freeze the cgroup but then try to cancel that.
5 state. We expect the process to still be alive as we cleanup the test.
9 The sleep process is frozen. We then kill the sleep process.
10 Then we unfreeze the sleep process and see what happens. We expect the
16 The sleep process is frozen. We then move the sleep process to a THAWED
17 cgroup. We expect moving the sleep process to fail.
22 part of. We then thaw the subshell process. We expect the unthawed
28 The sleep process is frozen. We then wait until the sleep process should
29 have exited. Then we unfreeze the sleep process. We expect the
36 The sleep process is frozen. We then thaw the process before it exits.
[all …]
|
| /third_party/unity/docs/ |
| D | ThrowTheSwitchCodingStandard.md | 7 We're not perfect. Please be polite where you notice these discrepancies and we'll try to be polite…
14 We've tried to keep our standard simple because we also believe that we can only expect someone to …
20 We're C developers and embedded software developers.
39 We believe that if you're working with a simple compiler and target, you shouldn't need to configur…
45 We name files, functions, variables, and so much more.
57 We want to read our code.
59 We try to avoid double negatives.
60 We try to avoid cryptic abbreviations (sticking to ones we feel are common).
64 We like descriptive names for things, especially functions and variables.
68 We're okay with a bit more typing if it means our code is easier to understand.
[all …]
|
| /third_party/cJSON/tests/unity/docs/ |
| D | ThrowTheSwitchCodingStandard.md | 6 followed. We're not perfect. Please be polite where you notice these discrepancies
14 Being consistent makes code easier to understand. We've made an attempt to keep
22 vision for these tools. We're C developers and embedded software developers.
45 default. We believe that if you're working with a simple compiler and target,
52 Let's talk about naming things. Programming is all about naming things. We name
67 We want to read our code. This means we like names and flow that are more
68 naturally read. We try to avoid double negatives. We try to avoid cryptic
74 We like descriptive names for things, especially functions and variables.
77 longer than the average. Guilty. We're okay with a tiny bit more typing if it
90 naming. We find i, j, and k are better loop counters than loopCounterVar or
[all …]
|
| /third_party/skia/third_party/externals/swiftshader/third_party/llvm-10.0/llvm/lib/Target/SystemZ/ |
| D | README.txt | 5 The initial backend is deliberately restricted to z10. We should add support
35 We don't use the BRANCH ON INDEX instructions.
39 We only use MVC, XC and CLC for constant-length block operations.
40 We could extend them to variable-length operations too,
47 We don't use CUSE or the TRANSLATE family of instructions for string
52 We don't take full advantage of builtins like fabsl because the calling
66 We don't use ICM, STCM, or CLM.
70 We don't use ADD (LOGICAL) HIGH, SUBTRACT (LOGICAL) HIGH,
151 We might want to model all access registers and use them to spill
156 We might want to use the 'overflow' condition of eg. AR to support
|
| /third_party/node/deps/openssl/openssl/ |
| D | README.md | 19 We are not in competition with OpenSSL project. We informed them of
20 our plans to fork the code before we went public. We do not speak for the
36 We will endeavor to track OpenSSL releases within a day or so, and there is an
44 We don't want to conflict with OpenSSL branch names. Our current plan is to append
69 and `3` (for the 3.0 branch). We will be prefixing `81` (ASCII for 'Q') to
83 We currently do not have any plans to change the name, mainly because we
91 We are not doing anything with FIPS. This is actually good news: you should
98 We want any code here to be acceptable to OpenSSL. This means that all contributors
100 [contributor license agreements](https://www.openssl.org/policies/cla.html). We
102 done so (and we might verify with OpenSSL). We are only interested in making it
[all …]
|
| /third_party/rust/crates/nix/ |
| D | CONVENTIONS.md | 14 We follow the conventions laid out in [Keep A CHANGELOG][kacl].
20 We do not define integer constants ourselves, but use or reexport them from the
23 We use the functions exported from [libc][libc] instead of writing our own
26 We use the `struct` definitions from [libc][libc] internally instead of writing
43 bitwise operations. We represent the types of these parameters by types defined
48 We name the type for a set of constants whose element's names start with `FOO_`
71 We represent sets of constants that are intended as mutually exclusive arguments
|
| D | CONTRIBUTING.md | 3 We're really glad you're interested in contributing to nix! This
14 We use GitHub's [issue tracker][issues].
42 We use labels to help manage issues. The structure is modeled after
58 some [great documentation][pr-docs] on using the Pull Request feature. We use the 'fork and
64 you fix a bug, please add an appropriate note to the [change log][cl]. We
78 environment. We also have [continuous integration set up on
|
| /third_party/skia/third_party/externals/angle2/doc/ |
| D | Update20120704.md | 3 We haven't posted an update on the development status of ANGLE in quite some
17 We have recently completed the implementation of depth texture support
28 We have also made a number of improvements in the shader compiler.
30 * We addressed a number of defects related to scoping differences between HLSL and
31 GLSL and improved the scoping support in ANGLE's compiler front-end. We also
34 * We addressed a number of correctness issues in the GLSL to HLSL
35 translation process. We fixed some bugs related to constant propagation and
41 * We implemented detection
63 explicitly defined. We use these new functions instead of the original ones in
71 current ES 2.0 implementations. We would only be able to achieve parity with
[all …]
|
| /third_party/pulseaudio/shell-completion/zsh/ |
| D | _pulseaudio | 300 # We're completing the first parameter after "list".
306 # We're completing the second parameter after "list". As
316 # We're completing the first parameter after "play-sample".
319 # We're completing the second parameter after "play-sample".
326 # We're completing the first parameter after "load-module".
329 # We're completing the second or later parameter after
337 # We're completing the first parameter after "move-sink-input".
343 # We're completing the second parameter after
351 # We're completing the first parameter after
357 # We're completing the second parameter after
[all …]
|
| /third_party/node/doc/contributing/ |
| D | technical-values.md | 7 evolve. We hope they are useful to people new
28 We value ensuring that developers are productive and enjoy developing
54 We value keeping Node.js safe, performant, and lightweight.
55 We value enabling the ability to investigate and debug problems in
68 We value the productivity and happiness of the Node.js maintainers.
78 We value providing developers with modern APIs and technologies
|
| /third_party/curl/tests/data/ |
| D | test1097 | 15 HTTP/1.1 200 We are fine and cool
24 HTTP/1.1 200 We are fine and cool
30 HTTP/1.1 200 We are fine and cool
33 HTTP/1.1 200 We are fine and cool
|
| /third_party/vixl/ |
| D | .clang-tidy | 2 # We use the clang-tidy defaults and the Google styles as a baseline, with a
11 # We don't put names on TODOs.
16 # We do this in internal contexts (typically in .cc files), but clang-tidy
19 # We follow this rule, but have some exceptions that are annotated using
|
| /third_party/curl/docs/ |
| D | CODE_STYLE.md | 20 We also work hard on writing code that are warning-free on all the major
30 functions should be made static. We like lower case names.
37 We use only spaces for indentation, never TABs. We use two spaces for each new
51 introduced in the C standard until C99. We use only __/* comments */__.
141 assigning variables within if/while conditions. We frown upon this style:
158 We never write multiple statements on the same source line, even for short
199 We use the 'return' statement without extra parentheses around the value:
266 Use **#ifdef HAVE_FEATURE** to do conditional code. We avoid checking for
271 We also encourage use of macros/functions that possibly are empty or defined
|
| /third_party/skia/third_party/externals/spirv-cross/shaders/comp/ |
| D | cfg-preserve-parameter.comp | 3 // We write in all paths (and no reads), so should just be out.
12 // We write in all paths (and no reads), so should just be out.
27 // We don't write in all paths, so should be inout.
|
| /third_party/skia/third_party/externals/spirv-cross/shaders-msl/comp/ |
| D | cfg-preserve-parameter.comp | 3 // We write in all paths (and no reads), so should just be out.
12 // We write in all paths (and no reads), so should just be out.
27 // We don't write in all paths, so should be inout.
|
| /third_party/mbedtls/ |
| D | BRANCHES.md | 16 We retain a number of historical branches, whose names are prefixed by `archive/`,
20 We use [Semantic Versioning](https://semver.org/). In particular, we maintain
22 the API of 3.(x+1) is backward compatible with 3.x). We only break API
23 compatibility on major version changes (e.g. from 3.x to 4.0). We also maintain
28 We maintain API compatibility in released versions of Mbed TLS. If you have
65 We maintain backward compatibility with previous versions of the
68 We intend to maintain this backward compatibility throughout a major version
77 are an experimental feature. We intend to maintain compatibility with the
|
| /third_party/cmsis/ |
| D | README.md | 71 We encourage you to append implementation suggestions as this helps to decrease the
74 We will be monitoring and responding to issues as best we can.
78 - **bug** – We consider this issue to be a bug that will be investigated.
80 - **wontfix** - We appreciate this issue but decided not to change the current behavior.
86 - **out-of-scope** - We consider this issue loosely related to CMSIS. It might by implemented outsi…
88 - **question** – We have further questions to this issue. Please review and provide feedback.
94 - **DONE** - We consider this issue as resolved - please review and close it. In case of no further…
98 - **Important Information** - We provide essential information regarding planned or resolved major …
|
| /third_party/spirv-tools/docs/ |
| D | projects.md | 3 We are experimenting with using the [GitHub Project
46 * We want these to be Issues (not Notes) so that someone can claim the work
58 * We keep rejected ideas so they are not proposed again. This serves
60 * We should record why an idea is rejected. For this reason, a rejected
65 We are considering prioritizing cards in the `Ideas` and `Ready to start`
81 We delete the placeholder when all its work has been decomposed into
|
| /third_party/skia/third_party/externals/spirv-tools/docs/ |
| D | projects.md | 3 We are experimenting with using the [GitHub Project
46 * We want these to be Issues (not Notes) so that someone can claim the work
58 * We keep rejected ideas so they are not proposed again. This serves
60 * We should record why an idea is rejected. For this reason, a rejected
65 We are considering prioritizing cards in the `Ideas` and `Ready to start`
81 We delete the placeholder when all its work has been decomposed into
|
| /third_party/skia/third_party/externals/swiftshader/third_party/SPIRV-Tools/docs/ |
| D | projects.md | 3 We are experimenting with using the [GitHub Project
46 * We want these to be Issues (not Notes) so that someone can claim the work
58 * We keep rejected ideas so they are not proposed again. This serves
60 * We should record why an idea is rejected. For this reason, a rejected
65 We are considering prioritizing cards in the `Ideas` and `Ready to start`
81 We delete the placeholder when all its work has been decomposed into
|
| /third_party/protobuf/benchmarks/ |
| D | README.md | 18 We are using [google/benchmark](https://github.com/google/benchmark) as the
28 We're using maven to build the java benchmarks, which is the same as to build
29 the Java protobuf. There're no other tools need to install. We're using
34 We're using python C++ API for testing the generated
110 We have three versions of python protobuf implementation: pure python, cpp
138 We have two version of php protobuf implemention: pure php, php with c extension. To run these vers…
225 We intend to add support for this within the makefile in due course.
240 We would like to add more data sets. In general we will favor data sets
|
| /third_party/typescript/tests/baselines/reference/ |
| D | renamingDestructuredPropertyInFunctionType.errors.txt | 45 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:10:36: We can…
66 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:20:40: We can…
75 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:26:28: We can…
79 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:27:26: We can…
86 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:29:28: We can…
90 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:30:32: We can…
94 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:31:30: We can…
101 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:33:32: We can…
108 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:37:24: We can…
114 !!! related TS2843 tests/cases/compiler/renamingDestructuredPropertyInFunctionType.ts:40:17: We can…
[all …]
|
| /third_party/lame/ |
| D | TODO | 48 get_audio.c: We need a way to open a second mp3 file, without
68 channel, less filtering for mid channel. We need to first replace
84 12. We should consider moving the experts options from the *long
94 We would probably need the best of both.
98 60. Different ATH handling for sfb21. We are using the minimum value of ath
100 We could perhaps use 2 or 3 ath partitions in sfb21
|
| /third_party/skia/third_party/externals/swiftshader/third_party/llvm-10.0/llvm/lib/Target/PowerPC/ |
| D | README.txt | 34 We compile the hottest inner loop of viterbi to:
69 We generate:
123 We still generate calls to foo$stub, and stubs, on Darwin. This is not
209 We should compile these two functions to the same thing:
287 We generate relatively atrocious code for this loop compared to gcc.
289 We could also strength reduce the rem and the div:
294 We generate ugly code for this:
329 We emit:
339 We could collapse a bunch of those ORs and ANDs and generate the following
394 We compile this:
[all …]
|
| /third_party/node/deps/v8/src/builtins/ |
| D | promise-jobs.tq | 16 // We can use a simple optimization here if we know that {then} is the
19 // @@species lookup chain is intact: We can connect {thenable} and
23 // We take the generic (slow-)path if a PromiseHook is enabled or the
31 // We know that the {thenable} is a JSPromise, which doesn't require
|
12345678910>>...106