\PHPUnit_TextUI_Command
A TestRunner for the Command Line Interface (CLI) PHP SAPI Module.
- Author: Sebastian Bergmann<EMAIL_ADDRESS>- Copyright: 2001-2014 Sebastian Bergmann<EMAIL_ADDRESS>- License: http://www.opensource.org/licenses/BSD-3-Clause The BSD 3-Clause License
Synopsis
- // members
- protected array $arguments;
- protected array $options;
- protected array $longOptions;
- private boolean $versionStringPrinted;
- // methods
- public static void main()
- public integer run()
- protected PHPUnit_TextUI_TestRunner createRunner()
- protected void handleArguments()
- protected PHPUnit_Runner_TestSuiteLoader handleLoader()
- protected PHPUnit_Util_Printer handlePrinter()
- protected void handleBootstrap()
- protected void handleSelfUpdate()
- protected void showHelp()
- protected void handleCustomTestSuite()
- private void printVersionString()
- private void showError()
Violations
PHPMessDetector
| Line | Rule | Message |
|---|---|---|
| 146 - 204 | CyclomaticComplexity | The method run() has a Cyclomatic Complexity of 12. The configured cyclomatic complexity threshold is 10. |
| 146 - 204 | NPathComplexity | The method run() has an NPath complexity of 300. The configured NPath complexity threshold is 200. |
| 176 | ExitExpression | The method run() contains an exit expression. |
| 200 | ExitExpression | The method run() contains an exit expression. |
| 262 - 718 | CyclomaticComplexity | The method handleArguments() has a Cyclomatic Complexity of 105. The configured cyclomatic complexity threshold is 10. |
| 262 - 718 | NPathComplexity | The method handleArguments() has an NPath complexity of<PHONE_NUMBER>20. The configured NPath complexity threshold is 200. |
| 262 - 718 | ExcessiveMethodLength | The method handleArguments() has 457 lines of code. Current threshold is set to 100. Avoid really long methods. |
| 354 | ExitExpression | The method handleArguments() contains an exit expression. |
| 505 | ExitExpression | The method handleArguments() contains an exit expression. |
| 638 | ExitExpression | The method handleArguments() contains an exit expression. |
| 716 | ExitExpression | The method handleArguments() contains an exit expression. |
| 832 | ExitExpression | The method handleSelfUpdate() contains an exit expression. |
| 882 | ExitExpression | The method handleSelfUpdate() contains an exit expression. |
| 886 | ExitExpression | The method handleSelfUpdate() contains an exit expression. |
| 1003 | ExitExpression | The method showError() contains an exit expression. |
Checkstyle
| Line | Column | Severity | Message |
|---|---|---|---|
| 281 | 17 | error | CASE statements must not be defined using curly braces |
| 286 | 17 | error | CASE statements must not be defined using curly braces |
| 292 | 17 | error | CASE statements must not be defined using curly braces |
| 297 | 17 | error | CASE statements must not be defined using curly braces |
| 302 | 17 | error | CASE statements must not be defined using curly braces |
| 307 | 17 | error | CASE statements must not be defined using curly braces |
| 312 | 17 | error | CASE statements must not be defined using curly braces |
| 317 | 17 | error | CASE statements must not be defined using curly braces |
| 328 | 17 | error | CASE statements must not be defined using curly braces |
| 333 | 17 | error | CASE statements must not be defined using curly braces |
| 346 | 17 | error | CASE statements must not be defined using curly braces |
| 352 | 17 | error | CASE statements must not be defined using curly braces |
| 358 | 17 | error | CASE statements must not be defined using curly braces |
| 363 | 17 | error | CASE statements must not be defined using curly braces |
| 368 | 17 | error | CASE statements must not be defined using curly braces |
| 373 | 17 | error | CASE statements must not be defined using curly braces |
| 375 | 30 | error | Only one argument is allowed per line in a multi-line function call |
| 380 | 17 | error | CASE statements must not be defined using curly braces |
| 382 | 30 | error | Only one argument is allowed per line in a multi-line function call |
| 387 | 17 | error | CASE statements must not be defined using curly braces |
| 392 | 17 | error | CASE statements must not be defined using curly braces |
| 397 | 17 | error | CASE statements must not be defined using curly braces |
| 402 | 17 | error | CASE statements must not be defined using curly braces |
| 407 | 17 | error | CASE statements must not be defined using curly braces |
| 412 | 17 | error | CASE statements must not be defined using curly braces |
| 417 | 17 | error | CASE statements must not be defined using curly braces |
| 422 | 17 | error | CASE statements must not be defined using curly braces |
| 427 | 17 | error | CASE statements must not be defined using curly braces |
| 432 | 17 | error | CASE statements must not be defined using curly braces |
| 437 | 17 | error | CASE statements must not be defined using curly braces |
| 442 | 17 | error | CASE statements must not be defined using curly braces |
| 447 | 17 | error | CASE statements must not be defined using curly braces |
| 452 | 17 | error | CASE statements must not be defined using curly braces |
| 457 | 17 | error | CASE statements must not be defined using curly braces |
| 462 | 17 | error | CASE statements must not be defined using curly braces |
| 467 | 17 | error | CASE statements must not be defined using curly braces |
| 472 | 17 | error | CASE statements must not be defined using curly braces |
| 477 | 17 | error | CASE statements must not be defined using curly braces |
| 482 | 17 | error | CASE statements must not be defined using curly braces |
| 487 | 17 | error | CASE statements must not be defined using curly braces |
| 492 | 17 | error | CASE statements must not be defined using curly braces |
| 498 | 17 | error | CASE statements must not be defined using curly braces |
| 503 | 17 | error | CASE statements must not be defined using curly braces |
| 509 | 17 | error | CASE statements must not be defined using curly braces |
| 514 | 17 | error | CASE statements must not be defined using curly braces |
| 519 | 17 | error | CASE statements must not be defined using curly braces |
| 524 | 17 | error | CASE statements must not be defined using curly braces |
| 529 | 17 | error | CASE statements must not be defined using curly braces |
| 534 | 17 | error | CASE statements must not be defined using curly braces |
| 544 | 17 | error | CASE statements must not be defined using curly braces |
| 549 | 17 | error | DEFAULT statements must not be defined using curly braces |
| 582 | 124 | warning | Line exceeds 120 characters; contains 123 characters |
| 672 | 47 | error | Only one argument is allowed per line in a multi-line function call |
| 684 | 55 | error | Only one argument is allowed per line in a multi-line function call |
| 696 | 149 | warning | Line exceeds 120 characters; contains 148 characters |
| 706 | 140 | warning | Line exceeds 120 characters; contains 139 characters |
Members
private
- $versionStringPrinted — boolean
protected
- $arguments — array
- $longOptions — array
- $options — array
Methods
private
protected
- createRunner() — Create a TestRunner, override in subclasses.
- handleArguments() — Handles the command-line arguments.
- handleBootstrap() — Loads a bootstrap file.
- handleCustomTestSuite() — Custom callback for test suite discovery.
- handleLoader() — Handles the loading of the PHPUnit_Runner_TestSuiteLoader implementation.
- handlePrinter() — Handles the loading of the PHPUnit_Util_Printer implementation.
- handleSelfUpdate()
- showHelp() — Show the help message.
public
History
-
2014-08-19T06:56:05+02:00 (commit #7c44e35)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes #1403
-
2014-08-17T21:12:03+02:00 (commit #29de7e9)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Printers implement the `TestListener` interface (via @fiunchinho).
-
2014-08-17T10:18:07+02:00 (commit #fd5ef8a)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>phpcbf --standard=PSR2 src tests
-
2014-08-12T06:43:31+02:00 (commit #50dfaba)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>phpcbf --standard=PSR2 src tests
-
2014-07-06T17:39:38+02:00 (commit #9edd518)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Fixes #1265 Don't fail on `testSuiteLoaderClass="PHPUnit_Runner_StandardTestSuiteLoader"`.
-
2014-06-16T06:54:22+02:00 (commit #0d0fd47)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Formatting.
-
2014-05-17T17:02:40+02:00 (commit #e5014cb)
Author: nikoms<EMAIL_ADDRESS>/ Commiter: nikoms<EMAIL_ADDRESS>If no "configuration file" is set, the bootstrap should be taken from "--bootstrap" command line option
-
2014-05-03T19:14:23+02:00 (commit #8d2e6ea)
Author: Vagrant (vagrant@php55) / Commiter: nikoms (vagrant@php55)
Issue #1216 with unit test
-
2014-05-02T15:42:23+02:00 (commit #7bd874f)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix syntax error introduced in 18e658bcaf63cfee8248f877249b19c1d99cdf6d
-
2014-05-02T15:33:35+02:00 (commit #18e658b)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Add --selfupdate alias for --self-update
-
2014-04-30T15:01:04+02:00 (commit #e16678d)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes #1242
-
2014-04-30T14:57:53+02:00 (commit #4ce28b2)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes #1242
-
2014-04-23T08:42:20+02:00 (commit #d93b7c5)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Refactor
-
2014-04-23T08:41:59+02:00 (commit #75e46c9)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Refactor
-
2014-04-23T08:38:06+02:00 (commit #b228f86)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix docblock
-
2014-04-23T08:36:53+02:00 (commit #85f1084)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Refactor printVersionString() and friends
-
2014-04-21T10:25:54+02:00 (commit #5797b06)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes #1218
-
2014-04-20T10:46:01+02:00 (commit #38baa96)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix handling of --report-useless-tests, --strict-coverage, --disallow-test-output, and --enforce-time-limit options
-
2014-04-20T10:44:50+02:00 (commit #a8aa89e)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Refinement of 560c99abb8b7db7f5d7ca72653126134c97b3ac1
-
2014-03-24T09:24:58+01:00 (commit #6479694)
Author: Ilya Bulah<EMAIL_ADDRESS>/ Commiter: Ilya Bulah<EMAIL_ADDRESS>Issue #657: stderr in xml configuration
-
2014-02-14T18:31:32+01:00 (commit #e5b50bc)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Next version will be 4.0
-
2014-01-31T16:13:49+01:00 (commit #0517bfc)
Author: Matt Parker<EMAIL_ADDRESS>/ Commiter: Matt Parker<EMAIL_ADDRESS>Clarifies documentation around extending TextUI_Command to add command line options
-
2014-01-22T19:43:07+01:00 (commit #02b42d7)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Initial work on formatting code according to PSR-2
-
2014-01-20T17:21:13+01:00 (commit #3a5808f)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Cleanup
-
2014-01-09T08:11:47+01:00 (commit #205e008)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Bump copyright year
-
2014-01-07T14:37:15+01:00 (commit #991bf00)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Revert "Next stable release will be PHPUnit 4" This reverts commit f4ee7815d1bb1664786fe95b226a3def20f24aa9.
-
2014-01-06T09:10:08+01:00 (commit #1b318d5)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Make --self-update aware of release channels (alpha, beta, stable)
-
2014-01-06T09:05:08+01:00 (commit #f4ee781)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Next stable release will be PHPUnit 4
-
2014-01-05T12:03:59+01:00 (commit #9101f51)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes #914
-
2014-01-05T11:24:11+01:00 (commit #08eb627)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Attempt to improve the --help output
-
2014-01-03T10:56:51+01:00 (commit #5fa6726)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Introduce new test classification: risky test
-
2013-11-18T18:48:04+01:00 (commit #3e7dd67)
Author: Evgeniy Makhrov<EMAIL_ADDRESS>/ Commiter: Evgeniy Makhrov<EMAIL_ADDRESS>Allow to specify custom printer with custom autoload
-
2013-11-13T09:49:57+01:00 (commit #648b096)
Author: Evgeniy Makhrov<EMAIL_ADDRESS>/ Commiter: Evgeniy Makhrov<EMAIL_ADDRESS>Allow extending phpunit classes
-
2013-08-26T19:44:24+02:00 (commit #d927ffe)
Author: uyga<EMAIL_ADDRESS>/ Commiter: uyga<EMAIL_ADDRESS>Changed doc due to no more serialize on export
-
2013-08-26T13:54:26+02:00 (commit #6496520)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes #847
-
2013-08-03T08:56:18+02:00 (commit #c3898aa)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Implement --coverage-xml option to generate code coverage report in PHPUnit's own XML format
-
2013-08-03T08:53:28+02:00 (commit #8a2e4cb)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Cleanup
-
2013-05-21T11:52:11+02:00 (commit #e186c42)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Reorder code coverage options in help output
-
2013-05-20T23:08:36+02:00 (commit #3235ac0)
Author: Zsolt Takács<EMAIL_ADDRESS>/ Commiter: Zsolt Takács<EMAIL_ADDRESS>Add support for crap4j coverage report
-
2013-02-24T22:03:37+01:00 (commit #3900fc8)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Fixes #835 * Custom printers that extend `PHPUnit_TextUI_ResultPrinter` now have access to `verbose`, `debug`, etc.
-
2013-02-02T10:46:21+01:00 (commit #bb8c2c8)
Author: Tobias Zander<EMAIL_ADDRESS>/ Commiter: Tobias Zander<EMAIL_ADDRESS>always use realpath of file
-
2013-01-07T11:37:52+01:00 (commit #c517984)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Bump copyright year
-
2012-11-24T15:07:18+01:00 (commit #ba02390)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix CS/WS
-
2012-11-24T14:24:37+01:00 (commit #302b465)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Fixes #719
-
2012-11-08T23:54:52+01:00 (commit #1cf63a9)
Author: jakoch<EMAIL_ADDRESS>/ Commiter: jakoch<EMAIL_ADDRESS>added coverage-text argument "showOnlySummary"
-
2012-09-24T17:35:08+02:00 (commit #cd92dd4)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Closes #655. BC issue in 3.7 fixed by: Revert "Positional argument count check introduced" This reverts commit 6ac554ede32330e3775c231cabe0f7b513770e6c. Conflicts: PHPUnit/TextUI/Command.php
-
2012-09-24T06:47:44+02:00 (commit #81ab540)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Do not perform string replacement for @package_version@ anymore.
-
2012-07-01T23:30:06+02:00 (commit #ba9bb8d)
Author: Jon Cave<EMAIL_ADDRESS>/ Commiter: Jon Cave<EMAIL_ADDRESS>Remove duplicate description of --debug flag
-
2012-04-30T12:02:38+02:00 (commit #5786e50)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>List The BSD 3-Clause License correctly and consistently. Thanks to Christian Aistleitner<EMAIL_ADDRESS>for bringing this issue to my attention.
-
2012-04-10T22:47:35+02:00 (commit #fbf368b)
Author: Anthon Pang<EMAIL_ADDRESS>/ Commiter: Anthon Pang<EMAIL_ADDRESS>Fix typo
-
2012-03-31T21:56:06+02:00 (commit #5d4f4f6)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Cleanup after merging #208
-
2012-03-31T21:20:51+02:00 (commit #588ef89)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Introduce --test-suffix option to enable run tests from a given directory with a specific extension(s) Conflicts: PHPUnit/Runner/BaseTestRunner.php PHPUnit/Runner/IncludePathTestCollector.php PHPUnit/TextUI/Command.php
-
2012-02-12T16:50:25+01:00 (commit #9a30713)
Author: jpic<EMAIL_ADDRESS>/ Commiter: jpic<EMAIL_ADDRESS>Documented --testsuite option in --help
-
2012-02-09T18:21:19+01:00 (commit #47c5f6d)
Author: jpic<EMAIL_ADDRESS>/ Commiter: jpic<EMAIL_ADDRESS>Added --testsuite option to filter directory/files based on the name attribute of their parent testsuite node
-
2012-01-24T15:21:04+01:00 (commit #42457c9)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Do not show message that Xdebug is not loaded multipe times when multiple code coverage report formats are requested.
-
2012-01-09T16:31:34+01:00 (commit #82c33f8)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Deprecate the skeleton generator.
-
2012-01-03T08:32:53+01:00 (commit #dc9e909)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Remove skeleton generator functionality.
-
2012-01-01T11:21:16+01:00 (commit #aae6c38)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Bump copyright year.
-
2011-12-27T10:21:52+01:00 (commit #37cacc9)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>PHPUnit no longer throws exceptions that do not extend PHPUnit_Framework_Exception.
-
2011-12-16T17:33:30+01:00 (commit #d368bf8)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Fix phpcs
-
2011-12-16T15:41:53+01:00 (commit #6ac554e)
Author: Oliver Gondža<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Positional argument count check introduced
-
2011-12-16T11:04:05+01:00 (commit #ebdcfc4)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fixes #442.
-
2011-12-11T15:34:11+01:00 (commit #6ab18a4)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Fixed phpcs warnings
-
2011-11-30T13:55:04+01:00 (commit #d127b0a)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix whitespace.
-
2011-11-26T16:49:59+01:00 (commit #750b938)
Author: Renan Gonçalves<EMAIL_ADDRESS>/ Commiter: Renan Gonçalves<EMAIL_ADDRESS>Loading bootstrap file configured in the xml before attempting to load the tests loader. Fixes #204.
-
2011-11-15T13:58:58+01:00 (commit #8121679)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Closes #408 by making the need for an equals sign for --coverage-text more explicit
-
2011-11-08T11:19:40+01:00 (commit #7fff85e)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Remove leftover from syntax check functionality.
-
2011-11-08T09:49:26+01:00 (commit #6852c80)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Eliminate PHPUnit_Util_Filesystem::fileExistsInIncludePath().
-
2011-10-26T12:19:28+02:00 (commit #bfc351c)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix whitespace issues.
-
2011-10-24T21:51:05+02:00 (commit #a29aeeb)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Closes issue #383.
-
2011-10-11T20:33:20+02:00 (commit #29b350d)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix whitespace.
-
2011-10-11T20:19:32+02:00 (commit #f42ab1e)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Coverage text defaults to stdout output for ease of use
-
2011-10-07T10:51:16+02:00 (commit #70e0629)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Add support for PHP_CodeCoverage_Report_PHP.
-
2011-10-07T10:44:15+02:00 (commit #950dcf7)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Refactor.
-
2011-09-30T12:00:09+02:00 (commit #4c9cd2a)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Initial cleanup.
-
2011-09-28T12:54:27+02:00 (commit #dcb1382)
Author: Pedro Mata-Mouros<EMAIL_ADDRESS>/ Commiter: Pedro Mata-Mouros<EMAIL_ADDRESS>Honouring the $exit parameter and returning the run status when this is false.
-
2011-09-24T09:49:09+02:00 (commit #f5b74aa)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Strict mode is more strict now.
-
2011-09-23T10:48:06+02:00 (commit #79e9e7f)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix executing PHPT files from the CLI.
-
2011-09-06T10:38:07+02:00 (commit #ed63176)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Move PHPUnit_Util_Log_DBUS and PHPUnit_Util_Log_XHProf to separate packages.
-
2011-09-04T14:30:16+02:00 (commit #f7e1d94)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Refactored cli output. It's now possible to write to the cli or to a file
-
2011-09-03T15:03:31+02:00 (commit #b3d843f)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>First draft of CLI coverage output. Work in progress. Just to see if it could work out like that
-
2011-08-24T12:01:36+02:00 (commit #a0276a9)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Remove the `--wait` functionality.
-
2011-03-07T17:21:52+01:00 (commit #6e5fc18)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Tweak message.
-
2011-03-07T17:21:42+01:00 (commit #1053703)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix logic.
-
2011-03-07T17:13:57+01:00 (commit #924b4b2)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix CS/WS issues.
-
2011-03-07T17:12:53+01:00 (commit #7611215)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Refactor.
-
2011-03-07T15:19:03+01:00 (commit #16aab25)
Author: Volker Dusch<EMAIL_ADDRESS>/ Commiter: Volker Dusch<EMAIL_ADDRESS>Fixes #174 - PHPUnit now will show a warning (but not die) when coverage-html or coverage-clover is specified in the phpunit.xml file but xdebug is not loaded
-
2011-03-07T12:41:51+01:00 (commit #056ae02)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Make --debug switch "public".
-
2011-02-14T19:53:21+01:00 (commit #4f7584a)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix help output.
-
2011-02-14T19:50:38+01:00 (commit #33bc4c1)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Close #169.
-
2011-02-14T07:56:19+01:00 (commit #a82ffda)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Add @since annotation.
-
2011-02-13T19:54:28+01:00 (commit #5f2aa47)
Author: Mark Story<EMAIL_ADDRESS>/ Commiter: Mark Story<EMAIL_ADDRESS>Creating a factory method for runner creation.
-
2011-02-12T21:23:01+01:00 (commit #a8a475a)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Tweak help output.
-
2011-01-30T03:27:41+01:00 (commit #44c90c2)
Author: Oleg Pudeyev<EMAIL_ADDRESS>/ Commiter: Oleg Pudeyev<EMAIL_ADDRESS>Added -h and -v short options for --help and --verbose, respectively
-
2011-01-30T03:27:36+01:00 (commit #a82d37a)
Author: Oleg Pudeyev<EMAIL_ADDRESS>/ Commiter: Oleg Pudeyev<EMAIL_ADDRESS>Documented -c short option
-
2011-01-21T08:03:59+01:00 (commit #83f8fec)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Fixes #127. * An error message is now printed for errors while parsing the phpunit.xml file. * Fixed a bug where XML errors were not being collected correctly.
-
2011-01-19T11:45:41+01:00 (commit #92547e6)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Implement configuration of printer.
-
2010-12-31T11:45:34+01:00 (commit #bee3344)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Bump copyright year.
-
2010-12-03T09:09:04+01:00 (commit #6093aa8)
Author: Sebastian Bergmann<EMAIL_ADDRESS>/ Commiter: Sebastian Bergmann<EMAIL_ADDRESS>Fix bad merge.
-
2010-10-17T06:20:43+02:00 (commit #59fa767)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Whitespace fix.
-
2010-10-17T06:09:54+02:00 (commit #465880b)
Author: Jeff Welch<EMAIL_ADDRESS>/ Commiter: Jeff Welch<EMAIL_ADDRESS>Including bootstrap files is now handled by `PHPUnit_Util_Fileloader::checkAndLoad` so that users get an informative message if the bootstrap file is not readable. This refs issue_34.


Triangular face used in [page:Geometry]. These are created automatically for all standard geometry types, however if you are building a custom geometry you will have to create them manually.
const material = new THREE.MeshStandardMaterial( { color : 0x00cc00 } );
//create a triangular geometry
const geometry = new THREE.Geometry();
geometry.vertices.push( new THREE.Vector3( -50, -50, 0 ) );
geometry.vertices.push( new THREE.Vector3( 50, -50, 0 ) );
geometry.vertices.push( new THREE.Vector3( 50, 50, 0 ) );
//create a new face using vertices 0, 1, 2
const normal = new THREE.Vector3( 0, 0, 1 ); //optional
const color = new THREE.Color( 0xffaa00 ); //optional
const materialIndex = 0; //optional
const face = new THREE.Face3( 0, 1, 2, normal, color, materialIndex );
//add the face to the geometry's faces array
geometry.faces.push( face );
//the face normals and vertex normals can be calculated automatically if not supplied above
geometry.computeFaceNormals();
geometry.computeVertexNormals();
scene.add( new THREE.Mesh( geometry, material ) );
[example:svg_sandbox svg / sandbox ]
[example:misc_exporter_obj exporter / obj ]
[example:webgl_shaders_vector WebGL / shaders / vector ]
a — Vertex A index.
b — Vertex B index.
c — Vertex C index.
normal — (optional) Face normal ([page:Vector3 Vector3]) or array of vertex normals.
If a single vector is passed in, this sets [page:.normal], otherwise if an array of three
vectors is passed in this sets [page:.vertexNormals]
color — (optional) Face [page:Color color] or array of vertex [page:Color colors].
If a single vector is passed in, this sets [page:.color], otherwise if an array of three
vectors is passed in this sets [page:.vertexColors]
materialIndex — (optional) which index of an array of materials to associate
with the face.
Vertex A index.
Vertex B index.
Vertex C index.
Face normal - vector showing the direction of the Face3. If calculated automatically (using [page:Geometry.computeFaceNormals]), this is the normalized cross product of two edges of the triangle. Default is *(0, 0, 0)*.
Face color - for this to be used a material's [page:Material.vertexColors vertexColors] property must be set to *true*.
Array of 3 [page:Vector3 vertex normals].
Array of 3 vertex colors - for these to be used a material's [page:Material.vertexColors vertexColors] property must be set to *true*.
Material index (points to an index in the associated array of materials). Default is *0*.
Creates a new clone of the Face3 object.
Copy the parameters of another Face3 into this.
[link:https://github.com/mrdoob/three.js/blob/master/src/[path].js src/[path].js]


Exception in thread “main” javax.xml.stream.XMLStreamException: ParseError at [row,col]:[86,11]
Problem:
When parsing an xml file by using Stax, get the following error message:
Exception in thread “main” javax.xml.stream.XMLStreamException: ParseError at [row,col]:[86,11]
Message: Open quote is expected for attribute “{1}” associated with an element type “type_id”.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next
(XMLStreamReaderImpl.java:594)
at com.sun.xml.internal.stream.XMLEventReaderImpl.nextEvent
(XMLEventReaderImpl.java:85)
at Main.main(Main.java:49)
Message: Open quote is expected for attribute “{1}” associated with an element type “type_id”.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next
(XMLStreamReaderImpl.java:594)
at com.sun.xml.internal.stream.XMLEventReaderImpl.nextEvent
(XMLEventReaderImpl.java:85)
at Main.main(Main.java:49)
The problem is gone, when the following DOCTYPE line is removed:
<!DOCTYPE bugzilla SYSTEM "https://bugs.eclipse.org/bugs/bugzilla.dtd"> |
Solution:
inputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false); |
This set the property to request processors that do not support DTDs.
Reference: http://download.oracle.com/javase/6/docs/api/javax/xml/stream/XMLInputFactory.html


ATPASS is a numerical tracking engine for AT 1.3 ROUT = ATPASS(LATTICE,RIN,MODE,NTURNS,REFPTS) LATTICE AT lattice RIN 6xN matrix: input coordinates of N particles MODE 0 - reuse lattice 1 - new lattice NTURNS number of turns REFPTS Indexes of elements where the trajectory is observed May run from 1 to length(LATTICE)+1 ROUT = ATPASS(LATTICE,RIN,MODE,NTURNS,REFPTS,PREFUNC,POSTFUNC) PREFUNC function called before each element POSTFUNC function called after each element [ROUT,LOST] = ATPASS(LATTICE,RIN,MODE,NTURNS,REFPTS,PREFUNC,POSTFUNC,NHIST) Returns additionally information on lost particles NHIST length of history buffer LOST 1x1 structure with the following fields: turn 1xN vector, turn number where the particle is lost element 1xN vector, element number where the particle is lost coordinates 6xNxNHIST matrix, coordinates at the entrance of the element where the particle was lost See also RINGPASS, LINEPASS
0001 function varargout=atpass(varargin) %#ok<STOUT> 0002 %ATPASS is a numerical tracking engine for AT 1.3 0003 % ROUT = ATPASS(LATTICE,RIN,MODE,NTURNS,REFPTS) 0004 % 0005 % LATTICE AT lattice 0006 % RIN 6xN matrix: input coordinates of N particles 0007 % MODE 0 - reuse lattice 0008 % 1 - new lattice 0009 % NTURNS number of turns 0010 % REFPTS Indexes of elements where the trajectory is observed 0011 % May run from 1 to length(LATTICE)+1 0012 % 0013 % ROUT = ATPASS(LATTICE,RIN,MODE,NTURNS,REFPTS,PREFUNC,POSTFUNC) 0014 % PREFUNC function called before each element 0015 % POSTFUNC function called after each element 0016 % 0017 % [ROUT,LOST] = ATPASS(LATTICE,RIN,MODE,NTURNS,REFPTS,PREFUNC,POSTFUNC,NHIST) 0018 % Returns additionally information on lost particles 0019 % 0020 % NHIST length of history buffer 0021 % LOST 1x1 structure with the following fields: 0022 % turn 1xN vector, turn number where the particle is lost 0023 % element 1xN vector, element number where the particle is lost 0024 % coordinates 6xNxNHIST matrix, coordinates at the entrance of the 0025 % element where the particle was lost 0026 % 0027 % See also RINGPASS, LINEPASS 0028 error('at:missingMex','missing MEX file.'); 0029 end


| PostgreSQL Tcl Interface Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next |
pg_select ?-rowbyrow
? ?-nodotfields
? ?-withoutnulls
? ?-paramarray var
? [-variables
] ?-params
paramList? ?-count
countVar?conn
commandString
arrayVar
procedure
pg_select
submits a query (SELECT statement) to the PostgreSQL server and executes a given chunk of code for each row in the result. The commandString
must be a SELECT statement; anything else returns an error. The arrayVar
variable is an array name used in the loop. For each row, arrayVar
is filled in with the row values, using the column names as the array indices. Then the procedure
is executed.
In addition to the column values, the following special entries are made in the array (unless the [-nodotfields] flag is provided):
A list of the column names returned by the query.
The number of columns returned by the query.
The current row number, starting at zero and incrementing for each iteration of the loop body.
If the [-param] flag is provided, then it contains a list of parameters that will replace "$1", "$2" and so on in the query string, as if it were a prepared statement. Be sure to properly escape or quote the "$" in the query. :)
If the [-paramarray] flag is provided, then a substitution is performed on the query, securely replacing each back-quote delimited name with the corresponding entry from the named array. If the array does not contain the named element, then NULL is substituted (similarly to the way an array created by -withoutnulls is generated). Each such name must occur in a location where a value or field name could appear.
If the [-variables] flag is provided, then embedded Tcl variables are passed as parameters. Variables can be flagged with ':' and array references and namespaces are supported. Complex variable names can usually be embedded with :{nasty-name-here} though no attempt at duplicating Tcl brace-escaping is made. If the variable does not exist, then NULL is substituted.
Notes: This substitution is performed by generating a positional parameter list and calling PQExecParams with a modified query containing $1, $2, ... where the original `names` appeared. This is a straight substitution, so if this mechanism is used the back-quote character (`) can not appear elsewhere in the query, even in a quoted string. There are a maximum of 99,999 names.
Perform parameter substitution using PQexecParams or PQSendQueryParams.
Perform parameter substitution via `quoted` elements of the array using PQexecParams or PQSendQueryParams.
Substitute Tcl variables found in the SQL string using PQexecParams or PQSendQueryParams.
Perform the select in row-by-row mode. This means that the code block is called immediately results become available, rather than waiting for the query to complete.
Suppress generation of the pseudo-fields .headers, .numcols, and .tupno.
If specified null columns will be unset from the array rather than being defined and containing the null string, typically an empty string.
Set the variable "countVar" to the number of tuples returned for use in the block.
conn
The handle of the connection on which to execute the query.
commandString
The SQL query to execute.
arrayVar
An array variable for returned rows.
procedure
The procedure to run for each returned row.
This examples assumes that the table table1
has columns control and name (and perhaps others):
pg_select $pgconn "SELECT * FROM table1;" array { puts [format "%5d %s" $array(control) $array(name)] }
This example demonstrates how to use named parameters to securely perform queries on an SQL database:
# An array imported from some hive of scum and villainy like a web form. set form(first) {Andrew'); DROP TABLE students;--} set form(last) {Randall} # Secure extraction of data pg_select -paramarray form $pgconn "SELECT * from students WHERE firstname = `first` AND lastname = `last`;" row { lappend candidates $row(student_id) $row(firstname) $row(lastname) $row(age) }


{{ _('To add a link to a downloadable document, you will need to use the API to upload the document and use double brackets to link to it in the message. For example:') }}
{{ _('Download your document at:') }} (({{ _('link_to_document') }}))
{{ _('Download your document at:') }} {{ _('Annual-report-2019.pdf') }}


The Date Picker, Time Picker, DateTime Picker and similar components
rely on provided datetime implementation (DatetimeAdapter
) and
datetime formats (DateTimeFormats
).
These components could be used with FdDatetimeAdapter
, based on the JavaScript's native
Date
object, but one of the biggest shortcomings of the native Date
object is the
inability to set the parse format. As an alternative could be the DayjsDatetimeAdapter
or a custom
DateAdapter
that works with the formatting/parsing library of your choice.
Please consider that you need to install this package separately.


|
| BLACKBONE_API NTSTATUS | Attach (DWORD pid, DWORD access=DEFAULT_ACCESS_P) |
| | Attach to existing process More...
|
| |
| BLACKBONE_API NTSTATUS | Attach (HANDLE hProc) |
| | Attach to existing process More...
|
| |
| BLACKBONE_API NTSTATUS | CreateAndAttach (const std::wstring &path, bool suspended=false, bool forceInit=true, const std::wstring &cmdLine=L"", const wchar_t *currentDir=nullptr, STARTUPINFOW *pStartup=nullptr) |
| | Create new process and attach to it More...
|
| |
| BLACKBONE_API NTSTATUS | Detach () |
| | Detach form current process, if any More...
|
| |
| BLACKBONE_API NTSTATUS | EnsureInit () |
| | Ensure LdrInitializeProcess gets called More...
|
| |
| BLACKBONE_API DWORD | pid () const |
| | Get process ID More...
|
| |
| BLACKBONE_API bool | valid () |
| | Checks if process still exists More...
|
| |
| BLACKBONE_API NTSTATUS | Terminate (uint32_t code=0) |
| | Terminate process More...
|
| |
| BLACKBONE_API NTSTATUS | EnumHandles (std::vector< HandleInfo > &handles) |
| | Enumerate all open handles More...
|
| |
|
BLACKBONE_API ProcessCore & | core () |
| |
|
BLACKBONE_API ProcessMemory & | memory () |
| |
|
BLACKBONE_API ProcessModules & | modules () |
| |
|
BLACKBONE_API ProcessThreads & | threads () |
| |
|
BLACKBONE_API RemoteHook & | hooks () |
| |
|
BLACKBONE_API RemoteLocalHook & | localHooks () |
| |
|
BLACKBONE_API RemoteExec & | remote () |
| |
|
BLACKBONE_API MMap & | mmap () |
| |
|
BLACKBONE_API NtLdr & | nativeLdr () |
| |
|
| static BLACKBONE_API void | EnumByName (const std::wstring &name, std::vector< DWORD > &found) |
| | Search for process by executable name More...
|
| |
| static BLACKBONE_API NTSTATUS | EnumByNameOrPID (uint32_t pid, const std::wstring &name, std::vector< ProcessInfo > &found, bool includeThreads=false) |
| | Search for process by executable name or by process ID More...
|
| |
| NTSTATUS blackbone::Process::Attach |
( |
DWORD |
pid, |
|
|
DWORD |
access = DEFAULT_ACCESS_P |
|
) |
| |
Attach to existing process
- Parameters
-
- Returns
- Status code
| NTSTATUS blackbone::Process::Attach |
( |
HANDLE |
hProc | ) |
|
Attach to existing process
- Parameters
-
- Returns
- Status code
| NTSTATUS blackbone::Process::CreateAndAttach |
( |
const std::wstring & |
path, |
|
|
bool |
suspended = false , |
|
|
bool |
forceInit = true , |
|
|
const std::wstring & |
cmdLine = L"" , |
|
|
const wchar_t * |
currentDir = nullptr , |
|
|
STARTUPINFOW * |
pStartup = nullptr |
|
) |
| |
Create new process and attach to it
- Parameters
-
| path | Executable path |
| suspended | Leave process in suspended state. To resume process one should resume its main thread |
| forceInit | If 'suspended' is true, this flag will enforce process initialization via second thread |
| cmdLine | Process command line |
| currentDir | Startup directory |
| pStartup | Additional startup params |
- Returns
- Status code
| NTSTATUS blackbone::Process::Detach |
( |
| ) |
|
Detach form current process, if any
- Returns
- Status code
| NTSTATUS blackbone::Process::EnsureInit |
( |
| ) |
|
Ensure LdrInitializeProcess gets called
- Returns
- Status code
| void blackbone::Process::EnumByName |
( |
const std::wstring & |
name, |
|
|
std::vector< DWORD > & |
found |
|
) |
| |
|
static |
Search for process by executable name
- Parameters
-
| name | Process name. If empty - function will retrieve all existing processes |
| found | Found processses |
| NTSTATUS blackbone::Process::EnumByNameOrPID |
( |
uint32_t |
pid, |
|
|
const std::wstring & |
name, |
|
|
std::vector< ProcessInfo > & |
found, |
|
|
bool |
includeThreads = false |
|
) |
| |
|
static |
Search for process by executable name or by process ID
- Parameters
-
| pid | Target process ID. rocess name. If empty - function will retrieve all existing processes |
| name | Process executable name. If empty - function will retrieve all existing processes |
| found | Found processses |
| includeThreads | If set to true, function will retrieve info ablout process threads |
- Returns
- Status code
| NTSTATUS blackbone::Process::EnumHandles |
( |
std::vector< HandleInfo > & |
handles | ) |
|
Enumerate all open handles
- Parameters
-
- Returns
- Status code
| BLACKBONE_API DWORD blackbone::Process::pid |
( |
| ) |
const |
|
inline |
| NTSTATUS blackbone::Process::Terminate |
( |
uint32_t |
code = 0 | ) |
|
Terminate process
- Parameters
-
- Returns
- Stratus code
| bool blackbone::Process::valid |
( |
| ) |
|
Checks if process still exists
- Returns
- true if process is valid and exists
- Returns
The documentation for this class was generated from the following files:
- C:/Users/Ton/Documents/visual studio 2013/projects/blackbone/src/BlackBone/Process/Process.h
- C:/Users/Ton/Documents/visual studio 2013/projects/blackbone/src/BlackBone/Process/Process.cpp


Symbol Index for "Temporal Phenomenon Link"
Symbol Index for diagram
"Temporal Phenomenon Link"
classifier (Association)
from (Association)
Subject Phenomenon (Class)
Temporal Link Type (Class)
Temporal Phenomenon Link (Class)
to (Association)


{% overextends "base.html" %} {% block top_block %}
This project is based on Froide, a free and open source project of the Open Knowledge Foundation. If you want to support Froide, please visit their Github repository.


Have a question? Want to just say hello? Let us know
Want to give back to the community? Donate today
Stay up to date on the most recent happenings around Lithgow.


MY FAVORITE PET
Characteristics of my favorite pet
Good guard dog
Good family pet
Loyal Companion
Courageous
Affectionate


Improving the pre-screening of eligible patients in order to increase enrollment in cancer clinical trials
Inserm U1099 - LTSI, Equipe Données Massives en Santé - Université Rennes 1, 2 rue du Professeur Léon Bernard, Rennes Cedex, 35043, France
Department of Medical Information, University Hospital of Rennes, 2 rue Henri Le Guilloux, Rennes, 35000, France
Comprehensive Cancer Center Eugene Marquis (CCC), Avenue de la Bataille Flandres-Dunkerque, Rennes Cedex, 35042, France
Clinical Investigation Center, University Hospital of Rennes, 2 rue du Professeur Léon Bernard, Rennes Cedex, 35043, France
The performance of randomized controlled trials (RCTs) is often hindered by recruitment difficulties. This study aims to explore the pre-screening phase of four prostate cancer RCTs to identify the impact of a systematic pre-selection of eligible patients for RCT recruitment.
The pre-screening of four RCTs opened at the Comprehensive Cancer Center in Rennes was analyzed retrospectively (French Genitourinary Tumor Group (GETUG) 14, 15, 16, and 17). Data were extracted from electronic multidisciplinary cancer (MDC) reports and manually completed by physicians and medical secretaries. These data were the main source of information for clinicians to discuss treatment alternatives during MDC sessions. The pre-screening decisions made by the clinicians during these MDC meetings were compared with those made after a systematic review of the MDC reports by a clinical research assistant (CRA). Any inconsistencies in decisions between the CRA and the MDC physicians were corrected by the principal investigator (PI).
The pre-screening rate was 9.1% during the MDC meetings, while it was estimated to be 12.9% after the final review by the PI, and 29% after the systematic review by the CRA. The study showed that 77% and 67% of the MDC reports did not mention clinical and pathological Tumor, lymph node and metastasis classification of malignant tumors (TNM) staging, respectively, and that 35 of the CRA’s 47 proposals rejected by the PI concerned implicit information (not specified in the MDC reports). Only one patient was proposed by the PI, and none by the CRA.
These results confirm that pre-screening could be improved by a systematic review of the medical reports. They also highlight the fact that missing data in electronic MDC reports leads to over-enrollment of non-eligible patients, but not to over-exclusion of eligible patients. Thus, our study confirms the potential gain in using semi-automated pre-selection of MDC reports, in order to avoid missing out on patients eligible for RCTs.
The trials evaluated in this study were previously registered with clinicaltrials.gov (registration number: NCT00104741 on 3 March 2005; NCT00104715 on 3 March 2005; NCT00423475 on 16 January 2007; and NCT00667069 on 24 April 2008).
The randomized controlled trial (RCT) is the gold standard for evaluating the effects of healthcare procedures, but the performance of clinical RCTs is often hindered by recruitment difficulties 1 . Inadequate recruitment causes delays, increases costs, reduces the statistical power of analysis and finally, may lead to failed clinical trials.
Clinical trials are an important option of care for cancer patients since they often provide the most up-to-date and effective treatment for end-stage disease. It has also been suggested that more participation in oncology clinical trials could lead to improved survival in cancer patients 2 , 3 . Nevertheless, patient enrollment remains particularly low in oncology clinical trials (according to the National Cancer Institute, less than 5% of adults with incident cancer participate in clinical trials in the United States) 4 , 5 .
Barriers to recruitment for oncology clinical trials can be summarized into three main categories 6 , 7 :
Individual barriers (such as patients feeling uncomfortable with experimentation or experiencing a loss of control over decision-making, and physician time and effort required for recruitment),
Barriers related to RCT designs (overly strict or non-adapted criteria, too large a number of RCTs, RCT complexity leading to difficulties in explaining trials to patients, and so forth), and
Barriers caused by system and organizational features (lack of staff and research nurses, communication difficulties, planning of local resources according to RCT designs, and so forth).
Different strategies, often timesaving and cost-effective, can be used to overcome these barriers (for example, hiring a research nurse or a data manager). But there is also evidence that Health Information Systems and Information Technologies can improve the recruitment process. A review of recent literature shows that many studies examine, discuss, and/or deal with support systems for clinical trial recruitment 5 . These are mainly concerned with addressing individual barriers, and sometimes with the development of tools to ease usability of eligibility criteria. However, the authors highlight the lack of evaluation and workflow integration of the support systems into the RCT recruitment process, and they emphasize the importance of the pre-screening phase for recruitment, particularly for RCT recruitment systems.
In this study, we hypothesized that the improvement of pre-screening of patients eligible for RCTs would lead to an improvement in overall patient enrollment in clinical trials. Thus, the study focused on the pre-screening steps of patient enrollment to RCTs.
The main objective of the present study was to assess the impact of semi-automated decision support systems in improving patient pre-screening in oncology RCTs. Therefore, the study compared the pre-screening decisions made prospectively by the physicians during patient care, with the pre-screening decisions made with a systematic and retrospective review of the medical reports. Then, the study identified factors that could make pre-screening more efficient.
As presented in Figure
Figure 1
The therapeutic decision-making process for patients with cancer in Brittany (France), including the multidisciplinary cancer (MDC) meeting.
The therapeutic decision-making process for patients with cancer in Brittany (France), including the multidisciplinary cancer (MDC) meeting. Step one: MDC meeting request by a treating physician concerning a patient; step two: MDC meeting scheduled by the MDC secretary; step three: presentation of the MDC report during the MDC meeting; step four: registration of the therapeutic decision in the oncologic electronic health records (EHR) and feedback to the treating physician.
In Brittany (France), the workflow starts with a request made by the treating physician to the MDC secretary, in order to schedule the presentation of the patient’s case within the MDM (steps one and two). With the patient data provided by the treating physician (most of the time from the paper-based patient record), the secretary fills in an online standard MDC report designed for each type of cancer. The MDC report is intended to collect all essential patient data to make the decision during the MDM.
On the day of the MDM, the secretary shows each MDC report to the tumor board (step three). After the discussion, the therapeutic decision is registered (step four) and sent back to the treating physician who can then inform the patient.
During the MDM, some patients may be proposed (in a pre-screening phase) as being potentially eligible for an RCT; according to a subset of selection criteria called that we will call ‘pre-screening criteria’. These criteria correspond to those that can be checked from the retrospective data available in the patient charts. Pre-screening criteria include, for instance, demographic characteristics (such as age and gender) and some medical characteristics (such as tumor stage and surgical history). The other criteria (which we will call ‘screening criteria’) are those that can only be tested secondarily (in a screening phase), after having contacted the patient (for example, a negative HIV test on the day of enrollment). The patients are eventually included in the appropriate RCT when all eligibility criteria are met.
The present study proposes to retrospectively analyze the decision-making process of the MDM and to compare it to a systematic review of the patient’s case.
Urologic oncology was chosen as the experimental field for practical reasons, partly because most eligibility criteria are readily handled by computerized data (Tumor, lymph node and metastasis classification of malignant tumors (TNM) staging, the Gleason score, prostate-specific antigen (PSA) level, and so forth). The study focused on prostate cancer, which is the most common form in urology. It is also the main topic of discussion at urology MDMs and of many clinical trials.
Four prostate cancer clinical trials were active and recruiting patients at the Cancer Research Institute of Rennes during the study period (between October 2008 and March 2009), all conducted by the French Genitourinary Tumor Group (GETUG) 8 :
Detailed eligibility criteria for the four RCTs discussed at the MDMs during the study period are presented in Table 1. The RCTs were conducted in accordance with the Declaration of Helsinki. All participants were required to give written informed consent before enrollment in one of the four studies.
|
Eligibility criteria |
GETUG 14 ( NCT00104741 ) |
GETUG 15 ( NCT00104715 ) |
GETUG 16 ( NCT00423475 ) |
GETUG 17 ( NCT00667069 ) |
|
|
Disease characteristics |
Histology |
Histologically confirmed prostate cancer: (Stage T1b-T1c AND PSA ≥10 ng/mL) OR (Stage T1b-T1c AND Gleason score ≥7 OR Stage T2a-T3a) a |
Histologically confirmed prostate adenocarcinoma a |
Histologically confirmed prostate adenocarcinoma: pT2, pT3, or pT4, pN0 or pNx a |
Histologically confirmed prostate adenocarcinoma: pT3a, pT3b (or pT4 by reaching the bladder neck), or R1 disease, OR pN0 or pNx a |
|
Disease’s prior treatment |
Not specified |
Not specified |
Treated with surgery only a |
Treated by curative surgery in the past 6 months a |
|
|
Positive margins (tumoral glands in contact with contour ink) |
|||||
|
Metastasis |
No metastatic disease (M0) confirmed by thoracic radiography and bone scan a |
Metastatic disease a |
Not specified |
Not specified |
|
|
Disease’s exclusion criteria |
History of invasive cancer a |
Brain metastases a |
Clinical signs of progressive disease |
pN1 disease, pT2 disease, |
|
|
Lymph node invasion (N0 or N-) a |
Other histology than adenocarcinoma a |
||||
|
PSA/GLEASON score |
PSA <30 ng/mL |
Not specified |
PSA ≤0.1 ng/mL after prostatectomy a |
PSA ≤0.1 ng/mL after prostatectomy a |
|
|
PSA ≥0.2 ng/mL and <2 ng/mL at study entry |
Gleason score <8 a |
||||
|
Patient characteristics |
Age |
Under 75 a |
18 and over a |
18 and over a |
18 and over a |
|
Performance status |
ECOG 0-1 a |
ECOG 0-2 a |
ECOG 0-1 a |
ECOG 0-1 a |
|
|
Life expectancy |
At least 10 years a |
At least 3 months a |
≥10 years a |
≥10 years a |
|
|
Hematopoietic |
Not specified |
WBC ≥2,000/mm 3 |
Not specified |
Not specified |
|
|
Absolute neutrophil count ≥1,000/mm 3 |
|||||
|
Platelet count ≥100,000/mm 3 |
|||||
|
Hepatic |
Not specified |
Bilirubin ≤1.5 × upper limit of normal (ULN) AND AST, ALT ≤1.5 × ULN |
Not specified |
Not specified |
|
|
Renal |
Not specified |
Creatinine ≤150 μmol/L |
Not specified |
Not specified |
|
|
Cardiovascular |
Not specified |
No symptomatic coronary disease a |
No uncontrolled hypertension |
No uncontrolled hypertension |
|
|
No congenital cardiac insufficiency a |
(systolic ≥160, diastolic ≥90 mm Hg) |
(systolic ≥160, diastolic ≥90 mm Hg) |
|||
|
NYHA class < III or IV a |
|||||
|
Other diseases |
Not specified |
No other malignancy (in the past 5 years) a |
No other malignancy (in the past 5 years) a |
No other malignancy (in the past 5 years) |
|
|
No active infection a |
No known pituitary gland adenoma a |
No known hypersensitivity to gonadotropin-releasing hormone a |
|||
|
No severe peripheral neuropathy a |
No contraindication of intramuscular injection a |
||||
|
Other |
Not specified |
No compliance and follow-up difficulties due to familial, social, geographical, or psychological situation a |
No compliance and follow-up difficulties due to familial, social, geographical, or psychological situation a |
No compliance and follow-up difficulties due to familial, social, geographical, or psychological situation a |
|
|
Affiliated with social security program a |
Affiliated with social security program a |
||||
|
No patients who are deprived of liberty or under guardianship a |
|||||
|
Prior concurrent therapy |
Chemotherapy |
Not specified |
No prior chemotherapy for metastatic prostate cancer (within the past year) a |
Not specified |
Not specified |
|
Endocrine therapy |
No prior hormonal therapy a |
Prior hormonal therapy within the past 2 months allowed a |
No prior hormonal therapy a |
No prior hormonal therapy a |
|
|
Radiotherapy |
No prior pelvic radiotherapy a |
No prior radiotherapy to metastatic sites (within the 4 last weeks) a |
No prior pelvic radiotherapy a |
No prior radiotherapy within 3 months after radical prostatectomy a |
|
|
No prior pelvic radiotherapy a |
|||||
|
Surgery |
No prior radical prostatectomy a |
No prior surgical castration a |
No prior surgical or chemical castration a |
No prior surgical or chemical castration a |
|
|
No prior castration |
At least 6 months since surgery for biological recurrence a |
||||
|
Other |
Not specified |
No concurrent investigational drugs a |
No concurrent anticancer therapy a |
No concurrent participation in another study a |
The data used in our study consisted of the information contained in the MDC reports, and of the corresponding therapeutic decisions taken during the MDMs. The MDC reports included general characteristics of patients, medical history, and data related to prostate cancer, such as the Gleason score, tumor staging (clinical and pathological TNM classification), and the prostate-specific antigen (PSA) level. According to each case, the MDC team’s decisions were either to propose a standard therapy to the patient, or to participate in a clinical trial (in this case, the MDC team had estimated that pre-screening criteria seemed to be verified). MDC reports and MDM decisions were retrospectively and exhaustively collected. The data extraction (Figures
Figure 2
Evaluation design of the multidisciplinary cancer (MDC) team’s pre-screening decisions.
Evaluation design of the multidisciplinary cancer (MDC) team’s pre-screening decisions. Step one: extraction of the MDC reports from the oncologic electronic health records (her); step two: Extraction of the MDC team’s pre-screening decisions from the oncologic EHR; Step 3: systematic review of the MDC reports by the clinical research assistant (CRA); step four: comparison of the pre-screening decisions made by the CRA and the MDC team; step five: principal investigator’s review of the MDC reports corresponding to the discrepancies between the CRA’s decisions and the MDC team’s decisions; step six: final pre-screening decisions (gold standard) including the principal investigator’s decisions.
Data were completed with the number of medical records and the number of prostate cancer records discussed at each MDC meeting, as well as the number of physicians who participated in the MDMs.
The local ethics committee, ‘Comité d’éthique du CHU de Rennes’, approved the present study (registration identifier: 13–26). All four trials cited in this study obtained ethical approval by a research ethics committee with the following approval numbers for GETUG 14: 2003/015 (CPPRB Haute Normandie), for GETUG 15: 04/08 (CPPRB Marseille 1), GETUG 16: 06/025 (CPPRB Lyon), GETUG 17: 2007/53 (CPP Sud-Ouest et Outre Mer III).
The evaluation protocol consisted in collecting and comparing three types of decision (MDC, clinical research assistant (CRA), and principal investigator (PI)). The MDC team’s decision was the initial tumor board’s decision made directly during the MDM.
The CRA’s decision (Figure
Results were described using means associated with standard deviations ( m ± ε), and absolute and relative frequencies (n (%)). The MDC, CRA, and PI pre-screening decisions were described especially by the MDC, CRA and PI pre-screening rate, and compared using the McNemar’s chi-square test. Factors that could influence the MDC team’s pre-screening decisions (the characteristics of the MDMs and the content of the MDC reports) were tested using the Pearson’s correlation test and the Mann–Whitney U test.
A descriptive analysis of the discrepancies between the MDC, CRA, and PI proposals was also performed. Statistical analysis was performed using R software, R Foundation for Statistical Computing, Vienna, Austria 9 . Two-tailed P values were reported with P <0.05 considered to be statistically significant.
During the study period, 23 urologic MDMs were held at the Comprehensive Cancer Center of Rennes, and 466 MDC reports were analyzed. Among them, 286 MDC reports concerned patients with prostate cancer, all of which were evaluated in the present study.
On average, 7 ± 1.7 physicians, including 3 ± 0.9 oncologists, attended each MDM. The PI of GETUG 14 was present at 12 of the 23 MDMs held during the study period, the PI of GETUG 15 at 15 of the 23 MDMs, the PI of GETUG 16 at 12 of the 23 MDMs, and the PI of GETUG 17 at 13 of the 23 MDMs.
On average, during an MDM, 20 ± 6.2 reports were discussed with 12 ± 4.6 of those being related to patients with prostate cancer. Clinical and pathological TNM stages were found in 67 (23.4%) and 94 (32.9%) of the 286 MDC reports, respectively concerning patients with prostate cancer. However, 261 (91.3%) and 252 (88.1%) of the 286 MDC reports included the Gleason score and the PSA level, respectively.
A total of 26 patients were proposed for screening by the physicians who participated in the MDMs; 17 for screening in GETUG 14, seven for screening in GETUG 16 and two for screening in GETUG 17. No patient was proposed for screening in GETUG 15.
Among factors that may have influenced pre-screening during the MDMs (the MDC team’s decisions), a statistically significant and negative correlation was found between the number of MDC reports concerning patients with prostate cancer and the pre-screening rate of each MDM (Pearson correlation coefficient (r) = −0.42, P = 0.046). There was also a reverse correlation between the overall number of MDC reports discussed in MDMs and the pre-screening rates of the MDMs, but this negative correlation was not found to be significant (r = −0.37, P = 0.082). The number of physicians and the number of oncologists attending the MDMs did not significantly influence the pre-screening rates ( P = 0.521 and P = 0.964, respectively). Neither did the presence of the PI, whatever the RCT (GETUG 14: P = 0.095, GETUG 15: no initial pre-screening proposal, GETUG 16: P = 0.550, GETUG 17: P = 0.950).
Absence of (clinical and pathological) TNM staging, the Gleason Score, or the PSA level in the MDC reports did not hinder MDM attenders to make pre-screening decisions, and did not significantly influence the pre-screening rate of the MDC team (data not shown).
In total, 146 cumulative MDC report selections were recorded, concerning 86 different patients eligible for at least one RCT. GETUG 14 was the RCT with the most selections during the pre-screening period, with 106 (72.6%) proposals concerning 60 (69.8%) different patients. Pre-screening rates related to each RCT, according to the MDC team’s, CRA’s, and PI’s decisions, are reported in Table 2. The overall pre-screening rates were estimated at 9.1% (26 patients) based on the MDC decisions, 29.0% (83 patients) based on the CRA’s decisions, and 12.9% (37 patients) based on the PI’s decisions.
|
GETUG 14 |
GETUG 15 |
GETUG 16 |
GETUG 17 |
Total* |
|
|
MDC team’s decisions (1) |
17 (5.9%) |
0 |
7 (2.4%) |
2 (0.7%) |
26 (9.1%) |
|
CRA’s decisions (2) |
59 (20.6%) |
8 (2.8%) |
13 (4.5%) |
3 (1.0%) |
83 (29.0%) |
|
PI’s decisions (3) |
30 (10.5%) |
0 |
6 (2.1%) |
1 (0.3%) |
37 (12.9%) |
A total of 22 patients were found eligible for screening in an RCT based on at least two pre-screening methods; most pre-selections were for the same RCTs. Only one discrepancy was observed between decisions made at the MDM and the CRA (GETUG 17 versus GETUG 16, respectively), but the PI retained neither.
Discrepancies mainly concerned patients initially excluded during the MDC meetings (59 patients were proposed by the CRA and 14 were finally validated by the PI). Regarding patients initially proposed for an RCT during the MDC meetings, two patients were secondarily excluded by the CRA and, finally, the PI definitively excluded four patients. There was no patient who was not proposed by the CRA but was proposed either during an MDM or by the PI. Nevertheless, the PI proposed one patient who was not proposed either by the CRA or at the MDC meetings. Figure
Figure 3
Venn diagram of the pre-screening of patients eligible for four randomized clinical trials carried out at the Comprehensive Cancer Center in Rennes (GETUG 14, 15, 16, and 17).
Venn diagram of the pre-screening of patients eligible for four randomized clinical trials carried out at the Comprehensive Cancer Center in Rennes (GETUG 14, 15, 16, and 17). Pre-screening was based on the physicians’ decisions during the multidisciplinary cancer meetings (MDC team’s decisions), the decisions of the clinical research assistant (CRA’s decisions), and the principal investigator (PI’s decisions) after a systematic review of the MDC reports.
The four MDC team’s pre-selections excluded by the PI were due to mistakes on the evaluation of some exclusion criteria during the MDMs (too high a PSA rate or the presence of a positive margin after surgery). Among the CRA's 47 pre-selections that were not retained by the PI, 35 were due to implicit information known only by the clinicians and not explicitly available in the MDC reports. For example, the PI excluded 18 CRA proposals because the patients had a Gleason score of less than seven, but such a criterion was not described in the exclusion or inclusion criteria of the RCTs. In the same way, six patients could have been eligible for an RCT but the MDC teams judged another type of care more effective. Further, nine patients were excluded because they had some specific characteristics (vital status, combination of comorbidities, and wishes) not compatible with enrollment in the RCTs according to the MDC teams.
In this study, the pre-screening rate with MDC team’s decisions made during the MDMs was estimated to be at 9.1%. It is higher than rates previously reported in other studies (around 5% for oncology RCTs) 4 . Nevertheless, the best pre-screening rate was estimated to be 12.9% (based on the PI’s decisions). This confirms that patient pre-screening in clinical cancer research could be improved by a systematic review of the MDC reports after MDMs.
It has been shown that individual barriers, such as the time and effort required for patient recruitment for the physicians, are factors that decrease enrollment in RCTs 6 . The present study found that all patients proposed by the PIs were also proposed by the CRA’s systematic review, except one. In other words, the CRA’s review resulted in the justified rejection of more than 200 of the 286 initial MDC reports. Thus, we argue that the addition of a manual (or a computerized) systematic review at the first step of the screening process (the pre-screening phase) could lead to substantial gains in time and effort for the physicians’ screening task afterwards.
Nevertheless, the results showed that the pre-screening decision should not be based only on the information available in the MDC reports, since some data are missing (such as TNM staging), or are not explicit. These issues illustrate why the pre-screening rate (29.0%) is so high when the CRA makes the decision alone; because their decision relies only on the content of the MDC reports. Missing data cannot be used to exclude the patients who are then selected as being eligible for RCTs. From the perspective of automating this decision-making process using a recruitment support system, we can foresee that such a system will overestimate the number of patients potentially eligible for RCTs, just as the CRA has done.
It is likely that the best approach for these systems is not intended to replace the physicians’ decision, but to help physicians by reminding them that every patient is potentially eligible for an available clinical trial. The main objective will therefore be more to avoid missing out on patients who could be included than deciding which patients should be included.
Indeed, our result showed that clinical TNM staging and pathological TNM staging are missing in 68% and 76%, respectively, of the MDC reports proposed by pre-screening after correction by the PI (data not shown). From a decision-making perspective, missing and implicit data (only known by the physicians of the MDC teams) could be seen as problematic regarding patient selection, but our results showed that missing and implicit information usually led to the exclusion of patients. Thus, these results showed that missing and implicit data mainly caused an overestimation of patients eligible for RCTs, resulting in the decreased precision of the systematic (or automated) pre-screening, but this did not lead to the wrongful exclusion of eligible patients.
It could be argued that observations in the present study reflect local patterns of pre-screening practice and medical record design. Indeed, centers with routine systematic pathology reporting, in line with international standards, could certainly have a better registration rate of clinical and pathological TNM staging and thus increase the performance, and above all precision, of systematic (or automated) pre-screening.
This illustrates that the best pre-screening practices cannot be guaranteed without providing the essential information (such as TNM staging) at the time of pre-screening, but they are not limited due to the systematic (or automated) pre-screening methods themselves. The present study shows that despite the presence of numerous missing data concerning key elements for enrollment in RCTs in urologic oncology, the implementation of a manual (or a computerized) systematic review could optimize the pre-screening task by improving the pre-screening rate and by reducing the time and effort required for pre-screening by physicians.
We did not succeed in discovering which factors could really impact the pre-screening rate, except for the number of MDC reports discussed per session. The low number of patients who are actually eligible in the present study could be a limit to the interpretation of such a result, but it confirmed at least that the workload during the MDC meetings is a major factor that decreases pre-screening performance and enrollment in RCTs in oncology. Therefore, this is a strong argument for research as investigated in the automatic selection of clinical trials based on eligibility criteria (ASTEC) project 10 , which aims to provide tools to physicians (oncologists) to make the recruitment of patients for RCTs easier and more automatic.
The study found that a systematic review of medical reports could increase the cumulative pre-screening rates of four RCTs recruiting patients at the Comprehensive Cancer Center in Rennes from 9 to 13%. Also, we argue that such an additional systematic review during the first step of the screening process could lead to substantial gains in time and effort for physicians in their task of recruiting patients for RCTs.
The study also showed that missing data in the MDC reports leads to a systematic review that over-includes non-eligible patients, but does not over-exclude eligible patients. Therefore, we confirm the potential gain in using the semi-automated selection of electronic MDC reports to avoid missing out on patients eligible for RCTs.
To conclude, optimizing the pre-screening process represents an interesting way to improve patient enrollment in clinical trials, which remains particularly low in oncology research. The use of computerized pre-screening support systems to perform a systematic review of eligible patients could help to reach such an objective.
ASTEC: Automatic selection of clinical trials based on eligibility criteria
CPP/CPPRB: French research ethics committee
CRA: Clinical research assistant
EHR: Electronic health records
GETUG: French Genitourinary Tumor Group
MDC: Multidisciplinary cancer
MDM: Multidisciplinary cancer meeting
PI: Principal investigator
PSA: Prostate-specific antigen
RCT: Randomized controlled trial
TNM: Tumor, lymph node and metastasis classification of malignant tumors
The authors declare that they have no competing interests.
MC is responsible for the ASTEC project coordination. MC and BCG conceptualized and designed the study. CB and OZ contributed in the data collection and pre-screening evaluation. BL, ELP, and RDC were responsible for the validation of patient pre-screening. BCG performed the statistical analysis. BCG and MC drafted the manuscript. All authors provided critical review and final approval.
The French National Research Agency under the TecSan program 2008 funded the ASTEC project (ASTEC number: ANR-08-003). The authors would like to especially thank Delphine Rosille, Sahar Bayat, Marc Carpentier, and Regis Duvauferrier for their valuable comments.
Strategies for increasing recruitment to randomised controlled trials: systematic review
National survival trends of young adults with sarcoma: lack of progress is associated with lack of clinical trial participation
Does enrollment in cancer trials improve survival?
Participation in cancer clinical trials: race-, sex-, and age-based disparities
France, an attractive country for international clinical research: 2010 survey assessed by Leem (French association of pharmaceutical companies)
Obstacles to participation in randomised cancer clinical trials: a systematic review of the literature
Barriers to participation in clinical trials of cancer: a meta-analysis and systematic review of patient-reported factors
The French clinical trials ongoing (GETUG and AFU) on urothelial carcinomas, kidney and prostate cancers
R Core Team
Using Semantic Web Technologies for Clinical Trial Recruitment


Hi,
Before finding OEM I have installed solar PV with a built in Immersun (solar PV diverter) to heat the HW. With this setup I need to monitor the HW temp to decide whether to turn on the immersion heater with mains supply.
A second emontx has been installed to measure the temp in the HW tank. I can see the output in emoncms. I am however struugling to get the display into the glcd. At the moment I am using the Home Energy Monitor software and the room temp quadrant is not needed.
How do you change this to import the 2nd emontx temp, which is running the Low Power Temp module, and display on the glcd in place of the Room Temp?
Regards
Steve
Re: feeds from multiple emontx
The short answer is you look at the sketch, understand how it works and writes to the GLCD, and you rewrite it to suit!
The long answer is the sketch as it stands is programmed to receive data from two places - an emonTx for energy measurements and an emonBase for the time of day. If you want to keep the time function (probably not?) then you need to modify that roughly in line with the other and then write that second temperature to the display in place of the room temperature, and change the wording too. If you do keep the time from the base, then you need to add a bit more code and that could be a problem as the GLCD is right on the limit of what's possible given the amount of memory available.
If you're happy to pursue that, then I can give you a more detailed steer - which I guess you'd appreciate?
Re: feeds from multiple emontx
As you've guessed programming is not my forte. The code appears to call functions in other sketches and in doing so confuses me. The problem then arises as to where the differentiation between the two emontx comes.
Time display is a nice to have but no-were near essential so it can be ditched is necessary. If you can give me a more detailed steer then it would be greatly appreciated.
Thanks for the offer.
Steve
Re: feeds from multiple emontx
Ok, give me a few days
Re: feeds from multiple emontx
To try to give you a "simple" explanation I'll tell you what I did .... some consider me to be simple!
Data is sent as an RF signal in little packets of information. If every piece of electronics used the same RF signal it would be a mess as everything would be sent and would clash between units. So, what we do is we send some data at some frequencies between units and at a different RF frequency on other units. We also send that information in different formats so as to minimise the chances of data clash.
With the EMON project the information is all sent at the same basic frequency and in the same format but we allow one unit to differentiate itself from another by allocating a different channel. So, the data sent between one emonTX and the base unit can be sent on one channel while the data between another emonTX unit and the base unit can be sent on a different channel. Then, sending the data from the base unit to the GLCD can be done on a third channel. The trick then is to read the incoming data from each of the emonTX units sequentially based upon looking for channels, then construct something to send to the GLCD which is a concatenation of the received data and send this data out on a different channel to the GLCD or, if you simply read all of the data straight into the GLCD, concatenate the results and choose a place to display them on the screen.
In my sketches I actually have the GLCD and the emon base unit listening to one emonTX simultaneously and I also have the emon base unit listening to another emonTX at the same time as listening to the first one. I then build a new packet of data and send it to the internet. So, my use is slightly different to yours, but the principles still apply.
So, the principle of reading is along the lines of the following:
This is a simple example of two payloads. They simply read in a pair of integer values but you can make the payloads whatever you like provided they agree with the structure of the payload which is being sent by each emonTX unit.
typedef struct { int MeterReading;
int Active ;
} PayloadTX; // create structure - a neat way of packaging data for RF comms
PayloadTX MeterMonitor;
typedef struct { int MeterReading;
int Active ; int flag;
} PayloadTXI; // create structure - a neat way of packaging data for RF comms
PayloadTXI ImmersionMonitor;
// This last one is another payload should you wish to transmit a concatenation of results.
typedef struct { int MeterOut1; int MeterOut2;
int Active ;
} PayloadTXI; // create structure - a neat way of packaging data for RF comms
PayloadGLCD GLCDData;
Here is a snippet of a loop where we read in the payloads
void loop () {
#ifdef UNO
wdt_reset();
#endif
dhcp_dns(); // handle dhcp and dns setup - see dhcp_dns ta
if (rf12_recvDone()){
if (rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0) // make sure the data is valid
{
int node_id = (rf12_hdr & 0x1F); // read the node id ... essentially the transmission channel
byte n = rf12_len;
if (node_id==17) \\ if the channel id is 17 then do this
{
Serial.println(F("Data received from Consumer Meter"));
MeterMonitor=*(PayloadTX*) rf12_data;
//Then do stuff based upon what has been read
Serial.println(MeterMonitor.MeterReading);
}
if (node_id==22) \\ if the channel id is 22 then do this
{
Serial.println(F("Data received from Immersion Monitor"));
ImmersionMonitor=*(PayloadTXI*) rf12_data;
//Then do stuff based upon what has been read
Serial.println(ImmersionMonitor.MeterReading);
}
// Then If you wish to transmit the data to someplace else you can load it into another structure like this
GLCDData.MeterOut1=MeterMonitor.MeterReading;
GLCDData.MeterOut1=ImmersionMonitor.MeterReading;
// and transmit this new payload on a different channel again
// or you can populate the display with the data along these lines
int displayPower=(ImmersionMonitor.MeterReading);
sprintf(str1,"%d A",displayPower);
glcd.drawString(80,57,str1);
// or you can simply work with sections of each payload without concatenation
int displayPower=(int)(GLCDData.MeterOut1);
sprintf(str1,"%d A",displayPower);
glcd.drawString(80,57,str1);
Here now is some data from the emon TX:
// These defines set the frequency and the channel for operation. You will need the same code in your GLCD sketch so that the frequencies and channels match. Note though that the myNodeID definition will be different on each emon TX (17 and 22 for this example
#define myNodeID 17 //node ID of tx (range 0-30)
#define network 129 //network group (can be in the range 1-250).
#define freq RF12_433MHZ //Freq of RF12B can be RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. Match freq to module
// Now the payload
typedef struct { int MeterReading;
int Active ;
} PayloadTX; // create structure - a neat way of packaging data for RF comms
PayloadTX MeterMonitor;
// Now some data populated into the structure
MeterMonitor.MeterReading=100;
// and here is some data being transmitted
rf12_initialize(myNodeID,freq,network); //Initialize RFM12 with settings defined above
Serial.print("Node: "); Serial.print(myNodeID);
Serial.print(" Freq: ");
if (freq == RF12_433MHZ) Serial.print("433Mhz");
if (freq == RF12_868MHZ) Serial.print("868Mhz");
if (freq == RF12_915MHZ) Serial.print("915Mhz");
Serial.print(" Network: "); Serial.println(network);
// send a payload with the channel set to 255. This tells the emonGLCD that the system is calibrating
// Put the revision code of the software in the vrms variable
int ii = 0; while (!rf12_canSend() && ii<10) {rf12_recvDone(); ii++;}
rf12_sendStart(0, &MeterMonitor, sizeof MeterMonitor);
This is the general idea. I hope that this helps a little.
Ian
Re: feeds from multiple emontx
Ian - I'll leave it to you then to help Steve through this.
Re: feeds from multiple emontx
Hi Robert and Steve,
I'll do what I can but it may be problematic as I'm away all of next week while we launch a new business venture and after that I hope to have very little spare time.
Certainly drop messages and I'll see what I can do. Responding with tried and tested detailed responses may be more difficult.
Ian
Re: feeds from multiple emontx
Thanks for the pointers.
I'm sure it will take me a few weeks to understand and incorporate the ideas into my system.
If and when I don't understand I'll come back b either way I'll let you know.
Regards
Steve


| Transaction Id | Version | Product Type | amount | Currency | From Account | To Account | Trade Date | Settlement Date | Approved By | To Account | Trade Date | Settlement Date | Approved By | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| {{transaction.transactionId}} | {{transaction.version}} | {{transaction.prodType}} | {{transaction.amount}} | {{transaction.currency}} | {{transaction.fromAccount}} | {{transaction.toAccount}} | {{transaction.tradeDate}} | {{transaction.settlementDate}} | {{transaction.approvedBy}} | {{transaction.toAccount}} | {{transaction.tradeDate}} | {{transaction.settlementDate}} | {{transaction.approvedBy}} |


Start with a writer you're interested in. See a graph of their connections to other writers. The blue links point to their influences—people they've mentioned in their Paris Review interview. The red links point to their influencees—people who have talked about them. Lavender means both writers influenced each other.
Writers in green have written fiction, those in orange are poets, and those in purple have worked in some other form (from nonfiction to theater to criticism). Some people fall into multiple categories, but they're grouped under fiction or poetry, and you can learn about their other genres when you click on them.
Click on the names of any the writers in the graph to highlight them and see some context about their relationships with your main writer in the sidebar. (If you don't think the "influence" is legit, there's a button in the sidebar to remove the link!) Then, if you want to learn more about the influences of that writer, just click on their name again (or click the "focus on" link in the sidebar) and all their influence links will be added to the graph. You can always click back to previous focuses of attention too, to recolor their links, or just keep venturing outward.
Explore! Maybe find someone new to read. And if an excerpt in the sidebar looks interesting, please do click through to the full interview: they're wonderful.
This project was made for Stanford's CS 448B: Data Visualization course. See the source on GitHub.


Minature text adventure demonstrating a utility-based AI. Free and open source, written in Haxe by Sam Twidale.
This demonstrates a need-based AI that simulates someone sitting at their computer all day. The open source code could be a starting point for AI for a roguelike, text adventure or Sims-style game.
The AI is modelled as a set of needs and a strategy to meet them. There are four strategies: always choose actions to satisfy the most urgent need, random selection weighted towards more urgent needs, true random selection, and nothing (purely manual control).
Threshold values are used to make the agent repeat actions to satisfy a need, when a single action might not be sufficient. Modifiers are used to change the effectiveness of needs or actions, to model traits or personality differences.
This was inspired by text adventures like Liberal Crime Squad and Oubliette, but went on a tangent.
If you have any suggestions, requests or comments then feel free to contact me.


WITNESS LIST Appropriations-S/C on Criminal Justice Committee February 12, 2003-8:00A Budget On: Davis, Colonel Thomas A. (Department of Public Safety) Dozier, Jim (Commission on Law Enforcement Officer Standards and Education) Evans, Bob (Department of Criminal Justice) Fabelo, Dr. Tony (Criminal Justice Policy Council) Fox, Jeannene (Alcoholic Beverage Commission) Grumbles, Cliff (Commission on Private Security) Hightower, Allen (Correctional Managed Health Care Committee, Department of Criminal Justice) Johnson, Gary L. (Department of Criminal Justice) Julian, Terry (Commission on Jail Standards) Kifowit, Dee (Department of Criminal Justice) Marty, MG Wayne D. (Adjutant General's Office) McGee, Barry (Office of the Attorney General) McHugh, Colleen (Public Safety Commission, Department of Public Safety) Rainer, Ben G. (Correctional Managed Health Care Committee, Department of Criminal Justice) Robinson, Steve (Youth Commission) Sapp, Allen (Correctional Managed Health Care Committee, Department of Criminal Justice) Smith, Dan (Self and Commission on Law Enforcement Officer Standards and Education) Spriggs, Vicki (Juvenile Probation Commission) Warren, Sr., Gary L. (Commission on Fire Protection) Wells, John (Military Facilities Commission)


Benito Gonzalez
about
portfolio
(current)
contact
resume
Portfolio
Realm Roller
Deployed Site
GitHub Repo
Yoke
Deployed Site
GitHub Repo
Weather Dashboard
Deployed Site
GitHub Repo
Team Profile Generator
GitHub Repo
Eat Da Burger app
Deployed Site
GitHub Repo
Daily Scheduler
Deployed Site
GitHub Repo
Budget Tracker
Deployed Site
GitHub Repo


replaced by PAIRED_READ. Kept for backwards compatibility.
replaced by PAIRED_WRITE. Kept for backwards compatibility.
replaced by PAIRED_READ. Kept for backwards compatibility.


We provide services in more than 200 countries. You get your best experience with us.
You can book flights online from anywhere, anytime. This provide a vast list of flights to your desired destination.
Now you can do online check-in even before reaching airport. This saves a lot of travel time and energy.
Check your flight status before leaving for the airport. You can manage your schedule accordingly.
find deals on flight just for you. Download the app now and save money every time you travel.Book tickets for today to get discounts
find deals on flight just for you. Download the app now and save money every time you travel.Book round trip at cheap rate
find deals on flight just for you. Download the app now and save money every time you travel.Book group tickets at a discount


home
bio
activities
projects
Enterprise
Swissblock Technologies
2019
Trading & Exchange platform
Interdiscount
2018
Microservice based eShop
Zeller-Gmelin
2017
hybris B2B catalog
Swisscom
2017
Customer eShop
Microspot
2016
New eCommerce portal
Interio
2015
eCommerce shop
Marionnaud
2014
eCommerce hybris portal
Pirelli
2012
B2B eCommerce portal
Open source
multi-profile
Golang
Resources multi-profiler
go-traces
Golang
Tracing advanced examples
go-tail-latency
Golang
How to deal with tail latency
On GitHub
My projects
bygui86


Wow! I finally hit javascript! Or, really, it hit me. It's an interesting one, and as such an intuitive thinker I found it waaay harder to get my head around. I haven't done maths like that since NCEA level 2. It feels much more like I'm speaking directly to a computer than html or css, which I guess makes sense given the increased level of involvement between the computer and the commands I'm writing. I guess the main difference I see is that html and css languages are mostly descriptive in nature, whereas js is strictly logic and mathematics.
Control flow is a process that regulates the performance of a certain action or set
of actions depending on the conditions of a situation before, during and after it
plays out.
Following? Probably not.
Let's look at it this way:
Think about having to refuel your car. Before you can do
anything, you have to check: does my car need re-fuelling? (that's assessing the
situation.) If your car has enough petrol, the conditions are not met for the action
of refuelling your car to take place.
And then when the conditions are right once again for your car to be refuelled (when it
is empty), the process will be repeated all over again.
I hope that makes more sense...
Actually I think I've managed to merge control flow and looping into one example there... So just to clarify:
Arrays and objects are both ways to store data. There's multiple data forms
such as numbers, strings (this is javascript for you - it defines a "word" as a
connected string of characters. Why can't it just be a word.), boolean (true or
false data), etc.
The difference between the two is that data stored in an array is in the
form of a series of ordered values, one after the other. To access that data
you have to refer to a certain position within that series.
Objects, on the other hand, store data in pairs, one part being the "key" and the other being the "value." It's kind of like labelling.
Ok, so a function is one of the meat patties in the javascript sandwich. It's
the one the does all the work. It basically does what it's called - a function
is a process that actually triggers a series of actions within the computer. It could be
a counting action, it could be a search, it could be to replace one piece of data
with another - there's many many possibilities.
It's like cooking a meal, you could know the recipe by heart, you could have all the
pots and pans and knives and ovens, and you could have all the ingredients ready to go,
but the function is the act of actually engaging with this knowledge and the tools and
ingredients (the data), and activating or changing them in whatever way necessary.


| Class | Parent | Description |
|---|---|---|
{{ item.class }} |
{{ item.applies }} |
{{ item.description }} |
Post summaries are a flexible component capable of previewing various content types—questions or articles. Post summaries are meant to be flexible, allowing for each individual piece to be removed. Let’s start with a full example of a few questions and an article interleaved.
{% header "h3", "Full" %}At their most complete, post summaries are presented in two columns and can contain:
At the smallest breakpoint, the layout will switch to a single column.
In the spirit of type safety associated with the CriteriaQuery JPA 2.0 also has an API to support Metamodel representation of entities.
{% icon "EllipsisVertical" %}I am creating my first react-native app. I am attempting to install the react-native command line interface as shown here. I keep getting an error when I type the command to initiate the react-native command line
{% icon "EllipsisVertical" %}This article aims to guide you through the steps and processes you may want to consider when running research at Stack Overflow. While there are obviously many methods, this guide will focus more interview-style research. For a full list of Product Research templates, guides, and links, see this article.
{% icon "EllipsisVertical" %}I’m trying to implement DDD approach in my project but realized that I have too big aggregates and trying to minimize the amount of data loaded from the database. I have an aggregate Order which
{% icon "EllipsisVertical" %}There are compact views where it’s appropriate to reduce the amount of information within the post summary. The minimal view forces the smallest breakpoint layout in any context, stacking the meta data on top and putting everything into a single column.
Within the stats section of the post summary, posts can have various answered states. A checkmark icon is displayed in questions that have accepted answers.
Post stats also have various states of hotness and display in corresponding shades of orange. A fire icon is added in the supernova level of popularity.


The biggest weakness with login systems used to be that if you leaked your password anyone could log into your account. Some sites added 2 factor authentication to combat this, only making their sites more clunky to use. With NewPwd, you have a different password for each device making leaking your password a non-issue!
Each time you attempt to log-in from a new device a new password will be automatically generated for you. This password only works on that device, so if someone steals your password but not your device it will be useless to them!
Every time you try to log-in you will need to complete a CAPTCHA to protect against automated bots. We here at NewPwd have a zero tolerance policy against incorrectly completed captchas, and will block all log-in attempts from devices which have sent an incorrect captcha in the past, blocking away brute forcing bots entierly!


Flecther
meme
learn about me
hi im kool that all you need to know boi
me skills
this is me skills
html
css
meme
drop me a dope line
bookface