| /external/brotli/tests/testdata/ |
| D | quickfox_repeated | 1 …the lazy dogThe quick brown fox jumps over the lazy dogThe quick brown fox jumps over the lazy dog…
|
| /external/pcre/dist2/testdata/ |
| D | grepinput | 2 that the pcregrep command is working correctly. The file must be more than
4 features should be added at the end, because some of the tests involve the
7 PATTERN at the start of a line.
8 In the middle of a line, PATTERN appears.
12 Here follows a whole lot of stuff that makes the file over 24KiB long.
15 The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the
16 lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox
17 jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick
18 brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.
20 The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the
[all …]
|
| /external/owasp/sanitizer/lib/htmlparser-1.3/doc/ |
| D | tokenization.txt | 14 Implementations must act as if they used the following state machine to
15 tokenise HTML. The state machine must start in the data state. Most
17 and either switches the state machine to a new state to reconsume the
18 same character, or switches it to a new state (to consume the next
19 character), or repeats the same state (to consume the next character).
26 the PCDATA state. In the RCDATA and CDATA states, a further escape flag
27 is used to control the behavior of the tokeniser. It is either true or
28 false, and initially must be set to the false state. The insertion mode
29 and the stack of open elements also affects tokenization.
31 The output of the tokenization step is a series of zero or more of the
[all …]
|
| D | tree-construction.txt | 14 The input to the tree construction stage is a sequence of tokens from
15 the tokenization stage. The tree construction stage is associated with
21 to render the Document so that it is available to the user, or when it
24 As each token is emitted from the tokeniser, the user agent must
25 process the token according to the rules given in the section
26 corresponding to the current insertion mode.
28 When the steps below require the UA to insert a character into a node,
29 if that node has a child immediately before where the character is to
30 be inserted, and that child is a Text node, and that Text node was the
31 last node that the parser inserted into the document, then the
[all …]
|
| /external/arm-trusted-firmware/docs/design/ |
| D | trusted-board-boot.rst | 5 the platform by authenticating all firmware images up to and including the
9 This document describes the design of Trusted Firmware-A (TF-A) TBB, which is an
10 implementation of the `Trusted Board Boot Requirements (TBBR)`_ specification,
11 Arm DEN0006D. It should be used in conjunction with the
13 of the TBBR.
19 the Arm development platforms, these components are:
21 - A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
23 be used and its hash embedded into the BL1 and BL2 images (only for
26 - The BL1 image, on the assumption that it resides in ROM so cannot be
29 The remaining components in the CoT are either certificates or boot loader
[all …]
|
| /external/OpenCSD/decoder/docs/ |
| D | external_custom.md | 4 @brief A description of the C API external decoder interface.
10 than an ARM core which cannot be decoded by the standard built-in decoders within the library.
14 The external decoder API allows a suitable decoder to be attached to the library and used in the
15 same way as the built-in decoders. This means that the external decoder can be created and destroyed
16 using the decode tree API, and will integrate seamlessly with any ARM processor decoders that are p…
17 of the same tree.
21 - `ocsd_extern_dcd_fact_t` : This is a decoder "factory" that allows the creation of the custom dec…
22 - `ocsd_extern_dcd_inst_t` : This structure provides decoder data to the library for a single decod…
23 …ucture provides a set of callback functions allowing the decoder to use library functionality in t…
25 These structures consist of data and function pointers to allow integration with the library infras…
[all …]
|
| /external/llvm/docs/CommandGuide/ |
| D | llvm-ar.rst | 16 The **llvm-ar** command is similar to the common Unix utility, ``ar``. It
19 LLVM program. However, the archive can contain any kind of file. By default,
21 only the symbol table needs to be consulted, not each individual file member
22 of the archive.
25 files. However, right now it can only write in the GNU format. If an
26 SVR4 or BSD style archive is used with the ``r`` (replace) or ``q`` (quick
27 update) operations, the archive will be reconstructed in GNU format.
41 archives with the GNU format.
52 perform on the archive, a variety of modifiers for that operation, the name of
53 the archive file, and an optional list of file names. These options are used to
[all …]
|
| /external/python/cpython2/Doc/library/ |
| D | cd.rst | 7 :synopsis: Interface to the CD-ROM on Silicon Graphics systems.
15 This module provides an interface to the Silicon Graphics CD library. It is
18 The way the library works is as follows. A program opens the CD-ROM device with
19 :func:`.open` and creates a parser to parse the data from the CD with
21 data from the CD, but also to get status information for the CD-ROM device, and
22 to get information about the CD, such as the table of contents. Data from the
23 CD is passed to the parser, which parses the frames, and calls any callback
26 An audio CD is divided into :dfn:`tracks` or :dfn:`programs` (the terms are used
28 contains a :dfn:`table of contents` which gives the starts of the tracks on the
29 CD. Index 0 is usually the pause before the start of a track. The start of the
[all …]
|
| D | ttk.rst | 11 The :mod:`ttk` module provides access to the Tk themed widget set, which has
14 provided by the new Tk, like anti-aliased font rendering under X11, window
18 The basic idea of :mod:`ttk` is to separate, to the extent possible, the code
19 implementing a widget's behavior from the code implementing its appearance.
47 and :class:`Scrollbar`) will automatically substitute for the Tk widgets.
49 This has the direct benefit of using the new widgets, giving better look & feel
53 achieve the same (or better) styling.
57 …`Converting existing applications to use the Tile widgets <http://tktable.sourceforge.net/tile/doc…
59 converting applications to use the new widgets.
74 As said previously, you will notice changes in look-and-feel as well in the
[all …]
|
| D | posixfile.rst | 16 by the :func:`fcntl.lockf` call.
20 This module implements some additional functionality over the built-in file
21 objects. In particular, it implements file locking, control over the file
22 flags, and an easy interface to duplicate the file object. The module defines a
23 new file object, the posixfile object. It has all the standard file object
24 methods and adds the methods described below. This module only works for
27 To instantiate a posixfile object, use the :func:`posixfile.open` function. The
28 resulting object looks and feels roughly the same as a standard file object.
30 The :mod:`posixfile` module defines the following constants:
35 Offset is calculated from the start of the file.
[all …]
|
| /external/llvm-project/llvm/bindings/ocaml/llvm/ |
| D | llvm.mli | 3 * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
11 This interface provides an OCaml API for the LLVM intermediate
12 representation, the classes in the VMCore library. *)
17 These abstract types correlate directly to the LLVMCore classes. *)
19 (** The top-level container for all LLVM global data. See the
24 objects. See the [llvm::Module] class. *)
27 (** Each value in the LLVM IR has a type, an instance of [lltype]. See the
31 (** Any value in the LLVM IR. Functions, instructions, global variables,
32 constants, and much more are all [llvalues]. See the [llvm::Value] class.
36 (** Used to store users and usees of values. See the [llvm::Use] class. *)
[all …]
|
| /external/llvm/bindings/ocaml/llvm/ |
| D | llvm.mli | 5 * This file is distributed under the University of Illinois Open Source
12 This interface provides an OCaml API for the LLVM intermediate
13 representation, the classes in the VMCore library. *)
18 These abstract types correlate directly to the LLVMCore classes. *)
20 (** The top-level container for all LLVM global data. See the
25 objects. See the [llvm::Module] class. *)
28 (** Each value in the LLVM IR has a type, an instance of [lltype]. See the
32 (** Any value in the LLVM IR. Functions, instructions, global variables,
33 constants, and much more are all [llvalues]. See the [llvm::Value] class.
37 (** Used to store users and usees of values. See the [llvm::Use] class. *)
[all …]
|
| /external/python/cpython3/Doc/library/ |
| D | email.compat32-message.rst | 3 :mod:`email.message.Message`: Representing an email message using the :data:`~email.policy.compat32…
12 The :class:`Message` class is very similar to the
13 :class:`~email.message.EmailMessage` class, without the methods added by that
14 class, and with the default behavior of certain other methods being slightly
15 different. We also document here some methods that, while supported by the
19 The philosophy and structure of the two classes is otherwise the same.
21 This document describes the behavior under the default (for :class:`Message`)
23 you should be using the :class:`~email.message.EmailMessage` class instead.
26 :rfc:`5233` style names and values, where the field name and value are
27 separated by a colon. The colon is not part of either the field name or the
[all …]
|
| D | email.message.rst | 16 The central class in the :mod:`email` package is the :class:`EmailMessage`
17 class, imported from the :mod:`email.message` module. It is the base class for
18 the :mod:`email` object model. :class:`EmailMessage` provides the core
23 to as the *content*). Headers are :rfc:`5322` or :rfc:`6532` style field names
24 and values, where the field name and value are separated by a colon. The colon
25 is not part of either the field name or the field value. The payload may be a
28 latter type of payload is indicated by the message having a MIME type such as
32 ordered dictionary of headers coupled with a *payload* that represents the
33 :rfc:`5322` body of the message, which might be a list of sub-``EmailMessage``
34 objects. In addition to the normal dictionary methods for accessing the header
[all …]
|
| D | tkinter.ttk.rst | 15 The :mod:`tkinter.ttk` module provides access to the Tk themed widget set,
22 The basic idea for :mod:`tkinter.ttk` is to separate, to the extent possible,
23 the code implementing a widget's behavior from the code implementing its
40 To override the basic Tk widgets, the import should follow the Tk import::
49 automatically replace the Tk widgets.
51 This has the direct benefit of using the new widgets which gives a better
52 look and feel across platforms; however, the replacement widgets are not
55 longer present in Ttk widgets. Instead, use the :class:`ttk.Style` class
63 encountered when moving applications to use the new widgets.
77 Using the Ttk widgets gives the application an improved look and feel.
[all …]
|
| /external/wayland-protocols/freedesktop.org/ |
| D | README | 5 available in the Wayland core protocol. Such protocols either add
6 completely new functionality, or extend the functionality of some other
11 of XML files containing the protocol specification, and a README file
16 Protocols may be 'stable', 'unstable' or 'deprecated', and the interface
17 and protocol names as well as place in the directory tree will reflect
21 the maintainers. Changes to such protocols will always be backward
25 will be reflected in the protocol and interface names. See <<Unstable
32 Depending on which of the above states the protocol is in, the protocol
33 is placed within the toplevel directory containing the protocols with the
34 same state. Stable protocols are placed in the +stable/+ directory,
[all …]
|
| /external/libxkbcommon/doc/ |
| D | keymap-format-text-v1.md | 3 This document describes the `XKB_KEYMAP_FORMAT_TEXT_V1` keymap format,
7 are nested the following sections.
12 This is the simplest section type, and is the first one to be
13 compiled. The purpose of this is mostly to map between the
15 by which it can be referred to later, e.g. in the symbols section.
19 Statements of the form:
24 The above would let 49 and 10 be valid keycodes in the keymap, and
25 assign them the names `TLDE` and `AE01` respectively. The format
28 [The naming convention `<AE01>` just denotes the position of the key
29 in the main alphanumric section of a standard QWERTY keyboard, with
[all …]
|
| /external/antlr/runtime/C/ |
| D | doxyfile | 3 # This file describes the settings to be used by the documentation system
17 # This tag specifies the encoding used for all characters in the config file
18 # that follow. The default is UTF-8 which is also the encoding used for all
19 # text before the first occurrence of this tag. Doxygen uses libiconv (or the
20 # iconv built into libc) for the transcoding. See
21 # http://www.gnu.org/software/libiconv for the list of possible encodings.
26 # by quotes) that should identify the project.
31 # This could be handy for archiving the generated documentation or
36 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
37 # base path where the generated documentation will be put.
[all …]
|
| /external/llvm-project/lldb/docs/ |
| D | doxygen.cfg.in | 3 # This file describes the settings to be used by the documentation system
17 # This tag specifies the encoding used for all characters in the config file
18 # that follow. The default is UTF-8 which is also the encoding used for all
19 # text before the first occurrence of this tag. Doxygen uses libiconv (or the
20 # iconv built into libc) for the transcoding. See
21 # http://www.gnu.org/software/libiconv for the list of possible encodings.
26 # by quotes) that should identify the project.
31 # This could be handy for archiving the generated documentation or
36 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
37 # base path where the generated documentation will be put.
[all …]
|
| /external/flac/doc/ |
| D | Doxyfile.in | 3 # This file describes the settings to be used by the documentation system
17 # This tag specifies the encoding used for all characters in the config file
18 # that follow. The default is UTF-8 which is also the encoding used for all
19 # text before the first occurrence of this tag. Doxygen uses libiconv (or the
20 # iconv built into libc) for the transcoding. See
21 # http://www.gnu.org/software/libiconv for the list of possible encodings.
26 # identify the project. Note that if you do not use Doxywizard you need
27 # to put quotes around the project name if it contains spaces.
32 # This could be handy for archiving the generated documentation or
37 # Using the PROJECT_BRIEF tag one can provide an optional one line description
[all …]
|
| /external/sonivox/jet_tools/JetCreator/ |
| D | JetCreatorhlp.dat | 3 play = Plays the segment with associated event attributes. To trigger the event, click the event in…
4 midi file = Displays the MIDI file associated with the segment. This is pulled in from the segment …
5 quantize = Displays the quantization associated with the segment. This is pulled in from the segmen…
7 event type = Selects the type of trigger event.
8 track mutes = Displays the track mute assignments associated with the segment. This is pulled in fr…
14 starting m/b/t = Sets the starting measure, beat, and tick for the event.
15 channel = Selects the MIDI channel for the event.
16 eventid = Sets the ID of the event. Each event must have a unique ID.
18 repeat = Displays the repeat count of the segment. This is pulled in from the segment attributes.
20 track = Selects the MIDI track (not the channel) for the event.
[all …]
|
| /external/python/cpython3/Lib/email/ |
| D | architecture.rst | 14 Takes a sequence of characters or bytes and produces a model of the
20 unicode string) or bytes suitable for transmission over the wire. In
21 the latter case all data is properly encoded using the content transfer
22 encodings specified by the relevant RFCs.
24 Conceptually the package is organized around the model. The model provides both
25 "external" APIs intended for use by application programs using the library,
26 and "internal" APIs intended for use by the Parser and Generator components.
27 This division is intentionally a bit fuzzy; the API described by this
31 In addition to the three major functional components, there is a third key
32 component to the architecture:
[all …]
|
| /external/deqp-deps/amber/docs/ |
| D | amber.md | 4 captured and communicated through a scripting interface. This removes the need
5 to program to the low level interface when reproducing bugs.
7 Amber is broken into multiple layers: the applications, the parsing components
8 and the script execution.
11 There are currently two applications, the `[amber](../samples/amber.cc)`
12 application and the Amber integration into the
14 for configuring the script execution environment (setting up Vulkan, Dawn or
15 another engine), calling into the parsing code to generate a test script and
16 then passing that script into the script execution component.
18 We require the application to configure the execution engine. This allows the
[all …]
|
| /external/tensorflow/tensorflow/core/api_def/base_api/ |
| D | api_def_DebugNumericSummaryV2.pbtxt | 7 Input tensor, to be summarized by the op.
13 Tensor debug mode: the mode in which the input tensor is summarized
14 by the op. See the TensorDebugMode enum in
19 element is the tensor_id, if provided, and -1 otherwise. The 2nd
20 element is a bit which is set to 1 if the input tensor has an
24 element is the tensor_id, if provided, and -1 otherwise. The
25 remaining four slots are the total number of elements, -infs,
26 +infs, and nans in the input tensor respectively.
29 element is the tensor_id, if provided, and -1 otherwise. The 2nd
30 element is the device_id, if provided, and -1 otherwise. The 3rd
[all …]
|
| /external/llvm-project/clang/docs/ |
| D | PCHInternals.rst | 8 This document describes the design and implementation of Clang's precompiled
9 headers (PCH) and modules. If you are interested in the end-user view, please
10 see the :ref:`User's Manual <usersmanual-precompiled-headers>`.
18 To generate PCH files using ``clang -cc1``, use the option `-emit-pch`:
25 resulting PCH file contains the serialized form of the compiler's internal
27 file can then be used as a prefix header with the `-include-pch`
38 the design of precompiled headers is entirely driven by performance concerns.
40 common set of headers that is included in nearly every source file in the
42 header (PCH file). Then, when compiling the source files in the project, we
43 load the PCH file first (as a prefix header), which acts as a stand-in for that
[all …]
|