Searched full:easier (Results 1 – 25 of 5787) sorted by relevance
12345678910>>...232
| /external/openthread/third_party/mbedtls/repo/scripts/mbedtls_dev/ |
| D | bignum_mod.py | 49 # To make negative tests easier, append 0 for success to the
66 # To make negative tests easier, append 0 for success to the
85 # To make negative tests easier, append 0 for success to the
100 # To make negative tests easier, append "0" for success to the
|
| /external/mbedtls/scripts/mbedtls_dev/ |
| D | bignum_mod.py | 49 # To make negative tests easier, append 0 for success to the
66 # To make negative tests easier, append 0 for success to the
85 # To make negative tests easier, append 0 for success to the
100 # To make negative tests easier, append "0" for success to the
|
| /external/curl/docs/ |
| D | CURLDOWN.md | 15 Make it easier for users to contribute and write documentation. A format that
16 is easier on the eye in its source format.
26 This allows us to fix issues in the nroff format easier since now we generate
165 converted with `roffit`. This makes the curldown text easier to read even when
|
| /external/guice/ |
| D | README.md | 12 …cases, but your code will not depend directly on them. Your code will be easier to change, unit te…
18 …easier and faster, not harder and slower. In that vein, Guice steers clear of surprises and magic.…
|
| /external/google-styleguide/ |
| D | Rguide.md | 5 easier to read, share, and verify.
59 `foo <-` is easier than searching for `foo <-` and `-> foo` (possibly split over
92 While there is a small performance penalty for using `::`, it makes it easier to
|
| /external/pigweed/docs/ |
| D | mission.rst | 26 make these sustained development situations easier. Our approach is to create
28 our porting abstractions make switching a microcontroller vendor easier.
51 correspondingly larger teams easier and faster, with an eye to support rapid
|
| /external/rust/android-crates-io/extra_versions/crates/clap/src/ |
| D | _faq.rs | 33 //! - Easier cross-linking in documentation
36 //! derives in mind and easier to change `clap` in response to `structopt` bugs.
77 //! - Easier to read, write, and modify
78 //! - Easier to keep the argument declaration and reading of argument in sync
79 //! - Easier to reuse, e.g. [clap-verbosity-flag](https://crates.io/crates/clap-verbosity-flag)
|
| /external/cronet/tot/third_party/rust/chromium_crates_io/vendor/clap-4.5.21/src/ |
| D | _faq.rs | 33 //! - Easier cross-linking in documentation
36 //! derives in mind and easier to change `clap` in response to `structopt` bugs.
77 //! - Easier to read, write, and modify
78 //! - Easier to keep the argument declaration and reading of argument in sync
79 //! - Easier to reuse, e.g. [clap-verbosity-flag](https://crates.io/crates/clap-verbosity-flag)
|
| /external/rust/android-crates-io/crates/clap/src/ |
| D | _faq.rs | 33 //! - Easier cross-linking in documentation
36 //! derives in mind and easier to change `clap` in response to `structopt` bugs.
77 //! - Easier to read, write, and modify
78 //! - Easier to keep the argument declaration and reading of argument in sync
79 //! - Easier to reuse, e.g. [clap-verbosity-flag](https://crates.io/crates/clap-verbosity-flag)
|
| /external/cronet/stable/third_party/rust/chromium_crates_io/vendor/clap-4.5.21/src/ |
| D | _faq.rs | 33 //! - Easier cross-linking in documentation
36 //! derives in mind and easier to change `clap` in response to `structopt` bugs.
77 //! - Easier to read, write, and modify
78 //! - Easier to keep the argument declaration and reading of argument in sync
79 //! - Easier to reuse, e.g. [clap-verbosity-flag](https://crates.io/crates/clap-verbosity-flag)
|
| /external/llvm/docs/HistoricalNotes/ |
| D | 2001-02-06-TypeNotationDebateResp1.txt | 33 example may be easier for you to read because this is the way you have been
34 thinking about it. Honestly, I don't find it much easier than the C syntax.
43 make function pointers easier but makes arrays much more difficult seems
|
| D | 2002-06-25-MegaPatchInfo.txt | 26 easier to handle.
31 makes it much easier to write nested loops that iterator over things, changing
48 to make it easier to use. Specifically, the include graph now includes these
|
| D | 2001-02-06-TypeNotationDebateResp4.txt | 26 > example may be easier for you to read because this is the way you have been
27 > thinking about it. Honestly, I don't find it much easier than the C syntax.
64 > make function pointers easier but makes arrays much more difficult seems
|
| /external/bazelbuild-rules_python/python/private/ |
| D | register_extension_info.bzl | 14 """Stub implementation to make patching easier."""
18 """A no-op stub to make Google patching easier."""
|
| /external/rust/android-crates-io/crates/ucs2/ |
| D | README.md | 15 The code was extracted and placed here for easier maintenance and easier reuse.
|
| /external/aws-sdk-java-v2/.changes/2.13.x/ |
| D | 2.13.53.json | 8 … consisting of a customer-defined key and an optional value allowing for easier resource managemen…
13 …"description": "We have launched a self-service option to make it easier for customers to manage t…
|
| /external/google-cloud-java/java-grafeas/src/main/java/io/grafeas/v1/ |
| D | UpgradeOccurrenceOrBuilder.java | 96 * making it easier to use the occurrence.
110 * making it easier to use the occurrence.
124 * making it easier to use the occurrence.
|
| /external/deqp-deps/SPIRV-Tools/ |
| D | CONTRIBUTING.md | 25 * The easier it is for a developer to reproduce the problem, the quicker a
26 fix can be found and verified. It will also make it easier for someone
70 Adding new commits makes it easier for the reviewer to see what has changed
112 always-working history is easier to understand and to bisect in case we want to
|
| /external/tensorflow/tensorflow/python/grappler/ |
| D | cost_analyzer_test.py | 59 # Also print the report to make it easier to debug
79 # Also print the report to make it easier to debug
105 # Print the report to make it easier to debug
155 # Print the report to make it easier to debug
|
| /external/swiftshader/third_party/SPIRV-Tools/ |
| D | CONTRIBUTING.md | 25 * The easier it is for a developer to reproduce the problem, the quicker a
26 fix can be found and verified. It will also make it easier for someone
70 Adding new commits makes it easier for the reviewer to see what has changed
112 always-working history is easier to understand and to bisect in case we want to
|
| /external/angle/third_party/spirv-tools/src/ |
| D | CONTRIBUTING.md | 25 * The easier it is for a developer to reproduce the problem, the quicker a
26 fix can be found and verified. It will also make it easier for someone
70 Adding new commits makes it easier for the reviewer to see what has changed
112 always-working history is easier to understand and to bisect in case we want to
|
| /external/cronet/tot/base/tracing/stdlib/chrome/ |
| D | README | 3 …ontains commonly used SQL tables, views, functions and macros to make it easier for users to query…
5 …dlib is the Chromium repository in `base/tracing/stdlib/` which makes it easier to develop new met…
|
| /external/cronet/stable/base/tracing/stdlib/chrome/ |
| D | README | 3 …ontains commonly used SQL tables, views, functions and macros to make it easier for users to query…
5 …dlib is the Chromium repository in `base/tracing/stdlib/` which makes it easier to develop new met…
|
| /external/cldr/docs/site/development/development-process/design-proposals/ |
| D | uts-35-splitting.md | 32 …or the subdocuments. We've done this in ICU, and it makes it easier to edit, and thus easier to ad…
|
| /external/curl/docs/internals/ |
| D | CODE_STYLE.md | 9 Source code that has a common style is easier to read than code that uses
12 making it easier to review when new things are added and it helps debugging
69 1. Narrower columns are easier to read than wide ones. There is a reason
72 2. Narrower columns allow developers to easier show multiple pieces of code
|
12345678910>>...232