cmake-file-api(7)¶
Contents
Introduction¶
CMake provides a file-based API that clients may use to get semantic information about the buildsystems CMake generates. Clients may use the API by writing query files to a specific location in a build tree to request zero or more Object Kinds. When CMake generates the buildsystem in that build tree it will read the query files and write reply files for the client to read.
The file-based API uses a <build>/.cmake/api/
directory at the top
of a build tree. The API is versioned to support changes to the layout
of files within the API directory. API file layout versioning is
orthogonal to the versioning of Object Kinds used in replies.
This version of CMake supports only one API version, API v1.
API v1¶
API v1 is housed in the <build>/.cmake/api/v1/
directory.
It has the following subdirectories:
query/
- Holds query files written by clients. These may be v1 Shared Stateless Query Files, v1 Client Stateless Query Files, or v1 Client Stateful Query Files.
reply/
Holds reply files written by CMake whenever it runs to generate a build system. These are indexed by a v1 Reply Index File file that may reference additional v1 Reply Files. CMake owns all reply files. Clients must never remove them.
Clients may look for and read a reply index file at any time. Clients may optionally create the
reply/
directory at any time and monitor it for the appearance of a new reply index file.
v1 Client Stateless Query Files¶
Client stateless query files allow clients to create owned requests for major versions of the Object Kinds and get all requested versions recognized by the CMake that runs.
Clients may create owned requests by creating empty files in client-specific query subdirectories. The form is:
<build>/.cmake/api/v1/query/client-<client>/<kind>-v<major>
where client-
is literal, <client>
is a string uniquely
identifying the client, <kind>
is one of the Object Kinds,
-v
is literal, and <major>
is the major version number.
Each client must choose a unique <client>
identifier via its
own means.
Files of this form are stateless queries owned by the client <client>
.
The owning client may remove them at any time.
v1 Client Stateful Query Files¶
Stateful query files allow clients to request a list of versions of each of the Object Kinds and get only the most recent version recognized by the CMake that runs.
Clients may create owned stateful queries by creating query.json
files in client-specific query subdirectories. The form is:
<build>/.cmake/api/v1/query/client-<client>/query.json
where client-
is literal, <client>
is a string uniquely
identifying the client, and query.json
is literal. Each client
must choose a unique <client>
identifier via its own means.
query.json
files are stateful queries owned by the client <client>
.
The owning client may update or remove them at any time. When a
given client installation is updated it may then update the stateful
query it writes to build trees to request newer object versions.
This can be used to avoid asking CMake to generate multiple object
versions unnecessarily.
A query.json
file must contain a JSON object:
{
"requests": [
{ "kind": "<kind>" , "version": 1 },
{ "kind": "<kind>" , "version": { "major": 1, "minor": 2 } },
{ "kind": "<kind>" , "version": [2, 1] },
{ "kind": "<kind>" , "version": [2, { "major": 1, "minor": 2 }] },
{ "kind": "<kind>" , "version": 1, "client": {} },
{ "kind": "..." }
],
"client": {}
}
The members are:
requests
A JSON array containing zero or more requests. Each request is a JSON object with members:
kind
- Specifies one of the Object Kinds to be included in the reply.
version
Indicates the version(s) of the object kind that the client understands. Versions have major and minor components following semantic version conventions. The value must be
- a JSON integer specifying a (non-negative) major version number, or
- a JSON object containing
major
and (optionally)minor
members specifying non-negative integer version components, or - a JSON array whose elements are each one of the above.
client
- Optional member reserved for use by the client. This value is preserved in the reply written for the client in the v1 Reply Index File but is otherwise ignored. Clients may use this to pass custom information with a request through to its reply.
For each requested object kind CMake will choose the first version that it recognizes for that kind among those listed in the request. The response will use the selected major version with the highest minor version known to the running CMake for that major version. Therefore clients should list all supported major versions in preferred order along with the minimal minor version required for each major version.
client
- Optional member reserved for use by the client. This value is preserved in the reply written for the client in the v1 Reply Index File but is otherwise ignored. Clients may use this to pass custom information with a query through to its reply.
Other query.json
top-level members are reserved for future use.
If present they are ignored for forward compatibility.
v1 Reply Index File¶
CMake writes an index-*.json
file to the v1/reply/
directory
whenever it runs to generate a build system. Clients must read the
reply index file first and may read other v1 Reply Files only by
following references. The form of the reply index file name is:
<build>/.cmake/api/v1/reply/index-<unspecified>.json
where index-
is literal and <unspecified>
is an unspecified
name selected by CMake. Whenever a new index file is generated it
is given a new name and any old one is deleted. During the short
time between these steps there may be multiple index files present;
the one with the largest name in lexicographic order is the current
index file.
The reply index file contains a JSON object:
{
"cmake": {
"version": {
"major": 3, "minor": 14, "patch": 0, "suffix": "",
"string": "3.14.0", "isDirty": false
},
"paths": {
"cmake": "/prefix/bin/cmake",
"ctest": "/prefix/bin/ctest",
"cpack": "/prefix/bin/cpack",
"root": "/prefix/share/cmake-3.14"
},
"generator": {
"name": "Unix Makefiles"
}
},
"objects": [
{ "kind": "<kind>",
"version": { "major": 1, "minor": 0 },
"jsonFile": "<file>" },
{ "...": "..." }
],
"reply": {
"<kind>-v<major>": { "kind": "<kind>",
"version": { "major": 1, "minor": 0 },
"jsonFile": "<file>" },
"<unknown>": { "error": "unknown query file" },
"...": {},
"client-<client>": {
"<kind>-v<major>": { "kind": "<kind>",
"version": { "major": 1, "minor": 0 },
"jsonFile": "<file>" },
"<unknown>": { "error": "unknown query file" },
"...": {},
"query.json": {
"requests": [ {}, {}, {} ],
"responses": [
{ "kind": "<kind>",
"version": { "major": 1, "minor": 0 },
"jsonFile": "<file>" },
{ "error": "unknown query file" },
{ "...": {} }
],
"client": {}
}
}
}
}
The members are:
cmake
A JSON object containing information about the instance of CMake that generated the reply. It contains members:
version
A JSON object specifying the version of CMake with members:
major
,minor
,patch
- Integer values specifying the major, minor, and patch version components.
suffix
- A string specifying the version suffix, if any, e.g.
g0abc3
. string
- A string specifying the full version in the format
<major>.<minor>.<patch>[-<suffix>]
. isDirty
- A boolean indicating whether the version was built from a version controlled source tree with local modifications.
paths
- A JSON object specifying paths to things that come with CMake.
It has members for
cmake
,ctest
, andcpack
whose values are JSON strings specifying the absolute path to each tool, represented with forward slashes. It also has aroot
member for the absolute path to the directory containing CMake resources like theModules/
directory (seeCMAKE_ROOT
). generator
A JSON object describing the CMake generator used for the build. It has members:
name
- A string specifying the name of the generator.
platform
- If the generator supports
CMAKE_GENERATOR_PLATFORM
, this is a string specifying the generator platform name.
objects
- A JSON array listing all versions of all Object Kinds generated as part of the reply. Each array entry is a v1 Reply File Reference.
reply
A JSON object mirroring the content of the
query/
directory that CMake loaded to produce the reply. The members are of the form<kind>-v<major>
- A member of this form appears for each of the
v1 Shared Stateless Query Files that CMake recognized as a
request for object kind
<kind>
with major version<major>
. The value is a v1 Reply File Reference to the corresponding reply file for that object kind and version. <unknown>
- A member of this form appears for each of the
v1 Shared Stateless Query Files that CMake did not recognize.
The value is a JSON object with a single
error
member containing a string with an error message indicating that the query file is unknown. client-<client>
A member of this form appears for each client-owned directory holding v1 Client Stateless Query Files. The value is a JSON object mirroring the content of the
query/client-<client>/
directory. The members are of the form:<kind>-v<major>
- A member of this form appears for each of the
v1 Client Stateless Query Files that CMake recognized as a
request for object kind
<kind>
with major version<major>
. The value is a v1 Reply File Reference to the corresponding reply file for that object kind and version. <unknown>
- A member of this form appears for each of the
v1 Client Stateless Query Files that CMake did not recognize.
The value is a JSON object with a single
error
member containing a string with an error message indicating that the query file is unknown. query.json
This member appears for clients using v1 Client Stateful Query Files. If the
query.json
file failed to read or parse as a JSON object, this member is a JSON object with a singleerror
member containing a string with an error message. Otherwise, this member is a JSON object mirroring the content of thequery.json
file. The members are:client
- A copy of the
query.json
fileclient
member, if it exists. requests
- A copy of the
query.json
filerequests
member, if it exists. responses
If the
query.json
filerequests
member is missing or invalid, this member is a JSON object with a singleerror
member containing a string with an error message. Otherwise, this member contains a JSON array with a response for each entry of therequests
array, in the same order. Each response is- a JSON object with a single
error
member containing a string with an error message, or - a v1 Reply File Reference to the corresponding reply file for the requested object kind and selected version.
- a JSON object with a single
After reading the reply index file, clients may read the other v1 Reply Files it references.
v1 Reply File Reference¶
The reply index file represents each reference to another reply file using a JSON object with members:
kind
- A string specifying one of the Object Kinds.
version
- A JSON object with members
major
andminor
specifying integer version components of the object kind. jsonFile
- A JSON string specifying a path relative to the reply index file to another JSON file containing the object.
v1 Reply Files¶
Reply files containing specific Object Kinds are written by CMake. The names of these files are unspecified and must not be interpreted by clients. Clients must first read the v1 Reply Index File and and follow references to the names of the desired response objects.
Reply files (including the index file) will never be replaced by files of the same name but different content. This allows a client to read the files concurrently with a running CMake that may generate a new reply. However, after generating a new reply CMake will attempt to remove reply files from previous runs that it did not just write. If a client attempts to read a reply file referenced by the index but finds the file missing, that means a concurrent CMake has generated a new reply. The client may simply start again by reading the new reply index file.
Object Kinds¶
The CMake file-based API reports semantic information about the build system using the following kinds of JSON objects. Each kind of object is versioned independently using semantic versioning with major and minor components. Every kind of object has the form:
{
"kind": "<kind>",
"version": { "major": 1, "minor": 0 },
"...": {}
}
The kind
member is a string specifying the object kind name.
The version
member is a JSON object with major
and minor
members specifying integer components of the object kind’s version.
Additional top-level members are specific to each object kind.
Object Kind “codemodel”¶
The codemodel
object kind describes the build system structure as
modeled by CMake.
There is only one codemodel
object major version, version 2.
Version 1 does not exist to avoid confusion with that from
cmake-server(7)
mode.
“codemodel” version 2¶
codemodel
object version 2 is a JSON object:
{
"kind": "codemodel",
"version": { "major": 2, "minor": 0 },
"paths": {
"source": "/path/to/top-level-source-dir",
"build": "/path/to/top-level-build-dir"
},
"configurations": [
{
"name": "Debug",
"directories": [
{
"source": ".",
"build": ".",
"childIndexes": [ 1 ],
"projectIndex": 0,
"targetIndexes": [ 0 ],
"hasInstallRule": true,
"minimumCMakeVersion": {
"string": "3.14"
}
},
{
"source": "sub",
"build": "sub",
"parentIndex": 0,
"projectIndex": 0,
"targetIndexes": [ 1 ],
"minimumCMakeVersion": {
"string": "3.14"
}
}
],
"projects": [
{
"name": "MyProject",
"directoryIndexes": [ 0, 1 ],
"targetIndexes": [ 0, 1 ]
}
],
"targets": [
{
"name": "MyExecutable",
"directoryIndex": 0,
"projectIndex": 0,
"jsonFile": "<file>"
},
{
"name": "MyLibrary",
"directoryIndex": 1,
"projectIndex": 0,
"jsonFile": "<file>"
}
]
}
]
}
The members specific to codemodel
objects are:
paths
A JSON object containing members:
source
- A string specifying the absolute path to the top-level source directory, represented with forward slashes.
build
- A string specifying the absolute path to the top-level build directory, represented with forward slashes.
configurations
A JSON array of entries corresponding to available build configurations. On single-configuration generators there is one entry for the value of the
CMAKE_BUILD_TYPE
variable. For multi-configuration generators there is an entry for each configuration listed in theCMAKE_CONFIGURATION_TYPES
variable. Each entry is a JSON object containing members:name
- A string specifying the name of the configuration, e.g.
Debug
. directories
A JSON array of entries each corresponding to a build system directory whose source directory contains a
CMakeLists.txt
file. The first entry corresponds to the top-level directory. Each entry is a JSON object containing members:source
- A string specifying the path to the source directory, represented
with forward slashes. If the directory is inside the top-level
source directory then the path is specified relative to that
directory (with
.
for the top-level source directory itself). Otherwise the path is absolute. build
- A string specifying the path to the build directory, represented
with forward slashes. If the directory is inside the top-level
build directory then the path is specified relative to that
directory (with
.
for the top-level build directory itself). Otherwise the path is absolute. parentIndex
- Optional member that is present when the directory is not top-level.
The value is an unsigned integer 0-based index of another entry in
the main
directories
array that corresponds to the parent directory that added this directory as a subdirectory. childIndexes
- Optional member that is present when the directory has subdirectories.
The value is a JSON array of entries corresponding to child directories
created by the
add_subdirectory()
orsubdirs()
command. Each entry is an unsigned integer 0-based index of another entry in the maindirectories
array. projectIndex
- An unsigned integer 0-based index into the main
projects
array indicating the build system project to which the this directory belongs. targetIndexes
- Optional member that is present when the directory itself has targets,
excluding those belonging to subdirectories. The value is a JSON
array of entries corresponding to the targets. Each entry is an
unsigned integer 0-based index into the main
targets
array. minimumCMakeVersion
Optional member present when a minimum required version of CMake is known for the directory. This is the
<min>
version given to the most local call to thecmake_minimum_required(VERSION)
command in the directory itself or one of its ancestors. The value is a JSON object with one member:string
A string specifying the minimum required version in the format:
<major>.<minor>[.<patch>[.<tweak>]][<suffix>]
Each component is an unsigned integer and the suffix may be an arbitrary string.
hasInstallRule
- Optional member that is present with boolean value
true
when the directory or one of its subdirectories contains anyinstall()
rules, i.e. whether amake install
or equivalent rule is available.
projects
A JSON array of entries corresponding to the top-level project and sub-projects defined in the build system. Each (sub-)project corresponds to a source directory whose
CMakeLists.txt
file calls theproject()
command with a project name different from its parent directory. The first entry corresponds to the top-level project.Each entry is a JSON object containing members:
name
- A string specifying the name given to the
project()
command. parentIndex
- Optional member that is present when the project is not top-level.
The value is an unsigned integer 0-based index of another entry in
the main
projects
array that corresponds to the parent project that added this project as a sub-project. childIndexes
- Optional member that is present when the project has sub-projects.
The value is a JSON array of entries corresponding to the sub-projects.
Each entry is an unsigned integer 0-based index of another
entry in the main
projects
array. directoryIndexes
- A JSON array of entries corresponding to build system directories
that are part of the project. The first entry corresponds to the
top-level directory of the project. Each entry is an unsigned
integer 0-based index into the main
directories
array. targetIndexes
- Optional member that is present when the project itself has targets,
excluding those belonging to sub-projects. The value is a JSON
array of entries corresponding to the targets. Each entry is an
unsigned integer 0-based index into the main
targets
array.
targets
A JSON array of entries corresponding to the build system targets. Such targets are created by calls to
add_executable()
,add_library()
, andadd_custom_target()
, excluding imported targets and interface libraries (which do not generate any build rules). Each entry is a JSON object containing members:name
- A string specifying the target name.
id
- A string uniquely identifying the target. This matches the
id
field in the file referenced byjsonFile
. directoryIndex
- An unsigned integer 0-based index into the main
directories
array indicating the build system directory in which the target is defined. projectIndex
- An unsigned integer 0-based index into the main
projects
array indicating the build system project in which the target is defined. jsonFile
- A JSON string specifying a path relative to the codemodel file to another JSON file containing a “codemodel” version 2 “target” object.
“codemodel” version 2 “target” object¶
A codemodel “target” object is referenced by a “codemodel” version 2
object’s targets
array. Each “target” object is a JSON object
with members:
name
- A string specifying the logical name of the target.
id
- A string uniquely identifying the target. The format is unspecified and should not be interpreted by clients.
type
- A string specifying the type of the target. The value is one of
EXECUTABLE
,STATIC_LIBRARY
,SHARED_LIBRARY
,MODULE_LIBRARY
,OBJECT_LIBRARY
, orUTILITY
. backtrace
- Optional member that is present when a CMake language backtrace to
the command in the source code that created the target is available.
The value is an unsigned integer 0-based index into the
backtraceGraph
member’snodes
array. folder
Optional member that is present when the
FOLDER
target property is set. The value is a JSON object with one member:name
- A string specifying the name of the target folder.
paths
A JSON object containing members:
source
- A string specifying the path to the target’s source directory,
represented with forward slashes. If the directory is inside the
top-level source directory then the path is specified relative to
that directory (with
.
for the top-level source directory itself). Otherwise the path is absolute. build
- A string specifying the path to the target’s build directory,
represented with forward slashes. If the directory is inside the
top-level build directory then the path is specified relative to
that directory (with
.
for the top-level build directory itself). Otherwise the path is absolute.
nameOnDisk
- Optional member that is present for executable and library targets that are linked or archived into a single primary artifact. The value is a string specifying the file name of that artifact on disk.
artifacts
Optional member that is present for executable and library targets that produce artifacts on disk meant for consumption by dependents. The value is a JSON array of entries corresponding to the artifacts. Each entry is a JSON object containing one member:
path
- A string specifying the path to the file on disk, represented with forward slashes. If the file is inside the top-level build directory then the path is specified relative to that directory. Otherwise the path is absolute.
isGeneratorProvided
- Optional member that is present with boolean value
true
if the target is provided by CMake’s build system generator rather than by a command in the source code. install
Optional member that is present when the target has an
install()
rule. The value is a JSON object with members:prefix
A JSON object specifying the installation prefix. It has one member:
path
- A string specifying the value of
CMAKE_INSTALL_PREFIX
.
destinations
A JSON array of entries specifying an install destination path. Each entry is a JSON object with members:
path
- A string specifying the install destination path. The path may be absolute or relative to the install prefix.
backtrace
- Optional member that is present when a CMake language backtrace to
the
install()
command invocation that specified this destination is available. The value is an unsigned integer 0-based index into thebacktraceGraph
member’snodes
array.
link
Optional member that is present for executables and shared library targets that link into a runtime binary. The value is a JSON object with members describing the link step:
language
- A string specifying the language (e.g.
C
,CXX
,Fortran
) of the toolchain is used to invoke the linker. commandFragments
Optional member that is present when fragments of the link command line invocation are available. The value is a JSON array of entries specifying ordered fragments. Each entry is a JSON object with members:
fragment
- A string specifying a fragment of the link command line invocation. The value is encoded in the build system’s native shell format.
role
A string specifying the role of the fragment’s content:
flags
: link flags.libraries
: link library file paths or flags.libraryPath
: library search path flags.frameworkPath
: macOS framework search path flags.
lto
- Optional member that is present with boolean value
true
when link-time optimization (a.k.a. interprocedural optimization or link-time code generation) is enabled. sysroot
Optional member that is present when the
CMAKE_SYSROOT_LINK
orCMAKE_SYSROOT
variable is defined. The value is a JSON object with one member:path
- A string specifying the absolute path to the sysroot, represented with forward slashes.
archive
Optional member that is present for static library targets. The value is a JSON object with members describing the archive step:
commandFragments
Optional member that is present when fragments of the archiver command line invocation are available. The value is a JSON array of entries specifying the fragments. Each entry is a JSON object with members:
fragment
- A string specifying a fragment of the archiver command line invocation. The value is encoded in the build system’s native shell format.
role
A string specifying the role of the fragment’s content:
flags
: archiver flags.
lto
- Optional member that is present with boolean value
true
when link-time optimization (a.k.a. interprocedural optimization or link-time code generation) is enabled.
dependencies
Optional member that is present when the target depends on other targets. The value is a JSON array of entries corresponding to the dependencies. Each entry is a JSON object with members:
id
- A string uniquely identifying the target on which this target depends.
This matches the main
id
member of the other target. backtrace
- Optional member that is present when a CMake language backtrace to
the
add_dependencies()
,target_link_libraries()
, or other command invocation that created this dependency is available. The value is an unsigned integer 0-based index into thebacktraceGraph
member’snodes
array.
sources
A JSON array of entries corresponding to the target’s source files. Each entry is a JSON object with members:
path
- A string specifying the path to the source file on disk, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute.
compileGroupIndex
- Optional member that is present when the source is compiled.
The value is an unsigned integer 0-based index into the
compileGroups
array. sourceGroupIndex
- Optional member that is present when the source is part of a source
group either via the
source_group()
command or by default. The value is an unsigned integer 0-based index into thesourceGroups
array. isGenerated
- Optional member that is present with boolean value
true
if the source isGENERATED
. backtrace
- Optional member that is present when a CMake language backtrace to
the
target_sources()
,add_executable()
,add_library()
,add_custom_target()
, or other command invocation that added this source to the target is available. The value is an unsigned integer 0-based index into thebacktraceGraph
member’snodes
array.
sourceGroups
Optional member that is present when sources are grouped together by the
source_group()
command or by default. The value is a JSON array of entries corresponding to the groups. Each entry is a JSON object with members:name
- A string specifying the name of the source group.
sourceIndexes
- A JSON array listing the sources belonging to the group.
Each entry is an unsigned integer 0-based index into the
main
sources
array for the target.
compileGroups
Optional member that is present when the target has sources that compile. The value is a JSON array of entries corresponding to groups of sources that all compile with the same settings. Each entry is a JSON object with members:
sourceIndexes
- A JSON array listing the sources belonging to the group.
Each entry is an unsigned integer 0-based index into the
main
sources
array for the target. language
- A string specifying the language (e.g.
C
,CXX
,Fortran
) of the toolchain is used to compile the source file. compileCommandFragments
Optional member that is present when fragments of the compiler command line invocation are available. The value is a JSON array of entries specifying ordered fragments. Each entry is a JSON object with one member:
fragment
- A string specifying a fragment of the compile command line invocation. The value is encoded in the build system’s native shell format.
includes
Optional member that is present when there are include directories. The value is a JSON array with an entry for each directory. Each entry is a JSON object with members:
path
- A string specifying the path to the include directory, represented with forward slashes.
isSystem
- Optional member that is present with boolean value
true
if the include directory is marked as a system include directory. backtrace
- Optional member that is present when a CMake language backtrace to
the
target_include_directories()
or other command invocation that added this include directory is available. The value is an unsigned integer 0-based index into thebacktraceGraph
member’snodes
array.
defines
Optional member that is present when there are preprocessor definitions. The value is a JSON array with an entry for each definition. Each entry is a JSON object with members:
define
- A string specifying the preprocessor definition in the format
<name>[=<value>]
, e.g.DEF
orDEF=1
. backtrace
- Optional member that is present when a CMake language backtrace to
the
target_compile_definitions()
or other command invocation that added this preprocessor definition is available. The value is an unsigned integer 0-based index into thebacktraceGraph
member’snodes
array.
sysroot
Optional member that is present when the
CMAKE_SYSROOT_COMPILE
orCMAKE_SYSROOT
variable is defined. The value is a JSON object with one member:path
- A string specifying the absolute path to the sysroot, represented with forward slashes.
backtraceGraph
A JSON object describing the graph of backtraces whose nodes are referenced from
backtrace
members elsewhere. The members are:nodes
A JSON array listing nodes in the backtrace graph. Each entry is a JSON object with members:
file
- An unsigned integer 0-based index into the backtrace
files
array. line
- An optional member present when the node represents a line within the file. The value is an unsigned integer 1-based line number.
command
- An optional member present when the node represents a command
invocation within the file. The value is an unsigned integer
0-based index into the backtrace
commands
array. parent
- An optional member present when the node is not the bottom of
the call stack. The value is an unsigned integer 0-based index
of another entry in the backtrace
nodes
array.
commands
- A JSON array listing command names referenced by backtrace nodes. Each entry is a string specifying a command name.
files
- A JSON array listing CMake language files referenced by backtrace nodes. Each entry is a string specifying the path to a file, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute.
Object Kind “cache”¶
The cache
object kind lists cache entries. These are the
Variables stored in the persistent cache
(CMakeCache.txt
) for the build tree.
There is only one cache
object major version, version 2.
Version 1 does not exist to avoid confusion with that from
cmake-server(7)
mode.
“cache” version 2¶
cache
object version 2 is a JSON object:
{
"kind": "cache",
"version": { "major": 2, "minor": 0 },
"entries": [
{
"name": "BUILD_SHARED_LIBS",
"value": "ON",
"type": "BOOL",
"properties": [
{
"name": "HELPSTRING",
"value": "Build shared libraries"
}
]
},
{
"name": "CMAKE_GENERATOR",
"value": "Unix Makefiles",
"type": "INTERNAL",
"properties": [
{
"name": "HELPSTRING",
"value": "Name of generator."
}
]
}
]
}
The members specific to cache
objects are:
entries
A JSON array whose entries are each a JSON object specifying a cache entry. The members of each entry are:
name
- A string specifying the name of the entry.
value
- A string specifying the value of the entry.
type
- A string specifying the type of the entry used by
cmake-gui(1)
to choose a widget for editing. properties
A JSON array of entries specifying associated cache entry properties. Each entry is a JSON object containing members:
name
- A string specifying the name of the cache entry property.
value
- A string specifying the value of the cache entry property.
Object Kind “cmakeFiles”¶
The cmakeFiles
object kind lists files used by CMake while
configuring and generating the build system. These include the
CMakeLists.txt
files as well as included .cmake
files.
There is only one cmakeFiles
object major version, version 1.
“cmakeFiles” version 1¶
cmakeFiles
object version 1 is a JSON object:
{
"kind": "cmakeFiles",
"version": { "major": 1, "minor": 0 },
"paths": {
"build": "/path/to/top-level-build-dir",
"source": "/path/to/top-level-source-dir"
},
"inputs": [
{
"path": "CMakeLists.txt"
},
{
"isGenerated": true,
"path": "/path/to/top-level-build-dir/.../CMakeSystem.cmake"
},
{
"isExternal": true,
"path": "/path/to/external/third-party/module.cmake"
},
{
"isCMake": true,
"isExternal": true,
"path": "/path/to/cmake/Modules/CMakeGenericSystem.cmake"
}
]
}
The members specific to cmakeFiles
objects are:
paths
A JSON object containing members:
source
- A string specifying the absolute path to the top-level source directory, represented with forward slashes.
build
- A string specifying the absolute path to the top-level build directory, represented with forward slashes.
inputs
A JSON array whose entries are each a JSON object specifying an input file used by CMake when configuring and generating the build system. The members of each entry are:
path
- A string specifying the path to an input file to CMake, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute.
isGenerated
- Optional member that is present with boolean value
true
if the path specifies a file that is under the top-level build directory and the build is out-of-source. This member is not available on in-source builds. isExternal
- Optional member that is present with boolean value
true
if the path specifies a file that is not under the top-level source or build directories. isCMake
- Optional member that is present with boolean value
true
if the path specifies a file in the CMake installation.


End Xenophobia Against Asians
"It feeds and then it justifies existing stereotypes and racism around immigrants.
And then leads to discriminatory public health policies that disproportionately impact
specific immigrant groups and minority groups.”
- Erika Lee
Jessica Wong, of Fall River, Mass., front left, Jenny Chiang, of Medford, Mass., center, and
Sheila Vo, of Boston, from the state's Asian American Commission, stand together during a protest,
Thursday, March 12, 2020, on the steps of the Statehouse in Boston.
Interview Highlights on Asian American Discrimination
George Takei:
“Asian Americans are Americans. Certain segments of the Asian American
community have been here since the 1840s. We are many generations here. We are Americans.
And as a matter of fact, Asian Americans are a part of the front line doctors, nurses,
researchers looking for a cure. We are a part of America. And still we are seen in the
context of our ancestral land. My grandparents came from Japan.
"In the case of many of my Chinese American friends, it's their great-great-grandparents
that came from China. We are Americans. And still we are compared in the context of our
ancestral land. Yes, there are a lot of first generation and second generation Asian Americans,
but it's the same as with our German or Italian or Irish friends. They have been here a long
time and they are part of America, despite the fact that we still have immigration ... immigrants
coming from Germany or Italy or Ireland.”
Cathy Park Hong:
“It's a really scary and vulnerable time for Asian Americans, that
they are being scapegoated. Anyone who looks East Asian. And what I want to say is
I would say, allow yourself to be scared, but also allow yourself to be angry. I
think some of us — I wouldn't say all of us — some of us are activists, but some
of us are afraid to even be angry. And be enraged. And I'm hoping that we speak
out about this hate as much as possible and that we could be proactive about this
and we could fight the racism in this country.


The "Struts-EL" library contains a set of tag libraries, all of whose classes are derived from classes in the Struts tag libraries. The Struts-EL tags all implement the same attributes as their counterparts in the base Struts tag libraries. The difference provided by Struts-EL is that the tag attribute values are not evaluated as run-time scriptlets (sometimes called "rtexprvalue"s), but are instead evaluated by the expression language engine in the JavaServer Pages Standard Tag Library (often called the JSTL).
The Struts-EL library is intended to be used alongside the Struts library, and with the JSTL. In the development of the Struts-EL library, each tag in the Struts tag libraries was examined to see if all of its functionality is covered in an existing tag in the JSTL. If this was the case, then it was decided to not include a version of this tag in the Struts-EL library. The tags that were "ported" to Struts-EL were deemed to have functionality which the JSTL could not directly cover.
The rest of this package description will briefly review the Struts tags which were not ported to the Struts-EL library (or which were "on the bubble", and why. The detailed package descriptions for each section of the library (html-el, logic-el, and bean-el) will demonstrate in detail the usage of the Struts-EL tags, focusing on attribute value evaluation issues. Details of the operation of these tags in the Struts framework can be learned from the package descriptions and documentation for the base Struts library.
The following table lists the "struts-logic" tags which were not ported to the "struts-logic-el" tag library, including which JSTL elements or features will provide that functionality. Examples after the table will demonstrate these.
| Struts-Logic tag | JSTL tags or feature |
|---|---|
| empty | c:if, c:when, EL |
| equal | c:if, c:when, EL |
| greaterEqual | c:if, c:when, EL |
| greaterThan | c:if, c:when, EL |
| lessEqual | c:if, c:when, EL |
| lessThan | c:if, c:when, EL |
| notEmpty | c:if, c:when, EL |
| notEqual | c:if, c:when, EL |
The following are some examples of "Before" and "After", where the first example is pure Struts usage, and the second example will be pure JSTL usage, not involving Struts-EL at all.
Struts Example:
<logic:empty name="foo" property="stuff"> Some stuff </logic:empty>
JSTL Version:
<c:if test="${empty foo.stuff}"> Some stuff </c:if>
Struts Example:
<logic:notEmpty name="foo" property="stuff"> Some stuff </logic:notEmpty>
JSTL Version:
<c:if test="${!empty foo.stuff}"> Some stuff </c:if>
Struts Example:
<logic:equal name="foo" property="stuff" value="<%=thing.getStuff()%>"> Some stuff </logic:equal>
JSTL Version:
<%-- Assumes "thing" is a scoped variable --%> <c:if test="${foo.stuff eq thing.stuff}"> Some stuff </c:if>
Struts Example:
<logic:greaterThan name="foo" property="stuff" value="<%=thing.getStuff()%>"> Some stuff </logic:empty>
JSTL Version:
<%-- Assumes "thing" is a scoped variable --%> <c:if test="${foo.stuff ge thing.stuff}"> Some stuff </c:if>
Struts Example:
<logic:present cookie="shoppingCart"> Some stuff </logic:present>
JSTL Version:
<c:if test='${!empty cookie["shoppingCart"]}"> Some stuff </c:if>
Struts Example:
<logic:present header="User-Agent"> Some stuff </logic:present>
JSTL Version:
<c:if test='${!empty header["User-Agent"]}"> Some stuff </c:if>
The following table lists the "struts-bean" tags which were not ported to the "struts-bean-el" tag library, including which JSTL elements or features will provide that functionality. Examples after the table will demonstrate these.
| Struts-Bean tag | JSTL tags or feature |
|---|---|
| cookie | c:set, EL |
| define | c:set, EL |
| header | c:set, EL |
| include | c:import |
| parameter | c:set, EL |
| write | c:out |
Note that the "bean:resource" Struts tag is similar, at least superficially, to the functionality of the "c:import" tag, but "bean:resource" was ported to the Struts-EL library. This is because resources requested through the "c:import" tag may be processed through a mapped servlet, preventing direct access to the resource. The "bean:resource" tag allows direct access to the resource, without an intervening servlet. For instance, if it is desired to obtain the raw text of a JSP page, using "c:import" will not work, because the JSP page will be processed by the JSP servlet. However, using "bean:resource" will retrieve just the text of the JSP page, if that is desired.
Also note that some functionality of the "bean:include" tag, which was not ported to the Struts-EL library, is not available in the JSTL. This includes the ability to specify the name of a Struts forward, and the ability to include the current transaction control token. These features will be addressed in a future minor release of Struts-EL.
The following are some examples of "Before" and "After", where the first example is pure Struts usage, and the second example will be pure JSTL usage, not involving Struts-EL at all.
Struts Example:
<bean:cookie id="cookieVal" name="stuff"/>
JSTL Version:
<c:set var="cookieVal" value='${cookie["stuff"]}'/>
Struts Example:
<bean:define id="thing" name="foo" property="stuff"/>
JSTL Version:
<c:set var="thing" value="${foo.stuff}"/>
Struts Example:
<bean:header id="headerVal" name="stuff"/>
JSTL Version:
<c:set var="headerVal" value='${header["stuff"]}'/>
Struts Example:
<bean:include id="stuffOut" href="http://somewhere.com/stuff.jsp"/>
JSTL Version:
<c:import var="stuffOut" value="http://somewhere.com/stuff.jsp"/>
Struts Example:
<bean:parameter id="parameterVal" name="stuff"/>
JSTL Version:
<c:set var="parameterVal" value='${param["stuff"]}'/>


Smooth Slideshow v2.1
Jondesign's
What does it look like ?
- Live on JonDesign websites
- Examples
JonDesign's Smooth SlideShow Library
Using mootools (there is also a moo.fx version available), this javascript slideshow system allows you to have a simple and smooth (cross-fading...) image slideshows and/or showcases on your website.
Why consider it instead of Flash ?
- Let's imagine you want to add a showcase of your last products, or even a showcase of one product on your homepage. Would you want to restrict it only to the users who have Flash enabled ?
- Another important point is the fact that using this script, you will have fully standard compliant web pages (which is important for accessibility, for example).
Wow cool ! How much does it costs ?
Nothing, this library is open-source, GPL licensed to be precise.
On what browsers does it run ?
Since it's based on the mootools library, it's somehow platform agnostic. I have fully tested it on:
- Firefox
- Opera
- Internet Explorer v6
Users reported successful tests on Safari.
Want to tell me about how it works on other browsers ? Sure! Just contact me by email or by google talk at<EMAIL_ADDRESS>What's new in version 2 ?
While maintaining nearly the same installation steps, a major rethinking of the internal architecture has been done in this version.
Now, what changed exactly ?
- All the code is now wrapped in objects, permitting you to put more than one slideshow at a time in the same webpage.
- Images don't have to be at the same size as the slideshow. This way you can use different image ratio for one instance of smoothslideshow.
- JonDesign's SmoothSlideshow now uses mootools instead of moo.fx and prototype.lite.js (but don't worry, there is still a version using moo.fx available ;-))
- Some graphical changes (yeah everyone wants to look cool :-))
- And last but not least, a lot of bugfixes.
How to use it ?
To use it, just insert those lines of code in your html files:
In the header
-
Include those lines in your header (external requirements):

 -
Then include in your header:
- If you want the timed mode:
- If you want the showcase ("changed by hand") mode:
- And finally, include the css: <link rel="stylesheet" href="css/jd.slideshow.css" type="text/css" media="screen" />
In your web page
-
This code (here I added 2 elements) to define the slideshow elements:
 As you see, the first argument is the image file (relative to the current document).
The second one is the url of the page the current element links to.
The third one is the title, and finally, the last one is the current element's description. -
Prepare a container for your slideshow:

 -
Then add this code to launch the slideshow (you can also put it in a separate JS file):
-
If you want the timed mode:
 -
If you want the showcase ("changed by hand") mode:

-
If you want the timed mode:


I_AM_LEGEND has been producing music since he was in school. In high school he would make beats inside of his film and media classes and email them so that he could listen to them at home. He has worked with a few artists and has competed in beat competitions. What makes this producer stand out is his ability to take a sound, warp it, and turn it into something enjoyable to hear. He's got a bright future ahead of him. Some say he's the next Kanye West.


Back to Main Page
Get a PDF version of this page
These buttons are hidden by a WOConditional on the printed version.
This page is in landscape
A big Apache logo


When interpreting changesets from TFVC, the TFS plugin will attempt to map domain accounts (i.e. DOMAIN\alias
) to Jenkins accounts.
The default mapping strategy (Resolve user using 'DOMAIN\alias') is to provide the string (received from TFVC) as-is to Jenkins, which causes Jenkins to convert the username from DOMAIN\alias
to DOMAIN_alias
. If your Jenkins users are named with a different convention, try another user mapping strategy.


Media Queries
Basic
1000
900
800
700
600
500
Orientation Portrait
Orientation Landscape
Orientation Landscape 500


Resize window to less than 768 pixels to display mobile menu toggle button.
Toggle navigation
A menu
Link 1
Link 2
Toggle collapse Vertically
Some content
Toggle collapse Horizontally
Some content


|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object edu.cmu.sphinx.linguist.acoustic.tiedstate.MixtureComponent
public class MixtureComponent
Defines the set of shared elements for a GaussianMixture. Since these elements are potentially
shared by a number of GaussianMixtures
, these elements should not be
written to. The GaussianMixture defines a single probability density function along with a set of
adaptation parameters.
| Field Summary | |
|---|---|
static float |
DEFAULT_DIST_FLOOR
|
static float |
DEFAULT_VAR_FLOOR
|
| Constructor Summary | |
|---|---|
MixtureComponent(LogMath logMath,
float[] mean,
float[] variance)
Create a MixtureComponent with the given sub components. |
|
MixtureComponent(LogMath logMath,
float[] mean,
float[][] meanTransformationMatrix,
float[] meanTransformationVector,
float[] variance,
float[][] varianceTransformationMatrix,
float[] varianceTransformationVector)
Create a MixtureComponent with the given sub components. |
|
MixtureComponent(LogMath logMath,
float[] mean,
float[][] meanTransformationMatrix,
float[] meanTransformationVector,
float[] variance,
float[][] varianceTransformationMatrix,
float[] varianceTransformationVector,
float distFloor,
float varianceFloor)
Create a MixtureComponent with the given sub components. |
| Method Summary | |
|---|---|
MixtureComponent |
clone()
|
float[] |
getMean()
Returns the mean for this component. |
float |
getScore(float[] feature)
Calculate the score for this mixture against the given feature. |
float |
getScore(FloatData feature)
Calculate the score for this mixture against the given feature. |
float[] |
getVariance()
Returns the variance for this component. |
float |
precomputeDistance()
Pre-compute factors for the Mahalanobis distance. |
java.lang.String |
toString()
|
void |
transformStats()
Applies transformations to means and variances. |
| Methods inherited from class java.lang.Object |
|---|
equals, getClass, hashCode, notify, notifyAll, wait, wait, wait |
| Field Detail |
|---|
public static final float DEFAULT_VAR_FLOOR
public static final float DEFAULT_DIST_FLOOR
| Constructor Detail |
|---|
public MixtureComponent(LogMath logMath, float[] mean, float[] variance)
logMath
- the log math to usemean
- the mean vector for this PDFvariance
- the variance for this PDFpublic MixtureComponent(LogMath logMath, float[] mean, float[][] meanTransformationMatrix, float[] meanTransformationVector, float[] variance, float[][] varianceTransformationMatrix, float[] varianceTransformationVector)
logMath
- the log math to usemean
- the mean vector for this PDFmeanTransformationMatrix
- transformation matrix for this pdfmeanTransformationVector
- transform vector for this PDFvariance
- the variance for this PDFvarianceTransformationMatrix
- var. transform matrix for this PDFvarianceTransformationVector
- var. transform vector for this PDFpublic MixtureComponent(LogMath logMath, float[] mean, float[][] meanTransformationMatrix, float[] meanTransformationVector, float[] variance, float[][] varianceTransformationMatrix, float[] varianceTransformationVector, float distFloor, float varianceFloor)
logMath
- the log math to usemean
- the mean vector for this PDFmeanTransformationMatrix
- transformation matrix for this pdfmeanTransformationVector
- transform vector for this PDFvariance
- the variance for this PDFvarianceTransformationMatrix
- var. transform matrix for this PDFvarianceTransformationVector
- var. transform vector for this PDFdistFloor
- the lowest score value (in linear domain)varianceFloor
- the lowest value for the variance| Method Detail |
|---|
public float[] getMean()
public float[] getVariance()
public float getScore(FloatData feature)
DoubleData
-features would require an array conversion to
float[]. Because getScore might be invoked with very high frequency, features are restricted
to be FloatData
s.
feature
- the feature to score
public float getScore(float[] feature)
Normal(x) = exp{-0.5 * (x-m)' * inv(Var) * (x-m)} / {sqrt((2 * PI) ^ N) * det(Var))}
where x and m are the incoming cepstra and mean vector respectively, Var is the Covariance matrix, det() is the determinant of a matrix, inv() is its inverse, exp is the exponential operator, x' is the transposed vector of x and N is the dimension of the vectors x and m.
feature
- the feature to score
public float precomputeDistance()
{sqrt((2 * PI) ^ N) * det(Var))}
public void transformStats()
public MixtureComponent clone() throws java.lang.CloneNotSupportedException
clone
in class java.lang.Object
java.lang.CloneNotSupportedException
public java.lang.String toString()
toString
in class java.lang.Object
|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Webring integration
A webring is a list of website links in a cicular structure, with a common theme.
We recommend Max Böck's excellent Webring Kit to start your own dynamic-URLs based webring, but you can always just link directly.
A webring is a list of website links in a cicular structure, with a common theme.
We recommend Max Böck's excellent Webring Kit to start your own dynamic-URLs based webring, but you can always just link directly.


| I l@ve RuBoard |
Although we haven't gotten very formal about it, we've already been using functions in earlier chapters. For instance, to make a file object, we call the built-in open function. Similarly, we use the len built-in function to ask for the number of items in a collection object.
In this chapter, we will learn how to write new functions in Python. Functions we write ourselves behave the same way as the built-ins we've already seen—they are called in expressions, are passed values, and return results. But writing functions requires a few new ideas; here's an introduction to the main concepts:
Python functions are written with a new statement, the def. Unlike functions in compiled languages such as C, def is an executable statement—when run, it generates a new function object and assigns it to the function's name. As with all assignments, the function name becomes a reference to the function object.
When a function is called, the caller stops until the function finishes its work and returns control to the caller. Functions that compute a value send it back to the caller with a return statement.
By default, all names assigned in a function are local to that function and exist only while the function runs. To assign a name in the enclosing module, functions need to list it in a global statement.
In Python, arguments are passed to functions by assignment (i.e., by object reference). As we'll see, this isn't quite like C's passing rules or C++'s reference parameters—the caller and function share objects by references, but there is no name aliasing (changing an argument name doesn't also change a name in the caller).
As with everything in Python, there are no type constraints on functions. In fact, nothing about a function needs to be declared ahead of time; we can pass in arguments of any type, return any sort of object, and so on. As one consequence, a single function can often be applied to a variety of object types.
Let's expand on these ideas and look at a few first examples.
The def statement creates a function object and assigns it a function name. As with all compound Python statements, it consists of a header line, followed by a block of indented statements. The indented statements become the function's body—the code Python executes each time the function is called. The header specifies a function name (which is assigned the function object), along with a list of arguments (sometimes called parameters ), which are assigned to the objects passed in parentheses at the point of call:
def <name>(arg1, arg2,... argN): <statements> return <value>
The Python return statement can show up in function bodies; it ends the function call and sends a result back to the caller. It consists of an object expression that gives the function's result. The return is optional; if it's not present, a function exits when control flow falls off the end of the function body. Technically, a function without a return returns the None object automatically (more on this later in this chapter).
Let's jump into a simple example. There are really two sides to the function picture: a definition (the def that creates a function) and a call (an expression that tells Python to run the function). A definition follows the general format above; here's one that defines a function called times, which returns the product of its two arguments:
>>> def times(x, y): # create and assign function ... return x * y # body executed when called ...
When Python runs this def, it creates a new function object that packages the function's code and assigns it the name times. After the def has run, the program can run (call) the function by adding parentheses after the function name; the parenthesis may optionally contain one or more object arguments, to be passed (assigned) to the names in the function's header:
>>> times(2, 4) # arguments in parentheses 8 >>> times('Ni', 4) # functions are 'typeless' 'NiNiNiNi'
In the first line, we pass two arguments to times: the name x in the function header is assigned the value 2, y is assigned 4, and the function's body is run. In this case, the body is just a return statement, which sends back the result 8 as the value of the call expression.
In the second call, we pass in a string and an integer to x and y instead. Recall that * works on both numbers and sequences; because there are no type declarations in functions, you can use times to multiply numbers or repeat sequences. Python is known as a dynamically typed language: types are associated with objects at runtime, rather than declared in the program itself. In fact, a given name can be assigned to objects of different types at different times.[1]
[1] If you've used compiled languages such as C or C++, you'll probably find that Python's dynamic typing makes for an incredibly flexible programming language. It also means that some errors a compiler roots out aren't caught by Python until a program runs (adding a string to an integer, for instance). Luckily, errors are easy to find and repair in Python.
Here's a more realistic example that illustrates function basics. Near the end of Chapter 3, we saw a for loop that collected items in common in two strings. We noted there that the code wasn't as useful as it could be because it was set up to work only on specific variables and could not be rerun later. Of course, you could cut and paste the code to each place it needs to be run, but this isn't a general solution; you'd still have to edit each copy to support different sequence names, and changing the algorithm requires changing multiple copies.
By now, you can probably guess that the solution to this dilemma is to package the for loop inside a function. By putting the code in a function, it becomes a tool that can be run as many times as you like. And by allowing callers to pass in arbitrary arguments to be processed, you make it general enough to work on any two sequences you wish to intersect. In effect, wrapping the code in a function makes it a general intersection utility:
def intersect(seq1, seq2): res = [] # start empty for x in seq1: # scan seq1 if x in seq2: # common item? res.append(x) # add to end return res
The transformation from simple code to this function is straightforward; you've just nested the original logic under a def header and made the objects on which it operates parameters. Since this function computes a result, you've also added a return statement to send it back to the caller.
>>> s1 = "SPAM" >>> s2 = "SCAM" >>> intersect(s1, s2) # strings ['S', 'A', 'M'] >>> intersect([1, 2, 3], (1, 4)) # mixed types [1]
Again, we pass in different types of objects to our function—first two strings and then a list and a tuple (mixed types). Since you don't have to specify the types of arguments ahead of time, the intersect function happily iterates though any kind of sequence objects you send it.[2]
[2] Technically, any object that responds to indexing. The for loop and in tests work by repeatedly indexing an object; when we study classes in Chapter 6, you'll see how to implement indexing for user-defined objects too, and hence iteration and membership.
| I l@ve RuBoard |


We exchange networks!
- extend granular partnerships
- grow transparent e-markets
- incubate holistic vortals
- redefine vertical experiences
- extend leading-edge deliverables
- brand cutting-edge vortals
- architect mission-critical paradigms
- matrix cutting-edge mindshare
- engage 24/365 paradigms
- transform best-of-breed markets
- engage value-added convergence
- engineer open-source deliverables
- empower sticky partnerships


{% extends "layout-vary.html" %} {% block page_title %} Prove your identity in the UK {% endblock %} {% block content %} How did you login last time? Choose Royal Mail Choose Post Office Choose CitizenSafe Choose Dutch identity details Choose Experian Choose SecureIdentity Choose Digidentity Choose Barclays {% endblock %}


Show Password
Must use all alphabet sets
Copyright © 2014 Jimmi Thøgersen
Based on ideas from PasswordMaker.
Includes code from:


Ecological Network Status Client
Current Species Counts
Species
Count
not connected
not connected
Webserver Status
Connect / Disconnect
Stop Simulation
Restart Simulation
Clear


xunk-calendar
This is an example for xunk-calendar, a simple calendar for Angular 5+ and Angular Material.
If you want it in your project, head over to the github repo
Selected Date is {{ selDate.year }}-{{ selDate.month + 1}}-{{ selDate.date }}
Month is {{ month.month }}, year is {{ month.year }}
Getting this was as simple as
Selected Date is {{ selDate.year }}-{{ selDate.month + 1}}-{{ selDate.date }}


Download the form and read the instructions. Collect the necessary documents to demonstrate your eligibility for naturalization. If you reside outside the United States, get 2 passport-style photo taken. Use the document checklist to make sure you collect all the required documents.
Once you submit Form N-400, USCIS will send you a receipt notice. You can check current processing times and the status of your application online or by calling the National Customer Service Center at 1-800-375-5283 or 1-800-767-1833 (hearing impaired).
Once all the preliminary processes on your case are complete, USCIS will schedule an interview with you to complete the naturalization process. You must report to the USCIS office at the date and time on your appointment notice. Please bring the appointment notice with you.
You are not a U.S. citizen until you take the Oath of Allegiance at a naturalization ceremony.
Complete the questionnaire on Form N-445, Notice of Naturalization Oath Ceremony. Report for your naturalization ceremony and check in with USCIS. A USCIS officer will review your responses to Form N-445. Turn in your Permanent Resident Card (Green Card). Take the Oath of Allegiance to become a U.S. citizen. Receive your Certificate of Naturalization, review it, and notify USCIS of any errors you see on your certificate before leaving the ceremony site.
Citizenship is the common thread that connects all Americans. Check out this list of some of the most important rights and responsibilities that all citizens—both Americans by birth and by choice—should exercise, honor, and respect.
For more detailed information on the naturalization process, please visit the Citizenship Through Naturalization page. For information on naturalization for members of the U.S. armed forces, please visit the citizenship for military personnel and family members page.


Lying to the NE of Skopelos, this long, thin island is wooded and hilly. Together with several small off lying islands, it forms the National Marine Part of Alonnisos.
The main port on this island is Patitiri. Moor stern-to off the NE quay or anchor fore and aft off the beach in the western part of the harbour. Limited space.
There are now new service poles for water and electricity available on the quay. Water quality is reported to be excellent. Unless leaving before 6am, you are charged an extra day (at 15 euro per day).
Cruisers report a nasty surge here (see comment below).
Last updated June 2015.


Welcome to E-Nation’s Constitution!¶
Worldwide Physical Distributed Nation
The innovative Social Pact of the New Global Nation that break with the slavery of human farm governments, by Giving the Power to Citizens.
You may view this constitution in the following languages:


The 27th International Conference on Computer Graphics and Applications (Pacific Graphics 2019) was held at Korea University, Seoul, Korea, on October 14-17, 2019. Pacific Graphics is a flagship conference of the Asia Graphics Association. Pacific Graphics provides a premium forum for researchers, developers, and practitioners in the Pacific Rim and around the world to present and discuss new problems, solutions, and technologies in computer graphics and related areas.
This year Pacific Graphics received 222 submissions, which were reviewed by a Program Committee of 108 international experts and 154 external reviewers. Each submission underwent a rigorous review process. The Program Co-Chairs assigned each paper to a primary reviewer and a secondary reviewer selected from the Program Committee. The primary invited external reviewers so that each paper received at least three reviews. The decision of the first review cycle was made after the authors’ rebuttal and extensive discussions among the reviewers. Each of the accepted full papers underwent a second review cycle to ensure that the necessary revisions indicated in the reviews were carried out.
Out of 222 submissions, 74 full papers (acceptance rate: 33.3%) and 9 short papers were selected for oral presentation at the conference. 69 of the full papers are published in the special issue of Computer Graphics Forum and 5 of them will be published in the regular issue of Computer Graphics Forum after major revision. All the accepted full and short papers are published electronically through the EG Digital Library and presented in a two-track format at the conference. The conference program also includes presentations of four recent articles from regular issues of IEEE Transactions on Visualization and Computer Graphics and another four articles from regular issues of Computer Graphics Forum. They are presented together with regular papers. The conference also features three keynote speeches by Markus Gross, Alla Sheffer, and Masahiko Inami.
The work-in-progress and poster sessions are an integral part of the conference program, which provides an opportunity for authors to display late-breaking technical achievements that are not yet ready for publication or added on previous publication. While conference attendees receive the abstracts and supplemental material for the work-in-progress and poster program, this material does not appear in any archival libraries since work-in-progress and posters are not formal publications.
We wish to thank the members of the international program committee and the external reviewers for doing thorough reviews despite short review and discussion periods. We are also very grateful to Stefanie Behnke for her help with the submission and review management system, Michael Wimmer for providing the paper sorting script, and Hwangpil Park for his help with conference scheduling and administration. Finally, we would like to thank the authors for their support of this venue and congratulate them for the high quality of the papers compiled into the proceedings.
Korea University
Trinity College Dublin
University of British Columbia
Seoul National University
Max Planck Institute for Informatics
Stanford University
Original unpublished papers are invited in all areas of computer graphics and its applications. The topics include (but are not limited to) modeling, rendering, animation, and imaging, as well as visualization, human-computer interaction, and graphics systems and applications. Any interesting new ideas related to computer graphics and applications are welcome.
The conference proceedings of Pacific Graphics 2019 will be published as an issue of the Eurographics journal, Computer Graphics Forum (CGF), in print and online. Regular (full) papers will be presented in oral sessions and appear in the journal issue. A few submissions with strong potentials but not accepted as regular papers will be recommended for a second review cycle of CGF after major revisions. Short papers will be accepted but will be published electronically through the EG digital library. Extended versions of selected, high-quality, short papers will be invited to ACM Computers in Entertainment.
Submission System here.
LaTeX-Template is available here.
For the first time in Pacific Graphics, the Pacific Graphics 2019 welcomes work-in-progress and poster submissions from all areas of computer graphics, such as modeling,
rendering, animation, imaging, visualization, human-computer interaction, and graphics systems. Authors are encouraged to submit work-in-progress and practical applications
to demonstrate a novel and applicable ideas in all aspects of computer graphics. Authors of accepted work-in-progress papers will have an approximately fifteen-minute oral
presentation of their work at the conference. Accepted posters will be displayed during the conference and also will form the focus of a poster session in conjunction with one
of the social events. Authors of accepted posters are expected to present their posters during the poster session to discuss their work and answer questions. More details will
follow when the conference program is finalized.
Authors can make an electronic submission through the Submission and Review Management (https://srmv2.eg.org/COMFy/Conference/PG_2019P). Authors are asked to
indicate their preferences whether the submission needs to be considered as a work-in-progress paper or a poster. When both options are selected, the work will first be
reviewed as a work-in-progress paper, and then evaluated as a poster submission. Work-in-progress papers and posters submission should strive not to exceed two pages
and must be formatted according to the Pacific Graphics Author’s guideline. Authors may accompany a preliminary version of the actual poster if they choose to be considered
as a poster submission. The review process will be double-blind. Please remove all personal data (e.g., names, affiliation, etc.) from your submission.
The detailed program schedule is available here : [Program Schedule]
Markus Gross
Abstract:
For more than a decade, DisneyResearch|Studios has been pushing the forefront of scientific and technological
innovation to advance entertainment products, experiences and shows. Our research covers a broad spectrum
of different fields including graphics, vision, augmented and virtual reality, machine learning and AI,
as well as interactive technologies. Our innovations are experienced by hundreds of millions of audiences and
customers across the world. In this talk I will give and overview of our core research programs including digital
humans, story technology, interactive content creation, video processing, and audience understanding. Furthermore,
I will share my insights into the fundamental differences between academic and corporate research and highlight the
challenges of transferring technology into products.
Short bio:
Markus Gross is a Professor of Computer Science at the Swiss Federal Institute of Technology Zurich (ETH), head of
the Computer Graphics Laboratory, Vice President Research, Walt Disney Studios and the director of DisneyResearch|Studios.
He joined the ETH Computer Science faculty in 1994. His research interests include physically based modeling,
computer animation, immersive displays, and video technology. Before joining Disney, Gross was director of the Institute of
Computational Sciences at ETH. He received a master of science in electrical and computer engineering and a PhD in computer
graphics and image analysis, both from Saarland University in Germany in 1986 and 1989. Gross serves on the boards of numerous
international research institutes, societies, and governmental organizations. He received the Technical Achievement Award from
EUROGRAPHICS in 2010 and the Swiss ICT Champions Award in 2011. He is a fellow of the ACM and of the EUROGRAPHICS
Association and a member of the German Academy of Sciences Leopoldina as well as the Berlin-Brandenburg Academy of Sciences
and Humanities. In 2013 he received the Konrad Zuse Medal of GI, the Karl Heinz Beckurts price. In 2013 and 2019 he received a
Technical Achievement Award from the Academy of Motion Picture Arts and Sciences. He cofounded Cyfex AG, Novodex AG,
LiberoVision AG, Dybuster AG, Gimalon AG, Kapanu AG, Perceptiko AG, Propulsion Academy AG, Arbrea Labs AG, Nanocorp AG
and Animatico AG.
Alla Sheffer
Abstract:
Humans have developed multiple ways to communicate about both tangible and abstract shape properties. Artists and designers
can quickly and effectively convey complex shapes to a broad audience using traditional mediums such as paper, while both experts
and the general public can analyze and agree on intangible shape properties such as style or aesthetics. While perception research
provides some clues as to the mental processes humans employ when performing these tasks, concrete and quantifiable
explanations of these actions are still lacking.
Short bio:
Alla Sheffer is a professor of Computer Science at the University of British Columbia, where she investigates algorithms for shape
modeling and analysis in the context of computer graphics applications. She is best known for her research on mesh
parameterization, hexahedral meshing, computational garment design, and perception driven shape modeling. Dr. Sheffer is the
recipient of the Canadian Human Computer Communications Society Achievement Award’18. Her research has been supported by
faculty awards from IBM, Google and Adobe, Discovery, Discovery Accelerator and I2I NSERC grants, a Killam research fellowship, and
an Audi Production Award. Dr. Sheffer has served as an Associate Editor of all three major computer graphics journals (ACM
Transactions on Graphics, IEEE Transactions on Visualization Computer Graphics, and Eurographics Computer Graphics Forum).
She served as a program co-chair for Eurographics’18, Symposium on Geometry Processing’06, and Shape Modeling’13. She was
a general co-chair for the Pacific Graphics’18 and Geometric Modeling and Processing’19 conferences. Dr. Sheffer had co-authored
over 100 peer-reviewed publications, including 42 papers in ACM Transactions on Graphics, the topmost competitive CG venue; 22
of these were published in the last five years. She holds six recent patents on methods for sketch analysis and hexahedral
mesh generation.
Masahiko Inami
Abstract:
The social revolutions have accompanied innovation of the view of the body. If we regard the information revolution as establishment
of a virtual society against the real society, it is necessary to design a new view of body "JIZAI body (Virtual Cyborg)", which can adapt
freely to the change of social structure, and establish a new view of the body.
In this talk, we discuss how we understand of basic knowledge about the body editing for construction of JIZAI body (Virtual Cyborg)
basedon VR, AR and Robotics. Superhuman Sports: Applying Human Augmentation to Physical Exercise.
This talk will also present Superhuman Sports, a form of "Human-Computer Integration” to overcome somatic and spatial
limitation of humanity by merging technology with the body. In Japan, official home of the 2020 Olympics and Paralympics , we hope
to create a future of sports where everyone, strong or weak, young or old, non-disabled or disabled, can play and enjoy playing
without being disadvantaged.
Short bio:
Masahiko Inami, Ph.D.
Professor, Research Center for Advanced Science and Technology, the University of Tokyo
Dr. Masahiko Inami took up his current position as professor at the University of Tokyo after working at the University of
Electro-Communications and Keio University. His interests include “JIZAI body editing technology,” the Augmented Human, and
entertainment engineering. He has received several awards, including TIME Magazine’s “Coolest Invention of the Year” award and
the Young Scientist Award from the Ministry of Education, Culture, Sports, Science, and Technology (MEXT). He is also the co-representative
of the Superhuman Sports Society and a director of the VR Consortium.
| JungHyun Han | Korea University |
| Carol O'Sullivan | Trinity College Dublin |
| Michiel van de Panne | University of British Columbia |
| Jehee Lee | Seoul National University |
| Christian Theobalt | MPI Informatik |
| Gordon Wetzstein | Stanford University |
| Sung-Eui Yoon | KAIST |
| Min-H-Kim | KAIST |
| Kang Hoon Lee | Kwangwoon University |
| Youngmin Kim | Seoul National University |
| Dongho Kim | Soongsil University |
| Heewon Kye | Hansung University |
| Jinho Park | Soongsil University |
| Joon-Kyung Seong | Korea University |
| Min Gyu Choi | Kwangwoon University |
*The Conference banquet will take place on Oct. 16th at Sudang Faculty House.
There is no decent hotel within the walking distance to Korea University. However, since the conference venue is situated in the most convenient location with great public transportation network, any hotel along the subway stations will allow conference guests to access to the conference venue with ease. For hotel booking, you may check out the agencies like Hotels.com, Booking.com.
JW Marriott Dongdaemun Square Seoul
http://www.jwmarriottddm.com
LOTTE Hotel Seoul
https://www.lottehotel.com/seoul-hotel/en.html
Novotel Ambassador Seoul Dongdaemun Hotels & Residences
https://www.ambatel.com/novotel/dongdaemun/en/main.do
Best Western Arirang Hill Dongdaemun
https://www.hotelahill.com
Ramada Encore by Wyndham Seoul Dongdaemun
http://www.ramadaencoreseouldongdaemun.com
Hamilton Hotel
https://www.hamilton.co.kr
Imperial Palace Boutique Hotel
http://www.imperialpalaceboutiquehotel.com
Visit Seoul http://english.visitseoul.net/index


Methods
back() → {*}
Get the element at the back of the queue without dequeueing it.
Returns:
Return the element at the back of the queue, or undefined if the queue is empty
- Type
- *
clear()
Clear the queue.
dequeue() → {*}
Remove an element from the front of the queue.
Returns:
Return the dequeued element, or -1 if the queue is empty
- Type
- *
enqueue(element)
Add an element to the back of the queue.
Parameters:
| Name | Type | Description |
|---|---|---|
element |
* | Any data type |
front() → {*}
Get the element at the front of the queue without dequeueing it.
Returns:
Return the element at the front of the queue, or undefined if the queue is empty
- Type
- *
getLength() → {number}
Get the length of the queue.
Returns:
Return the length/number of elements in the queue
- Type
- number
isEmpty() → {Boolean}
Determine whether the queue is empty or not.
Returns:
Return true if queue is empty, false if not
- Type
- Boolean
toString() → {string}
Get a string representation of the queue.
Returns:
Return string representation of the queue (using Object.prototype.toString())
- Type
- string


class: center, middle, inverse, title-slide # Welcome! ### BaselRBootcamp
www.therbootcamp.com
@therbootcamp
### July 2018 --- # Welcome!

 --- .pull-left5[ # Materials

 Get all of the course materials through our homepage!

 www.therbootcamp.com

 Bookmark it :)

  ] .pull-right5[

 ] --- # Aim .pull-left6[ >###The aim of this workshop is enable you to thoughtfully and actively use R. We will communicate both the basics of the R language, as well as cutting-edge packages for wrangling, analyzing, and communicating statistical data. ] .pull-right4[

 ] --- # Principles We all have different backgrounds and learn at different speeds Best way to learn?  We're here to help (but we won't make it too easy for you) You'll never master a language (certainly not in 2 weekends), you'll always be learning. Have fun and keep it light, learning a programming language should be (often) fun! # BaselRBootcamp logo --- .pull-left4[ # Schedule We have a very intense and ambitious schedule!
 The amount of material we will be covering in two short weekends is...crazy
 The course is separated into different sessions
 ### Two Tracks There is both a beginner and advanced track
 Red sessions are generally more advanced than Gray sessions

 ] .pull-right55[  ] --- .pull-left45[
 # Sessions Each session is 2 hours
 Introduction lecture with slides (45 - 75 min)
 Hands-on programming practical
 ] .pull-right55[  ] --- .pull-left45[

 # Introduction 45 - 75 minute slide based introduction Theory + code examples + live demonstrations Goal: Help you understand the basic concepts All available online! Follow along on your computer. Don't worry about memorizing Be interactive! Ask questions! ] .pull-right5[ ] --- .pull-left45[ # Practicals This is where you really learn how to program! Anywhere from 10 ~ 30 programming tasks. Starts easy, gets progressively more challenging Struggle, work together, ask questions and challenge yourself We are here to help! But won't make it too easy for you :) You will **not** be able to finish all of the tasks. That's ok! ] .pull-right5[  ] --- .pull-left5[

 # ~15 min, 1-1 Coaching Sometimes, you may find yourself in need of some intensive help. That's ok! We're here to help! At any time, you can request a 15 minute 1-1 intensive help / coaching session We'll find some space and help you with whatever you're struggling with ] .pull-right45[  ] --- # Cheatsheets

RStudio IDE

Base R

Data Import

Data Transformation

Data Visualization

 --- .pull-left4[

 # Breaks Feel free to take breaks when you need them! Help yourself to refreshments Coffee machine nearby (1 CHF) Lunch on your own or together at Tibits ] .pull-right6[

Tibits

 ] --- .pull-left35[ # Introductions 1. What is your name?

 2. Where are you from?

 3. What is your programming experience?

 4. Why do you want to learn R?

 5. Coffee or tea?

 6. Pizza or pasta?

 7. Beer or wine?

 8. Berlin or Paris? ] .pull-right6[

 ] ---

 --- # Session 1: What is R?
Link to Session 1: What is R?


Company profile - Canadian Company Capabilities
Third-Party Information Liability Disclaimer
Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.
Regal Beloit Canada ULC dba Thomson Power Systems
Legal Name:
Regal Beloit Canada ULC dba Thomson Power Systems
Operating Name:
Thomson Power Systems
Mailing Address:
9087A 198th StLANGLEY, British Columbia
V1M 3B1
Location Address:
9087A 198th StLANGLEY, British Columbia
V1M 3B1
Tel.:<PHONE_NUMBER>
Tel.:<PHONE_NUMBER>
Fax:<PHONE_NUMBER>
Logo
Company Profile
Thomson Power Systems designs, manufactures and services power generation switchgear for prime power, standby, distributed generation and cogeneration applications. Other products include automatic and bypass isolation transfer switches, engine generator controllers, loadbanks, battery chargers and remote monitoring and control software. We also provide full field commissioning and customer training packages.
Full profile
Full profile
Contact information
Company description
Product / Service / Licensing
over 40 years of product development and system design
experience. Each product option has been field tested and
certified by qualified Thomson engineering and field service
personnel providing our customers with proven quality and
reliability. Standard designs are available to fit most
applications and can be adapted to fit an owner's specific
requirements. Custom engineered systems and design
recommendations are available for those applications requiring a
unique design approach. System 2000 series of products can be
utilized with diesel or gas engine generator sets, as well as
gas, steam or hydro electric turbines. Applications include
prime power, cogeneration distributed generation and standby. By
incorporating advanced communication interfaces, System 2000
products can operate in harmony with any site or building
management system, providing maximum equipment utilization and
total energy management.
Visit our website at www.thomsonps.com.
Type "D" (double-sided) isolates the transfer switch and can
bypass either the utility or generator source of the load, as
selected by the operator. Single-sided types "U" (utility
bypass) and "G" (generator bypass) can bypass only one source to
the load, and can provide isolation when used in conjunction with
a generator output circuit breaker. Numerous control features
are available as standard or optional accessories to provide the
desired sensing, time delay, and switching logic.
TLB-H and TLB-V
Also available are two models of fixed mounted resistive test load banks:
LBI and LBO
Thomson resistive test load banks utilize coiled chromium alloy load elements supported with cool cast ceramic insulators. 4.5 maximum continuous spacing is provided between each support point. All load resistor ends are fitted with silver soldered stainless steel connection studs.Thomsons cool load® resistor design guaranteeslower operating temperatures and extended life in the most adverse environments.
Market profile
Industry sector market interests:
- Manufacturing
- Mining/Petroleum/Gas
Geographic markets:
Export experience:
- Algeria
- Australia
- Brazil
- Hong Kong
- Iran, Islamic Republic of
- Japan
- Mexico
- Russian Federation
- Singapore
- Taiwan
- United Kingdom
- United States
- Alabama
- Alaska
- Arizona
- Arkansas
- California
- Colorado
- Connecticut
- Delaware
- District of Columbia
- Florida
- Georgia
- Hawaii
- Idaho
- Illinois
- Indiana
- Iowa
- Kansas
- Kentucky
- Louisiana
- Maine
- Maryland
- Massachusetts
- Michigan
- Minnesota
- Mississippi
- Missouri
- Montana
- Nebraska
- Nevada
- New Hampshire
- New Jersey
- New Mexico
- New York
- North Carolina
- North Dakota
- Ohio
- Oklahoma
- Oregon
- Pennsylvania
- Rhode Island
- South Carolina
- South Dakota
- Tennessee
- Texas
- Utah
- Vermont
- Virginia
- Washington
- West Virginia
- Wisconsin
- Wyoming
Sector information
Total plant size:
Distribution of employees:
Admin, Accounting, Systems - 14Sales - 29
Engineering & R&D - 29
Production & Materials - 69
Service - 11
Third-Party Information Liability Disclaimer
Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.
Contacts
Contact information
Description
Company description
Products, services and licensing
Product / Service / Licensing
over 40 years of product development and system design
experience. Each product option has been field tested and
certified by qualified Thomson engineering and field service
personnel providing our customers with proven quality and
reliability. Standard designs are available to fit most
applications and can be adapted to fit an owner's specific
requirements. Custom engineered systems and design
recommendations are available for those applications requiring a
unique design approach. System 2000 series of products can be
utilized with diesel or gas engine generator sets, as well as
gas, steam or hydro electric turbines. Applications include
prime power, cogeneration distributed generation and standby. By
incorporating advanced communication interfaces, System 2000
products can operate in harmony with any site or building
management system, providing maximum equipment utilization and
total energy management.
Visit our website at www.thomsonps.com.
Type "D" (double-sided) isolates the transfer switch and can
bypass either the utility or generator source of the load, as
selected by the operator. Single-sided types "U" (utility
bypass) and "G" (generator bypass) can bypass only one source to
the load, and can provide isolation when used in conjunction with
a generator output circuit breaker. Numerous control features
are available as standard or optional accessories to provide the
desired sensing, time delay, and switching logic.
TLB-H and TLB-V
Also available are two models of fixed mounted resistive test load banks:
LBI and LBO
Thomson resistive test load banks utilize coiled chromium alloy load elements supported with cool cast ceramic insulators. 4.5 maximum continuous spacing is provided between each support point. All load resistor ends are fitted with silver soldered stainless steel connection studs.Thomsons cool load® resistor design guaranteeslower operating temperatures and extended life in the most adverse environments.
Market
Market profile
Industry sector market interests:
- Manufacturing
- Mining/Petroleum/Gas
Geographic markets:
Export experience:
- Algeria
- Australia
- Brazil
- Hong Kong
- Iran, Islamic Republic of
- Japan
- Mexico
- Russian Federation
- Singapore
- Taiwan
- United Kingdom
- United States
- Alabama
- Alaska
- Arizona
- Arkansas
- California
- Colorado
- Connecticut
- Delaware
- District of Columbia
- Florida
- Georgia
- Hawaii
- Idaho
- Illinois
- Indiana
- Iowa
- Kansas
- Kentucky
- Louisiana
- Maine
- Maryland
- Massachusetts
- Michigan
- Minnesota
- Mississippi
- Missouri
- Montana
- Nebraska
- Nevada
- New Hampshire
- New Jersey
- New Mexico
- New York
- North Carolina
- North Dakota
- Ohio
- Oklahoma
- Oregon
- Pennsylvania
- Rhode Island
- South Carolina
- South Dakota
- Tennessee
- Texas
- Utah
- Vermont
- Virginia
- Washington
- West Virginia
- Wisconsin
- Wyoming
Sector
Sector information
Total plant size:
Distribution of employees:
Admin, Accounting, Systems - 14Sales - 29
Engineering & R&D - 29
Production & Materials - 69
Service - 11


WITNESS LIST Natural Resources Committee February 14, 2005-2:00P State Agency/Organizational On: Holcomb, Doug (Texas Commission on Environmental Quality) Shankle, Glenn (Texas Commission on Environmental Quality) Ward, J. Kevin (Texas Water Development Board) White, Kathleen (Texas Commission on Environmental Quality)


We got interfaces!
- architect B2B vortals
- reintermediate end-to-end paradigms
- facilitate intuitive eyeballs
- recontextualize strategic bandwidth
- brand B2C web-readiness
- grow granular initiatives
- synergize front-end convergence
- productize visionary portals
- leverage dot-com markets
- integrate customized functionalities
- revolutionize dynamic portals
- deliver holistic supply-chains
- transform open-source schemas
- maximize revolutionary channels
- unleash end-to-end platforms


Tag Yourself !
Home
Uddhav
Siddharth
Anshul
Vitobha
Kedar
Rohit
Chaitra
Karan J
Karan P
Imran
Vivek T
Mayank
Krithi
Spoorthy
Prasad
Keisuke
Utsav
Shruti
People in Lab
None
People count
0


I'm excited to learn about pretty much anything. Recently, I've been into functional programming in Haskell.
Ultimately, I am interested in pursing a career path that involves machine learning, artificial intelligence, and entrepreneurship.
When I am not performing computer magic, I am a strong advocate for Starcraft 2, Eminem, dysfunctional pickup basketball games, and the podcast JavaScript Jabber.


To-Do List
Try to click "+" on the top right corner
This is a sample to-do task :)
Click on the task to finish me
Click the trash icon to delete me


Computes attributable effects based confidence interval, permutation test confidence interval, or asymptotic confidence interval for the the average treatment effect on a binary outcome.
| Version: | 1.3 |
| Imports: | compiler, gtools, Rcpp |
| LinkingTo: | Rcpp |
| Suggests: | testthat |
| Published: | 2016-10-21 |
| Author: | Joseph Rigdon, Wen Wei Loh, Michael G. Hudgens |
| Maintainer: | Wen Wei Loh <wwloh at email.unc.edu> |
| License: | GPL (≥ 3) |
| NeedsCompilation: | yes |
| CRAN checks: | RI2by2 results |
| Reference manual: | RI2by2.pdf |
| Package source: | RI2by2_1.3.tar.gz |
| Windows binaries: | r-devel: RI2by2_1.3.zip, r-release: RI2by2_1.3.zip, r-oldrel: RI2by2_1.3.zip |
| OS X binaries: | r-release: RI2by2_1.3.tgz, r-oldrel: RI2by2_1.3.tgz |
| Old sources: | RI2by2 archive |
Please use the canonical form https://CRAN.R-project.org/package=RI2by2 to link to this page.


Hi guys Would like some enlightment or ideas on this, i want to make a powerfull 2 weapon wielder, with weapon master as one of the classes prefently, with good AB and not too low AC with decent saves and playable from lvl 1-40. Can be str or dex based but pref str based to dish more damage. ps:not the bioware kukrimaster
Edited By AZAZ3L on 11/16/05 09:03
What about the improved kukri master? _________________ HEAD KNIGHT: Shh shh. We are now the Knights Who Say Ekke ekke ekke ptang zoo boing! RANDOM: Ni!
Ferny, its considered boastin when you link your own build! jk
I am not sure, but when I read the title, i assumed he wants 2 weapons! There is a build that i read a month or 2 ago that had both mace and handaxe (slash and bludgeon) in wm build (both master lvl LOL) and had incredibly high ab (as i recall). It was kaliban's build, here's the link Click Here Peace


This dashboard is wrapped within a custom control that will be used on all pages to create the header we saw on the home page. Components can be full pages, but also sub-components that are used anywhere in the app that the component has scope (components are scoped within Modules, which we won't discuss on this demo).


{% extends 'questionnaire/analytics/base.html' %} {% load app_filters %} {% block css %} {% endblock %} {% block title %}Worker sentiment analytics{% endblock %} {% block body_class %}worker-sentiment analytics-page{% endblock %} {% block content %}
Currently selected:
All
| # | Type | Date | Campaign | Temperature | Humidity | Acoustics | Natural Light | Interior Lighting |
|---|---|---|---|---|---|---|---|---|
| {{ forloop.counter }} | {{ answer_group.0.subject.type }} | {{ answer_group.0.answered_at|date:"d/m/Y" }} | {{ campaign }} | {% for answer in answer_group %} {% with answer_text=answer.get_answer_text %}{{ answer_text }} | {% endwith %} {% endfor %}
Currently selected:
All
Currently selected:
All


Minimal Mistakes is a flexible two-column Jekyll theme. Perfect for hosting your personal site, blog, or portfolio on GitHub or self-hosting on your own server. As the name implies — styling is purposely minimalistic to be enhanced and customized by you :smile:.
The theme includes responsive layouts (single
, archive
, and splash
pages) that look great on mobile and desktop browsers.
| Name | Description |
|---|---|
| Post with Header Image | A post with a large header image. |
| HTML Tags and Formatting Post | A variety of common markup showing how the theme styles them. |
| Syntax Highlighting Post | Post displaying highlighted code. |
| Post with a Gallery | A post showing several images wrapped in <figure> elements. |
| Sample Collection Page | Single page from a collection. |
| Categories Archive | Posts grouped by category. |
| Tags Archive | Posts grouped by tags. |
For even more demo pages check the posts archive.
Having trouble working with the theme? Found a typo in the documentation? Interested in adding a feature or fixing a bug? Then by all means submit an issue or pull request. If this is your first pull request, it may be helpful to read up on the GitHub Flow first.
Minimal Mistakes has been designed as a base for you to customize and fit your site’s unique needs. Please keep this in mind when requesting features and/or submitting pull requests. If it’s not something that most people will use, I probably won’t consider it. When in doubt ask.
This goes for author sidebar links and “share button” additions – I have no intention of merging in every possibly option, the essentials are there to get you started :smile:.
To help me out try to avoid creating pull requests on master
and instead branch off of develop
. It’s much easier for me to test, merge, and roll them into new releases this way.
The MIT License (MIT)
Copyright (c) 2016 Michael Rose
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


We all know that being a student can hit the bank account pretty hard… So why not get paid for something that is minimum effort and doesn’t interrupt whatever you’re getting up to over the vac.
It’s pretty simple, all you have to do is invite your mates to Finimize by sending them your personal link on all and every platform you wish to. We’ll even give you tips on how to do this quickly and effectively.
If you haven't already signed up to be an affiliate...
If you get 10 signups we’ll pay you £10! You will also get an extra £1 for every extra signup. (So 23 signups would get you £23!)
Most of our ambassadors get £15-25 from a single facebook post, but many go on to earn much more by thinking outside the box.
You'll receive your payout roughly 2 weeks after you get your first signup.
£71
£45
You’re creative and I know you’ve got this, but here are a few ideas to get the juices flowing. 💪
The rules are simple and mutually beneficial 🤜💥🤛