Home
last modified time | relevance | path

Searched refs:our (Results 1 – 25 of 2605) sorted by relevance

12345678910>>...105

/external/flatbuffers/swift/Sources/FlatBuffers/Documentation.docc/Tutorials/
Dcreate_your_first_buffer.tutorial2 @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 …]
Dcreating_flatbuffer_schema.tutorial15 … We will start by adding our Color object. We will be using an enumerate, to represent this object
24 …Then we will be creating our Monster object of type table. This will contain the current position …
30 …fields to our table with a proper data type for each. Example; weapons, and path would be a vector…
40 And to finalize our monster table, we can add a root type of type Monster.
/external/llvm/docs/tutorial/
DBuildingAJIT1.rst35 - `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 …]
DLangImpl09.rst28 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 …]
DBuildingAJIT2.rst36 added to it. In this Chapter we will make optimization a phase of our JIT
38 layers, but in the long term making optimization part of our JIT will yield an
41 optimization managed by our JIT will allow us to optimize lazily too, rather
42 than having to do all our optimization up-front.
44 To add optimization support to our JIT we will take the KaleidoscopeJIT from
79 but after the CompileLayer we introduce a typedef for our optimization function.
82 our optimization function typedef in place we can declare our OptimizeLayer,
83 which sits on top of our CompileLayer.
85 To initialize our OptimizeLayer we pass it a reference to the CompileLayer
122 OptimizeLayer in our key methods: addModule, findSymbol, and removeModule. In
[all …]
DLangImpl08.rst12 <index.html>`_" tutorial. This chapter describes how to compile our
28 As an example, we can see what clang thinks is our current target
64 We can now use our target triple to get a ``Target``:
108 For our example, we'll use the generic CPU without any additional
124 We're now ready to configure our module, to specify the target and
139 our file to:
171 Does it work? Let's give it a try. We need to compile our code, but
189 link it with our output. Here's the source code:
203 We link our program to output.o and check the result is what we
/external/grpc-grpc/examples/cpp/
Dcpptutorial.md25 With gRPC we can define our service once in a `.proto` file and implement clients
35 The example code for our tutorial is in [examples/cpp/route_guide](route_guide).
70 the returned stream until there are no more messages. As you can see in our
110 the request and response types used in our service methods - for example, here's
126 Next we need to generate the gRPC client and server interfaces from our `.proto`
155 - All the protocol buffer code to populate, serialize, and retrieve our request
172 There are two parts to making our `RouteGuide` service do its job:
173 - Implementing the service interface generated from our service definition:
174 doing the actual "work" of our service.
178 You can find our example `RouteGuide` server in
[all …]
/external/okio/docs/
Dcode_of_conduct.md6 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/skia/site/docs/dev/testing/
D_index.md11 Skia relies heavily on our suite of unit and GM tests, which are served by our
12 DM test tool, for correctness testing. Tests are executed by our trybots, for
13 every commit, across most of our supported platforms and configurations.
22 See the individual subpages for more details on our various test tools.
/external/curl/tests/data/
Dtest108033 http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER -…
40 GET /we/want/our/%TESTNUMBER HTTP/1.1
45 GET /we/want/our/%TESTNUMBER HTTP/1.1
58 http://%HOSTIP:%HTTPPORT/we/want/our/data/%TESTNUMBER0002.txt?coolsite=yes
65 http://%HOSTIP:%HTTPPORT/we/want/our/data/%TESTNUMBER0002.txt?coolsite=yes
Dtest208139 http://user:pass@%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER#anchor --location --referer ';auto' --wr…
46 GET /we/want/our/%TESTNUMBER HTTP/1.1
52 GET /we/want/our/data/%TESTNUMBER0002.txt?coolsite=yes HTTP/1.1
57 Referer: http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER
70 http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER
Dtest118829 …} %{errormsg}\n' http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER http://%HOSTIP:%HTTPPORT/we/want…
36 GET /we/want/our/%TESTNUMBER HTTP/1.1
41 GET /we/want/our/%TESTNUMBER HTTP/1.1
Dtest108141 http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER00…
48 GET /we/want/our/%TESTNUMBER HTTP/1.1
53 GET /we/want/our/%TESTNUMBER0002 HTTP/1.1
66 http://%HOSTIP:%HTTPPORT/we/want/our/data/%TESTNUMBER0099.txt?coolsite=yes
Dtest102933 http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER -w '%{redirect_url} %{url} %{exitcode} %{errormsg}…
40 GET /we/want/our/%TESTNUMBER HTTP/1.1
53 http://%HOSTIP:%HTTPPORT/we/want/our/data/%TESTNUMBER0002.txt?coolsite=yes http://%HOSTIP:%HTTPPORT…
Dtest126133 http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER -w '%{redirect_url}\n' --location --max-redirs 0
40 GET /we/want/our/%TESTNUMBER HTTP/1.1
56 http://%HOSTIP:%HTTPPORT/we/want/our/data/10290002.txt?coolsite=yes
/external/skia/bazel/rbe/
DREADME.md7 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/python/cryptography/docs/x509/
Dtutorial.rst32 >>> # Generate our key
37 >>> # Write our key to disk for safe keeping
51 * Information about our public key (including a signature of the entire body).
76 ... # Sign the CSR with our private key.
78 >>> # Write our CSR out to disk.
82 Now we can give our CSR to a CA, who will give a certificate to us in return.
102 >>> # Generate our key
107 >>> # Write our key to disk for safe keeping
144 ... # Sign our certificate with our private key
146 >>> # Write our certificate out to disk.
/external/pigweed/pw_thread_embos/
DBUILD.bazel47 # TODO(b/234876414): This should depend on embOS but our third parties
78 # TODO(b/234876414): This should depend on embOS but our third parties
104 # TODO(b/234876414): This should depend on embOS but our third parties
118 # TODO(b/234876414): This should depend on embOS but our third parties
148 # TODO(b/234876414): This should depend on embOS but our third parties
175 # TODO(b/234876414): This should depend on embOS but our third parties
199 # TODO(b/234876414): This should depend on embOS but our third parties
/external/mesa3d/docs/drivers/openswr/
Dfaq.rst10 * Architecture - given our focus on scientific visualization, our
40 them through our driver yet. The fetch shader, streamout, and blend is
55 While our current performance is quite good, we know there is more
66 Visualization Toolkit (VTK), and as such our development efforts have
76 the piglit failures are errors in our driver layer interfacing Mesa
77 and SWR. Fixing these issues is one of our major future development
84 download the Mesa source and enable our driver makes life much
87 * The internal gallium APIs are not stable, so we'd like our driver
101 expose through our driver, such as MSAA, geometry shaders, compute
122 intrinsics in our code and the in-tree JIT creation. It is not the
/external/rust/crates/aho-corasick/src/packed/teddy/
DREADME.md87 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/perfetto/docs/design-docs/
Dheapprofd-sampling.md52 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/protobuf/kokoro/
DREADME.md6 tests under Kokoro, our internal CI.
8 We have shared this part of our CI configuration in hopes that it is
10 our test and release processes. If there are changes, please file an
/external/cronet/third_party/protobuf/kokoro/
DREADME.md6 tests under Kokoro, our internal CI.
8 We have shared this part of our CI configuration in hopes that it is
10 our test and release processes. If there are changes, please file an
/external/toolchain-utils/binary_search_tool/ndk/
DREADME.md44 flavor for arm7, our compiler wrapper won't try to bisect object files meant
55 specific build flavor in our app/build.gradle file:
63 We want to add this under the same "productFlavors" section that our arm7
65 task in our build system. We can use this to build and install an x86-64
66 version of our app.
68 Now we want to change our `test_setup.sh` script to run our new gradle task:
/external/cronet/third_party/protobuf/php/
DREFCOUNTING.md56 Note that all of our custom objects (messages, repeated fields, descriptors,
82 simplest way of releasing a ref, it is not the most common (at least in our code
88 // Returns the value of zv to the caller and donates our ref.
94 donates our `zval`'s refcount to the caller, and thus saves us from needing to
95 destroy our `zval` explicitly. This is ideal when we have a full `zval` to
99 parameters to our function and ask for a `zval`, PHP will give us pointers to

12345678910>>...105