- NAME
- tcltest - Test harness support code and utilities
- SYNOPSIS
- package require tcltest ?2.2.5?
- tcltest::test name description ?option value ...?
- tcltest::test name description ?constraints? body result
- tcltest::loadTestedCommands
- tcltest::makeDirectory name ?directory?
- tcltest::removeDirectory name ?directory?
- tcltest::makeFile contents name ?directory?
- tcltest::removeFile name ?directory?
- tcltest::viewFile name ?directory?
- tcltest::cleanupTests ?runningMultipleTests?
- tcltest::runAllTests
- tcltest::configure
- tcltest::configure option
- tcltest::configure option value ?option value ...?
- tcltest::customMatch mode command
- tcltest::testConstraint constraint ?value?
- tcltest::outputChannel ?channelID?
- tcltest::errorChannel ?channelID?
- tcltest::interpreter ?interp?
- tcltest::debug ?level?
- tcltest::errorFile ?filename?
- tcltest::limitConstraints ?boolean?
- tcltest::loadFile ?filename?
- tcltest::loadScript ?script?
- tcltest::match ?patternList?
- tcltest::matchDirectories ?patternList?
- tcltest::matchFiles ?patternList?
- tcltest::outputFile ?filename?
- tcltest::preserveCore ?level?
- tcltest::singleProcess ?boolean?
- tcltest::skip ?patternList?
- tcltest::skipDirectories ?patternList?
- tcltest::skipFiles ?patternList?
- tcltest::temporaryDirectory ?directory?
- tcltest::testsDirectory ?directory?
- tcltest::verbose ?level?
- tcltest::test name description optionList
- tcltest::bytestring string
- tcltest::normalizeMsg msg
- tcltest::normalizePath pathVar
- tcltest::workingDirectory ?dir?
- DESCRIPTION
- COMMANDS
- test name description ?option value ...?
- test name description ?constraints? body result
- loadTestedCommands
- makeFile contents name ?directory?
- removeFile name ?directory?
- makeDirectory name ?directory?
- removeDirectory name ?directory?
- viewFile file ?directory?
- cleanupTests
- runAllTests
- CONFIGURATION COMMANDS
- configure
- configure option
- configure option value ?option value ...?
- customMatch mode script
- testConstraint constraint ?boolean?
- interpreter ?executableName?
- outputChannel ?channelID?
- errorChannel ?channelID?
- SHORTCUT COMMANDS
- debug ?level?
- errorFile ?filename?
- limitConstraints ?boolean?
- loadFile ?filename?
- loadScript ?script?
- match ?patternList?
- matchDirectories ?patternList?
- matchFiles ?patternList?
- outputFile ?filename?
- preserveCore ?level?
- singleProcess ?boolean?
- skip ?patternList?
- skipDirectories ?patternList?
- skipFiles ?patternList?
- temporaryDirectory ?directory?
- testsDirectory ?directory?
- verbose ?level?
- OTHER COMMANDS
- test name description optionList
- workingDirectory ?directoryName?
- normalizeMsg msg
- normalizePath pathVar
- bytestring string
- TESTS
- -constraints keywordList|expression
- -setup script
- -body script
- -cleanup script
- -match mode
- -result expectedValue
- -output expectedValue
- -errorOutput expectedValue
- -returnCodes expectedCodeList
- TEST CONSTRAINTS
- singleTestInterp
- unix
- win
- nt
- 95
- 98
- mac
- unixOrWin
- macOrWin
- macOrUnix
- tempNotWin
- tempNotMac
- unixCrash
- winCrash
- macCrash
- emptyTest
- knownBug
- nonPortable
- userInteraction
- interactive
- nonBlockFiles
- asyncPipeClose
- unixExecs
- hasIsoLocale
- root
- notRoot
- eformat
- stdio
- RUNNING ALL TESTS
- CONFIGURABLE OPTIONS
- -singleproc boolean
- -debug level
- 0
- 1
- 2
- 3
- -verbose level
- body (b)
- pass (p)
- skip (s)
- start (t)
- error (e)
- -preservecore level
- 0
- 1
- 2
- -limitconstraints boolean
- -constraints list
- -tmpdir directory
- -testdir directory
- -file patternList
- -notfile patternList
- -relateddir patternList
- -asidefromdir patternList
- -match patternList
- -skip patternList
- -load script
- -loadfile filename
- -outfile filename
- -errfile filename
- CREATING TEST SUITES WITH TCLTEST
- COMPATIBILITY
- KNOWN ISSUES
- KEYWORDS
tcltest - Test harness support code and utilities
package require tcltest ?2.2.5?
tcltest::test name description ?option value ...?
tcltest::test name description ?constraints? body result
tcltest::loadTestedCommands
tcltest::makeDirectory name ?directory?
tcltest::removeDirectory name ?directory?
tcltest::makeFile contents name ?directory?
tcltest::removeFile name ?directory?
tcltest::viewFile name ?directory?
tcltest::cleanupTests ?runningMultipleTests?
tcltest::runAllTests
tcltest::configure
tcltest::configure option
tcltest::configure option value ?option value ...?
tcltest::customMatch mode command
tcltest::testConstraint constraint ?value?
tcltest::outputChannel ?channelID?
tcltest::errorChannel ?channelID?
tcltest::interpreter ?interp?
tcltest::debug ?level?
tcltest::errorFile ?filename?
tcltest::limitConstraints ?boolean?
tcltest::loadFile ?filename?
tcltest::loadScript ?script?
tcltest::match ?patternList?
tcltest::matchDirectories ?patternList?
tcltest::matchFiles ?patternList?
tcltest::outputFile ?filename?
tcltest::preserveCore ?level?
tcltest::singleProcess ?boolean?
tcltest::skip ?patternList?
tcltest::skipDirectories ?patternList?
tcltest::skipFiles ?patternList?
tcltest::temporaryDirectory ?directory?
tcltest::testsDirectory ?directory?
tcltest::verbose ?level?
tcltest::test name description optionList
tcltest::bytestring string
tcltest::normalizeMsg msg
tcltest::normalizePath pathVar
tcltest::workingDirectory ?dir?
The tcltest package provides several utility commands useful
in the construction of test suites for code instrumented to be
run by evaluation of Tcl commands. Notably the built-in commands
of the Tcl library itself are tested by a test suite using the
tcltest package.
All the commands provided by the tcltest package are defined
in and exported from the ::tcltest namespace, as indicated in
the SYNOPSIS above. In the following sections, all commands
will be described by their simple names, in the interest of brevity.
The central command of tcltest is [test] that defines
and runs a test. Testing with [test] involves evaluation
of a Tcl script and comparing the result to an expected result, as
configured and controlled by a number of options. Several other
commands provided by tcltest govern the configuration of
[test] and the collection of many [test] commands into
test suites.
See CREATING TEST SUITES WITH TCLTEST below for an extended example
of how to use the commands of tcltest to produce test suites
for your Tcl-enabled code.
- test name description ?option value ...?
-
Defines and possibly runs a test with the name name and
description description. The name and description of a test
are used in messages reported by [test] during the
test, as configured by the options of tcltest. The
remaining option value arguments to [test]
define the test, including the scripts to run, the conditions
under which to run them, the expected result, and the means
by which the expected and actual results should be compared.
See TESTS below for a complete description of the valid
options and how they define a test. The [test] command
returns an empty string.
- test name description ?constraints? body result
-
This form of [test] is provided to support test suites written
for version 1 of the tcltest package, and also a simpler
interface for a common usage. It is the same as
[test name description -constraints constraints -body
body -result result]. All other options to [test]
take their default values. When constraints is omitted, this
form of [test] can be distinguished from the first because
all options begin with ``-''.
- loadTestedCommands
-
Evaluates in the caller's context the script specified by
[configure -load] or [configure -loadfile].
Returns the result of that script evaluation, including any error
raised by the script. Use this command and the related
configuration options to provide the commands to be tested to
the interpreter running the test suite.
- makeFile contents name ?directory?
-
Creates a file named name relative to
directory directory and write contents
to that file using the encoding [encoding system].
If contents does not end with a newline, a newline
will be appended so that the file named name
does end with a newline. Because the system encoding is used,
this command is only suitable for making text files.
The file will be removed by the next evaluation
of [cleanupTests], unless it is removed by
[removeFile] first. The default value of
directory is the directory [configure -tmpdir].
Returns the full path of the file created. Use this command
to create any text file required by a test with contents as needed.
- removeFile name ?directory?
-
Forces the file referenced by name to be removed. This file name
should be relative to directory. The default value of
directory is the directory [configure -tmpdir].
Returns an empty string. Use this command to delete files
created by [makeFile].
- makeDirectory name ?directory?
-
Creates a directory named name relative to directory directory.
The directory will be removed by the next evaluation of [cleanupTests],
unless it is removed by [removeDirectory] first.
The default value of directory is the directory
[configure -tmpdir].
Returns the full path of the directory created. Use this command
to create any directories that are required to exist by a test.
- removeDirectory name ?directory?
-
Forces the directory referenced by name to be removed. This
directory should be relative to directory.
The default value of directory is the directory
[configure -tmpdir].
Returns an empty string. Use this command to delete any directories
created by [makeDirectory].
- viewFile file ?directory?
-
Returns the contents of file, except for any
final newline, just as [read -nonewline] would return.
This file name should be relative to directory.
The default value of directory is the directory
[configure -tmpdir]. Use this command
as a convenient way to turn the contents of a file generated
by a test into the result of that test for matching against
an expected result. The contents of the file are read using
the system encoding, so its usefulness is limited to text
files.
- cleanupTests
-
Intended to clean up and summarize after several tests have been
run. Typically called once per test file, at the end of the file
after all tests have been completed. For best effectiveness, be
sure that the [cleanupTests] is evaluated even if an error
occurs earlier in the test file evaluation.
Prints statistics about the tests run and removes files that were
created by [makeDirectory] and [makeFile] since the
last [cleanupTests]. Names of files and directories
in the directory [configure -tmpdir] created since
the last [cleanupTests], but not created by
[makeFile] or [makeDirectory] are printed
to [outputChannel]. This command also restores the original
shell environment, as described by the ::env
array. Returns an empty string.
- runAllTests
-
This is a master command meant to run an entire suite of tests,
spanning multiple files and/or directories, as governed by
the configurable options of tcltest. See RUNNING ALL TESTS
below for a complete description of the many variations possible
with [runAllTests].
- configure
-
Returns the list of configurable options supported by tcltest.
See CONFIGURABLE OPTIONS below for the full list of options,
their valid values, and their effect on tcltest operations.
- configure option
-
Returns the current value of the supported configurable option option.
Raises an error if option is not a supported configurable option.
- configure option value ?option value ...?
-
Sets the value of each configurable option option to the
corresponding value value, in order. Raises an error if
an option is not a supported configurable option, or if
value is not a valid value for the corresponding option,
or if a value is not provided. When an error is raised, the
operation of [configure] is halted, and subsequent option value
arguments are not processed.
If the environment variable ::env(TCLTEST_OPTIONS) exists when
the tcltest package is loaded (by [package require tcltest])
then its value is taken as a list of arguments to pass to [configure].
This allows the default values of the configuration options to be
set by the environment.
- customMatch mode script
-
Registers mode as a new legal value of the -match option
to [test]. When the -match mode option is
passed to [test], the script script will be evaluated
to compare the actual result of evaluating the body of the test
to the expected result.
To perform the match, the script is completed with two additional
words, the expected result, and the actual result, and the completed script
is evaluated in the global namespace.
The completed script is expected to return a boolean value indicating
whether or not the results match. The built-in matching modes of
[test] are exact, glob, and regexp.
- testConstraint constraint ?boolean?
-
Sets or returns the boolean value associated with the named constraint.
See TEST CONSTRAINTS below for more information.
- interpreter ?executableName?
-
Sets or returns the name of the executable to be [exec]ed by
[runAllTests] to run each test file when
[configure -singleproc] is false.
The default value for [interpreter] is the name of the
currently running program as returned by [info nameofexecutable].
- outputChannel ?channelID?
-
Sets or returns the output channel ID. This defaults to stdout.
Any test that prints test related output should send
that output to [outputChannel] rather than letting
that output default to stdout.
- errorChannel ?channelID?
-
Sets or returns the error channel ID. This defaults to stderr.
Any test that prints error messages should send
that output to [errorChannel] rather than printing
directly to stderr.
- debug ?level?
-
Same as [configure -debug ?level?].
- errorFile ?filename?
-
Same as [configure -errfile ?filename?].
- limitConstraints ?boolean?
-
Same as [configure -limitconstraints ?boolean?].
- loadFile ?filename?
-
Same as [configure -loadfile ?filename?].
- loadScript ?script?
-
Same as [configure -load ?script?].
- match ?patternList?
-
Same as [configure -match ?patternList?].
- matchDirectories ?patternList?
-
Same as [configure -relateddir ?patternList?].
- matchFiles ?patternList?
-
Same as [configure -file ?patternList?].
- outputFile ?filename?
-
Same as [configure -outfile ?filename?].
- preserveCore ?level?
-
Same as [configure -preservecore ?level?].
- singleProcess ?boolean?
-
Same as [configure -singleproc ?boolean?].
- skip ?patternList?
-
Same as [configure -skip ?patternList?].
- skipDirectories ?patternList?
-
Same as [configure -asidefromdir ?patternList?].
- skipFiles ?patternList?
-
Same as [configure -notfile ?patternList?].
- temporaryDirectory ?directory?
-
Same as [configure -tmpdir ?directory?].
- testsDirectory ?directory?
-
Same as [configure -testdir ?directory?].
- verbose ?level?
-
Same as [configure -verbose ?level?].
The remaining commands provided by tcltest have better
alternatives provided by tcltest or Tcl itself. They
are retained to support existing test suites, but should be avoided
in new code.
- test name description optionList
-
This form of [test] was provided to enable passing many
options spanning several lines to [test] as a single
argument quoted by braces, rather than needing to backslash quote
the newlines between arguments to [test]. The optionList
argument is expected to be a list with an even number of elements
representing option and value arguments to pass
to [test]. However, these values are not passed directly, as
in the alternate forms of [switch]. Instead, this form makes
an unfortunate attempt to overthrow Tcl's substitution rules by
performing substitutions on some of the list elements as an attempt to
implement a ``do what I mean'' interpretation of a brace-enclosed
``block''. The result is nearly impossible to document clearly, and
for that reason this form is not recommended. See the examples in
CREATING TEST SUITES WITH TCLTEST below to see that this
form is really not necessary to avoid backslash-quoted newlines.
If you insist on using this form, examine
the source code of tcltest if you want to know the substitution
details, or just enclose the third through last argument
to [test] in braces and hope for the best.
- workingDirectory ?directoryName?
-
Sets or returns the current working directory when the test suite is
running. The default value for workingDirectory is the directory in
which the test suite was launched. The Tcl commands [cd] and
[pwd] are sufficient replacements.
- normalizeMsg msg
-
Returns the result of removing the ``extra'' newlines from msg,
where ``extra'' is rather imprecise. Tcl offers plenty of string
processing commands to modify strings as you wish, and
[customMatch] allows flexible matching of actual and expected
results.
- normalizePath pathVar
-
Resolves symlinks in a path, thus creating a path without internal
redirection. It is assumed that pathVar is absolute.
pathVar is modified in place. The Tcl command [file normalize]
is a sufficient replacement.
- bytestring string
-
Construct a string that consists of the requested sequence of bytes,
as opposed to a string of properly formed UTF-8 characters using the
value supplied in string. This allows the tester to create
denormalized or improperly formed strings to pass to C procedures that
are supposed to accept strings with embedded NULL types and confirm
that a string result has a certain pattern of bytes. This is
exactly equivalent to the Tcl command [encoding convertfrom identity].
The [test] command is the heart of the tcltest package.
Its essential function is to evaluate a Tcl script and compare
the result with an expected result. The options of [test]
define the test script, the environment in which to evaluate it,
the expected result, and how the compare the actual result to
the expected result. Some configuration options of tcltest
also influence how [test] operates.
The valid options for [test] are summarized:
test name description
?-constraints keywordList|expression?
?-setup setupScript?
?-body testScript?
?-cleanup cleanupScript?
?-result expectedAnswer?
?-output expectedOutput?
?-errorOutput expectedError?
?-returnCodes codeList?
?-match mode?
The name may be any string. It is conventional to choose
a name according to the pattern:
target-majorNum.minorNum
For white-box (regression) tests, the target should be the name of the
C function or Tcl procedure being tested. For black-box tests, the
target should be the name of the feature being tested. Some conventions
call for the names of black-box tests to have the suffix _bb.
Related tests should share a major number. As a test suite evolves,
it is best to have the same test name continue to correspond to the
same test, so that it remains meaningful to say things like ``Test
foo-1.3 passed in all releases up to 3.4, but began failing in
release 3.5.''
During evaluation of [test], the name will be compared
to the lists of string matching patterns returned by
[configure -match], and [configure -skip]. The test
will be run only if name matches any of the patterns from
[configure -match] and matches none of the patterns
from [configure -skip].
The description should be a short textual description of the
test. The description is included in output produced by the
test, typically test failure messages. Good description values
should briefly explain the purpose of the test to users of a test suite.
The name of a Tcl or C function being tested should be included in the
description for regression tests. If the test case exists to reproduce
a bug, include the bug ID in the description.
Valid attributes and associated values are:
- -constraints keywordList|expression
-
The optional -constraints attribute can be list of one or more
keywords or an expression. If the -constraints value is a list of
keywords, each of these keywords should be the name of a constraint
defined by a call to [testConstraint]. If any of the listed
constraints is false or does not exist, the test is skipped. If the
-constraints value is an expression, that expression
is evaluated. If the expression evaluates to true, then the test is run.
Note that the expression form of -constraints may interfere with the
operation of [configure -constraints] and
[configure -limitconstraints], and is not recommended.
Appropriate constraints should be added to any tests that should
not always be run. That is, conditional evaluation of a test
should be accomplished by the -constraints option, not by
conditional evaluation of [test]. In that way, the same
number of tests are always reported by the test suite, though
the number skipped may change based on the testing environment.
The default value is an empty list.
See TEST CONSTRAINTS below for a list of built-in constraints
and information on how to add your own constraints.
- -setup script
-
The optional -setup attribute indicates a script that will be run
before the script indicated by the -body attribute. If evaluation
of script raises an error, the test will fail. The default value
is an empty script.
- -body script
-
The -body attribute indicates the script to run to carry out the
test. It must return a result that can be checked for correctness.
If evaluation of script raises an error, the test will fail.
The default value is an empty script.
- -cleanup script
-
The optional -cleanup attribute indicates a script that will be
run after the script indicated by the -body attribute.
If evaluation of script raises an error, the test will fail.
The default value is an empty script.
- -match mode
-
The -match attribute determines how expected answers supplied by
-result, -output, and -errorOutput are compared. Valid
values for mode are regexp, glob, exact, and
any value registered by a prior call to [customMatch]. The default
value is exact.
- -result expectedValue
-
The -result attribute supplies the expectedValue against which
the return value from script will be compared. The default value is
an empty string.
- -output expectedValue
-
The -output attribute supplies the expectedValue against which
any output sent to stdout or [outputChannel] during evaluation
of the script(s) will be compared. Note that only output printed using
[::puts] is used for comparison. If -output is not specified,
output sent to stdout and [outputChannel] is not processed for
comparison.
- -errorOutput expectedValue
-
The -errorOutput attribute supplies the expectedValue against
which any output sent to stderr or [errorChannel] during
evaluation of the script(s) will be compared. Note that only output
printed using [::puts] is used for comparison. If -errorOutput
is not specified, output sent to stderr and [errorChannel] is
not processed for comparison.
- -returnCodes expectedCodeList
-
The optional -returnCodes attribute supplies expectedCodeList,
a list of return codes that may be accepted from evaluation of the
-body script. If evaluation of the -body script returns
a code not in the expectedCodeList, the test fails. All
return codes known to [return], in both numeric and symbolic
form, including extended return codes, are acceptable elements in
the expectedCodeList. Default value is {ok return}.
To pass, a test must successfully evaluate its -setup, -body,
and -cleanup scripts. The return code of the -body script and
its result must match expected values, and if specified, output and error
data from the test must match expected -output and -errorOutput
values. If any of these conditions are not met, then the test fails.
Note that all scripts are evaluated in the context of the caller
of [test].
As long as [test] is called with valid syntax and legal
values for all attributes, it will not raise an error. Test
failures are instead reported as output written to [outputChannel].
In default operation, a successful test produces no output. The output
messages produced by [test] are controlled by the
[configure -verbose] option as described in CONFIGURABLE OPTIONS
below. Any output produced by the test scripts themselves should be
produced using [::puts] to [outputChannel] or
[errorChannel], so that users of the test suite may
easily capture output with the [configure -outfile] and
[configure -errfile] options, and so that the -output
and -errorOutput attributes work properly.
Constraints are used to determine whether or not a test should be skipped.
Each constraint has a name, which may be any string, and a boolean
value. Each [test] has a -constraints value which is a
list of constraint names. There are two modes of constraint control.
Most frequently, the default mode is used, indicated by a setting
of [configure -limitconstraints] to false. The test will run
only if all constraints in the list are true-valued. Thus,
the -constraints option of [test] is a convenient, symbolic
way to define any conditions required for the test to be possible or
meaningful. For example, a [test] with -constraints unix
will only be run if the constraint unix is true, which indicates
the test suite is being run on a Unix platform.
Each [test] should include whatever -constraints are
required to constrain it to run only where appropriate. Several
constraints are pre-defined in the tcltest package, listed
below. The registration of user-defined constraints is performed
by the [testConstraint] command. User-defined constraints
may appear within a test file, or within the script specified
by the [configure -load] or [configure -loadfile]
options.
The following is a list of constraints pre-defined by the
tcltest package itself:
- singleTestInterp
-
test can only be run if all test files are sourced into a single interpreter
- unix
-
test can only be run on any Unix platform
- win
-
test can only be run on any Windows platform
- nt
-
test can only be run on any Windows NT platform
- 95
-
test can only be run on any Windows 95 platform
- 98
-
test can only be run on any Windows 98 platform
- mac
-
test can only be run on any Mac platform
- unixOrWin
-
test can only be run on a Unix or Windows platform
- macOrWin
-
test can only be run on a Mac or Windows platform
- macOrUnix
-
test can only be run on a Mac or Unix platform
- tempNotWin
-
test can not be run on Windows. This flag is used to temporarily
disable a test.
- tempNotMac
-
test can not be run on a Mac. This flag is used
to temporarily disable a test.
- unixCrash
-
test crashes if it's run on Unix. This flag is used to temporarily
disable a test.
- winCrash
-
test crashes if it's run on Windows. This flag is used to temporarily
disable a test.
- macCrash
-
test crashes if it's run on a Mac. This flag is used to temporarily
disable a test.
- emptyTest
-
test is empty, and so not worth running, but it remains as a
place-holder for a test to be written in the future. This constraint
has value false to cause tests to be skipped unless the user specifies
otherwise.
- knownBug
-
test is known to fail and the bug is not yet fixed. This constraint
has value false to cause tests to be skipped unless the user specifies
otherwise.
- nonPortable
-
test can only be run in some known development environment.
Some tests are inherently non-portable because they depend on things
like word length, file system configuration, window manager, etc.
This constraint has value false to cause tests to be skipped unless
the user specifies otherwise.
- userInteraction
-
test requires interaction from the user. This constraint has
value false to causes tests to be skipped unless the user specifies
otherwise.
- interactive
-
test can only be run in if the interpreter is in interactive mode
(when the global tcl_interactive variable is set to 1).
- nonBlockFiles
-
test can only be run if platform supports setting files into
nonblocking mode
- asyncPipeClose
-
test can only be run if platform supports async flush and async close
on a pipe
- unixExecs
-
test can only be run if this machine has Unix-style commands
cat, echo, sh, wc, rm, sleep,
fgrep, ps, chmod, and mkdir available
- hasIsoLocale
-
test can only be run if can switch to an ISO locale
- root
-
test can only run if Unix user is root
- notRoot
-
test can only run if Unix user is not root
- eformat
-
test can only run if app has a working version of sprintf with respect
to the "e" format of floating-point numbers.
- stdio
-
test can only be run if [interpreter] can be [open]ed
as a pipe.
The alternative mode of constraint control is enabled by setting
[configure -limitconstraints] to true. With that configuration
setting, all existing constraints other than those in the constraint
list returned by [configure -constraints] are set to false.
When the value of [configure -constraints]
is set, all those constraints are set to true. The effect is that
when both options [configure -constraints] and
[configure -limitconstraints] are in use, only those tests including
only constraints from the [configure -constraints] list
are run; all others are skipped. For example, one might set
up a configuration with
configure -constraints knownBug \
-limitconstraints true \
-verbose pass
to run exactly those tests that exercise known bugs, and discover
whether any of them pass, indicating the bug had been fixed.
The single command [runAllTests] is evaluated to run an entire
test suite, spanning many files and directories. The configuration
options of tcltest control the precise operations. The
[runAllTests] command begins by printing a summary of its
configuration to [outputChannel].
Test files to be evaluated are sought in the directory
[configure -testdir]. The list of files in that directory
that match any of the patterns in [configure -file] and
match none of the patterns in [configure -notfile] is generated
and sorted. Then each file will be evaluated in turn. If
[configure -singleproc] is true, then each file will
be [source]d in the caller's context. If it is false,
then a copy of [interpreter] will be [exec]d to
evaluate each file. The multi-process operation is useful
when testing can cause errors so severe that a process
terminates. Although such an error may terminate a child
process evaluating one file, the master process can continue
with the rest of the test suite. In multi-process operation,
the configuration of tcltest in the master process is
passed to the child processes as command line arguments,
with the exception of [configure -outfile]. The
[runAllTests] command in the
master process collects all output from the child processes
and collates their results into one master report. Any
reports of individual test failures, or messages requested
by a [configure -verbose] setting are passed directly
on to [outputChannel] by the master process.
After evaluating all selected test files, a summary of the
results is printed to [outputChannel]. The summary
includes the total number of [test]s evaluated, broken
down into those skipped, those passed, and those failed.
The summary also notes the number of files evaluated, and the names
of any files with failing tests or errors. A list of
the constraints that caused tests to be skipped, and the
number of tests skipped for each is also printed. Also,
messages are printed if it appears that evaluation of
a test file has caused any temporary files to be left
behind in [configure -tmpdir].
Having completed and summarized all selected test files,
[runAllTests] then recursively acts on subdirectories
of [configure -testdir]. All subdirectories that
match any of the patterns in [configure -relateddir]
and do not match any of the patterns in
[configure -asidefromdir] are examined. If
a file named all.tcl is found in such a directory,
it will be [source]d in the caller's context.
Whether or not an examined directory contains an
all.tcl file, its subdirectories are also scanned
against the [configure -relateddir] and
[configure -asidefromdir] patterns. In this way,
many directories in a directory tree can have all their
test files evaluated by a single [runAllTests]
command.
The [configure] command is used to set and query the configurable
options of tcltest. The valid options are:
- -singleproc boolean
-
Controls whether or not [runAllTests] spawns a child process for
each test file. No spawning when boolean is true. Default
value is false.
- -debug level
-
Sets the debug level to level, an integer value indicating how
much debugging information should be printed to stdout. Note that
debug messages always go to stdout, independent of the value of
[configure -outfile]. Default value is 0. Levels are defined as:
- 0
-
Do not display any debug information.
- 1
-
Display information regarding whether a test is skipped because it
doesn't match any of the tests that were specified using by
[configure -match] (userSpecifiedNonMatch) or matches any of
the tests specified by [configure -skip] (userSpecifiedSkip). Also
print warnings about possible lack of cleanup or balance in test files.
Also print warnings about any re-use of test names.
- 2
-
Display the flag array parsed by the command line processor, the
contents of the ::env array, and all user-defined variables that exist
in the current namespace as they are used.
- 3
-
Display information regarding what individual procs in the test
harness are doing.
- -verbose level
-
Sets the type of output verbosity desired to level,
a list of zero or more of the elements body, pass,
skip, start, and error. Default value
is {body error}.
Levels are defined as:
- body (b)
-
Display the body of failed tests
- pass (p)
-
Print output when a test passes
- skip (s)
-
Print output when a test is skipped
- start (t)
-
Print output whenever a test starts
- error (e)
-
Print errorInfo and errorCode, if they exist, when a test return code
does not match its expected return code
The single letter abbreviations noted above are also recognized
so that [configure -verbose pt] is the same as
[configure -verbose {pass start}].
- -preservecore level
-
Sets the core preservation level to level. This level
determines how stringent checks for core files are. Default
value is 0. Levels are defined as:
- 0
-
No checking - do not check for core files at the end of each test
command, but do check for them in [runAllTests] after all
test files have been evaluated.
- 1
-
Also check for core files at the end of each [test] command.
- 2
-
Check for core files at all times described above, and save a
copy of each core file produced in [configure -tmpdir].
- -limitconstraints boolean
-
Sets the mode by which [test] honors constraints as described
in TESTS above. Default value is false.
- -constraints list
-
Sets all the constraints in list to true. Also used in
combination with [configure -limitconstraints true] to control an
alternative constraint mode as described in TESTS above.
Default value is an empty list.
- -tmpdir directory
-
Sets the temporary directory to be used by [makeFile],
[makeDirectory], [viewFile], [removeFile],
and [removeDirectory] as the default directory where
temporary files and directories created by test files should
be created. Default value is [workingDirectory].
- -testdir directory
-
Sets the directory searched by [runAllTests] for test files
and subdirectories. Default value is [workingDirectory].
- -file patternList
-
Sets the list of patterns used by [runAllTests] to determine
what test files to evaluate. Default value is *.test.
- -notfile patternList
-
Sets the list of patterns used by [runAllTests] to determine
what test files to skip. Default value is l.*.test, so
that any SCCS lock files are skipped.
- -relateddir patternList
-
Sets the list of patterns used by [runAllTests] to determine
what subdirectories to search for an all.tcl file. Default
value is *.
- -asidefromdir patternList
-
Sets the list of patterns used by [runAllTests] to determine
what subdirectories to skip when searching for an all.tcl file.
Default value is an empty list.
- -match patternList
-
Set the list of patterns used by [test] to determine whether
a test should be run. Default value is *.
- -skip patternList
-
Set the list of patterns used by [test] to determine whether
a test should be skipped. Default value is an empty list.
- -load script
-
Sets a script to be evaluated by [loadTestedCommands].
Default value is an empty script.
- -loadfile filename
-
Sets the filename from which to read a script to be evaluated
by [loadTestedCommands]. This is an alternative to
-load. They cannot be used together.
- -outfile filename
-
Sets the file to which all output produced by tcltest should be
written. A file named filename will be [open]ed for writing,
and the resulting channel will be set as the value of [outputChannel].
- -errfile filename
-
Sets the file to which all error output produced by tcltest
should be written. A file named filename will be [open]ed
for writing, and the resulting channel will be set as the value
of [errorChannel].
The fundamental element of a test suite is the individual [test]
command. We begin with several examples.
- [1]
-
Test of a script that returns normally.
test example-1.0 {normal return} {
format %s value
} value
- [2]
-
Test of a script that requires context setup and cleanup. Note the
bracing and indenting style that avoids any need for line continuation.
test example-1.1 {test file existence} -setup {
set file [makeFile {} test]
} -body {
file exists $file
} -cleanup {
removeFile test
} -result 1
- [3]
-
Test of a script that raises an error.
test example-1.2 {error return} -body {
error message
} -returnCodes error -result message
- [4]
-
Test with a constraint.
test example-1.3 {user owns created files} -constraints {
unix
} -setup {
set file [makeFile {} test]
} -body {
file attributes $file -owner
} -cleanup {
removeFile test
} -result $::tcl_platform(user)
At the next higher layer of organization, several [test] commands
are gathered together into a single test file. Test files should have
names with the .test extension, because that is the default pattern
used by [runAllTests] to find test files. It is a good rule of
thumb to have one test file for each source code file of your project.
It is good practice to edit the test file and the source code file
together, keeping tests synchronized with code changes.
Most of the code in the test file should be the [test] commands.
Use constraints to skip tests, rather than conditional evaluation
of [test]. That is, do this:
- [5]
-
testConstraint X [expr $myRequirement]
test goodConditionalTest {} X {
# body
} result
and do not do this:
- [6]
-
if $myRequirement {
test badConditionalTest {} {
#body
} result
}
Use the -setup and -cleanup options to establish and release
all context requirements of the test body. Do not make tests depend on
prior tests in the file. Those prior tests might be skipped. If several
consecutive tests require the same context, the appropriate setup
and cleanup scripts may be stored in variable for passing to each tests
-setup and -cleanup options. This is a better solution than
performing setup outside of [test] commands, because the setup will
only be done if necessary, and any errors during setup will be reported,
and not cause the test file to abort.
A test file should be able to be combined with other test files and not
interfere with them, even when [configure -singleproc 1] causes
all files to be evaluated in a common interpreter. A simple way to
achieve this is to have your tests define all their commands and variables
in a namespace that is deleted when the test file evaluation is complete.
A good namespace to use is a child namespace test of the namespace
of the module you are testing.
A test file should also be able to be evaluated directly as a script,
not depending on being called by a master [runAllTests]. This
means that each test file should process command line arguments to give
the tester all the configuration control that tcltest provides.
After all [test]s in a test file, the command [cleanupTests]
should be called.
- [7]
-
Here is a sketch of a sample test file illustrating those points:
package require tcltest 2.2
eval ::tcltest::configure $argv
package require example
namespace eval ::example::test {
namespace import ::tcltest::*
testConstraint X [expr {...}]
variable SETUP {#common setup code}
variable CLEANUP {#common cleanup code}
test example-1 {} -setup $SETUP -body {
# First test
} -cleanup $CLEANUP -result {...}
test example-2 {} -constraints X -setup $SETUP -body {
# Second test; constrained
} -cleanup $CLEANUP -result {...}
test example-3 {} {
# Third test; no context required
} {...}
cleanupTests
}
namespace delete ::example::test
The next level of organization is a full test suite, made up of several
test files. One script is used to control the entire suite. The
basic function of this script is to call [runAllTests] after
doing any necessary setup. This script is usually named all.tcl
because that's the default name used by [runAllTests] when combining
multiple test suites into one testing run.
- [8]
-
Here is a sketch of a sample test suite master script:
package require Tcl 8.4
package require tcltest 2.2
package require example
::tcltest::configure -testdir
[file dirname [file normalize [info script]]]
eval ::tcltest::configure $argv
::tcltest::runAllTests
A number of commands and variables in the ::tcltest namespace
provided by earlier releases of tcltest have not been documented
here. They are no longer part of the supported public interface of
tcltest and should not be used in new test suites. However,
to continue to support existing test suites written to the older
interface specifications, many of those deprecated commands and
variables still work as before. For example, in many circumstances,
[configure] will be automatically called shortly after
[package require tcltest 2.1] succeeds with arguments
from the variable ::argv. This is to support test suites
that depend on the old behavior that tcltest was automatically
configured from command line arguments. New test files should not
depend on this, but should explicitly include
eval ::tcltest::configure $::argv
to establish a configuration from command line arguments.
There are two known issues related to nested evaluations of [test].
The first issue relates to the stack level in which test scripts are
executed. Tests nested within other tests may be executed at the same
stack level as the outermost test. For example, in the following code:
test level-1.1 {level 1} {
-body {
test level-2.1 {level 2} {
}
}
}
any script executed in level-2.1 may be executed at the same stack
level as the script defined for level-1.1.
In addition, while two [test]s have been run, results will only
be reported by [cleanupTests] for tests at the same level as
test level-1.1. However, test results for all tests run prior to
level-1.1 will be available when test level-2.1 runs. What this
means is that if you try to access the test results for test level-2.1,
it will may say that 'm' tests have run, 'n' tests have
been skipped, 'o' tests have passed and 'p' tests have failed,
where 'm', 'n', 'o', and 'p' refer to tests that were run at the
same test level as test level-1.1.
Implementation of output and error comparison in the test command
depends on usage of ::puts in your application code. Output is
intercepted by redefining the ::puts command while the defined test
script is being run. Errors thrown by C procedures or printed
directly from C applications will not be caught by the test command.
Therefore, usage of the -output and -errorOutput
options to [test] is useful only for pure Tcl applications
that use [::puts] to produce output.
test, test harness, test suite
Copyright © 1990-1994 The Regents of the University of California
Copyright © 1994-1997 Sun Microsystems, Inc.
Copyright © 1998-1999 Scriptics Corporation
Copyright © 2000 Ajuba Solutions
Copyright © 1995-1997 Roger E. Critchlow Jr.


Real Madrid vs Paris Saint-Germain: Where to Watch, Live Stream, Kick Off Time & Team News
by Ewan MurrayReal Madrid host Paris Saint-Germain on Tuesday evening seeking revenge for the 3-0 humiliation they suffered at the Parc des Princes in September.
Madrid know a victory would secure a place in the next round of the Champions League, while they will also look to right the wrongs of the reverse fixture in which the Spanish giants were torn apart.
Meanwhile, PSG have already qualified but if they were to earn a point or more at the Bernabeu, they would guarantee top spot in Group A.
This clash of titans is another mouthwatering fixture served up by this year's Champions League group stage, and it proves a difficult game to call.
Where to Watch
| When Is Kick Off? | Tuesday 26 November |
| Wheat Time Is Kick Off? | 20:00 (BST) |
| Where Is It Played? | Santiago Bernabeu |
| TV Channel/Live Stream? | BT Sport ESPN |
| Referee? | Artur Soares Dias |
Team News
Real Madrid are still without James Rodriguez, Lucas Vazquez, Nacho and Marco Asensio, however, Gareth Bale did come on as a substitute in Madrid's 3-1 win over Real Sociedad - evidently putting his 'Wales, Golf, Madrid' antics behind him.
PSG welcomed back Neymar, Kylian Mbappé and Edinson Cavani in their 2-0 win over Lille, all of which could feature on Tuesday.
The visitors will be will be without Thilo Kehrer, while Marco Verratti and Ander Herrera are doubtful in midfield.
Predicted Lineups
| Real Madrid | Courtois; Carvajal, Varane, Ramos, Mendy; Casemiro, Modric, Kroos; Bale, Benzema, Hazard |
| PSG | Navas; Meunier, T.Silva, Diallo, Bernat; Gueye, Marquinhos, Paredes; Di Maria, Icardi, Neymar |
Head-to-Head Record
These two teams have faced one another on ten occasions, sharing the spoils with four wins each and two draws.
The most recent outing was back in September when Real Madrid fell to a 3-0 defeat in Paris - a performance which was much maligned by the Spanish media. Zinedine Zidane will look to alleviate some of the pressure on himself with a far more positive outcome this time round.
Recent Form
Los Blancos' form has been much better in recent times, having won five of their last six matches and losing only once since the reverse fixture against PSG.
Zidane's side have started to play with the swagger that Madrid fans are accustomed to, scoring 18 goals in their last five fixtures with a happier looking starting lineup. They currently sit second in La Liga and in Champions League Group A.
PSG are in fine form of late with nine victories from their last ten matches. The return to fitness of Neymar, Mbappé and Cavani will only boost the confidence of the French side, with a ridiculous amount of quality building within their squad.
PSG's last outing was a straightforward 2-0 win over last year's Ligue 1 runners-up Lille, a game in which Mauro Icardi and Angel Di Maria continued their great goalscoring form.
Here is each side's last five matches:
| Real Madrid | PSG |
| Real Madrid 3-1 Real Sociedad (23/11) | PSG 2-0 Lille (22/11) |
| Eibar 0-4 Real Madrid (9/11) | Stade Brest 1-2 PSG (9/11) |
| Real Madrid 6-0 Galatasaray (6/11) | PSG 1-0 Club Brugge (6/11) |
| Real Madrid 0-0 Real Betis (2/11) | Dijon 2-1 PSG (1/11) |
| Real Madrid 5-0 Leganes (30/10) | PSG 4-0 Marseille (27/10) |
Prediction
It's highly unlikely that we will see a similar performance from Real Madrid to that of their humbling defeat in the last encounter between the pair. Zidane's side seem to have got their act together since then and a number of key individuals such as Luka Modric and Eden Hazard are returning to form.
With the home advantage, Madrid will be confident of getting a crucial victory which would see them qualify for the next round with a game to spare.
PSG will be in high spirits too, and will aim to resurrect the kind of performance they exhibited back in September's meeting. The return to fitness of their front three, as well as the fantastic form of Icardi and Di Maria, means Thomas Tuchel is spoilt for choice up front.
It will be a close encounter with both sides aiming to assert their attacking dominance in Europe once more.
Prediction: Real Madrid 2-2 PSG


{% extends 'base.html' %} {% load i18n %} {% block content %} {% url django_odesk.auth.views.authenticate as auth_url %} {% blocktrans %}
Log in with oDesk account here.


Adventures in
Snarfing and Crunching!
Starring:
Heka
Cloud Services
Cloud Servers
Cloud Data
Many Flavors, Many Tools
- Log files / (r)syslog(-ng) / Logstash / Splunk / etc.
- Stats / StatsD / Graphite / Ganglia / etc.
- CEP / EEP / Riemann / Esper / ArcSight / etc.
- Monitoring / Nagios / Zenoss / etc.
- App instrumentation / New Relic / etc.
- Server metrics / proc fs / etc.
- etc. / etc. / etc.
One Basic Pattern
- Get data
- Transform and/or transport data
- Deliver data
One Basic Pattern: More Detail
- Access some stream of bits
- Identify / split on record boundaries
- Convert records to common format
- Route records to appropriate consumers
- Watch data as it streams
- Generate new messages in common format
- Convert from common format to some other format
- Push bits
Heka to the Rescue!
Packs, Runners, and Channels, Oh My!
- Protocol buffer Message structs
- Wrapped in PipelinePack envelopes
- Plugins run in their own goroutines
- Packs are passed through the pipeline over channels
-
Plugin lifespan and system interaction handled by PluginRunners
-
Tight coupling of a plugin to a single goroutine helps keep concurrency sane
Routing
After decoding, most packs will be handed to Heka's internal router
for delivery to any appropriate filter and/or output plugins.
- Filters and outputs specify a "message matcher"
- Simple YACC grammar (e.g. "Type == 'MyMessageType'")
- Supports regular expression matching
- Very fast
- Run in their own goroutines, fed via input channels
Sandboxes: Lua
All Heka plugins can be written in Go, but filters, decoders, and
encoders can have their logic in Lua.
- Lua sandboxes limit resource usage and consumption
- Filters support dynamic loading
- Very fast
- Turing complete > complex config DSLs
- Lua Parsing Expression Grammars (LPEG)
Let's See It!
Why Go?
Once we decided we wanted to write this tool, a number of factors
contributed to our choice to use Go:
- Performance
- Lightweight deployment env
- Concurrency primitives
- Risk management
We looked at Rust, but it wasn't (and still isn't) quite ready.
What's Been Awesome?
- See last slide
- Tooling
- Interfaces
- Back pressure fail conditions
- Platform rapidly improving underneath us
- Static linking
- CGo
What's Been !Awesome?
- Static linking
- CGo
- CGo interactions cause a lot of copying
- CFLAGS / LDFLAGS directives require full paths
- No static linking on Windows => test pain
- Linking is finicky on Windows / OSX
- Test scoping
- Can't effectively test from outside of package
- Can't export test code from within a package
- Packaging
What's Been !Awesome?
Yes, generics would be nice.
Gotchas
- Mind the copies
- Interface > struct
- Package bloat
- No guard rails


Protesters bring lion to anti-government protest in Iraq
by DAILY SABAH WITH AGENCIESProtesters brought a lion draped in the Iraqi flag to the streets amid anti-government protests across the country.
A video showing a man walking out of a car with his lion went viral on social media. It is unclear where the video was taken but over the last month, there have been numerous protests in several Iraqi cities.
Many social media users said that the animal was brought in response to police dogs deployed to assist in the handling of the demonstrations.
Intense protests have been underway in Iraq since October, as millions have come out onto the streets protesting against corruption and unemployment.
Iraqi security and medical officials said Saturday that protesters have pushed closer to the Green Zone, Baghdad's fortified seat of government after security forces pulled back following a night of violent altercations.
The officials said that protesters took control of the strategic Khilani Square and part of Sinak bridge leading to the Green Zone, which houses Parliament and several foreign embassies.
Security forces are still deployed on part of the bridge in order to block the protesters from pushing into the Green Zone.
Officials say a roadside bomb killed three people and wounded 18 late Friday near Tahrir Square, the epicenter of the protest movement. Another roadside blast in the southern city of Nassiriya wounded 18 that same evening.
The officials all spoke on condition of anonymity in line with regulations.
According to the Iraq's High Commission for Human Rights, at least 325 Iraqis have been killed and 15,000 injured since the protests began Oct. 1.


Ford Facing A Difficult Future
by Michael A. Gayed, CFASummary
- In September this year, Moody's downgraded Ford's rating to junk and now S&P downgraded it to BBB- just above junk.
- Q3 2019 numbers beat the market expectations; however, management lowered the earnings estimates for the rest of the year.
- The future looks tough due to factors like the auto industry slowdown in the international market and the ongoing restructuring phase of the company.
Failure is simply the opportunity to begin again, this time more intelligently. – Henry Ford
In the previous article on Ford, I mentioned the difficulties the company might face surviving the next recession. Let’s look at what has changed since then.
The company recently reported Q3 earnings, the first since Moody's downgraded its bond to junk this September. It has beaten market expectations, however lowered the earnings estimates for the year.
The positives
The company declared the Q3 2019 adjusted-EBIT of $1.8 billion, up from $1.7 billion in the third quarter last year. It has improved by 8% as compared to the previous quarter due to higher sales in some regions and mark-to-market gains. EBT for Ford Credit also saw an increase.
Sourced – Investor Presentation
The strong performance of Ford’s automotive segment was primarily driven by North America. Overall, it generated revenue of $33.93 billion, and EBIT stands at $2 billion, as shown in the figure below. The lower effective tax rate of around 12-13% also helped in providing a boost to the net earnings.
Source – Investor Presentation
Additionally, the company is undergoing a massive organizational restructuring. Last year, CEO James Hackett announced an $11 billion restructuring plan.
Management has decided to phase out all sedans (except Ford Mustang) to refocus on the company’s stronger segments, i.e. trucks and SUVs. About 10% of white-collar workforce (~ 7,000 employees) was slashed earlier this year This frees capital to ramp up their electric and autonomous vehicle programs.
Ford has also entered into a $275 million JV with Mahindra and Mahindra, which will help the company to withstand competition through operational synergies.
The negatives
Although the company has exceeded market expectations in Q3 2019, it guided low earnings for the rest of the year. The company has lowered its earnings guidance to around $6.5 billion - $ 7.0 billion.
| Management Guidance | 2018 | 2019E |
| Adj. Free Cash Flow | $2.8B | Improvement from 2018 |
| Adj. EBIT | $7.0B | $6.5 - $7.0B |
| Adj. EPS | $1.30 | $1.20 - $1.32 |
Source – Investor Presentation
The lower earnings guidance for the next quarter was primarily due to the expectation of higher warranty cost, higher than planned incentives in North America, and lower demand in China.
From management’s standpoint, Q3 2019 was a good quarter. However, the stock is still under pressure.  The future still looks bumpy because of the government’s deadlines to meet environmental targets and the company's ongoing restructuring phase.
The company is trying hard to regain the investor’s confidence by maintaining specific liquidity standards and expanding the electrical vehicle portfolio. But in the current scenario, many factors are going against the company:
- S&P rating cut - S&P downgraded Ford rating from BBB to BBB- (just one step above junk)
- Newer Ford models cannibalizing sales of older models.
- Management low earning guidance in the near future.
Restructuring is very critical for the company. It expects the restructuring to cost around $3 billion - $3.5 billion for the year. Looking at the expenses and the down gradation of credit rating by S&P, the road ahead looks bumpy for the veteran automaker.
*Like this article? Don’t forget to hit the follow button above!
---------------------------------------------------------------------------------------
Your Biggest Mistakes Are Often Invisible.

That’s why paying attention to the right data and insights is so important. A few quick tips from an investment manager isn’t enough: you need to dive deep into the signals that shake the market and move your portfolio.
This kind of in-depth research is exactly how I’ve managed to become an award-winning author, and I’m sharing all of my data analysis with you right here.
Click here now to get 14 days free of my Lead-Lag Report today.
Disclosure: I/we have no positions in any stocks mentioned, and no plans to initiate any positions within the next 72 hours. I wrote this article myself, and it expresses my own opinions. I am not receiving compensation for it (other than from Seeking Alpha). I have no business relationship with any company whose stock is mentioned in this article.
Additional disclosure: This writing is for informational purposes only. It does not constitute an offer to sell, a solicitation to buy, or a recommendation regarding any securities transaction. It also does not offer to provide advisory or other services by Pension Partners, LLC in any jurisdiction in which such offer, solicitation, purchase or sale would be unlawful under the securities laws of such jurisdiction. The information contained in this writing should not be construed as financial or investment advice on any subject matter. Pension Partners, LLC expressly disclaims all liability in respect to actions taken based on any or all of the information on this writing.


New Gran Turismo X Lamborghini Collab Looks Like A Batmobile From 2076
by Luke PlunkettThis is Lamborghini’s Vision GT, a new car unveiled in the flesh tonight at the Gran Turismo Championship World Finals in Monaco. It looks like something Bruce Wayne would take to an open track day, but despite this physical unveiling, the car is actually only going to be made digitally inside Gran Turismo Sport.
The Vision GT is envisaged as a single-seat racer with a hybrid V12, which drivers climb into like a fighter jet and which displays its information not on screens or panels, but by projecting it into the air around the driver’s head.
It’s coming to the game in Spring 2020.
This if course isn’t the first time GT has done something like this. Previous GT Vision cars from just 2019 include this Jag:
While in 2017 McLaren designed this:


Lorem ipsum
This should be blue and in same font size as lorem ipsum
Lorem ipsum
This should be blue and in same font size as lorem ipsum


{% block css %}
{% endblock %}
Santa Banta Bulk Image Downloader
Download a bulk of images directly to Box Drive
Provide the full image address by right-clicking and then selecting
Copy image address
Submit
{{ message }}


The Replacement Killers could have been a good, solid action movie. It could have been a sleeper hit; a movie that decided to break a few rules and be original and inventive. Instead it's a boring, forgettable movie that'll be out of theaters in a few weeks.
It's the American debut of Chow Yen Fat, who's Hong Kong films The Killer and Hard Boiled made him the best action star in the movies today. He has a grace about his characters: he can be somber and confident at the same time. When you compare him to American action stars he seems more real, more identifiable. After his international success, he came to Hollywood and was wasted. While he does manage to walk out of The Replacement Killers with his reputation intact, but everything else around him was a waste. It also stars Mira Sorvino, who plays your standard breaking the law loner who does everything her way and fakes passports to make ends meet. She's totally unbelievable here and spends most of her time trying to convince us that she's tough and knows how to shoot a gun. To describe the plot is to waste your time and lower your I.Q. You don't pay attention to the details in a movie like this, you don't follow the plot holes. Things like that will only frustrate you.  The action scenes were passable, though they tended to get old after awhile. Director Anotoine Fuqua puts a little bit of style in the movie, he tries to give the movie an Asian feel. But his problem is that you don't really know if he's spoofing Fat's movies, or if he's taking them seriously. There's a moment towards the end of the movie where Fat makes a stand-off with the main mean bad guy. The bad guy is driving down an alley in his limo (because bad guys always ride in limos in movies like this), the gates to his fortress open, and there stands Fat, holding seven or eight handguns. Whether or not it was supposed to be funny, half the theater laughed.
Rather than watch The Replacement Killers, rent Fat's best action films, The Killer or Hard Boiled. Those movies also brought director John Woo to Hollywood. Woo's first film was a bomb in Hard Target . Hollywood let him stick around and he eventually made the successful and acclaimed Face/Off. Let's hope Fat gets the same chance.
The Replacement Killers (* and half out four). Directed by Antoine Fuqua. Starring: Chow Yen Fat, Mira Sorvino.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


A tech & innovation event built to be a vehicle for change.
-
2019, Slush China held three main events in Nanjing, Shenzhen, and Shanghai.
I worked with the Production and Marketing team as a visual designer, and designed the visual systems for the Shenzhen and Shanghai Event.
ECHO: dynamic visual element generated using processing
Tickets and Souvenirs
Onsite Photos
In the Arena: between digital and physical
posters
Agenda


For the alternatives that you have placed in this list, type a phrase describing why these are similar.
For the alternatives that you have placed in this list, type a phrase describing why these differ from the others.
{% extends 'gridMng/wizard/gridWizard_base.html' %} {% load wizard_extras %} {% block stylesheet %} {{ block.super }} {% endblock stylesheet %} {% block javascript %} {% endblock javascript %} {% block step_info %}
In this step you can add the concerns. Drag and drop alternatives from the alternatives list and place them in the two other lists below.
For the alternatives that you have placed in this list, type a phrase describing why these are similar.
For the alternatives that you have placed in this list, type a phrase describing why these differ from the others.
The list below contains the concerns that you have already added. You can change their names in place.
{{ error }}
{% endfor %}No concerns have been added yet.
{{ error }}
{% endfor %}


Pinnacle Artists is a company dedicated to finding the most talented and marketable artists in the country. We then represent and promote the artists we find to fine art galleries across the United States. We understand that art galleries are challenged to find skilled artists that are not over sold, yet still have broad appeal. It is our mission to provide maximum exposure to the artists we represent working through our network of galleries. We have carefully selected our artists based on their talent, existing market appeal, and their dedicated work ethics. We have attempted to find the best artist in different styles in order to offer our clients a broad base of artists to fit their specific market.
Gallery owners are invited to review the portfolios of the artists we represent. We will be happy to discuss exclusive territories and our special promotional packages. |


|
QuantLib: a free/open-source library for quantitative finance
Fully annotated sources - version 1.30
|
global repository for run-time library settings More...
#include <ql/experimental/commodities/commoditysettings.hpp>
Public Member Functions | |
| Currency & | currency () |
| UnitOfMeasure & | unitOfMeasure () |
| Public Member Functions inherited from Singleton< CommoditySettings > | |
| Singleton (const Singleton &)=delete | |
| Singleton (Singleton &&)=delete | |
| Singleton & | operator= (const Singleton &)=delete |
| Singleton & | operator= (Singleton &&)=delete |
| ~Singleton ()=default | |
Private Member Functions | |
| CommoditySettings () | |
Private Attributes | |
| Currency | currency_ |
| UnitOfMeasure | unitOfMeasure_ |
Friends | |
| class | Singleton< CommoditySettings > |
Additional Inherited Members | |
| Static Public Member Functions inherited from Singleton< CommoditySettings > | |
| static CommoditySettings & | instance () |
| access to the unique instance More... | |
| Protected Member Functions inherited from Singleton< CommoditySettings > | |
| Singleton ()=default | |
global repository for run-time library settings
Definition at line 34 of file commoditysettings.hpp.
|
private |
Definition at line 27 of file commoditysettings.cpp.
| Currency & currency | ( | ) |
| UnitOfMeasure & unitOfMeasure | ( | ) |
|
friend |
Definition at line 1 of file commoditysettings.hpp.
|
private |
Definition at line 43 of file commoditysettings.hpp.
|
private |
Definition at line 44 of file commoditysettings.hpp.


species medicinal therapeutic (RI plants ICF Revista (), number .), Brasileira Brazil activity community indications Plantas use used indicated Albuquerque Myracrodruon Oliveira {border-style areas urundeuva px;} #ffffff;} Brasil Diseases importance presented Medicinal diseases Medicinais relative species, studies study Ethnopharmacology activities body obtained studied treatment Silva communities ethnobotanical highest present ./j.jep... Disorder Ribeiro Souza community, medicinais survey ./RI Brazilian Ximenia cited northeastern plantas related (ICF ./S- Almeida Quincuncá Stryphnodendron categories potential reported rotundifolium values Amburana Caatinga Mimosa area areas, bodily information knowledge systems Acta Andrade Ferreira Lantana Neto Research americana areas. articles cearensis extract inflammation pharmacological px; tenuiflora {font-family Croton Lucena Northeast Pereira Rodrigues Santos Table Uso analyzed and/or anti-inflammatory antioxidant caatinga category citations demonstrated font-size however, indication inflammation, informants popular problems value ./-X/_ Alves Consensus Disorders Geoffroea However, Informants Leite Macêdo Menezes Nordeste Plants Respiratory São agreement consensus considered das divergence double; estado important peruiferum plant properties respiratory results semiarid systems, total Brazil, Coelho Costa Desenvolvimento Ethnobotanical Farmacognosia Gonçalves Health Marinho Rio Species Use Ziziphus appear article border-color border-width calculated collected communities, comunidade different diseases, effect essential greater high interviews largest northeast, pyramidalis respectively. rural showed solid; species. state stomach treat uma urundeuva, using various versatility work {font-style {font-weight ./ptr. ./s--- Anadenanthera Barbosa Barros Caatinga, Carvalho Causes Ceará, Consequences Digestive Evaluation External Factor Freitas Grande Injuries, Licania Lima Maria Matos Myroxylon Natural Northeastern Paraíba, Phytotherapy Poincianella Poisonings Recife, Sciences Senegalia Sensory Therapeutic Tissue Tocoyena Undefined Viana according americana, antibacterial appears attributed average based biological bold camara citations), colubrina conservação courier; distributed diversity dos em; formosa general great greatest health influenza, mainly material maximum medical mentioned native oil population presenting pt;} purposes ranging rats region resources rigida second semi-arid stem stood systems. treated uses uterine utilizadas widely


By redesigning the user interface of Statfin, the official statistics database of Finland, the project aims to demonstrate how design could help the citizens interactively visualise the data, and how design could lower the threshold of transforming raw data into useful and comprehensive information.
Find Out MoreRedesign
The new nested list provides a comprehensive overview of each table. Only essential information would be shown at the first glance (e.g. period of data collection and categorical information). Clear, straightforward, so you never mess up.
Current
Current
After selecting the variables, the data is usually shown as a wide and long table that overflows the margin of the display. Nonetheless, the table also fails to provide a comprehensive overview of the data to its users. As a result, the users disappointedly find that they don’t know what to do with the data, not to mention to proceed any furthur analysis.
Redesign
The new design provides a WYSIWYG (what you see is what you get) selector for variables. Once the selection of variables is modified, the graph/table shown on the right side would be updated simultaneously.
Redesign
The redesign also provides a brand-new function that enable the users to compare the variables cross the datasets. The aim of this function is to provide the users a more intuitive way to see possible relations between different variables, and not to be constrained by the official categories.
Redesign
Current
Always visualise raw data at the first glance, than provide tools for further investigation.
Reduce cognitive load and keep the interface intuitive and effective
Make experience consistent while producing, interacting, and viewing information
I am keen to know how do you think of this project. Any comment would be highly appreciated!
Master Student in Collaborative and Industrial Design at Aalto UniversityI am an enthusiastic designer and learner with strong interests in digital design for activism, democracy, and governance. And, I am looking for job & collaboration opportunities!
This webpage is only for the showcase session of Visualizing Knowledge Conference 2018. Please visit my website for more of my works by scanning the QR code or by the address shown below. :-D
yentsenliu.com


--- layout: post title: ! '"I accept shawls as a payment..."' date: 2009-07-25 20:08:23.000000000 +02:00 categories: [] tags: [] status: publish type: post published: true meta: _edit_last: '5236424' author: login: stricksucht email<EMAIL_ADDRESS>display_name: stricksucht first_name: '' last_name: '' ---
Even though I'm still heavily in love with the Gossamer Garden Stole, and even though my Owls sweater is far from being finished (and I'm really, really planning on finishing both before starting anything else), oh, and then there are the Hedwig the Owl Socks, I'm already thinking about what I can do next.
Once Conny has returned from the US, I'll be able to add three lovely yarns to my stash (Trendsetter Cashwool, Conjoined Creations Pastimes, Too and Cascade Yarns Alpaca Lace) that will be worked into different shawls and wraps and stoles.
And then along came Mam. She was so kind as to gift me two gorgeous pairs of shoes (black pumps, to be precise), and when I asked her how I could possibly return the favour she said: "Well, if you feel the urge to knit something for somebody else some day, you could do a shawl for me..." Well, we sat down right that afternoon and decided on a pattern (the North Roe Shawl) as well as yarn (KnitPicks Shimmer in Spice), so now I just have to finish my projects, order the yarn and I'm ready to go. Damn, I love lace knitting! :D


MDS Capstone Report: Diagnosing Lipohypertrophy¶
Capstone project in collaboration with the Gerontology and Diabetes Research Laboratory (GDRL). Using Machine Learning Approaches to Diagnosing Lipohypertrophy at the bedside.
contributors: Ela Bandari, Lara Habashy, Javairia Raza, Peter Yang
About¶
This repository hosts all the files and scripts needed to run, generate, and publish the final capstone project report written by Ela Bandari, Lara Habashy, Javairia Raza, and Peter Yang. The report is published on GitHub pages via Jupyter Book. The most recent deployment of this report took place on June 28th, 2021 at 11:00AM PST.
Usage¶
To re-generate this report, follow these steps:
First, you will need to install Jupyter Book via pip. Refer to this manual to get started.
Ensure Anaconda Python is installed.Clone this repository by running the following commands from your terminal line:
git clone https://github.com/larahabashy/capstone-report.git
cd capstone-report
Install our environment by running:
conda env create -f environment.yml
conda activate report_env
Compile the report component by running the following command from the root directory:
jupyter-book build ./capstone-report
This allows you to view an html rendered version of the book on your browser of choicePublish the report on GitHub pages by running the following two commands:
pip install ghp-import
ghp-import -n -p -f _build/html
For more information, visit the Jupyter Book tutorial page here.


hello
- hello world
Your output might look like this:
* Chris
*
* GitHub
* GitHub
Here's some special entities:
Here's a line that uses non-breaking spaces to force the last few words to wrap together.
And stuff like this:
git bulk [-g] ([-a]|[-w
git bulk --addworkspace
git bulk --removeworkspace <ws-name>
Should have the <
/>
entities stay as <
/>
in HTML, but be
turned into literal brackets in the ROFF.


src/shared/services/settings.service.ts
Properties |
Methods |
constructor()
|
|
Defined in src/shared/services/settings.service.ts:58
|
| getItem | ||||||||
getItem(key: string)
|
||||||||
|
Defined in src/shared/services/settings.service.ts:177
|
||||||||
|
Get the value of a given item and return it to the calling function.
Parameters :
Returns :
unknown
|
| setItem | ||||||||||||
setItem(key: string, value: string | number | boolean)
|
||||||||||||
|
Defined in src/shared/services/settings.service.ts:169
|
||||||||||||
|
Save a specific user preference to the settings store. Since the user may do a lot of adjusting to the theme, a timeout is set to allow for those adjustments, and reduce the number of writes to the settings store.
Parameters :
Returns :
void
|
| cursorBlinkSubject |
Default value : new BehaviorSubject(false)
|
|
Defined in src/shared/services/settings.service.ts:56
|
| cursorStyleSubject |
Default value : new BehaviorSubject("block")
|
|
Defined in src/shared/services/settings.service.ts:55
|
| Private store |
Type : Store<literal type>
|
|
Defined in src/shared/services/settings.service.ts:28
|
|
Since Electron store returns an "unknown" type, to provide some level of type safety, we can use the default initialization scheme provided by ElectronStore,
|
| terminalFontSizeSubject |
Default value : new BehaviorSubject(13)
|
|
Defined in src/shared/services/settings.service.ts:53
|
| terminalLetterSpacingSubject |
Default value : new BehaviorSubject(1)
|
|
Defined in src/shared/services/settings.service.ts:57
|
| terminalLineHeightSubject |
Default value : new BehaviorSubject(1.2)
|
|
Defined in src/shared/services/settings.service.ts:58
|
| windowControlSubject |
Default value : new BehaviorSubject("mac")
|
|
Defined in src/shared/services/settings.service.ts:54
|
import { Injectable } from "@angular/core"
import { BehaviorSubject } from "rxjs"
import Store from "electron-store"
@Injectable({ providedIn: "root" })
/**
* A helper class to get or set the application wide settings.
* The store uses Subscriptions and Behavior subjects for settings
* related to the terminal theme. The benefit of this is each time a value
* in the store is changed, the new value will be applied to the
* terminal in real time through the terminal?.setOption() call.
*
* However this only applies to "theme" related settings
* (i.e. background, foreground, etc). Other settings such as the
* type of session, rows, and columns used by the underlying pty/terminal
* will require a window reload, as those cannot be properly
* updated in real time.
* */
export class SettingsService {
/** Since Electron store returns an "unknown" type, to provide some
* level of type safety, we can use the default initialization
* scheme provided by ElectronStore,
* ```
* ElectronStore<{key: string, value: unknown}>
*```*/
private store: Store<{
customTerminalTitle: unknown
darkMacTrafficLights: unknown
fontSize: unknown
linesOfTerminalScrollback: unknown
ptyRows: unknown
ptyCols: unknown
terminalCursorColor: unknown
terminalCursorStyle: unknown
terminalCursorAccentColor: unknown
terminalCursorBlink: unknown
shellType: unknown
terminalBackgroundTransparency: unknown
terminalBackgroundColor: unknown
terminalType: unknown
terminalFontSize: unknown
terminalLineHeight: unknown
terminalLetterSpacing: unknown
terminalSelectionColor: unknown
terminalForegroundColor: unknown
terminalFont: unknown
windowsStyleControls: unknown
windowControlStyle: unknown
}>
terminalFontSizeSubject = new BehaviorSubject(13)
windowControlSubject = new BehaviorSubject("mac")
cursorStyleSubject = new BehaviorSubject("block")
cursorBlinkSubject = new BehaviorSubject(false)
terminalLetterSpacingSubject = new BehaviorSubject(1)
terminalLineHeightSubject = new BehaviorSubject(1.2)
constructor() {
// configure the terminal settings store
this.store = new Store({
name: "terminal-settings",
watch: true,
schema: {
terminalBackgroundTransparency: {
type: "number",
default: 0.90
},
terminalBackgroundColor: {
type: "string",
default: "#18242f"
},
customTerminalTitle: {
type: "string",
default: ""
},
darkMacTrafficLights: {
type: "boolean",
default: false
},
fontSize: {
type: "number",
default: 13
},
linesOfTerminalScrollback: {
type: "number",
default: 100
},
ptyCols: {
type: "number",
default: 80
},
ptyRows: {
type: "number",
default: 25
},
terminalCursorAccentColor: {
type: "string",
default: "#47bedb"
},
terminalCursorBlink: {
type: "boolean",
default: false
},
terminalCursorColor: {
type: "string",
default: "#47bedb"
},
terminalCursorStyle: {
type: "string",
default: "block"
},
terminalFont: {
type: "string",
default: "Hack Nerd Font"
},
terminalForegroundColor: {
type: "string",
default: "#dbf4fa"
},
terminalFontSize: {
type: "number",
default: 13,
},
terminalLetterSpacing: {
type: "number",
default: 1
},
terminalType: {
type: "string",
default: process.platform === "win32" ? null : "xterm-256color"
},
terminalLineHeight: {
type: "number",
default: 1
},
terminalSelectionColor: {
type: "string",
default: "#47bedb"
},
shellType: {
type: "string",
default: process.platform === "win32" ? "powershell.exe" : "bash"
},
windowsStyleControls: {
type: "boolean",
default: false
},
windowControlStyle: {
type: "string",
default: process.platform === "darwin" ? "mac" : "windows"
}
}
})
}
/**
* Save a specific user preference to the settings store.
*
* Since the user may do a lot of adjusting to the theme,
* a timeout is set to allow for those adjustments,
* and reduce the number of writes to the settings store.
*
* @param {string} key the accessor which is used to access the value of a setting.
* @param {string | number | boolean} value the value to be used by the terminal
* or overall application.
* */
setItem(key: string, value: string | number | boolean) {
this.store.set(key, value)
}
/**
* Get the value of a given item and return it to the calling function.
* @param {string} key the key which will "point" a specific item.
* */
getItem(key: string): unknown {
return this.store.get(key)
}
}


Home
3
Brad Diesel
Call me whenever you can...
4 Hours Ago
John Pierce
I got your message bro
4 Hours Ago
Nora Silvester
The subject goes here
4 Hours Ago
See All Messages
15
15 Notifications
4 new messages
3 mins
8 friend requests
12 hours
3 new reports
2 days
See All Notifications
Tutor Profile Edit
Home
Tutor Profile Edit
Nina Mcintire
Update Profile Pic
Edit Your Profile
First Name
Last Name
Email
Phone Number
Birthday
Old Password
New Password
Confirm Password
Country
Alaska
California
Delaware
Tennessee
Texas
Washington
State
Alaska
California
Delaware
Tennessee
Texas
Washington
City
Alaska
California
Delaware
Tennessee
Texas
Washington
Zipcode
Choose Subjects
English
Science
History
Mathematics
Geography
Economics
Computer Science
Summary
How would you like to teach?
Online
In-Person
Both
Select a price per hour that you want to be paid


[gecode-users] Implementing No-goods
Kish Shen
kisshen at cisco.com
Fri Sep 13 06:11:58 CEST 2013
Hi Christian,
Thanks for your reply!
On 12/09/2013 09:22, Christian Schulte wrote:
> Please re-read MPG on how restart-based search works: the no-goods are
> posted in the master space (that's why the master() function does it) and
> are hence re-used for each restart (as it starts from the master).
>
I was thinking about what happens when there is more than one search,
i.e. after a search -- search1 -- in a space (using a subset of
variables of the space), another search (with a different subset of
variables) -- search2 -- is done on the space. Each of these search will
use their own search engines, and can use different search engines, with
different options.
I understand that the no-goods are posted in the master space, but I
assume the master space in search1 is not the same as search2. My
question was if the no-goods gathered in search1 will be posted in
search2 (assuming both are doing a restart search with no-goods).
As far as I can see, there is no need to post these no-goods from
search1, because a different subset of variables are used in search2,
and in addition I assume the no-goods from search1 will be represented
as constraints in the master space of search2.
> If you do nothing extra (such as randomization or BAB where the constrain()
> function is called on the master etc) restarting after having found a
> solution will produce the same solution again.
>
I am thinking here of what to do with next() when using a restart DFS
search engine in the context of the ECLiPSe interface.
For Gecode, I can understand that you want to leave any extra thing to
be done to the user.
For the interface, the user is programming in ECLiPSe, and anything
extra must be done by the interface. After obtaining a solution, I want
a call to next() to return a different answer (if this exist), and
potentially to be able to return all the solutions, as in a non-restart
DFS. The only way I can think of doing this is to post the previous
solution as a no-good, and this has to be done regardless of what
nogoods_limit is. Is this possible, and/or is there some other way of
ensuring that the previous solution will not be returned?
Cheers,
Kish
More information about the users
mailing list


Set a base name
Looks like it's your first time here.
Please choose a unique base name that we can use to identify your account. The base name is used to help form the email addresses that you will set up (e.g. test-[if(basename.length > 0, basename, 'basename')]@attachmentsaver.com).
A good base name is between 3 and 8 characters long, and must not contain any non-letter characters


Renderer coupled with a basic diffuse path tracer. The user can move the camera anywhere and trigger a path-traced rendering. Can also display the raycaster acceleration structure.
More...
#include <BVHRenderer.hpp>
|
| void | castRay (const glm::vec2 &position) |
| |
Renderer coupled with a basic diffuse path tracer. The user can move the camera anywhere and trigger a path-traced rendering. Can also display the raycaster acceleration structure.
Inherits Renderer.
◆ BVHRenderer()
Constructor.
- Parameters
-
| config | the configuration to apply |
◆ castRay()
| void BVHRenderer::castRay |
( |
const glm::vec2 & |
position | ) |
|
|
private |
Generate visualisation for a ray cast from a given unit viewport position.
- Parameters
-
| position | the position in unit viewport space. |
◆ clean()
| void BVHRenderer::clean |
( |
| ) |
|
|
overridevirtual |
Clean internal resources.
Reimplemented from Renderer.
◆ draw()
| void BVHRenderer::draw |
( |
| ) |
|
|
overridevirtual |
Draw the scene and effects
Implements Renderer.
◆ physics()
| void BVHRenderer::physics |
( |
double |
fullTime, |
|
|
double |
frameTime |
|
) |
| |
|
overridevirtual |
Perform physics simulation update.
- Parameters
-
| fullTime | the time elapsed since the beginning of the render loop |
| frameTime | the duration of the last frame |
- Note
- This function can be called multiple times per frame.
Implements Renderer.
◆ resize()
| void BVHRenderer::resize |
( |
unsigned int |
width, |
|
|
unsigned int |
height |
|
) |
| |
|
overridevirtual |
Handle a window resize event.
- Parameters
-
| width | the new width |
| height | the new height |
Implements Renderer.
◆ setScene()
| void BVHRenderer::setScene |
( |
const std::shared_ptr< Scene > & |
scene | ) |
|
Set the scene to render.
- Parameters
-
◆ update()
| void BVHRenderer::update |
( |
| ) |
|
|
overridevirtual |
Perform once-per-frame update (buttons, GUI,...)
Reimplemented from Renderer.
The documentation for this class was generated from the following files:


{{#harvest.screenshots.hasScreenshots}}
{{>screenshots}}
{{/harvest.screenshots.hasScreenshots}}
Report: {{#report.success}} Verified! {{/report.success}} {{^report.success}} Not verified {{/report.success}}
Started {{formattedStarted}}.
Runtime was {{totalRuntime}}.


Please select a gene from the list of nascent AD targets to view details and evidence. You can find a gene by typing in a gene symbol (e.g. “VGF”).


My awesome journey in South Africa
From Sweden to South Africa which became my home for 5 months. It is without a question one of the foremost beautiful countries at the planet, a genuine diamond with staggering scenes and natural life. With everything from shorelines to deserts and mountains. In expansion, the mix of the diverse societies will promptly make you're feeling at domestic in this captivating nation.
Read Article


Try clicking the button below!
A loader overlay will appear over this <div> element until the async operation is completed.
Start async operation
{ ongoingOperation: }


layout: definitions
---
Let $\chi_S:\mathbb{R}^n\to\mathbb{R}$ be the characteristic function of a set $S\subseteq\mathbb{R}^n$. We say that $S$ has (Jordan) content if $\chi_S$ is integrable on $S$ and the volume is
$$\begin{align*}
\mu(S):=\int_S\chi_S(\vec{x})d\vec{x}.
\end{align*}$$
Concepts
Coming soon
Used In
Coming soon
Hypothesis
Coming soon
Results
Coming soon
Related
Coming soon


public interface BidiConstants
Constants used for bidirectional processing.
This work was originally authored by Glenn Adams (gadams@apache.org).
| Modifier and Type | Field and Description |
|---|---|
static int |
AL
right-to-left arabic class
|
static int |
AN
arabic number class
|
static int |
B
paragraph separator class
|
static int |
BN
boundary neutral class
|
static int |
CS
common number separator class
|
static int |
EN
european number class
|
static int |
ES
european number separator class
|
static int |
ET
european number terminator class
|
static int |
FIRST
first external (official) category
|
static int |
L
left-to-right class
|
static int |
LAST
last external (official) category
|
static int |
LRE
left-to-right embedding class
|
static int |
LRO
left-to-right override class
|
static int |
MAX_LEVELS
last
/** maximum bidirectional levels
|
static int |
NSM
non-spacing mark class
|
static int |
ON
other neutrals class
|
static int |
OVERRIDE
override flag
|
static int |
PDF
pop directional formatting class
|
static int |
R
right-to-left class
|
static int |
RLE
right-to-left embedding class
|
static int |
RLO
right-to-left override class
|
static int |
S
segment separator class
|
static int |
SURROGATE
placeholder for low surrogate
|
static int |
WS
whitespace class
|
static final int FIRST
static final int L
static final int LRE
static final int LRO
static final int R
static final int AL
static final int RLE
static final int RLO
static final int PDF
static final int EN
static final int ES
static final int ET
static final int AN
static final int CS
static final int NSM
static final int BN
static final int B
static final int S
static final int WS
static final int ON
static final int LAST
static final int SURROGATE
static final int MAX_LEVELS
static final int OVERRIDE
Copyright 1999-2020 The Apache Software Foundation. All Rights Reserved.