| /dports/multimedia/libv4l/linux-5.13-rc2/Documentation/filesystems/ |
| H A D | porting.rst | 185 int (*test)(struct inode *, void *),
203 test and set for you.
393 via rcu-walk path walk (basically, if the file can have had a path name in the
409 filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
412 are rcu-walk aware, shown below. Filesystems should take advantage of this
420 the filesystem provides it), which requires dropping out of rcu-walk mode. This
426 directory inodes on the way down a path walk (to check for exec permission). It
479 anymore, so if you require i_mutex locking you must make sure to take it and
491 for the inode. If d_make_root(inode) is passed a NULL inode it returns NULL
670 they used to - they just take it exclusive. However, ->lookup() may be
[all …]
|
| H A D | path-lookup.rst | 211 REF-walk can take ``d_lock`` to get a stable reference to ``d_parent``,
472 component remains for the caller to sort out. Those callers are
710 is needed - which it usually is - RCU-walk must take a copy and then
736 it for that too, but for quite a bit more.
813 take ``i_rwsem`` and modifies the directory in a way that RCU-walk needs
817 REF-walk mode which can take whatever locks are needed.
845 Other reasons for dropping out of RCU-walk that do not trigger a call
868 For ``mnt->mnt_count`` it is safe to take a reference as long as
1059 allocate memory without the need to drop out of RCU-walk. If a
1252 We previously said of RCU-walk that it would "take no locks, increment
[all …]
|
| /dports/multimedia/v4l-utils/linux-5.13-rc2/Documentation/filesystems/ |
| H A D | porting.rst | 185 int (*test)(struct inode *, void *),
203 test and set for you.
393 via rcu-walk path walk (basically, if the file can have had a path name in the
409 filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
412 are rcu-walk aware, shown below. Filesystems should take advantage of this
420 the filesystem provides it), which requires dropping out of rcu-walk mode. This
426 directory inodes on the way down a path walk (to check for exec permission). It
479 anymore, so if you require i_mutex locking you must make sure to take it and
491 for the inode. If d_make_root(inode) is passed a NULL inode it returns NULL
670 they used to - they just take it exclusive. However, ->lookup() may be
[all …]
|
| H A D | path-lookup.rst | 211 REF-walk can take ``d_lock`` to get a stable reference to ``d_parent``,
472 component remains for the caller to sort out. Those callers are
710 is needed - which it usually is - RCU-walk must take a copy and then
736 it for that too, but for quite a bit more.
813 take ``i_rwsem`` and modifies the directory in a way that RCU-walk needs
817 REF-walk mode which can take whatever locks are needed.
845 Other reasons for dropping out of RCU-walk that do not trigger a call
868 For ``mnt->mnt_count`` it is safe to take a reference as long as
1059 allocate memory without the need to drop out of RCU-walk. If a
1252 We previously said of RCU-walk that it would "take no locks, increment
[all …]
|
| /dports/multimedia/v4l_compat/linux-5.13-rc2/Documentation/filesystems/ |
| H A D | porting.rst | 185 int (*test)(struct inode *, void *),
203 test and set for you.
393 via rcu-walk path walk (basically, if the file can have had a path name in the
409 filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
412 are rcu-walk aware, shown below. Filesystems should take advantage of this
420 the filesystem provides it), which requires dropping out of rcu-walk mode. This
426 directory inodes on the way down a path walk (to check for exec permission). It
479 anymore, so if you require i_mutex locking you must make sure to take it and
491 for the inode. If d_make_root(inode) is passed a NULL inode it returns NULL
670 they used to - they just take it exclusive. However, ->lookup() may be
[all …]
|
| H A D | path-lookup.rst | 211 REF-walk can take ``d_lock`` to get a stable reference to ``d_parent``,
472 component remains for the caller to sort out. Those callers are
710 is needed - which it usually is - RCU-walk must take a copy and then
736 it for that too, but for quite a bit more.
813 take ``i_rwsem`` and modifies the directory in a way that RCU-walk needs
817 REF-walk mode which can take whatever locks are needed.
845 Other reasons for dropping out of RCU-walk that do not trigger a call
868 For ``mnt->mnt_count`` it is safe to take a reference as long as
1059 allocate memory without the need to drop out of RCU-walk. If a
1252 We previously said of RCU-walk that it would "take no locks, increment
[all …]
|
| /dports/math/R-cran-mcmc/mcmc/vignettes/ |
| H A D | morph.Rnw | 59 \eqref{eq:def-fy}, a Metropolis random-walk for $f_Y$ can be geometrically
61 even though a Metropolis random-walk for $f_X$ is not.
77 A necessary condition for geometric ergodicity of a random-walk Metropolis
81 a sufficient condition for geometric ergodicity of a random-walk Metropolis
90 $\pi_\gamma$ for which a Metropolis random-walk will be geometrically
188 t.test(out$batch)
232 take, we save the results to a file
266 We do a formal test just to check our interpretation of the plot
268 shapiro.test(foo)
302 We do a formal test just to check our interpretation of the plot
[all …]
|
| /dports/math/R-cran-mcmc/mcmc/inst/doc/ |
| H A D | morph.Rnw | 59 \eqref{eq:def-fy}, a Metropolis random-walk for $f_Y$ can be geometrically
61 even though a Metropolis random-walk for $f_X$ is not.
77 A necessary condition for geometric ergodicity of a random-walk Metropolis
81 a sufficient condition for geometric ergodicity of a random-walk Metropolis
90 $\pi_\gamma$ for which a Metropolis random-walk will be geometrically
188 t.test(out$batch)
232 take, we save the results to a file
266 We do a formal test just to check our interpretation of the plot
268 shapiro.test(foo)
302 We do a formal test just to check our interpretation of the plot
[all …]
|
| /dports/textproc/kibana6/kibana-6.8.16-darwin-x86_64/node_modules/acorn-dynamic-import/node_modules/acorn/ |
| H A D | README.md | 122 - `block`: `true` if the comment is a block comment, false if it
250 invalid code in as meaningful a way as it can. It'll insert identifier
299 walk, where the walker functions are responsible for continuing the
333 (as wildcard) or a number. `test` may be a string (indicating a node
340 **findNodeAround**`(node, pos, test, base, state)` is a lot like
371 The utility spits out the syntax tree as JSON data.
381 The command-line test runner (`npm test`) uses the ES6 modules. The
385 If you are working on Acorn, you'll probably want to try the code out
398 the parser object. This is not a clean, elegant API—using it requires
403 combine such plugins, so that if you have, for example, a plugin for
[all …]
|
| /dports/lang/rust/rustc-1.58.1-src/src/tools/rustfmt/ |
| H A D | Contributing.md | 20 Having a strong test suite for a tool like this is essential. It is very easy
34 leaves a piece of code unformatted, it may suffice to only create a target file.
53 test harness looks for a configuration file with the same filename as the test
54 file in the `./tests/config/` directory, so a test source file named `test-indent.rs`
80 Talking of tests, if you add a new feature or fix a bug, please also add a test.
124 take an AST (abstract syntax tree) and print it in a nice way (including staying
130 a lot of code, but it is relatively simple.
174 to walk the AST. This is in [src/visitor.rs](src/visitor.rs). This is really just used to walk
177 then walk their own children.
184 take a context which contains information used for parsing, the current block
[all …]
|
| /dports/security/py-passlib/passlib-1.7.4/docs/lib/ |
| H A D | passlib.utils.handlers.rst | 37 Once a handler has been written, it may be used explicitly, passed into
42 :ref:`testing-hash-handlers` for details about how to test
63 for almost all the boilerplate associated with writing a password hash.
75 * fill out the :attr:`~PasswordHash.setting_kwds` attribute with a tuple listing
80 this method should take in a potential hash string,
109 By default, it returns ``True`` for all hashes that :meth:`~GenericHandler.from_string`
112 with the hash's identifying prefix, which :meth:`~GenericHandler.identify` will then test for
140 Show some walk-through examples of how to use GenericHandler and its mixins
162 which can be subclassed to provide a unittest-compatible test class capable of
174 # create a subclass for the handler...
[all …]
|
| /dports/devel/mdds/mdds-1.7.0/ |
| H A D | CHANGELOG | 26 * added support for lcov, to visualize test coverage.
42 boolean_element_block, by adding specialization for it to work around the
108 * all of its walk() methods now return either a copied or moved
169 method with out-of-bound segment value pair.
200 * find() and prefix_search() now have a variant that can take a key
215 take a key value that is of key_type directly.
291 * added a variant of walk() that takes the upper-left and
481 * setter methods that take a position object to also return a
652 * added MSVS Solution file, to make it easier to build unit test
716 * added quickcheck test code.
[all …]
|
| /dports/textproc/kibana6/kibana-6.8.16-darwin-x86_64/node_modules/webpack/node_modules/acorn/ |
| H A D | README.md | 127 - `block`: `true` if the comment is a block comment, false if it
255 invalid code in as meaningful a way as it can. It'll insert identifier
263 `acorn.walk` when loaded without a module system.
304 walk, where the walker functions are responsible for continuing the
338 (as wildcard) or a number. `test` may be a string (indicating a node
345 **findNodeAround**`(node, pos, test, base, state)` is a lot like
376 The utility spits out the syntax tree as JSON data.
390 If you are working on Acorn, you'll probably want to try the code out
403 the parser object. This is not a clean, elegant API—using it requires
408 combine such plugins, so that if you have, for example, a plugin for
[all …]
|
| /dports/www/node10/node-v10.24.1/deps/acorn/ |
| H A D | README.md | 127 - `block`: `true` if the comment is a block comment, false if it
255 invalid code in as meaningful a way as it can. It'll insert identifier
263 `acorn.walk` when loaded without a module system.
304 walk, where the walker functions are responsible for continuing the
338 (as wildcard) or a number. `test` may be a string (indicating a node
345 **findNodeAround**`(node, pos, test, base, state)` is a lot like
376 The utility spits out the syntax tree as JSON data.
390 If you are working on Acorn, you'll probably want to try the code out
403 the parser object. This is not a clean, elegant API—using it requires
408 combine such plugins, so that if you have, for example, a plugin for
[all …]
|
| /dports/math/stanmath/math-4.2.0/doxygen/contributor_help_pages/ |
| H A D | distribution_tests.md | 3 …ve written a framework for testing our univariate distribution functions. It's not well doc'ed and…
22 This will take hours, perhaps many hours. Most of the time is spent compiling. You might want to ad…
27 …write a test and what's inside the framework are further down. These are the steps taken when call…
31 …test file inside `test/prob/*/*`, it will call the executable with the test file as the first argu…
50 2. Run the test. For example, it were the bernoulli test for reverse mode:
55 Before getting into how to write a distribution test, I'll walk through some of the reasons why we …
57 …out of necessity and part as a reaction. The framework was built after we started vectorizing func…
68 …adients were correct for each of the instantiations; this wasn't hard, but tricky to get right and…
72 - make it easy to test new distributions
91 Writing a single distribution test isn't overly difficult. It's a bit tedious, but it beats writing…
[all …]
|
| /dports/sysutils/bacula9-docs/bacula-docs-9.6.7/manuals/es/main/base/ |
| H A D | critical.tex | 9 We recommend you take your time before implementing a production a Bacula
17 find that we have left out an important point, please inform us, so
36 \item Test your tape drive for compatibility with Bacula by using the test
38 \item Better than doing the above is to walk through the nine steps in the
40 may take you a bit of time, but it will eliminate surprises.
50 \item Write a bootstrap file to a separate system for each backup job. The
63 \item Write a bootstrap file for the catalog. An example of this is found in
65 catalog in the event it is wiped out -- otherwise it is many excruciating
114 tape each night and take it offsite in the morning. We recommend that you do
118 of your catalog backup to a floppy disk or a CDROM, and take that with
[all …]
|
| /dports/sysutils/bacula9-docs/bacula-docs-9.6.7/manuals/de/main/ |
| H A D | critical.tex | 9 We recommend you take your time before implementing a production a Bacula
17 find that we have left out an important point, please inform us, so
36 \item Test your tape drive for compatibility with Bacula by using the test
38 \item Better than doing the above is to walk through the nine steps in the
40 may take you a bit of time, but it will eliminate surprises.
50 \item Write a bootstrap file to a separate system for each backup job. The
63 \item Write a bootstrap file for the catalog. An example of this is found in
65 catalog in the event it is wiped out -- otherwise it is many excruciating
114 tape each night and take it offsite in the morning. We recommend that you do
118 of your catalog backup to a floppy disk or a CDROM, and take that with
[all …]
|
| /dports/sysutils/bacula9-docs/bacula-docs-9.6.7/manuals/en/main/ |
| H A D | critical.tex | 9 We recommend you take your time before implementing a production a Bacula
17 find that we have left out an important point, please inform us, so
36 \item Test your tape drive for compatibility with Bacula by using the test
38 \item Better than doing the above is to walk through the nine steps in the
40 may take you a bit of time, but it will eliminate surprises.
48 \item Write a bootstrap file to a separate system for each backup job. The
61 \item Write a bootstrap file for the catalog. An example of this is found in
63 catalog in the event it is wiped out -- otherwise it is many excruciating
112 tape each night and take it offsite in the morning. We recommend that you do
116 of your catalog backup to a floppy disk or a CDROM, and take that with
[all …]
|
| /dports/sysutils/bacula9-docs/bacula-docs-9.6.7/manuals/es/main/ |
| H A D | critical-en.tex | 9 We recommend you take your time before implementing a production a Bacula
17 find that we have left out an important point, please inform us, so
36 \item Test your tape drive for compatibility with Bacula by using the test
38 \item Better than doing the above is to walk through the nine steps in the
40 may take you a bit of time, but it will eliminate surprises.
50 \item Write a bootstrap file to a separate system for each backup job. The
63 \item Write a bootstrap file for the catalog. An example of this is found in
65 catalog in the event it is wiped out -- otherwise it is many excruciating
114 tape each night and take it offsite in the morning. We recommend that you do
118 of your catalog backup to a floppy disk or a CDROM, and take that with
[all …]
|
| /dports/sysutils/bacula9-docs/bacula-docs-9.6.7/manuals/fr/main/ |
| H A D | critical-en.tex | 9 We recommend you take your time before implementing a production a Bacula
17 find that we have left out an important point, please inform us, so
36 \item Test your tape drive for compatibility with Bacula by using the test
38 \item Better than doing the above is to walk through the nine steps in the
40 may take you a bit of time, but it will eliminate surprises.
50 \item Write a bootstrap file to a separate system for each backup job. The
63 \item Write a bootstrap file for the catalog. An example of this is found in
65 catalog in the event it is wiped out -- otherwise it is many excruciating
114 tape each night and take it offsite in the morning. We recommend that you do
118 of your catalog backup to a floppy disk or a CDROM, and take that with
[all …]
|
| /dports/sysutils/bacula11-docs/bacula-docs-11.0.5/manuals/en/main/www-main/ |
| H A D | critical.tex | 6 We recommend you take your time before implementing a production a \bacula{}
14 find that we have left out an important point, please inform us, so
34 \item Test your tape drive for compatibility with \bacula{} by using the \bcommandname{test}
36 \item Better than doing the above is to walk through the nine steps in the
38 may take you a bit of time, but it will eliminate surprises.
48 \item Write a bootstrap file to a separate system for each backup job. The
60 \item Write a bootstrap file for the catalog. An example of this is found in
62 catalog in the event it is wiped out -- otherwise it is many excruciating
112 tape each night and take it offsite in the morning. We recommend that you do
116 of your catalog backup to a usb disk or a \acs{CDROM} and take that with
[all …]
|
| /dports/sysutils/bacula11-docs/bacula-docs-11.0.5/manuals/en/main/ |
| H A D | critical.tex | 6 We recommend you take your time before implementing a production a \bacula{}
14 find that we have left out an important point, please inform us, so
34 \item Test your tape drive for compatibility with \bacula{} by using the \bcommandname{test}
36 \item Better than doing the above is to walk through the nine steps in the
38 may take you a bit of time, but it will eliminate surprises.
48 \item Write a bootstrap file to a separate system for each backup job. The
60 \item Write a bootstrap file for the catalog. An example of this is found in
62 catalog in the event it is wiped out -- otherwise it is many excruciating
112 tape each night and take it offsite in the morning. We recommend that you do
116 of your catalog backup to a usb disk or a \acs{CDROM} and take that with
[all …]
|
| /dports/sysutils/bacula9-docs/bacula-docs-9.6.7/manuals/fr/main/base/ |
| H A D | critical.tex | 9 We recommend you take your time before implementing a production a Bacula
17 find that we have left out an important point, please inform us, so
36 \item Test your tape drive for compatibility with Bacula by using the test
38 \item Better than doing the above is to walk through the nine steps in the
40 may take you a bit of time, but it will eliminate surprises.
50 \item Write a bootstrap file to a separate system for each backup job. The
63 \item Write a bootstrap file for the catalog. An example of this is found in
65 catalog in the event it is wiped out -- otherwise it is many excruciating
114 tape each night and take it offsite in the morning. We recommend that you do
118 of your catalog backup to a floppy disk or a CDROM, and take that with
[all …]
|
| /dports/devel/py-testresources/testresources-2.0.1/ |
| H A D | ChangeLog | 25 * Add a tox.ini for convenience
73 * Make public reusable functions for setting up and tearing down resources of a test
75 * Make public reusable functions for setting up and tearing down resources of a test
124 * Move test_suite definitions to the top of test files, because lifeless likes it that way
130 * Add a sample test resource
147 * Make _getGraph take only tests with resources as a parameter
152 * Rename adsorbSuite to flatAddTest, add a bunch of tests for it. Disable the test that has been ca…
157 * Refactor a little to take advantage of instance-based resources
165 * Change TestResource so that instances of it are passed to test cases, rather than the classes the…
200 * Add the GOALS document worked out between Rob and I
[all …]
|
| /dports/math/SCIP/scip-7.0.3/tests/ |
| H A D | README.md | 14 …test is an automated piece of code that invokes a unit of work in the system and then checks a sin…
32 | check stdout | unittest_framework_tmp branch, `src/cons/expr/walk.c` |
44 …OTE** `make` will read the options used for building `SCIP` from the binary. It uses `scip --versi…
45 …not used when compiling `SCIP`, `make` will end with a proper error. If the binary is not found, i…
48 This command will check for [Criterion](http://criterion.readthedocs.io/en/master/) in ./Criterion,…
61 …ith a list of the test to run and then calls `ctest --output-on-failure`. By default, tests in `sr…
67 You can also run a single test, e.g. `
73 space layout randomization (ASLR) enabled. One can disable ASLR for a
74 specific process (and its children) by calling it in a modified environment, e.g.,
87 TODO: Define a policy for moving/removing tests in `src/bugs` once the bugs are fixed.
[all …]
|