| /external/curl/tests/ |
| D | globalconfig.pm | 36 our @EXPORT = qw(
83 our $verbose; # 1 to show verbose test output
84 our $torture; # 1 to enable torture testing
85 our $proxy_address; # external HTTP proxy address
86 our $listonly; # only list the tests
87 our $run_duphandle; # run curl with --test-duphandle to verify handle duplication
88 our $run_event_based; # run curl with --test-event to test the event API
89 our $automakestyle; # use automake-like test status output format
90 our $anyway; # continue anyway, even if a test fail
91 our $CURLVERSION=""; # curl's reported version number
[all …]
|
| /external/pigweed/docs/ |
| D | mission.rst | 8 Our Mission
15 Each component of our mission has additional meaning:
17 - **Software** - Our modular components and surrounding tooling are our
18 primary deliverable. The software is the product of our philosophies.
20 all teams have time for. Our mission is to create reusable processes that can
21 save time and increase team happiness. Our approach is to offer tooling and
22 standards. For example, our integrated code formatting, module directory
25 related products; and over time the requirements change. Our mission is to
26 make these sustained development situations easier. Our approach is to create
28 our porting abstractions make switching a microcontroller vendor easier.
[all …]
|
| /external/llvm/docs/tutorial/ |
| D | BuildingAJIT1.rst | 35 - `Chapter #4 <BuildingAJIT4.html>`_: Improve the laziness of our JIT by
43 To provide input for our JIT we will use the Kaleidoscope REPL from
46 code for that chapter and replace it with optimization support in our JIT class
61 compiler does. To support that aim our initial, bare-bones JIT API will be:
92 In the previous section we described our API, now we examine a simple
96 input for our JIT: Each time the user enters an expression the REPL will add a
99 use the findSymbol method of our JIT class find and execute the code for the
102 of this tutorial we'll modify the REPL to enable new interactions with our JIT
103 class, but for now we will take this setup for granted and focus our attention on
104 the implementation of our JIT itself.
[all …]
|
| D | LangImpl09.rst | 28 our program down to something small and standalone. As part of this
73 First we make our anonymous function that contains our top level
74 statement be our "main":
147 our piece of Kaleidoscope language down to an executable program via this
162 construct one for our fib.ks file.
176 of our IR level descriptions. Construction for it takes a module so we
177 need to construct it shortly after we construct our module. We've left it
180 Next we're going to create a small container to cache some of our frequent
181 data. The first will be our compile unit, but we'll also write a bit of
182 code for our one type since we won't have to worry about multiple typed
[all …]
|
| /external/sdv/vsomeip/third_party/boost/tti/doc/ |
| D | tti_nested_type.qbk | 20 The macro takes a single parameter, which is the name of a nested type. We will call this our
24 As with our other macros we can use the alternative form of the macro
27 of our resulting metafunction is exactly the same.
88 to use it in our template instantiation of one of TTI's macro metafunctions.
92 types we have and that a nested type exists, and these declarations are within our scope, we can
114 from our metafunction, which is the same type as a nested type if it exists or some other
116 compiler error. If we had to use the 'T::InnerType' syntax to specify our type, where 'T' represents
117 out enclosing type and 'InnerType' our nested type, and there was no nested type 'InnerType' within…
124 when doing metafunction programming. Occasionally the TTI produced marker type, when our nested
136 we will want to ask if the type is really our nested type or the marker type instead. Essentially
[all …]
|
| D | tti_nested_type_and_signatures.qbk | 13 reasons why we have two different ways of using our generated metafunction when introspecting
29 `BOOST_TTI_HAS_MEMBER_FUNCTION`, and `BOOST_TTI_HAS_STATIC_MEMBER_FUNCTION`, our composite
30 type in our signatures is broken down into their individual types so that using
40 First using `BOOST_TTI_HAS_MEMBER_FUNCTION` using our composite form we would code:
49 We really want to avoid this situation, so let's try our alternative.
51 Second using `BOOST_TTI_HAS_MEMBER_FUNCTION` using our specific form we would code:
63 whose signature is `void aMemberFunction(U::Ntype)` our 'value' is true,
66 As a second example we will once again use the suppositions of our first
71 First using `BOOST_TTI_HAS_STATIC_MEMBER_FUNCTION` using our composite form we would code:
80 so let's try our alternative.
[all …]
|
| /external/flatbuffers/swift/Sources/FlatBuffers/Documentation.docc/Tutorials/ |
| D | create_your_first_buffer.tutorial | 2 @Intro(title: "After having our code generated") {
3 …After generating the code from the previous section, we will know start creating our monster objec…
11 Starting with a new file, we will create our very first Flatbuffer.
24 … After creating the builder, we can start serializing our data. Before we make our orc Monster,
25 …let's create some Weapons: a Sword and an Axe. However we will start by naming our weapons as `Swo…
35 …We will take our (Sword and Axe) serialized data and serialize their offsets as a vector of tables…
36 So we can reference them later on from our Monster Object
40 We will add our Monster name as a string value just like we did with the weapons.
45 …We will create a path that our monster should be using while roaming in its den. To create a vecto…
55 …Now to serialize our data into our `Monster` object. Which again there are two ways of doing, by c…
[all …]
|
| /external/okio/docs/ |
| D | code_of_conduct.md | 6 thousands of people who have already contributed to our projects — and we want to ensure our commun…
9 This code of conduct outlines our expectations for participants, as well as steps to reporting
11 expect our code of conduct to be honored.
15 * **Be open**: We invite anyone to participate in any aspect of our projects. Our community is
19 * **Be considerate**: People use our work, and we depend on the work of others. Consider users and
26 * **Be collaborative**: Collaboration reduces redundancy and improves the quality of our work. We
27 strive for transparency within our open source community, and we work closely with upstream
28 developers and others in the free software community to coordinate our efforts.
38 This code is not exhaustive or complete. It serves to distill our common understanding of a
49 has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do
[all …]
|
| /external/leakcanary2/docs/ |
| D | code_of_conduct.md | 6 thousands of people who have already contributed to our projects — and we want to ensure our commun…
9 This code of conduct outlines our expectations for participants, as well as steps to reporting
11 expect our code of conduct to be honored.
15 * **Be open**: We invite anyone to participate in any aspect of our projects. Our community is
19 * **Be considerate**: People use our work, and we depend on the work of others. Consider users and
26 * **Be collaborative**: Collaboration reduces redundancy and improves the quality of our work. We
27 strive for transparency within our open source community, and we work closely with upstream
28 developers and others in the free software community to coordinate our efforts.
38 This code is not exhaustive or complete. It serves to distill our common understanding of a
49 has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do
[all …]
|
| /external/cronet/stable/third_party/rust/chromium_crates_io/vendor/aho-corasick-1.1.3/src/packed/teddy/ |
| D | README.md | 87 matches, then a verification step is performed. In this implementation, our
91 pick our fingerprints. In Hyperscan's implementation, I *believe* they use the
98 some examples to motivate the approach. Here are our patterns:
107 our 16 byte block to:
117 this case, our fingerprint is a single byte, so an appropriate abstraction is
127 we can make is to represent our patterns as bit fields occupying a single
143 If we could somehow cause `B` to contain our 16 byte block from the haystack,
144 and if `A` could contain our bitmasks, then we'd end up with something like
152 And if `B` contains our window from our haystack, we could use shuffle to take
153 the values from `B` and use them to look up our bitsets in `A`. But of course,
[all …]
|
| /external/rust/android-crates-io/crates/aho-corasick/src/packed/teddy/ |
| D | README.md | 87 matches, then a verification step is performed. In this implementation, our
91 pick our fingerprints. In Hyperscan's implementation, I *believe* they use the
98 some examples to motivate the approach. Here are our patterns:
107 our 16 byte block to:
117 this case, our fingerprint is a single byte, so an appropriate abstraction is
127 we can make is to represent our patterns as bit fields occupying a single
143 If we could somehow cause `B` to contain our 16 byte block from the haystack,
144 and if `A` could contain our bitmasks, then we'd end up with something like
152 And if `B` contains our window from our haystack, we could use shuffle to take
153 the values from `B` and use them to look up our bitsets in `A`. But of course,
[all …]
|
| /external/cronet/tot/third_party/rust/chromium_crates_io/vendor/aho-corasick-1.1.3/src/packed/teddy/ |
| D | README.md | 87 matches, then a verification step is performed. In this implementation, our
91 pick our fingerprints. In Hyperscan's implementation, I *believe* they use the
98 some examples to motivate the approach. Here are our patterns:
107 our 16 byte block to:
117 this case, our fingerprint is a single byte, so an appropriate abstraction is
127 we can make is to represent our patterns as bit fields occupying a single
143 If we could somehow cause `B` to contain our 16 byte block from the haystack,
144 and if `A` could contain our bitmasks, then we'd end up with something like
152 And if `B` contains our window from our haystack, we could use shuffle to take
153 the values from `B` and use them to look up our bitsets in `A`. But of course,
[all …]
|
| /external/skia/bazel/rbe/ |
| D | README.md | 7 that we use to compile our code.
9 We build our own, bare-bones, Docker image to use on RBE. We intend to use a hermetic toolchain
14 change a small detail of our toolchain.
16 The only requirement we have of our Docker image (beyond the minimum requirements to run Bazel)
17 are that it have sufficient runtime libraries to run our toolchain. For example, this means that
19 Linux binaries in our toolchain. This is the same requirement of any developer who tries to
30 In accordance with SLSA level 1, we want to be able to have a scripted way of building our image
48 be used by our RBE workers. Note the sha256 hash of this created container
57 Defining our own Bazel RBE platforms
62 our own platforms, which we do in `//bazel/platform`, which is where we put the exec_properties
[all …]
|
| /external/rust/android-crates-io/crates/zerocopy/ |
| D | POLICIES.md | 16 correctness, and we take our responsibility to meet that bar very seriously.
19 soundness of our code and prevent regressions.
27 Zerocopy strives to ensure that our code - and code emitted by our custom
28 derives - is sound under any version of Rust as early as our MSRV, and will
35 provides a rationale for its soundness. In order to ensure that our soundness is
53 outstanding uncommented `unsafe` blocks which are tracked in [#429]. Our goal is
63 #### Exceptions to our safety comment policy
68 comment may violate our safety comment policy so long as all of the following
92 <!-- Our policy used to be simply that MSRV was a breaking change in all
99 will only increase our MSRV during semver-breaking version changes (e.g., 0.1 ->
[all …]
|
| /external/perfetto/docs/design-docs/ |
| D | heapprofd-sampling.md | 52 small size and our low sampling rate. This means it’s more efficient to use the
60 our probability of sampling an allocation of any size is, as well as our
68 sample all bytes within the allocation if we sample bytes at our sampling rate.
76 We can see from the chart below that if we 16X our sampling rate from 32KiB to
95 about and it’s useful as a gauge of how wrong on average we might be with our
111 can expect for the things that end up in our heap profile. It’s important to
121 Benchmarking of the STL distributions on a Pixel 4 reinforces our approach of
144 and immediately if the allocation size was greater than our sampling rate. This
149 an allocation equal in size to our sampling rate ~63% of the time, rather than
151 byte smaller than our sampling rate, and one a byte larger. This is still
[all …]
|
| /external/apache-xml/test/java/src/org/apache/qetest/ |
| D | IncludeExcludeFilter.java | 32 * any name on our excludes list is never accepted; any
33 * name on our includes list is accepted as long as any subclass
116 * @return clone of our hash of inclusion name(s); null if not set
134 * if null or blank, unsets any of our includes
158 * @return clone of our hash of exclusion name(s); null if not set
176 * if null or blank, unsets any of our excludes
198 * Tests if a specified file is on our inclusion list.
202 * @return <code>true</code> if the name is on our include list;
210 // Otherwise, our default behavior is to ignore it in isInclude()
216 * Tests if a specified file is on our exclusion list.
[all …]
|
| /external/sdv/vsomeip/third_party/boost/spirit/doc/x3/tutorial/ |
| D | annotation.qbk | 18 trees) in our previoius examples. We parsed a single structure and generated
39 First, we'll update our previous employee struct, this time separating the
68 Like before, we need to tell __fusion__ about our structs to make them
110 imperative code. But semantic actions mess up our clean declarative grammars.
111 If we care to keep our code clean, `on_success` handlers are alternative
121 our `on_success` handler:
141 Our `on_success` handler gets a reference to the actual `position_cache` and
148 Now we'll write a parser for our employee. To simplify, inputs will be of the
216 By subclassing the rule class from a client supplied handler such as our
233 For our particular example, we use to inject the `position_cache` into the
[all …]
|
| /external/sdv/vsomeip/third_party/boost/fusion/doc/ |
| D | extension.qbk | 23 [heading Our example]
58 Next we need to enable the `traits::tag_of` metafunction to return our newly chosen
59 tag type for operations involving our sequence. This is done by specializing
60 `traits::tag_of` for our sequence type.
76 for our sequence, but for an example see the code in:
84 the data within our sequence. As it is straightforward to do,
85 we are going to provide a random access iterator in our example.
106 A quick summary of the details of our iterator:
115 We also need to enable __tag_dispatching__ for our iterator type, with another specialization of
119 add features to our implementation.
[all …]
|
| /external/jspecify/docs/docs/ |
| D | start-here.md | 14 language interoperation. Our initial focus is on nullness analysis.
31 analysis. Our upcoming 1.0 release will be the first tool-neutral,
54 * Our [wiki] has about 20 informal, non-normative articles on various topics
65 * Please experiment with our **[reference implementation]**. This lets you
66 validate your usages of the annotations against our defined semantics, which
67 is when you will really get to find out how helpful or annoying our current
69 tool is still a work in progress, and is not at *full* conformance with our
81 It's not too late for your input to matter! After our 1.0 release, we have plans
82 to extend our support beyond nullness.
84 * Join our new [Google Group]. Introduce yourself! Ask questions, complain, or
[all …]
|
| /external/rust/android-crates-io/extra_versions/crates/zerocopy/ |
| D | POLICIES.md | 16 correctness, and we take our responsibility to meet that bar very seriously.
19 soundness of our code and prevent regressions.
27 Zerocopy strives to ensure that our code - and code emitted by our custom
28 derives - is sound under any version of Rust as early as our MSRV, and will
35 provides a rationale for its soundness. In order to ensure that our soundness is
53 outstanding uncommented `unsafe` blocks which are tracked in [#429]. Our goal is
63 #### Exceptions to our safety comment policy
68 comment may violate our safety comment policy so long as all of the following
92 <!-- Our policy used to be simply that MSRV was a breaking change in all
99 will only increase our MSRV during semver-breaking version changes (e.g., 0.1 ->
[all …]
|
| /external/cronet/stable/third_party/rust/chromium_crates_io/vendor/zerocopy-0.7.35/ |
| D | POLICIES.md | 16 correctness, and we take our responsibility to meet that bar very seriously.
19 soundness of our code and prevent regressions.
27 Zerocopy strives to ensure that our code - and code emitted by our custom
28 derives - is sound under any version of Rust as early as our MSRV, and will
35 provides a rationale for its soundness. In order to ensure that our soundness is
53 outstanding uncommented `unsafe` blocks which are tracked in [#429]. Our goal is
63 #### Exceptions to our safety comment policy
68 comment may violate our safety comment policy so long as all of the following
92 <!-- Our policy used to be simply that MSRV was a breaking change in all
99 will only increase our MSRV during semver-breaking version changes (e.g., 0.1 ->
[all …]
|
| /external/cronet/tot/third_party/rust/chromium_crates_io/vendor/zerocopy-0.7.35/ |
| D | POLICIES.md | 16 correctness, and we take our responsibility to meet that bar very seriously.
19 soundness of our code and prevent regressions.
27 Zerocopy strives to ensure that our code - and code emitted by our custom
28 derives - is sound under any version of Rust as early as our MSRV, and will
35 provides a rationale for its soundness. In order to ensure that our soundness is
53 outstanding uncommented `unsafe` blocks which are tracked in [#429]. Our goal is
63 #### Exceptions to our safety comment policy
68 comment may violate our safety comment policy so long as all of the following
92 <!-- Our policy used to be simply that MSRV was a breaking change in all
99 will only increase our MSRV during semver-breaking version changes (e.g., 0.1 ->
[all …]
|
| /external/apache-xml/test/java/src/org/apache/qetest/xsl/ |
| D | ThreadedStylesheetTestlet.java | 59 // Initialize our classname for TestletImpl's main() method
62 // Initialize our defaultDatalet
65 /** Accessor for our Datalet instead of calling execute(). */
74 /* Description of our current state; changes during our lifecycle. */
81 * description of our current result or status.
93 * Automatically adds our identifier at the start.
95 * @param d String to set as our current description.
102 /* Our 'final' test result; actually changes during our lifecycle. */
149 // All the rest of the test is executed in our thread. in execute()
153 …gger.CRITICALMSG, "//@todo execute() is not yet implemented - you must start our thread yourself"); in execute()
[all …]
|
| /external/toolchain-utils/binary_search_tool/ndk/ |
| D | DO_BISECTION.sh | 6 # application for Android. Our example is the Teapot app that comes bundled with
9 # Our Teapot app only has 12 or so object files generated per build. Bisection
29 # Unzip our repository we'll be testing with.
38 # We want all of our cached files to be stored in ~/NDK_EXAMPLE_BISECT
45 # We will now take our normal "good compiler" and do a full build of the app. We
55 # error in the code, but this is used to simulate our compiler error. This patch
61 # Now that we have installed our bad compiler (i.e. applied the above patch that
72 # outputs. We will now use these to bisect our problem. We should find that
80 # object file has the error. The test_setup.sh script will rebuild our app
|
| /external/pigweed/pw_format/rust/ |
| D | pw_format_example_macro.rs | 28 // Declare a struct to hold our proc macro arguments.
36 // Implement `Parse` for our argument struct.
39 // Our prefix argument comes first argument and ends with a `,`. in parse()
53 // Our generator struct needs to track the prefix as well as the code
71 // Wrap all our fragments in boilerplate and return the code.
79 // Initialize the result string with our prefix. in finalize()
83 // Enumerate all our code fragments. in finalize()
138 // Lastly we declare our proc macro.
141 // Parse our proc macro arguments. in example_macro()
144 // Create our generator. in example_macro()
|