Domino Class Reference
[Example scripts (models)]
Example: Solitaire domino More...
Public Types | |
| enum | { PROP_ELEMENT, PROP_EXTENSIONAL } |
Propagation to use for model. More... | |
Public Member Functions | |
| Domino (const SizeOptions &opt) | |
| Actual model. | |
| virtual void | print (std::ostream &os) const |
| Print solution. | |
| Domino (Domino &s) | |
| Constructor for cloning s. | |
| virtual Space * | copy (void) |
| Copy space during cloning. | |
Related Functions | |
(Note that these are not member functions.) | |
| const unsigned int | n_examples |
| Number of board specifications. | |
Puzzle specifications | |
|
| |
| const int * | specs [] |
| Board specifications. | |
| const int | domino0 [] |
| Example 0 | |
| const int | domino1 [] |
| Example 1 | |
| const int | domino2 [] |
| Example 2 | |
| const int | domino3 [] |
| Example 3 | |
| const int | domino4 [] |
| Example 4 | |
| const int | domino5 [] |
| Example 5 | |
| const unsigned | n_examples = sizeof(specs)/sizeof(int*) |
| Number of specifications. | |
| const int * | specs [] |
| List of specifications. |
Detailed Description
Example: Solitaire domino
The task is to place domino pieces on a board. Each piece covers two fields and has two numbers. There are 28 pieces, from 0-0 to 6-6. The board is set up with a number in each field that must match the number of the domino piece placed on that field.
Definition at line 68 of file domino.cpp.
Member Enumeration Documentation
| anonymous enum |
Propagation to use for model.
Definition at line 82 of file domino.cpp.
Constructor & Destructor Documentation
| Domino::Domino | ( | const SizeOptions & | opt | ) | [inline] |
Actual model.
Definition at line 88 of file domino.cpp.
| Domino::Domino | ( | Domino & | s | ) | [inline] |
Constructor for cloning s.
Definition at line 206 of file domino.cpp.
Member Function Documentation
| virtual void Domino::print | ( | std::ostream & | os | ) | const [inline, virtual] |
Print solution.
Reimplemented from Gecode::Driver::ScriptBase< BaseSpace >.
Definition at line 193 of file domino.cpp.
| virtual Space* Domino::copy | ( | void | ) | [inline, virtual] |
Copy space during cloning.
Definition at line 212 of file domino.cpp.
Friends And Related Function Documentation
const int* specs[] [related] |
const unsigned int n_examples [related] |
Number of board specifications.
Definition at line 53 of file domino.cpp.
const int domino0[] [related] |
{ 8,7, 2,1,0,3,0,4,5,5, 6,2,0,6,3,1,4,0, 3,2,3,6,2,5,4,3, 5,4,5,1,1,2,1,2, 0,0,1,5,0,5,4,4, 4,6,2,1,3,6,6,1, 4,2,0,6,5,3,3,6 }
Example 0
Definition at line 249 of file domino.cpp.
const int domino1[] [related] |
{ 8,7, 5,1,2,4,6,2,0,5, 6,6,4,3,5,0,1,5, 2,0,4,0,4,0,5,0, 6,1,3,6,3,5,4,3, 3,1,0,1,2,2,1,4, 3,6,6,2,4,0,5,4, 1,3,6,1,2,3,5,2 }
Example 1
Definition at line 263 of file domino.cpp.
const int domino2[] [related] |
{ 8,7, 4,4,5,4,0,3,6,5, 1,6,0,1,5,3,4,1, 2,6,2,2,5,3,6,0, 1,3,0,6,4,4,2,3, 3,5,5,2,4,2,2,1, 2,1,3,3,5,6,6,1, 5,1,6,0,0,0,4,0 }
Example 2
Definition at line 277 of file domino.cpp.
const int domino3[] [related] |
{ 8,7, 3,0,2,3,3,4,4,3, 6,5,3,4,2,0,2,1, 6,5,1,2,3,0,2,0, 4,5,4,1,6,6,2,5, 4,3,6,1,0,4,5,5, 1,3,2,5,6,0,0,1, 0,5,4,6,2,1,6,1 }
Example 3
Definition at line 291 of file domino.cpp.
const int domino4[] [related] |
{ 8,7, 4,1,5,2,4,4,6,2, 2,5,6,1,4,6,0,2, 6,5,1,1,0,1,4,3, 6,2,1,1,3,2,0,6, 3,6,3,3,5,5,0,5, 3,0,1,0,0,5,4,3, 3,2,4,5,4,2,6,0 }
Example 4
Definition at line 305 of file domino.cpp.
const int domino5[] [related] |
{ 8,7, 4,1,2,1,0,2,4,4, 5,5,6,6,0,4,6,3, 6,0,5,1,1,0,5,3, 3,4,2,2,0,3,1,2, 3,6,5,6,1,2,3,2, 2,5,0,6,6,3,3,5, 4,1,0,0,4,1,4,5 }
Example 5
Definition at line 319 of file domino.cpp.
const unsigned n_examples = sizeof(specs)/sizeof(int*) [related] |
Number of specifications.
Definition at line 336 of file domino.cpp.
| const int * specs | ( | ) | [related] |
List of specifications.
Definition at line 333 of file domino.cpp.
The documentation for this class was generated from the following file:
- examples/domino.cpp


Exporting a Jenkins Pipeline
In this tutorial, you will pull an example blueprint that declares Kubernetes resources and two kpt functions. Then you will export a pipeline that runs the functions against the resources on Jenkins. To make the generated pipeline work, extra steps that you may need is covered in the tutorial. This tutorial takes about 20~25 minutes.
A kpt version v0.32.0
or higher is required.
Before you begin
New to Jenkins? Here is a tutorial.
Before diving into the following tutorial, you need to create a public repo on GitHub if you don’t have one yet, e.g. function-export-example
.
On your local machine, create an empty directory:
mkdir function-export-example
cd function-export-example
All commands must be run at the root of this directory.
Use kpt pkg get
to fetch source files of this tutorial:
# Init git
git init
git remote add origin https://github.com/<USER>/<REPO>.git
# Fetch source files
kpt pkg get https://github.com/GoogleContainerTools/kpt/package-examples/function-export-blueprint example-package
Then you will get an example-package
directory:
resources/resources.yaml
: declares aDeployment
and aNamespace
.resources/constraints/
: declares constraints used by thegatekeeper-validate
function.functions.yaml
: runs two functions from Kpt Functions Catalog declaratively:gatekeeper-validate
enforces constraints over all resources.label-namespace
adds a label to all Namespaces.
Creating a Jenkins instance
If you do not have a Jenkins instance yet, you can refer to this page to create one on GCP step by step, or launch a prebuilt Jenkins VM
instance on the Marketplace.
Installing Docker on the Jenkins Agents
The exported pipeline leverages docker to run the kpt container, so you also need to install docker on the Jenkins agents.
-
Install docker using the convenience script.
curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh
-
Add the
jenkins
user to thedocker
group so that docker commands can be run in Jenkins pipelines.sudo usermod -aG docker jenkins
-
Reboot the VM to let it take effect.
Create a project on Jenkins
- Go to
<instance ip>: 8080
, clickNew Item
on the left sidebar to create a new project. - Enter
function-export-example
as name, selectPipeline
, and clickOK
. - In the newly created project, click
Configure
to set up. - In the
Pipeline
section, selectPipeline script from SCM
asDefinition
,Git
asSCM
, and your repo url asRepository URL
. - Click
Save
at the bottom.
Exporting a pipeline
kpt fn export example-package --workflow jenkins --output Jenkinsfile
Running this command on your local machine will get a Jenkinsfile like this:
pipeline {
agent any
stages {
stage('Run kpt functions') {
steps {
// This requires that docker is installed on the agent.
// And your user, which is usually "jenkins", should be added to the "docker" group to access "docker.sock".
sh '''
docker run \
-v $PWD:/app \
-v /var/run/docker.sock:/var/run/docker.sock \
gcr.io/kpt-dev/kpt:latest \
fn run /app/example-package
'''
}
}
}
}
Integrating with your existing pipeline
Now you can manually copy and paste the Run kpt functions
stage in the Jenkinsfile
into your existing pipeline. This stage can be run with any agent as long as docker is installed on that agent, and your jenkins
user is added to the docker
group to access docker.sock
file on the host. Basically, you do not have to do anything if you follow the instructions from the beginning as it is covered.
If you do not have one, you can simply copy the exported Jenkinsfile
into your project root. It is fully functional.
If you want to see the diff after running kpt functions, append a git diff
step . Your final Jenkinsfile
looks like this:
pipeline {
agent any
stages {
stage('Run kpt functions') {
steps {
// This requires that docker is installed on the agent.
// And your user, which is usually "jenkins", should be added to the "docker" group to access "docker.sock".
sh '''
docker run \
-v $PWD:/app \
-v /var/run/docker.sock:/var/run/docker.sock \
gcr.io/kpt-dev/kpt:latest \
fn run /app/example-package
'''
sh '''
git diff
'''
}
}
}
}
Viewing the result on Jenkins
git add .
git commit -am 'Init pipeline'
git push --set-upstream origin master
Once the changes are committed and pushed, you can go to your Jenkins server at <instance ip>:8080
and click Build Now
on the left sidebar in your project page. Then you will see a latest job like this:
Next step
Try to remove the owner: alice
line in example-package/resources/resources.yaml
.
Once local changes are pushed, build again on Jenkins, then you can see how it fails.


|
ENet
v1.3.14
Reliable UDP networking library
|
Functions | |
| void | enet_deinitialize (void) |
| Shuts down ENet globally. More... | |
| int | enet_initialize (void) |
| Initializes ENet globally. More... | |
| int | enet_initialize_with_callbacks (ENetVersion version, const ENetCallbacks *inits) |
| Initializes ENet globally and supplies user-overridden callbacks. More... | |
| ENetVersion | enet_linked_version (void) |
| Gives the linked version of the ENet library. More... | |
| void enet_deinitialize | ( | void | ) |
#include <include/enet/enet.h>
Shuts down ENet globally.
Should be called when a program that has initialized ENet exits.
| int enet_initialize | ( | void | ) |
#include <include/enet/enet.h>
Initializes ENet globally.
Must be called prior to using any functions in ENet.
| int enet_initialize_with_callbacks | ( | ENetVersion | version, |
| const ENetCallbacks * | inits | ||
| ) |
#include <include/enet/enet.h>
Initializes ENet globally and supplies user-overridden callbacks.
Must be called prior to using any functions in ENet. Do not use enet_initialize() if you use this variant. Make sure the ENetCallbacks structure is zeroed out so that any additional callbacks added in future versions will be properly ignored.
| version | the constant ENET_VERSION should be supplied so ENet knows which version of ENetCallbacks struct to use |
| inits | user-overridden callbacks where any NULL callbacks will use ENet's defaults |
| ENetVersion enet_linked_version | ( | void | ) |
#include <include/enet/enet.h>
Gives the linked version of the ENet library.


Please's BUILD files typically contain a series of build rule declarations. These are
invocations of builtins like java_binary
which create new BUILD targets.
However, you can do much more with it; the syntax is actually a restricted Python subset so it's possible to script the creation of build targets in elaborate ways. See below for a formal description of the grammar.
You can do most things that one might consider "simple" Python; for
and
if
statements, define functions, create lists and dicts, etc. Conventionally
we keep complex logic in build_defs files but at present there is no difference in accepted
syntax between the two.
Since it is not possible to import
things, one obviously requires a different
method of sharing code; in Please that is subinclude.
This function takes the output of a build rule elsewhere in the repo and makes it available
in the context of the currently executing file - for example, if it has defined a function,
that function is now available in your BUILD file at the top level.
See here for a full description of available builtin rules.
The set of builtin types are again a subset of Python's:
True
, False
and None
are singletons which are
instantiated by name.Specifically there are no classes, sets, floats or bytes. Tuples don't exist as a standalone type, in various cases lists are generated as a replacement. In some cases the runtime may prohibit modification of a list or dict when they can be shared between multiple BUILD files in order to prevent one from seeing another's modifications.
Dictionaries are somewhat restricted in function; they may only be keyed by strings and cannot
be iterated directly - i.e. one must use keys()
, values()
or
items()
. The results of all these functions are always consistently ordered.
The following functions are available as builtins; unless otherwise noted they mimic Python's builtins in most cases (although this is not guaranteed to every possible nuance).
len
enumerate
zip
isinstance
range
any
all
sorted
Several additional builtin functions are also available:
package_name
- returns the package being currently parsed.join_path
- like os.path.join
split_path
- like os.path.split
splitext
- like os.path.splitext
basename
- like os.path.basename
dirname
- like os.path.dirname
exec
- like subprocess.Popen
The following are available as member functions of strings:
join
split
replace
partition
rpartition
startswith
endswith
format
- although this lacks some functionality, %
is generally preferredlstrip
rstrip
strip
find
rfind
count
upper
lower
The following are available as member functions of dictionaries:
keys
values
items
copy
Finally, messages can be logged to Please's usual logging mechanism. These
may or may not be displayed depending on the -v
flag; by default only
warning
and above are visible.
log.debug
log.info
log.notice
log.warning
log.error
log.fatal
- this will cause the process to exit immediately and unsuccessfully.We normally write BUILD files in an idiom which doesn't quite match standard Python styles. The justification is that these are mostly just inherited from working on Blaze, but a brief explanation follows after an example:
# Taken from //src/core/BUILD in the Please repo
go_library(
name = 'core',
srcs = glob(['*.go'], exclude=['*_test.go', 'version.go']) + [':version'],
visibility = ['PUBLIC'],
deps = [
'//third_party/go:gcfg',
'//third_party/go:logging',
'//third_party/go:queue',
]
)
All arguments to build rules are passed as keywords. This is pretty important since (1) nobody will be able to read your BUILD file otherwise and (2) while we don't normally change the order of function arguments, we might sometimes insert earlier ones which will break code using positional arguments.
Arguments to functions like glob()
and subinclude()
are not
necessarily passed as keywords.
We put spaces around the =
for each argument to the build rule.
Either single or double quotes work, as usual, but don't mix both in one file.
Lists either go all on one line:
['*_test.go', 'version.go']
or are broken across multiple lines like so:
[
'//third_party/go:gcfg',
'//third_party/go:logging',
'//third_party/go:queue',
]
Indentation is normally four spaces.
We generally try to order lists lexicographically but don't always get this 100%.
If you'd like an autoformatter for BUILD files, Google's Buildifier is very good & fast. We use a slightly modified version of it internally & on the Please repo.
The grammar is defined as (more or less) the following, where Ident
,
String
, Int
and EOL
are token types emitted by the lexer.
{{ .Grammar }}
As mentioned above, this is similar to Python but lacks the import
, try
,
except
, finally
, class
, global
,
nonlocal
, while
and async
keywords. The implementation
may happen to permit using these as identifiers although it's discouraged (some tools might
attempt to operate on the file using Python's ast
module for convenience, which would not
be possible if those keywords are used).
As a result, while raise
and assert
are supported, it's
not possible to catch and handle the resulting exceptions. These hence function only to
signal an error condition which results in immediate termination.
A more limited set of operators than in Python are available. The provided set are considered sufficient for use in BUILD files.
Function annotations similar to PEP-3107
/ PEP-484 are available, although
they have first-class meaning as type hints. The arguments are annotated with the expected
type or types (separated by |
) and when called the type of the argument will
be verified to match. This makes it easier to give useful feedback to users if they
make mistakes in their BUILD files (e.g. passing a string where a list is required).
Varargs and kwargs functions are not supported.
PEP-498 style string interpolation is available, but it is much more limited than in Python; it can only interpolate variable names rather than arbitrary expressions.


Chicago Lobbyists Version 2 Is Here
by Derek Eder
Dec 2, 2011 – We just rolled out a new version of Chicago Lobbyists last night. Thanks to our meetings with Chicago CDO Brett Goldstein and the efforts from his staff, we now have the ability to show:
- What clients paid to each lobbyist (and how much)
- Which actions clients hired lobbyists to take
- How much money each client spent (total) on lobbyists in 2010
The new data also seems to have been cleaned up and normalized quite a bit (we still had to do some normalizing ourselves – especially with addresses), resulting in a more accurate picture of lobbying activity in Chicago for 2010.
Here is a rundown of the new features:
Most active clients is now determined by amount spent instead of number of lobbyists hired (Salvation Army, you are now #1 with $380,000 spent on lobbyists in 2010)
-
All detail pages have a summary section at the top, displaying total amounts, number of lobbyists, number of clients, number of firms, and number of actions (depending on what you’re viewing). Here’s an example of each:
- Lobbyist – Ronald Johnson
- Firm – Neal & Leroy, LLC
- Client – Fifth Third Bank
- Agency – City Council
Global site search (using Google custom search engine)
Every lobbyist action has a client associated with it
Every lobbyist payment shows the client who paid them
Categorized lobbyist expenditures (office expenses, food, travel, education, etc) are now listed
We cross referenced the City of Chicago Payments database, and listed all payments by Chicago to each client (example: Christy Webber Landscapes)
All detail pages now have tabs for each section so you can see all the rich data, without cluttering the page
All data on the detail pages is sortable and searchable (thanks to jQuery Datatables)
- All detail pages have comments (powered by Disqus)
We’re all really excited about these new updates.  That’s something to be proud of.
blog comments powered by Disqus
An open process
In the spirit of openness, the goal of this blog is to share our milestones, setbacks and thoughts as we continue to develop and expand this project.
Who are we?
We are Open City, a group of developers and designers based in Chicago that build civic-minded apps using open data.
- Paul Baker
- President and co-founder of Webitects
- Derek Eder
- Developer at Webitects and organizer for OpenGov Chicago
- Chad W Pry
- Engineer at Groupon, Code Academy mentor, and all around charming fellow
- Nick Rougeux
- Designer and CSS wiz at Webitects


$interval
ng
Angular's wrapper for window.setInterval
. The fn
function is executed every delay
milliseconds.
The return value of registering an interval function is a promise. This promise will be
notified upon each tick of the interval, and will be resolved after count
iterations, or
run indefinitely if count
is not defined. The value of the notification will be the
number of iterations that have run.
To cancel an interval, call $interval.cancel(promise)
.
In tests you can use $interval.flush(millis)
to
move forward by millis
milliseconds and trigger any functions scheduled to run in that
time.
$interval(fn, delay[, count][, invokeApply]);
| Param | Type | Details |
|---|---|---|
| fn | function() |
A function that should be called repeatedly. |
| delay | number |
Number of milliseconds between each function call. |
| count
(optional)
|
number |
Number of times to repeat. If not set, or 0, will repeat indefinitely. (default: 0) |
| invokeApply
(optional)
|
boolean |
If set to (default: true) |
| promise |
A promise which will be notified on each iteration. |


Language
Select Language
{{language.viewValue}}
Unit of Distance
Select Distance
{{distance.viewValue}}
Unit of Capacity
Select Capacity
{{capacity.viewValue}}
Unit of Temperature
Select Temperature
{{temperature.viewValue}}
Time Zone
Select Time Zone
{{time.viewValue}}


flask.blueprints
~~~~~~~~~~~~~~~~
Blueprints are the recommended way to implement larger or more
pluggable applications in Flask 0.7 and later.
:copyright: (c) 2011 by Armin Ronacher.
:license: BSD, see LICENSE for more details.
from functools import update_wrapper
from .helpers import _PackageBoundObject, _endpoint_from_view_func
Temporary holder object for registering a blueprint with the
class BlueprintSetupState(object):
application. An instance of this class is created by the
:meth:~flask.Blueprint.make_setup_state
method and later passed
to all register callback functions.
def __init__(self, blueprint, app, options, first_registration):
: a reference to the current application
self.app = app
: a reference to the blueprint that created this setup state.
self.blueprint = blueprint
: a dictionary with all options that were passed to the
: :meth:~flask.Flask.register_blueprint
method.
self.options = options
: as blueprints can be registered multiple times with the : application and not everything wants to be registered : multiple times on it, this attribute can be used to figure : out if the blueprint was registered in the past already.
self.first_registration = first_registration
subdomain = self.options.get('subdomain')
if subdomain is None:
subdomain = self.blueprint.subdomain
: The subdomain that the blueprint should be active for, None
: otherwise.
self.subdomain = subdomain
url_prefix = self.options.get('url_prefix')
if url_prefix is None:
url_prefix = self.blueprint.url_prefix
: The prefix that should be used for all URLs defined on the : blueprint.
self.url_prefix = url_prefix
: A dictionary with URL defaults that is added to each and every : URL that was defined with the blueprint.
self.url_defaults = dict(self.blueprint.url_values_defaults)
self.url_defaults.update(self.options.get('url_defaults', ()))
A helper method to register a rule (and optionally a view function)
def add_url_rule(self, rule, endpoint=None, view_func=None, **options):
to the application. The endpoint is automatically prefixed with the blueprint's name.
if self.url_prefix:
rule = self.url_prefix + rule
options.setdefault('subdomain', self.subdomain)
if endpoint is None:
endpoint = _endpoint_from_view_func(view_func)
defaults = self.url_defaults
if 'defaults' in options:
defaults = dict(defaults, **options.pop('defaults'))
self.app.add_url_rule(rule, '%s.%s' % (self.blueprint.name, endpoint),
view_func, defaults=defaults, **options)
Represents a blueprint. A blueprint is an object that records
class Blueprint(_PackageBoundObject):
functions that will be called with the
:class:~flask.blueprint.BlueprintSetupState
later to register functions
or other things on the main application. See :ref:blueprints
for more
information.
.. versionadded:: 0.7
warn_on_modifications = False
_got_registered_once = False
def __init__(self, name, import_name, static_folder=None,
static_url_path=None, template_folder=None,
url_prefix=None, subdomain=None, url_defaults=None):
_PackageBoundObject.__init__(self, import_name, template_folder)
self.name = name
self.url_prefix = url_prefix
self.subdomain = subdomain
self.static_folder = static_folder
self.static_url_path = static_url_path
self.deferred_functions = []
self.view_functions = {}
if url_defaults is None:
url_defaults = {}
self.url_values_defaults = url_defaults
Registers a function that is called when the blueprint is
def record(self, func):
registered on the application. This function is called with the
state as argument as returned by the :meth:make_setup_state
method.
if self._got_registered_once and self.warn_on_modifications:
from warnings import warn
warn(Warning('The blueprint was already registered once '
'but is getting modified now. These changes '
'will not show up.'))
self.deferred_functions.append(func)
Works like :meth:record
but wraps the function in another
def record_once(self, func):
function that will ensure the function is only called once. If the blueprint is registered a second time on the application, the function passed is not called.
def wrapper(state):
if state.first_registration:
func(state)
return self.record(update_wrapper(wrapper, func))
Creates an instance of :meth:~flask.blueprints.BlueprintSetupState
def make_setup_state(self, app, options, first_registration=False):
object that is later passed to the register callback functions. Subclasses can override this to return a subclass of the setup state.
return BlueprintSetupState(self, app, options, first_registration)
Called by :meth:Flask.register_blueprint
to register a blueprint
def register(self, app, options, first_registration=False):
on the application. This can be overridden to customize the register
behavior. Keyword arguments from
:func:~flask.Flask.register_blueprint
are directly forwarded to this
method in the options
dictionary.
self._got_registered_once = True
state = self.make_setup_state(app, options, first_registration)
if self.has_static_folder:
state.add_url_rule(self.static_url_path + '/<path:filename>',
view_func=self.send_static_file,
endpoint='static')
for deferred in self.deferred_functions:
deferred(state)
Like :meth:Flask.route
but for a blueprint. The endpoint for the
def route(self, rule, **options):
:func:url_for
function is prefixed with the name of the blueprint.
def decorator(f):
endpoint = options.pop("endpoint", f.__name__)
self.add_url_rule(rule, endpoint, f, **options)
return f
return decorator
Like :meth:Flask.add_url_rule
but for a blueprint. The endpoint for
def add_url_rule(self, rule, endpoint=None, view_func=None, **options):
the :func:url_for
function is prefixed with the name of the blueprint.
if endpoint:
assert '.' not in endpoint, "Blueprint endpoint's should not contain dot's"
self.record(lambda s:
s.add_url_rule(rule, endpoint, view_func, **options))
Like :meth:Flask.endpoint
but for a blueprint. This does not
def endpoint(self, endpoint):
prefix the endpoint with the blueprint name, this has to be done
explicitly by the user of this method. If the endpoint is prefixed
with a .
it will be registered to the current blueprint, otherwise
it's an application independent endpoint.
def decorator(f):
def register_endpoint(state):
state.app.view_functions[endpoint] = f
self.record_once(register_endpoint)
return f
return decorator
Register a custom template filter, available application wide. Like
def app_template_filter(self, name=None):
:meth:Flask.template_filter
but for a blueprint.
:param name: the optional name of the filter, otherwise the function name will be used.
def decorator(f):
self.add_app_template_filter(f, name=name)
return f
return decorator
Register a custom template filter, available application wide. Like
def add_app_template_filter(self, f, name=None):
:meth:Flask.add_template_filter
but for a blueprint. Works exactly
like the :meth:app_template_filter
decorator.
:param name: the optional name of the filter, otherwise the function name will be used.
def register_template(state):
state.app.jinja_env.filters[name or f.__name__] = f
self.record_once(register_template)
Register a custom template test, available application wide. Like
def app_template_test(self, name=None):
:meth:Flask.template_test
but for a blueprint.
.. versionadded:: 0.10
:param name: the optional name of the test, otherwise the function name will be used.
def decorator(f):
self.add_app_template_test(f, name=name)
return f
return decorator
Register a custom template test, available application wide. Like
def add_app_template_test(self, f, name=None):
:meth:Flask.add_template_test
but for a blueprint. Works exactly
like the :meth:app_template_test
decorator.
.. versionadded:: 0.10
:param name: the optional name of the test, otherwise the function name will be used.
def register_template(state):
state.app.jinja_env.tests[name or f.__name__] = f
self.record_once(register_template)
Register a custom template global, available application wide. Like
def app_template_global(self, name=None):
:meth:Flask.template_global
but for a blueprint.
.. versionadded:: 0.10
:param name: the optional name of the global, otherwise the function name will be used.
def decorator(f):
self.add_app_template_global(f, name=name)
return f
return decorator
Register a custom template global, available application wide. Like
def add_app_template_global(self, f, name=None):
:meth:Flask.add_template_global
but for a blueprint. Works exactly
like the :meth:app_template_global
decorator.
.. versionadded:: 0.10
:param name: the optional name of the global, otherwise the function name will be used.
def register_template(state):
state.app.jinja_env.globals[name or f.__name__] = f
self.record_once(register_template)
Like :meth:Flask.before_request
but for a blueprint. This function
def before_request(self, f):
is only executed before each request that is handled by a function of that blueprint.
self.record_once(lambda s: s.app.before_request_funcs
.setdefault(self.name, []).append(f))
return f
Like :meth:Flask.before_request
. Such a function is executed
def before_app_request(self, f):
before each request, even if outside of a blueprint.
self.record_once(lambda s: s.app.before_request_funcs
.setdefault(None, []).append(f))
return f
Like :meth:Flask.before_first_request
. Such a function is
def before_app_first_request(self, f):
executed before the first request to the application.
self.record_once(lambda s: s.app.before_first_request_funcs.append(f))
return f
Like :meth:Flask.after_request
but for a blueprint. This function
def after_request(self, f):
is only executed after each request that is handled by a function of that blueprint.
self.record_once(lambda s: s.app.after_request_funcs
.setdefault(self.name, []).append(f))
return f
Like :meth:Flask.after_request
but for a blueprint. Such a function
def after_app_request(self, f):
is executed after each request, even if outside of the blueprint.
self.record_once(lambda s: s.app.after_request_funcs
.setdefault(None, []).append(f))
return f
Like :meth:Flask.teardown_request
but for a blueprint. This
def teardown_request(self, f):
function is only executed when tearing down requests handled by a function of that blueprint. Teardown request functions are executed when the request context is popped, even when no actual request was performed.
self.record_once(lambda s: s.app.teardown_request_funcs
.setdefault(self.name, []).append(f))
return f
Like :meth:Flask.teardown_request
but for a blueprint. Such a
def teardown_app_request(self, f):
function is executed when tearing down each request, even if outside of the blueprint.
self.record_once(lambda s: s.app.teardown_request_funcs
.setdefault(None, []).append(f))
return f
Like :meth:Flask.context_processor
but for a blueprint. This
def context_processor(self, f):
function is only executed for requests handled by a blueprint.
self.record_once(lambda s: s.app.template_context_processors
.setdefault(self.name, []).append(f))
return f
Like :meth:Flask.context_processor
but for a blueprint. Such a
def app_context_processor(self, f):
function is executed each request, even if outside of the blueprint.
self.record_once(lambda s: s.app.template_context_processors
.setdefault(None, []).append(f))
return f
Like :meth:Flask.errorhandler
but for a blueprint. This
def app_errorhandler(self, code):
handler is used for all requests, even if outside of the blueprint.
def decorator(f):
self.record_once(lambda s: s.app.errorhandler(code)(f))
return f
return decorator
Registers a function as URL value preprocessor for this
def url_value_preprocessor(self, f):
blueprint. It's called before the view functions are called and can modify the url values provided.
self.record_once(lambda s: s.app.url_value_preprocessors
.setdefault(self.name, []).append(f))
return f
Callback function for URL defaults for this blueprint. It's called
def url_defaults(self, f):
with the endpoint and values and should update the values passed in place.
self.record_once(lambda s: s.app.url_default_functions
.setdefault(self.name, []).append(f))
return f
Same as :meth:url_value_preprocessor
but application wide.
def app_url_value_preprocessor(self, f):
self.record_once(lambda s: s.app.url_value_preprocessors
.setdefault(None, []).append(f))
return f
Same as :meth:url_defaults
but application wide.
def app_url_defaults(self, f):
self.record_once(lambda s: s.app.url_default_functions
.setdefault(None, []).append(f))
return f
Registers an error handler that becomes active for this blueprint
def errorhandler(self, code_or_exception):
only. Please be aware that routing does not happen local to a blueprint so an error handler for 404 usually is not handled by a blueprint unless it is caused inside a view function. Another special case is the 500 internal server error which is always looked up from the application.
Otherwise works as the :meth:~flask.Flask.errorhandler
decorator
of the :class:~flask.Flask
object.
def decorator(f):
self.record_once(lambda s: s.app._register_error_handler(
self.name, code_or_exception, f))
return f
return decorator


{{ partial "meta.html" . }} {{ partial "style.html" . }}
{{ partial "navbar.html" . }}
Essh is a single binary CLI tool and simply wraps ssh command.
You can use it in the same way as ssh. And it has useful features over ssh.
You can write SSH client configuration (aka: ~/.ssh/config
) in Lua code. So your ssh_config can become more dynamic.
Essh supports hooks that execute commands when it connects a remote server.
Essh provides utilities for managing hosts, that list and classify servers by using tags.
Essh supports per-project configuration. This allows you to change SSH hosts config by changing current working directory.
Task is a script that runs on remote and local servers. You can use it to automate your system administration tasks.
Essh is an open source software that is licensed the MIT License.
Essh configuration is written in Lua.
You can also use DSL syntax that is more human-readable. See below examples:
Configuration:
host "webserver-01" {
HostName = "<IP_ADDRESS>",
Port = "22",
User = "kohkimakimoto",
description = "web server-01",
hooks_after_connect = {
"echo -------------------------------------------------",
"echo I am in $(pwd)",
"cat /etc/redhat-release",
"echo ",
"echo This message was displayed by hook functionality.",
"echo -------------------------------------------------",
},
tags = {
"web",
},
}
host "webserver-02" {
HostName = "<IP_ADDRESS>",
Port = "22",
User = "kohkimakimoto",
description = "web server-02",
tags = {
"web",
},
}
host "dbserver-01" {
HostName = "<IP_ADDRESS>",
Port = "22",
User = "kohkimakimoto",
description = "db server-01",
tags = {
"db",
},
}
Demo:
Configuration:
task "hello" {
description = "say hello",
prefix = true,
backend = "remote",
targets = "web",
script = [=[
echo "hello on $(hostname)"
]=],
}
task "hello-after-confirm" {
description = "say hello after you entering 'y'",
prepare = function()
local question = require "question"
local r = question.ask("Are you OK? [y/N]: ")
if r ~= "y" then
-- return false, the task does not run.
return false
end
end,
prefix = true,
backend = "remote",
targets = "web",
script = [=[
echo "hello on $(hostname)"
]=],
}
Demo:
Essh is provided as a single binary. You can download it and drop it in your $PATH.


Your fleet has lost. And your friends on the Endor moon will not survive. There is no escape, my young apprentice. The Alliance will die...as will your friends. Good. I can feel your anger. I am defenseless. Take your weapon! Strike me down with all your hatred, and your journey towards the dark side will be complete.


@cwinters
Turnitin
Talk about moving parts behind microservices
Why are we using microservices, and what are our plans?
How do they help and hinder?
Docker
Microservices
AWS/Azure/Google/...
Small teams, small-ish companies
Deeply skeptical of magic
Relational database pro, ORM con
Kernighan on debugging applies to more than code
Ease cognitive load
A change in feature X also changes feature Y
Second order effect: fear, uncertainty, and doubt
Response: slather on that process!
Pittsburgh company! (previously: Lightside Labs)
Use machine learning to help students write better
Focus on drafting process
Single app taking all requests; one per EC2
Single worker taking all async jobs; two-ish per EC2
Deployment via Ansible
App and worker => Docker containers
...still serve a lot of traffic
Created associated app served by separate microservices and tables
Re-architecting the workers to scale
More pieces of the single app out into services
Merge duplicated data
Autoscale individual services
Operating a single app is way easier
Easier to propagate patterns within single codebase
Everything is in one place... code and admin tools (Django)
One Approved Way to do things
Reaching into another table is easy
No network call boundaries (latency)
Keep a thing in your head
Independence (concurrent projects)
...both of which help with speed
Disentangle via forced separation
Make side-effects explicit
Small vectors for experimenting
Scale at more granular level
...doesn't really apply to us, yet
Are microservices the only way to do these?
...but few teams exhibit discipline to do them in monolith
Help where you're prone to get things wrong
...and enable freedom to experiment in others
Deployment and configuration
Routing and load balancing
Monitoring
Logging
Recovery
Smart people have already thought about this design
You really need to internalize this document and goals.
Just a few:
3. Config: Store in the environment
4. Backing services: Treat as attached resources
11. Logs: Treat as event streams
EC2 instances providing compute pool of compute
Can be in single AZ or spread across
Immutable metadata to run container
- Resource constraints
- Environment
- Docker image tag
- Linked containers
- ...generally, arguments to docker run...
Given resource constraints, where to put the task?

More overhead: duplicate deploys
Bonus: switch off an entire AZ
Deployment and configuration: OK to Amazing
Routing and load balancing: So-so
Monitoring: Meh
Logging: Meh
Recovery: OK
Feature branch: work work work => push
Slack: make me a color environment
Slack: run end-to-end-tests
Slack: make me some classes
Test test test...
code review
PR to staging, merge => deploys
PR to production, merge => deploys
Slightly different for front-end and services
Local + "Color"
All containers on one host
Includes datastores
Front-end deployed to S3
Extra containers for router, docs, mail
Deployable with slack
Specify different branches for different services
Constrain at Docker, assume other differences minimized for these purposes
Local development can be in container, or not
CI/CD uses Codeship: builds and tests in containers
We currently do not use that same container to deploy
Does it matter?
Basic flow from API call through the system
Postgres, Redis, S3, Simple Queue Service, Simple Notification Service...
All configured through environment and URL
Logs collected on per-host container and forwarded to Loggly
Two inputs: Loggly and NewRelic
Loggly: watch log entries for patterns
NewRelic: watch performance and exceptions for patterns
Both go to Slack (maybe elsewhere in the future?)
Events: coming up and going down
Docker knows about those!
Registrator picks them up and publishes name + address + port...
...to Consul. Distributed k/v store and service registry
Consul Template listens for Consul changes...
...and rewrites nginx config with contents, then gives it a HUP
Two flavors of nginx:
1. Central: in front of the application routing from the internet
2. Distributed: on every host, acting as a client-side load balancer
"It depends"
Central is easier to monitor and manage, but SPOF
Distributed spreads out risk and load, but harder to manage and monitor
Cluster of EC2 instances across AZs
ECS will spread containers across AZs
ELB per service (lots of services, lots of ELBs)
Ensure datastores are Multi-AZ
Documentation
First idea: one document to rule them all
What do you really want?
Different than one place to write
Your instinct is to control at the wrong level
It's what you're comfortable with
You are mutable
Control the format and API
Tool to collect and merge
Everything is a container
Control allows leverage
What does that even mean?
Constraints: define the boundaries of a thing, hands off within
Control: define both what a thing must do and how it must do its job
Control illusory if not at right level
You'll probably get it wrong with something new
Developers: control coding standard, module layout, etc.
What problem are you trying to solve?
Why do you use them?
Small service: few entities, few relationships
Are you really going to switch databases?
Shouldn't you know SQL?
Get away from integrating at data level - they live forever
Wrapping API around queries means you can control arbitrary access
Fewer connections, less to keep in your head
Everything is relational (except caches)
...with some JSONB tables
We are using a single database... for now
Services cannot peek into other services tables...
...except for reporting (still thinking about this)
Data affinity for read-only.
"You get these emergent simplicities when the thing starts to take shape..." (Dan North)
As you pull small systems out of larger systems, keep your eyes open for commonalities or things to eliminate.
Client per backend service
Testing service-to-service interactions
Monitoring improvements
Move to AWS blessed architecture?


Note:
Sign in with your registered email-ID. This console is only for heads of clubs, heads of official groups and administrative staff of SSN College of Engineering. To use our android app, please download it from the Playstore. If you would like to get access to use the webconsole please contact The SSN App team. For best experience use the console from a desktop or laptop.


Largest Online Scam Syndicate Busted In Malaysia As Nearly 1000 Chinese Nationals Are Arrested
by Peace FM OnlineThe Immigration Department busted the largest online scam syndicate believed to be run by Chinese nationals in the country.
The announcement was made in the Immigration Department’s Facebook page today about the raid on an online scam headquarters in Cyberjaya.
Featured Video


BokehJS Reference¶
Data Sources¶
Data is typically passed to bokehjs through a ColumnDataSource
which has named columns
of data that are available to glyph renderers. Note that all the columns in a given
ColumnDataSource
should have the same length. It is possible and often necessary to have
different data sources for different renderers.
Warning
JavaScript null
values are not valid inputs to BokehJS renderers. Please be aware that they will be silently interpreted as zero.
Line Properties¶
BokehJS exposes all the standard HTML5 canvas path stroking properties. All of these
properties may take single values, or references to vectors of data. For instance, it
is possible to draw multiple rectangles at once using the rect
glyph. They may
all be given the same line_width
or each rectangle may be given its own line_width
.
line_color
- color to use to stroke lines with
line_width
- line stroke width in units of pixels
line_alpha
- floating point between 0 (transparent) and 1 (opaque)
line_join
how path segments should be joined together
line_cap
how path segments should be terminated
line_dash
a line style to use
'solid'
'dashed'
'dotted'
'dotdash'
'dashdot'
- an array of integer pixel distances that describe the on-off pattern of dashing to use
- a string of spaced integers matching the regular expression ‘^(\d+(\s+\d+)*)?$’ that describe the on-off pattern of dashing to use
line_dash_offset
- the distance in pixels into the
line_dash
that the pattern should start from
Fill Properties¶
BokehJS exposes all the standard HTML5 path filling properties. All of these properties
may take single values, or references to vectors of data. For instance, it is possible to
draw multiple rectangles at once using the rect
glyph. They may all be given the same
fill_width
, or each rectangle may be given its own fill_width
.
fill_color
- color to use to fill paths with
fill_alpha
- floating point between 0 (transparent) and 1 (opaque)
Text Properties¶
BokehJS exposes most of the standard HTML5 text properties. All of these properties
may take single values, or references to vectors of data. For instance, it is possible to
draw multiple text items at once using the text
glyph. They may all be given the same
font_size
or each line of text may be given its own font_size
.
text_font
- font name, e.g.,
'times'
,'helvetica'
text_font_size
- font size in px, em, or pt, e.g.,
'12pt'
,'1.5em'
text_font_style
font style to use
'normal'
normal text'italic'
italic text'bold'
bold text
text_color
- color to use to render text with
text_alpha
- floating point between 0 (transparent) and 1 (opaque)
text_align
- horizontal anchor point for text:
'left'
,'right'
,'center'
text_baseline
vertical anchor point for text
'top'
'middle'
'bottom'
'alphabetic'
'hanging'
Note
There is currently only support for filling text. An interface to stroke the outlines of text has not yet been exposed.
Markers¶
Markers are a subset of BokehJS glyphs that have a uniform interface and are suitable for simple scatter type plots. All markers expose the following fields:
x
,y
- center point coordinatessize
- screen units
and have Line Properties and Fill Properties as appropriate.
Glyphs¶
Bokeh plots are centered around glyphs, which generally have some combination of line, fill, or
text properties, depending on what is appropriate for a given glyph. For example, the Circle
glyph has both line and fill properties, but the Bezier
glyph only has line properties.
Note
Each of the glyph images below links to a live JSFiddle.
annular_wedge
¶
The annular_wedge glyph displays annular wedges centered at the given coordinates with the
corresponding start_radius
, end_radius
, start_angle
and end_angle
.
Note
the direction
field may be used to indicate which direction the drawing should occur between start_radius
and end_radius
.
x
,y
- center point coordinatesstart_radius
end_radius
start_angle
end_angle
direction
- values:
'clock'
,'anticlock'
- default:
'anticlock'
- values:
- Line Properties
- Fill Properties
annulus
¶
The annulus glyph displays annular rings centered at the given coordinates with the
corresponding start_radius
and end_radius
.
x
,y
- center point coordinatesstart_radius
end_radius
- Line Properties
- Fill Properties
arc
¶
The annulus glyph displays circular line arcs centered at the given coordinates with the
corresponding radius
, start_angle
and end_angle
.
Note
the direction
field may be used to indicate which direction the drawing should occur between start_radius
and end_radius
.
x
,y
- center point coordinatesradius
start_angle
end_angle
direction
- values: [
'clock'
or'anticlock'
] - default:
'anticlock'
- values: [
- Line Properties
asterisk
¶
The asterisk glyph is a marker that displays asterisks at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
bezier
¶
The bezier glyph displays Bezier curves with the given starting, ending, and control points.
x0
,y0
- starting point coordinatesx1
,y1
- ending point coordinatescx0
,cy0
- first control point coordinatescx1
,cy1
- second control point coordinates- Line Properties
circle
¶
The circle glyph has two forms, a marker form that takes a size
field or a non-marker form that takes a radius
field.
|
|
circle_cross
¶
The circle_cross glyph is a marker that displays circles together with a crossbar (+) at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
circle_x
¶
The circle_x glyph is a marker that displays circles together with an X at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
cross
¶
The cross glyph is a marker that displays crossbar symbols (+) at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
diamond
¶
The diamond glyph is a marker that displays diamonds at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
diamond_cross
¶
The diamond_cross glyph is a marker that displays diamonds together with a crossbar (+) at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
image
¶
The image glyph has two forms. The first form takes each image
as a one-dimensional
array of scalar values together with rows
and cols
fields that describe the two-dimensional
shape of the array. The second form takes each image
as a”array of arrays” (assumed to be
non-ragged) and the shape is inferred automatically. A palette
(string name of a built-in
palette, currently) must also be supplied to use for color-mapping the scalar image.
Note
The image glyph is vectorized like other glyphs, i.e. it may be used to display several images at once.
Warning
The second (2D) form is significantly less efficient. It is currently used by the python interface to send data to the browser, but may be deprecated in the future.
|
|
image_rgba
¶
The image_rgba glyph has two forms. The first form takes each image
as a one-dimensional
array of RGBA values (encoded as 32-bit integers) together with rows
and cols
fields
that describe the two-dimensional shape of the array. The second form takes each image
as a
“array of arrays” (assumed to be non-ragged) and the shape is inferred automatically.
Note
The image_rgba glyph is vectorized like other glyphs, i.e. it may be used to display several images at once.
Warning
The second (2D) form is significantly less efficient. It is currently used by the python interface to send data to the browser, but may be deprecated in the future.
|
|
image_url
¶
The image_url glyph accepts the URLs of an images to display. The images are centered on the given coordinates and rotated by the given angles.
x
,y
- center point coordinatesurl
angle
inverted_triangle
¶
The inverted_triangle glyph is a marker that displays upside-down triangles at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
line
¶
The line glyphs displays a single line that connects several points given by the arrays
of coordinates x
and y
.
x
,y
- line coordinates- Line Properties
multi_line
¶
The multi_line glyphs displays several lines, each with points given by the arrays of
coordinates that are the elements of xs
and ys
. This glyph is especially useful for
implementing parallel coordinates plots, or plotting several aligned series simultaneously.
Note
For this glyph, the vector data is not simply an array of scalars, it is really an “array of arrays”.
xs
,ys
- lists of line coordinates- Line Properties
oval
¶
The oval glyph displays ovals centered on the given coordinates with the given dimensions and angle.
x
,y
- center point coordinateswidth
height
angle
- default: 0
- Line Properties
- Fill Properties
patch
¶
The line glyphs displays a single polygonal patch that connects several points given by the arrays
of coordinates x
and y
.
x
,y
- coordinates- Line Properties
- Fill Properties
patches
¶
The patches glyphs displays several patches, each with points given by the arrays of
coordinates that are the elements of xs
and ys
. This glyph is especially useful for
implementing stacked area charts and cartograms.
Note
For this glyph, the vector data is not simply an array of scalars, it is really an “array of arrays”.
xs
,ys
- lists of coordinates- Line Properties
- Fill Properties
quad
¶
The quad glyph displays axis-aligned rectangles with the given dimensions.
left
right
top
bottom
- Line Properties
- Fill Properties
quadratic
¶
The quadratic glyph displays quadratic curves with the given starting, ending, and control points.
x0
,y0
- starting point coordinatesx1
,y1
- ending point coordinatescx
,cy
- control point coordinates- Line Properties
ray
¶
The ray glyph displays line segments starting at the given coordinate and extending the given
length
at the given angle
.
x0
,y0
- starting point coordinateslength
- screen unitsangle
- default: 0
- Line Properties
rect
¶
The rect glyph displays rectangles centered on the given coordinates with the given dimensions and angle.
x
,y
- center point coordinateswidth
height
angle
- default: 0
- Line Properties
- Fill Properties
segment
¶
The segment glyph displays line segments with the given starting and ending coordinates.
x0
,y0
- starting point coordinatesx1
,y1
- ending point coordinates- Line Properties
square
¶
The square glyph is a marker that displays squares at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
square_cross
¶
The square_cross glyph is a marker that displays squares together with a crossbar (+) at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
square_x
¶
The square_x glyph is a marker that displays squares together with an X at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
text
¶
The text glyph displays text at the given coordinates rotated by the given angle. The location of the coordinates relative to the text is indicated by the text properties.
x
,y
- text coordinates (positioning determined by text properties)text
angle
- default: 0
- Text Properties
triangle
¶
The triangle glyph is a marker that displays triangles at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties
wedge
¶
The annular_wedge glyph displays circular wedges centered at the given coordinates with the
corresponding radius
, start_angle
and end_angle
.
Note
the direction
field may be used to indicate which direction the drawing should occur between start_radius
and end_radius
.
x
,y
- center point coordinatesradius
start_angle
end_angle
direction
- values: [
'clock'
or'anticlock'
] - default:
'anticlock'
- values: [
- Line Properties
- Fill Properties
x
¶
The x glyph is a marker that displays X symbols at the given coordinates.
x
,y
- center point coordinatessize
- Line Properties
- Fill Properties


#include <dummy.h>
Inheritance diagram for DummyBox:
Public Member Functions | |
| Int | GetClassID () |
| Returns DummyBox class id. | |
| Matrix4fx | GetResultTransform () |
| Returns object's result transform matrix. | |
| AABB | GetBoundingBox () |
| Builds and returns Bounding Box of this object. | |
| void | SetMin (const Vector3fx &min_) |
| Sets Min value of Bounding Box for this dummy object. | |
| void | SetMax (const Vector3fx &max_) |
| Sets Max value of Bounding Box for this dummy object. | |
| Vector3fx | GetMin () |
| Returns Min value of Bounding Box for this dummy object. | |
| Vector3fx | GetMax () |
| Returns Max value of Bounding Box for this dummy object. | |
| Vector3fx | GetPosition () |
| Returns Position of this dummy object. | |
Static Public Member Functions | |
| static ObjRef< DummyBox > | New () |
| Creates new DummyBox. | |
| static ObjRef< DummyBox > | New (const Vector3fx &min_, const Vector3fx &max_) |
| Creates new DummyBox. | |
| static ObjRef< DummyBox > | New (const AABB &aab_) |
| Creates new DummyBox. | |
Public Attributes | |
| Matrix4fx | relative |
| Relative transformation matrix. | |
Protected Member Functions | |
| DummyBox () | |
| Default constructor. | |
| DummyBox (const Vector3fx &min_, const Vector3fx &max_) | |
| Constructor with given min and max values of Bounding Box. | |
| DummyBox (const AABB &aab_) | |
| Constructor with given Bounding Box value. | |
| ~DummyBox () | |
| Destructor. |
|
|
Constructor with given min and max values of Bounding Box. Creates dummy box object and set Bounding Box values.
|
|
|
Constructor with given Bounding Box value. Creates dummy box object and set Bounding Box values.
|
|
|
Builds and returns Bounding Box of this object.
|
|
|
Returns DummyBox class id.
Reimplemented from Basic3D. |
|
|
Returns Max value of Bounding Box for this dummy object.
|
|
|
Returns Min value of Bounding Box for this dummy object.
|
|
|
Returns Position of this dummy object.
|
|
|
Returns object's result transform matrix.
Reimplemented from Basic3D. |
|
|
Creates new DummyBox. Call this function instead constructor calling.
|
|
|
Creates new DummyBox. Call this function instead constructor calling.
|
|
|
Creates new DummyBox. Call this function instead constructor calling.
Reimplemented from Basic3D. |
|
|
Sets Max value of Bounding Box for this dummy object.
|
|
|
Sets Min value of Bounding Box for this dummy object.
|


| Modifier and Type | Method and Description |
|---|---|
com.ibm.team.build.internal.common.model.dto.IBuildItemNamePair[] |
ITeamBuildClient.getChildrenOfFolder(IBuildFolderHandle buildFolderHandle,
IProcessAreaHandle[] processAreaHandles,
org.eclipse.core.runtime.IProgressMonitor progressMonitor)
Gets children of the specified folder that have a process area within
processAreaHandles . |
| Modifier and Type | Method and Description |
|---|---|
static IBuildFolder |
BuildItemFactory.createBuildFolder(IBuildFolderHandle parentFolderHandle,
java.lang.String name,
IProcessAreaHandle processAreaHandle)
Create a new build folder.
|
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaHandle |
IBuildFolder.getProcessArea()
Retrieves the process area of the build folder.
|
IProcessAreaHandle |
IBuildEngine.getProcessArea()
Retrieves the process area handle for the build engine.
|
IProcessAreaHandle |
IBuildDefinition.getProcessArea()
Retrieves the process area the build definition is associated with.
|
| Modifier and Type | Method and Description |
|---|---|
void |
IBuildFolder.setProcessArea(IProcessAreaHandle processArea)
Sets the process area of the build folder.
|
void |
IBuildEngine.setProcessArea(IProcessAreaHandle processAreaHandle)
Sets the process area handle for the build engine.
|
void |
IBuildDefinition.setProcessArea(IProcessAreaHandle processAreaHandle)
Sets the process area the build definition is associated with.
|
| Modifier and Type | Method and Description |
|---|---|
java.util.List |
IProcessItemService.findAdministratorsFor(IProcessAreaHandle areaHandle,
org.eclipse.core.runtime.IProgressMonitor monitor)
Returns the collection of contributors who are designated as
administrators for the given process area.
|
java.util.List |
IProcessItemService.findTeamAreaHierarchies(IContributor user,
IProcessAreaHandle parentHandle,
java.util.Collection properties,
org.eclipse.core.runtime.IProgressMonitor monitor)
Returns the collection of team areas rooted at the given process area in
which the given user is a member.
|
| Modifier and Type | Interface and Description |
|---|---|
interface |
IProcessArea
Common interface for project and team areas.
|
interface |
IProjectArea
A project area is owned by a project team and contains or references all
artifacts and all relationships between these artifacts that constitute the
resources of a development project.
|
interface |
IProjectAreaHandle |
interface |
ITeamArea
A team area defines the resort of a team inside a project area.
|
interface |
ITeamAreaHandle |
| Modifier and Type | Method and Description |
|---|---|
void |
IAccessGroup.add(IProcessAreaHandle processAreaHandle,
IAccessGroup.ReadAccessContextType contextType)
Adds a process area to the access group.
|
void |
IAccessGroup.remove(IProcessAreaHandle processAreaHandle)
Removes a process area from the access group.
|
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaHandle |
IReportDescriptor.getParentProjectArea()
Gets the project area that contains the report design.
|
IProcessAreaHandle |
ISharableDescriptor.getProcessArea()
Returns the process area of this descriptor.
|
| Modifier and Type | Method and Description |
|---|---|
void |
ISharableDescriptor.setup(IProjectAreaHandle projectArea,
IProcessAreaHandle processArea,
IContributorHandle owner)
Sets up the various properties of this item.
|
void |
ISharableDescriptor.setup(IProjectAreaHandle projectArea,
IProcessAreaHandle processArea,
IContributorHandle owner,
boolean shared)
Sets up the various properties of this item.
|
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaHandle |
IReportService.getDefaultProcessArea(IProjectAreaHandle projectArea,
IContributorHandle contributor)
Fetch the default process area for a given project area and contributor.
|
| Modifier and Type | Method and Description |
|---|---|
IFolderDescriptor[] |
IReportService.fetchFolderDescriptors(IContributorHandle owner,
IProjectAreaHandle projectArea,
IProcessAreaHandle[] processAreas,
IFolderDescriptorHandle parent,
int flags)
Fetch folder descriptors meeting the parameter criteria.
|
IReportDescriptor[] |
IReportService.fetchMissingReportDescriptors(IProcessAreaHandle processArea,
IProjectAreaHandle sourceProjectArea)
Fetches report descriptors that exist in the source project area but are
missing from the given process area.
|
IReportDescriptor[] |
IReportService.fetchMissingSharedReportDescriptors(IProcessAreaHandle processArea)
Fetches report descriptors missing from the given process area.
|
IReportQueryDescriptor[] |
IReportService.fetchQueryDescriptors(IContributorHandle owner,
IProjectAreaHandle projectArea,
IProcessAreaHandle[] processAreas,
IReportDescriptorHandle report,
IFolderDescriptorHandle folder,
int flags)
Fetch query descriptors meeting the parameter criteria.
|
IReportDescriptor[] |
IReportService.fetchReportDescriptors(IContributorHandle owner,
IProjectAreaHandle projectArea,
IProcessAreaHandle[] processAreas,
java.lang.String snapshotName,
java.lang.String[] parameters,
int flags)
Fetches report descriptors meeting the parameter criteria.
|
IFolderDescriptor[] |
IReportService.fetchRootFolderDescriptors(IContributorHandle owner,
IProjectAreaHandle projectArea,
IProcessAreaHandle[] processAreas,
int flags)
Fetch root folder descriptors meeting the parameter criteria.
|
void |
IReportService.setDefaultTeamQueryDescriptor(IProcessAreaHandle processArea,
IReportQueryDescriptorHandle queryHandle)
Set the default query for the given team area to the query descriptor
specified.
|
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaHandle |
IFlowNodeConnection.getProcessArea(org.eclipse.core.runtime.IProgressMonitor monitor)
Returns the process areas with which this stream is associated.
|
| Modifier and Type | Method and Description |
|---|---|
IWorkspaceConnection |
IWorkspaceManager.createStream(IProcessAreaHandle scopeHandle,
java.lang.String streamName,
java.lang.String description,
org.eclipse.core.runtime.IProgressMonitor monitor)
Creates a stream in the repository.
|
java.util.List |
IWorkspaceManager.findBaselineSets(java.lang.String namePattern,
IProcessAreaHandle teamScope,
boolean exact,
org.eclipse.core.runtime.IProgressMonitor progressMonitor)
|
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaHandle |
IBaselineSetSearchCriteria.getProcessArea()
The process area as set by
IBaselineSetSearchCriteria.setProcessArea(IProcessAreaHandle) |
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaScope |
IReadScope.IReadScopeFactory.createProcessAreaScope(IProcessAreaHandle area) |
IBaselineSetSearchCriteria |
IBaselineSetSearchCriteria.setProcessArea(IProcessAreaHandle teamScope)
The owner workspace should be owned by the given process area
|
| Modifier and Type | Method and Description |
|---|---|
IProcessAreaHandle |
IWorkItemCommon.findProcessArea(IWorkItemHandle handle,
org.eclipse.core.runtime.IProgressMonitor monitor)
Returns a handle of the process area the given work item is associated
with.
|
IProcessAreaHandle |
IWorkItemCommon.findProcessAreaForCategoryAndIteration(ICategoryHandle category,
IIterationHandle target,
org.eclipse.core.runtime.IProgressMonitor monitor)
Returns a handle of the process area associated with the passed category and iteration.
|
| Modifier and Type | Method and Description |
|---|---|
IAdvisorDeclaration |
IAuditableCommonProcess.findAdvisorDeclaration(IProcessAreaHandle processArea,
IDevelopmentLine developmentLine,
java.lang.String advisableOperationId,
java.lang.String operationAdvisorId,
org.eclipse.core.runtime.IProgressMonitor monitor)
|
IAdvisorDeclaration |
IAuditableCommonProcess.findAdvisorDeclaration(IProcessAreaHandle processArea,
java.lang.String advisableOperationId,
java.lang.String operationAdvisorId,
org.eclipse.core.runtime.IProgressMonitor monitor)
|
java.util.List<IAdvisorDeclaration> |
IAuditableCommonProcess.findAdvisorDeclarations(IProcessAreaHandle processArea,
java.lang.String advisableOperationId,
java.lang.String operationAdvisorId,
org.eclipse.core.runtime.IProgressMonitor monitor) |
java.util.List<ICategory> |
IWorkItemCommon.findCategoriesOfProcessArea(IProcessAreaHandle processArea,
ItemProfile<ICategory> profile,
org.eclipse.core.runtime.IProgressMonitor monitor)
Finds all categories which are associated with the given process area.
|
IAuditableCommonProcess |
IAuditableCommon.getProcess(IProcessAreaHandle processArea,
org.eclipse.core.runtime.IProgressMonitor monitor) |