Runtime Management
brooklyn uses many of the ideas from autonomic computing to implement management of entities in a structured and reusable fashion (including provisioning, healing, and optimising).
Each external system, process or service is represented as an entity within brooklyn, with collections of these being represented and managed by other entities, and so forth through a hierarchy rooted in entities referred to as "Applications". Each entity has:
- provisioning and tear-down logic for the external system(s) it represents
- sensors which it publishes to report on its state and activity
- effectors which can be invoked to change it
- policies which perform analysis, enrichment (sensors), and execution (effectors). It is the policies in brooklyn which perform the self-management (in autonomic terms) by monitoring sensors and invoking effectors.
There are several ways to launch applications with brooklyn, and useful configuration options, as well as a debug-view web console. This chapter describes these high-level runtime concepts, then proceeds to present more detailed information on the underlying implementation of management within brooklyn.
Startup Configuration
brooklyn can read configuration from a variety of places:
- the file
~/.brooklyn/brooklyn.properties
-D
defines on the brooklyn (java) command-line- shell environment variables
Default properties are described in the Javadoc and code of classes CredentialsFromEnv
and BrooklynSystemProperties
,
but some of the most common ones are:
brooklyn.jclouds.aws-ec2.identity=AKA50M30N3S1DFR0MAW55
brooklyn.jclouds.aws-ec2.credential=aT0Ps3cr3tC0D3wh1chAW5w1llG1V3y0uTOus333
brooklyn.jclouds.private-key-file=~/my/id_rsa # use specified key (default is ~/.ssh/id_rsa)
brooklyn.jclouds.public-key-file=~/my/id_rsa.pub # (optional, inferred from previous if omitted)
These can be specified as a shell environment variable or as a Java system property,
although in those contexts the conventional format BROOKLYN_JCLOUDS_AWS_EC2_IDENTITY
is supported and recommended.
Command Line Interface
Brooklyn comes with a Command Line Interface (cli) that makes it easier to launch an application.
In order to have easy access to the cli it is useful to configure the PATH environment variable to also point to the cli's bin directory:
BROOKLYN_HOME=/path/to/brooklyn/
export PATH=$PATH:$BROOKLYN_HOME/usage/dist/target/brooklyn-dist/bin/
If you have set this up correctly you should be able to invoke the brooklyn
command:
brooklyn
To get information about all the supported cli options just run:
brooklyn help
usage: brooklyn [(-q | --quiet)] [(-v | --verbose)] <command> [<args>]
The most commonly used brooklyn commands are:
help Display help information about brooklyn
launch Starts a brooklyn application. Note that a BROOKLYN_CLASSPATH environment variable needs to be set up beforehand to point to the user application classpath.
See 'brooklyn help <command>' for more information on a specific command.
Here is an example of the commands you might run to get the Brooklyn code, compile it and launch an application:
git clone https://github.com/brooklyncentral/brooklyn.git
cd brooklyn
mvn clean install -DskipTests
BROOKLYN_HOME=$(pwd)
export PATH=${PATH}:${BROOKLYN_HOME}/usage/dist/target/brooklyn-dist/bin/
export BROOKLYN_CLASSPATH=${BROOKLYN_HOME}/examples/simple-web-cluster/target/classes
brooklyn launch --app brooklyn.demo.SingleWebServerExample --location localhost
Management Web Console
The web-based management console that comes with brooklyn serves as a way to observe and manage brooklyn entities. It provides low-level details of activity (including stack-traces), sensor values, and policies, and some visual widgets for observing what is happening. This console is not designed as a management dashboard or portal -- many good options exist in that space -- but what could be useful is to embed widgets from the brooklyn portal for selected high-level views.
To start a management console from your own code, use BrooklynLaucher.launch
:
public static void main(String[] argv) {
Application app = new MyApplicationExample(displayName:"myapp")
BrooklynServerDetails server = BrooklynLauncher.newLauncher()
.managing(app)
.launch();
// ...
}
This will start an embedded brooklyn management node, including the web console. The URL for the web console defaults to http://localhost:8081, with credentials admin/password.
The mechanism for launching brooklyn management will change in a future release. For this release, the brooklyn management node is embedded.
The console contains two main views: Dashboard and Detail. These update in real-time.
Dashboard
The dashboard is a high level overview of the state of the application:
Detail
The Detail view gives an in-depth view of the application and its entities. Child-parent relationships between entities are navigable using the entity tree; each entity is shown with its children (or, in the case of childless group entities, the members). Selecting a specific entity allows you to access detailed information about that entity.
The Detail view contains a breadcrumb trail, showing the current entitiy's position in the heirarchy, and six tabs:
Summary: Description of the selected entity.
Sensors: Lists the attribute sensors that the entity has and their values.
Effectors: Lists the effectors that can be invoked on the selected entity.
Activity: Current and historic activity of the entity, currently running effectors, finished effectors.
Location: The geographical location of the selected entity.
Policies: Lists the policies associated with the current entity. Policies can be suspended, resumed and removed through the UI.
Security
Security providers can be configured by specifying brooklyn.webconsole.security.provider
equal
to the name of a class implementing SecurityProvider
.
An implementation of this could point to Spring, LDAP, OpenID or another identity management system.
The default implementation, ExplicitUsersSecurityProvider
, reads from a list of users and passwords
which should be specified as configuration parameters e.g. in brooklyn.properties
.
This configuration could look like:
brooklyn.webconsole.security.explicit.users=admin
brooklyn.webconsole.security.explicit.user.admin=password
The users
line should contain a comma-separated list. The special value *
is accepted to permit all users.
If no values are specified at all the above setting (admin
/password
) is used by default.
If not using the web console, you should specify
brooklyn.webconsole.security.provider=brooklyn.rest.security.provider.BlackholeSecurityProvider
to prevent inadvertant logins.
During dev/test you can specify brooklyn.webconsole.security.provider=brooklyn.rest.security.provider.AnyoneSecurityProvider
to allow logins with no credentials.
Other Ways to Observe Activity
Java API
ManagementContext
provides a Java programmatic API.
More information can be found in the javadoc for ManagementContext
.
Command-line Console
Not available yet.
Management REST API
Brooklyn does not yet expose a REST API. This was to allow the APi to be designed to align with emerging standards.
Selected management operations are possible remotely using links exposed by the GUI (after authenticating with the GUI).
Logging
Brooklyn uses the SLF4J logging facade, which allows use of many popular frameworks including java.util.logging, log4j, and logback.
The convention for log levels is as follows: * ERROR and above: exceptional situations which indicate that something has unexpectedly failed or some other problem has occured which the user is expected to attend to * WARN: exceptional situations which the user may which to know about but which do not necessarily indicate failure or require a response * INFO: a synopsis of activity, but which should not generate large volumes of events nor overwhelm a human observer * DEBUG and lower: detail of activity which is not normally of interest, but which might merit closer inspection under certain circumstances.
Loggers follow the package.ClassName
naming standard.
It is possible for entities to emit logging activity sensors so that an operator can observe what is occurring within their application through the web console or via programmatic means.
Examples for testing can be found in some of the poms.
Key APIs
This section still needs to be written. Feel free to fork the docs and lend a hand.
ManagementContext
(Java management API)EntityLocal
(used by policies)
Sensors and Effectors
Sensors
Sensors are typically defined as static named fields on the Entity subclass. These define the channels of events and activity that interested parties can track remotely. For example:
/** a sensor for saying hi (illustrative), carrying a String value
which is typically the name of the person to whom we are saying hi */
public static final Sensor<String> HELLO_SENSOR = ...
If the entity is local (e.g. to a policy) these can be looked up using get(Sensor)
. If it may be remote, you can subscribe to it through various APIs.
Sensors are used by operators and policies to monitor health and know when to invoke the effectors. The sensor data forms a nested map (i.e. JSON), which can be subscribed to through the ManagementContext
.
Often Policy
instances will subscribe to sensor events on their associated entity or its children; these events might be an AttributeValueEvent
– an attribute value being reported on change or periodically – or something transient such as LogMessage
or a custom Event
such as "TOO_HOT".
Sensor values form a map-of-maps. An example of some simple sensor information is shown below in JSON:
{
config : {
url : "jdbc:mysql://ec2-50-17-19-65.compute-1.amazonaws.com:3306/mysql"
status : "running"
}
workrate : {
msgsPerSec : 432
}
}
Sensor values are defined as statics, which can be used to programmatically drive the subscription.
SubscriptionManager
This section is not complete. Feel free to fork the docs and lend a hand.
See the SubscriptionManager
class.
Effectors
Like sensors and config info, effectors are also static fields on the Entity class. These describe actions available on the entity, similar to methods. Their implementation includes details of how to invoke them, typically this is done by calling a method on the entity. Effectors are typically defined as follows:
/** an effector which returns no value,
but which causes the entity to emit a HELLO sensor event */
public static Effector<Void> SAY_HI = ...
Effectors are invoked by calling invoke(SAY_HI, name:"Bob")
or similar. The method may take an entity if context is not clear, and it takes parameters as named parameters or a Map.
Invocation returns a Task
object (extending Future
). This allows the caller to understand progress and errors on the task, as well as Task.get()
the return value. Be aware that task.get()
is a blocking function that will wait until a value is available before returning.
The management framework ensures that execution occurs on the machine where the Entity
is mastered, with progress, result, and/or any errors reported back to the caller. It does this through the ExecutionManager
which, where necessary, creates proxy Task
instances. The ExecutionManager
associates Tasks
with the corresponding Entity
so that these can be tracked externally (and relocated if the Entity is remastered to a different location).
It is worth noting that where a method corresponds to an effector, direct invocation of that method on an Entity
will implicitly generate the Task
object as though the effector had been invoked. For example, invoking Cluster.resize(int)
, where resize
provides an Effector RESIZE
, will generate a Task
which can be observed remotely.
ExecutionManager
The ExecutionManager
is responsible for tracking simultaneous executing tasks and associating these with given tags.
Arbitrary tasks can be run by calling Task submit(Runnable)
(similarly to the standard Executor
, although it also supports Callable
arguments including Groovy closures, and can even be passed Task
instances which have not been started). submit
also accepts a few other named parameters, including description
, which allow additional metadata to be kept on the Task
. The main benefit then is to have rich metadata for executing tasks, which can be inspected through methods on the Task
interface.
By using the tag
or tags
named parameters on submit
(or setting tags
in a Task
that is submitted), execution can be associated with various categories. This allows easy viewing can be examined by calling
ExecutionManager.getTasksWithTag(...)
.
The following example uses Groovy, with time delays abused for readability. brooklyn's test cases check this using mutexes, which is recommended.
ExecutionManager em = []
em.submit(tag:"a", description:"One Mississippi", { Thread.sleep(1000) })
em.submit(tags:["a","b"], description:"Two Mississippi", { Thread.sleep(1000) })
assert em.getTasksWithTag("a").size()==2
assert em.getTasksWithTag("a").every { Task t -> !t.isDone() }
Thread.sleep(1500)
assert em.getTasksWithTag("a").size()==2
assert em.getTasksWithTag("a").every { Task t -> t.isDone() }
It is possible to define ParallelTasks and SequentialTasks and to specify inter-task relationships with TaskPreprocessors. This allows building quite sophisticated workflows relatively easily.
Continuing the example above, submitting a SequentialTasks or specifying em.setTaskPreprocessorForTag("a", SingleThreadedExecution.class)
will cause Two Mississippi
to run after One Mississippi
completes.
For more information consult the javadoc on these classes and associated tests.
Note that it is currently necessary to prune dead tasks, either periodically or by the caller. By default they are kept around for reference. It is expected that an enhancement in a future release will allow pruning completed and failed tasks after a specified amount of time.


√(
2
-
1
)
2
+ (
2
-
1
)
2
=
SOLVE
Enter all 4 values into the boxes above. Press SOLVE, and the program will calculate the distance
Back


Collision detection in Impact is done in two separate steps: "static" collison (Entity vs. World) and "dynamic" collision (Entity vs. Entity).
Static collision is resolved by the entity itself while it's moving - i.e. the entity checks if it can move where it wants to. Before the entity moves, it does a trace from its current position to the destination. The game's CollisionMap answers with a trace result that states if and where there was a collision.
Dynamic collision is resolved after all entities have moved. Dynamic collision only checks if two entities are currently overlapping - and if so - moves them apart.
It is important to note that static collision is always accurate and framerate independent, while dynamic collision is not. This means, that fast moving entities can never move through walls but a collision between two fast moving entities might remain unnoticed.
Impact always maintains a minimum framerate of 20 frames per game second, so that all dynamic collisions are still adequately accurate. See ig.Timer.maxStep.
By default, all entities will collide with the game's .collisionMap. The entity's .update() method calculates the movement speed based on the entities properties and then does a trace against the CollisionMap. The result of this trace is then handled by the entity's .handleMovementTrace() method.
So if you want an entity to opt out of static collision, the easiest way to do this, is to overwrite the .handleMovementTrace()
method for this entity with the following:
handleMovementTrace: function( res ) { // This completely ignores the trace result (res) and always // moves the entity according to its velocity this.pos.x += this.vel.x * ig.system.tick; this.pos.y += this.vel.y * ig.system.tick; }
Refer to the CollisionMap's trace() method for a description of the res
argument.
You can also check with which tile the entity collided and act accordingly (e.g. if you have tiles that are slippery).
If you want to play a sound when your player entity hits the floor with a certain speed, you can overwrite .handleMovementTrace()
and check for collision and speed.
handleMovementTrace: function( res ) { if( res.collision.y && this.vel.y > 32 ) { this.soundBounce.play(); } // Continue resolving the collision as normal this.parent(res); }
You can use Weltmeister to create a CollisionMap. By default, the game's .loadLevel()
method assumes that a layer named 'collision'
is the CollisionMap for that level.
You can always create a CollisionMap manually:
// In your Game's init() method var map = [ 0,0,0,0 0,1,1,0 0,0,0,0 ]; this.collisionMap = new ig.CollisionMap( 8, map );
If you don't specify a CollisionMap at all, an empty dummy (ig.CollisionMap.staticNoCollision
) will be used.
Entity vs. entity collision is a bit more complex, because an entity can have one of several collision modes. If two entities collide with each other, the collision modes of both of them determine if and how the collision will be resolved.
The collision mode of an entity is specified by its .collides property. By default, this property is set to ig.Entity.COLLIDES.NEVER
, ignoring all collisions no matter which collision mode the other entity has.
The other collision modes are LITE
, PASSIVE
, ACTIVE
and FIXED
.
If a PASSIVE
entity collides with an ACTIVE
entity the collision will be resolved by moving both entities apart. The same is true for ACTIVE
vs. ACTIVE
collisions.
The reason that there is a PASSIVE
mode is that PASSIVE
vs. PASSIVE
collisions won't be resolved at all (i.e. they will just overlap). This can be useful for enemies that can move "through" each other, instead of blocking the way. These PASSIVE
entities will still collide with ACTIVE
entities.
The two other modes effectively define a "weak" and a "strong" entity for each collision. In these cases only the weak entity will be moved to resolve the collision.
An entity that has the LITE
collision mode set is always the weak entity - i.e. the entity that moves. An entity that has the FIXED
collision mode set is always the strong entity - it will stay where it is.
LITE
entities only collide with ACTIVE
or FIXED
entities. FIXED
entities will collide with LITE
, PASSIVE
and ACTIVE
entities.
Still confused? Here's some general advice:
The player and enemy character typically should be PASSIVE
so that they don't collide with each other, but can collide with ACTIVE
entities, such a crates.
Platforms and elevators should be FIXED
so that they move regardless if another entity is blockign their path.
All entities that are purely visual and don't affect the gameplay, should collide LITE
or NEVER
.


Balance Yoga is Your
Personal Studio
123 Balanced Way
Cortez, CO 81321
Copyright Balance Yoga 2019
This Site is for Educational Purposes Only
Home
Schedule
Classes
Teachers
Join
Balance Yoga
Join Now


--- layout: archive title: Zulip Chat Archive permalink: /stream/113488-general/topic/tidy.20lost.20my.20metavars.html ---
Somehow tidy
claims it closed all goals, but the kernel says there are still metavariables left. Is there a good approach to debugging this? Somewhere a metavariable got removed from the goal-list without being fully instantiated. I guess it should be possible to track this, right?
it is possible to write a tactic that will tell you if the current tactic state is broken, but you will have to sprinkle it around and it will often give false positives because of focus
and such
the recover
tactic does this, essentially
Thanks. Didn't know about recover
. I'll try it out.
Oh by the way, recover
worked. It figured out that there was some naturality condition that wasn't proven. I don't know how it got lost.
It'd be really great to see a reproducible case of that Johan, probably there is a bug in a tactic somewhere
@Keeley Hoek https://github.com/leanprover-community/mathlib/blob/sheaf/category_theory/presheaf.lean#L113
Voila. I retried this with a freshly restarted Lean. Problem still occurs. I have no idea how I could build a MWE out of this. It's pretty deep down in ugly maths.
Seems like a bug in constructor
to me
For anyone who is interested:
def oopsie (F : C ⥤ D) : functor.id (presheaf C) ⟹ yoneda_extension F ⋙ restricted_yoneda F := begin constructor, -- One goal recover, -- Two goals :O sorry end
But I guess this ties in to the auto_params, doesn't it?
I'm not sure I understand
I mean, surely it shouldn't erase a metavar it creates from history
Maybe constructor
is throwing away goals that have an auto_param attached to them?
I wonder if the extract_opt_auto_param
in get_constructors_for
has anything to do with it
Actually, I bet it is the mk_const
on line 23 of constructor_tactic.lean in lean core
That could create metavariables which don't get fully bound by the apply
maybe
Thanks for debugging this!
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


PUSH BACK THE DARKNESS
Thank you very much for your interest in contributing a story!
On January 29th, 2019, there will be a commemoration of the Quebec City mosque attack in the House of Commons and the Senate on Parliament Hill in Ottawa. As part of this commemoration, we are seeking drawings, stories, and photographs from community members in order to send those to Ottawa as part of the commemoration.
In order to participate in this, we would like you to create either a story or a drawing (or both) which can be sent to Members of Parliament and Senators in Ottawa, and if you feel comfortable, include a picture of you and your family to go along with this. Photographs are not a requirement of submission. We can also make your contribution anonymous if you prefer. If you find yourself becoming upset when writing your story, please reach out to a counsellor.
The theme of these stories and drawings is hope and optimism for the future, with the idea being that we can work together as a community to push back against the darkness of fear, ignorance, and hate using the light of friendship, knowledge, and kindness. As Martin Luther King, Jr. said:
Darkness cannot drive out darkness;
Only light can do that.
Hate cannot drive out hate;
Only love can do that.
When writing a story, you could include responses to these questions (though you may also want to focus on other questions):
- Where were you when the Quebec City mosque attack happened?
- What did you do after you heard about it (or about another such incident in which a particular group was targeted for violence on racial or religious grounds)?
- Do you feel that the Quebec mosque shooting has affected your identity as a Canadian in any way? What are some specific moments you can think of? Successes or challenges?
- How has it affected your relationship with your neighbours, school mates, work colleagues, people on the streets?
- How did it make you feel?
- What did your community do in response?
- What do you think your community should have done in response?
- What would you like to know about the Quebec City mosque attack?
- What message would you like to send Members of Parliament or Senators about what would you like to see in the future, both for you and for any children you may have?
An example story which is based on these guidelines, created by the founder of this initiative (Ryan Slobojan),
can be found here, if you are seeking inspiration and would like an idea what these suggestions can mean in practice.
We would like you to include your contact information with any stories or drawings you submit, if you feel comfortable doing that - this will give the Member of Parliament or Senator who receives your story or drawing a chance to get in touch with you to learn more, if they choose. However, this is not required, and you can choose to submit with as much or as little contact information as you wish.
Similarly, we would like to publish these stories and pictures on this website on the date of the commemoration, so that Canadians across the country can also see and hear from you - however, this is also not required, and if you do not wish to have your story or drawing made public then we will not do so. Also, any public stories or drawings will have contact information removed (only names and cities will be displayed).
Thank you for reading this, and we look forward to hearing from you.


Luminus is a Clojure micro-framework based on a set of lightweight libraries. It aims to provide a robust, scalable, and easy to use platform. With Luminus you can focus on developing your app the way you want without any distractions.
Clojure Web Development Made Simple
Quick Start Guide
$ lein new luminus my-app
$ cd my-app
$ lein run
Started server on port 3000
Get started in seconds using Leiningen.
Developer Friendly
Start hacking immediately with the REPL and embedded development server
- Simple and easy to learn
- REPL driven development
- Powerful build tools
Productive
Choose productivity and performance by leveraging Clojure on the JVM
- Built on top of the JVM
- Low overhead
- Compiled for production
Modern Web & Mobile
Luminus is built for needs of modern web & mobile apps
- ClojureScript support
- Stateless web tier
- Excellent SQL/NoSQL support


Deprecated: This routine has been superseded by the CSPICE routine
cspice_illumf. This routine is supported for purposes of backward
compatibility only.
Compute the illumination angles---phase, solar incidence, and
emission---at a specified point on a target body at a particular
epoch, optionally corrected for light time and stellar aberration.
Return logical flags indicating whether the surface point is
shadowed or occulted by the target body.
The target body's surface is represented by a triangular plate model
contained in a type 2 DSK segment. The ID of the plate on which the
point is located must be provided by the caller.
Given:
handle the DAS file handle of a DSK file open for read
access. This kernel must contain a type 2 segment
that provides a plate model representing the entire
surface of the target body.
[1,1] = size(handle); int32 = class(handle)
dladsc the DLA descriptor of a DSK segment representing
the surface of the target body.
[SPICE_DLA_DSCSIZ,1] = size(dladsc)
int32 = class(dladsc)
target the name of the target body. `target' is
case-insensitive, and leading and trailing blanks in
`target' are not significant. Optionally, you may supply
a string containing the integer ID code for the object.
For example both 'MOON' and '301' are legitimate strings
that indicate the moon is the target body.
This routine assumes that the target body's surface is
represented using a plate model, and that a DSK file
containing the plate model has been loaded via cspice_dasopr.
[1,c1] = size(target); char = class(target)
or
[1,1] = size(target); cell = class(target)
et the epoch, represented as seconds past J2000 TDB, at
which the illumination angles are to be computed. When
aberration corrections are used, `et' refers to the
epoch at which radiation is received at the observer.
[1,1] = size(et); double = class(et)
abcorr indicates the aberration corrections to be applied to
the position and orientation of the target body and the
position of the Sun to account for one-way light time
and stellar aberration. See the discussion in the
Particulars section for recommendations on how to choose
aberration corrections.
[1,c2] = size(abcorr); char = class(abcorr)
or
[1,1] = size(abcorr); cell = class(abcorr)
`abcorr' may be any of the following:
'NONE' Apply no correction. Use the geometric
positions of the Sun and target body
relative to the observer; evaluate the
target body's orientation at `et'.
The following values of `abcorr' apply to the
"reception" case in which photons depart from the
target's location at the light-time corrected epoch
et-lt and *arrive* at the observer's location at
`et':
'LT' Correct for one-way light time (also
called "planetary aberration") using a
Newtonian formulation. This correction
uses the position and orientation of the
target at the moment it emitted photons
arriving at the observer at `et'. The
position of the Sun relative to the
target is corrected for the one-way light
time from the Sun to the target.
The light time correction uses an
iterative solution of the light time
equation (see Particulars for details).
The solution invoked by the 'LT' option
uses one iteration.
'LT+S' Correct for one-way light time and stellar
aberration using a Newtonian formulation.
This option modifies the positions
obtained with the 'LT' option to account
for the observer's velocity relative to
the solar system barycenter (note the
target plays the role of "observer" in the
computation of the aberration-corrected
target-Sun vector). The result is that the
illumination angles are computed using
apparent position and orientation of the
target as seen by the observer and the
apparent position of the Sun as seen by
the target.
'CN' Converged Newtonian light time correction.
In solving the light time equation, the
'CN' correction iterates until the
solution converges (three iterations on
all supported platforms).
'CN+S' Converged Newtonian light time
and stellar aberration corrections.
obsrvr the name of the observing body. This is typically a
spacecraft, the earth, or a surface point on the earth.
`obsrvr' is case-insensitive, and leading and trailing
blanks in `obsrvr' are not significant. Optionally, you
may supply a string containing the integer ID code for
the object. For example both 'EARTH' and '399' are
legitimate strings that indicate the earth is the
observer.
[1,c3] = size(obsrvr); char = class(obsrvr)
or
[1,1] = size(obsrvr); cell = class(obsrvr)
spoint a surface point on the target body, expressed in
rectangular body-fixed (body equator and prime meridian)
coordinates. `spoint' need not be visible from the
observer's location at time `et'.
[3,1] = size(spoint); double = class(spoint)
plid is the integer ID of the plate on which `spoint' is
located. If `spoint' was found by calling any of the
routines
cspice_dskx02
cspice_subpt_pl02
cspice_subsol_pl02
`plid' is the plate ID returned by the called routine.
[1,1] = size(plid); int32 = class(plid)
the call:
[trgepc, srfvec, phase, solar, emissn, visibl, lit] = ...
cspice_illum_plid_pl02( handle, dladsc, target, ...
et, abcorr, obsrvr, ...
spoint, plid )
returns:
All outputs are computed using the body-fixed, body-centered
reference frame of the DSK segment identified by `handle' and
`dladsc'. This frame is referred to below as `fixref'. The
frame ID of `fixref' may be obtained by calling cspice_dskgd, as
is shown in the Examples section below.
The orientation of the frame `fixref' is evaluated at the
epoch `trgepc'.
trgepc is the "surface point epoch." `trgepc' is defined as
follows: letting `lt' be the one-way light time between
the observer and the input surface point `spoint',
`trgepc' is either the epoch et-lt or `et' depending on
whether the requested aberration correction is,
respectively, for received radiation or omitted. `lt' is
computed using the method indicated by `abcorr'.
`trgepc' is expressed as seconds past J2000 TDB.
[1,1] = size(trgepc); double = class(trgepc)
srfvec is the vector from the observer's position at `et' to
the aberration-corrected (or optionally, geometric)
position of `spoint', where the aberration corrections
are specified by `abcorr'. `srfvec' is expressed in the
target body-fixed reference frame designated by
`fixref', evaluated at `trgepc'.
[3,1] = size(phase); double = class(phase)
The components of `srfvec' are given in units of km.
One can use the function norm to obtain the
distance between the observer and `spoint':
dist = norm( srfvec );
The observer's position `obspos', relative to the
target body's center, where the center's position is
corrected for aberration effects as indicated by
`abcorr', can be computed with:
obspos = spoint - srfvec
To transform the vector `srfvec' from a reference frame
`fixref' at time `trgepc' to a time-dependent reference
frame `ref' at time `et', the routine cspice_pxfrm2 should be
called. Let `xform' be the 3x3 matrix representing the
rotation from the reference frame `fixref' at time
`trgepc' to the reference frame `ref' at time `et'. Then
`srfvec' can be transformed to the result `refvec' as
follows:
xform = cspice_pxfrm2 ( fixref, ref, trgepc, et )
refvec = xform * srfvec
phase is the phase angle at `spoint', as seen from `obsrvr' at
time `et'. This is the angle between the spoint-obsrvr
vector and the spoint-sun vector. Units are radians. The
range of `phase' is [0, pi].
[1,1] = size(phase); double = class(phase)
solar is the solar incidence angle at `spoint', as seen from
`obsrvr' at time `et'. This is the angle between the
surface normal vector at `spoint' and the spoint-sun
vector. Units are radians. The range of `solar' is [0,
pi].
Note that if the target surface is non-convex, a solar
incidence angle less than pi/2 radians does not imply
the surface point is illuminated. See the description of
`lit' below.
[1,1] = size(solar); double = class(solar)
emissn is the emission angle at `spoint', as seen from `obsrvr'
at time `et'. This is the angle between the surface
normal vector at `spoint' and the spoint-observer
vector. Units are radians. The range of `emissn' is
is [0, pi].
See Particulars below for a detailed discussion of the
definitions of these angles.
Note that if the target surface is non-convex, an emission
angle less than pi/2 radians does not imply the surface
point is visible to the observer. See the description of
`visible' below.
[1,1] = size(emissn); double = class(emissn)
See Particulars below for a detailed discussion of the
definitions of these angles.
visible is a logical flag indicating whether the surface point
is visible to the observer. `visible' takes into account
whether the target surface occults `spoint', regardless
of the emission angle at `spoint'. `visible' is returned
with the value true if `spoint' is visible;
otherwise it is false.
[1,1] = size(visibl); logical = class(visibl)
lit is a logical flag indicating whether the surface point
is illuminated; the point is considered to be
illuminated if the vector from the point to the center
of the sun doesn't intersect the target surface. `lit'
takes into account whether the target surface casts a
shadow on `spoint', regardless of the solar incidence
angle at `spoint'. `lit' is returned with the value
true if `spoint' is illuminated; otherwise it is
false.
[1,1] = size(lit); logical = class(lit)
The numerical results shown for this example may differ across
platforms. The results depend on the SPICE kernels used as input,
the compiler and supporting libraries, and the machine specific
arithmetic implementation.
Example:
Find the illumination angles at both the sub-observer point and
sub-solar point on Phobos as seen from Mars for a specified
sequence of times. Perform each computation twice, using both the
"intercept" and "ellipsoid near point" options for the sub-observer
point and sub-solar point computations. Compute the corresponding
illumination angles using an ellipsoidal surface for comparison.
(Note that the surface points on the plate model generally will
not lie on the ellipsoid's surface, so the emission and solar
incidence angles won't generally be zero at the sub-observer
and sub-solar points, respectively.)
In the following example program, the file
phobos_3_3.bds
is a DSK file containing a type 2 segment that provides a plate model
representation of the surface of Phobos. The file
mar097.bsp
is a binary SPK file containing data for Phobos, Mars, and the
Sun for a time interval starting at the date
2000 JAN 1 12:00:00 TDB.
pck00010.tpc is a planetary constants kernel file containing radii
and rotation model constants. naif0010.tls is a leapseconds kernel.
All of the kernels other than the DSK file should be loaded via
a meta-kernel. An example of the contents of such a kernel is:
KPL/MK
File name: illum.tm
\begindata
KERNELS_TO_LOAD = ( 'naif0010.tls'
'pck00010.tpc'
'mar097.bsp' )
\begintext
function illum_plid_pl02_t
%
% MiceUser globally defines DSK parameters.
% For more information, please see DSKMiceUser.m and
% DSKMice02.m.
%
MiceUser
%
% Constants
%
NCORR = 2;
NSAMP = 3;
NMETHOD = 2;
FIXREF = 'IAU_PHOBOS';
ILUM_METHOD = 'ELLIPSOID';
TOL = 1.d-12;
%
% Initial values
%
abcorrs = { 'NONE', 'CN+S' };
methods = { 'Intercept', 'Ellipsoid near point' };
obsrvr = 'Mars';
target = 'Phobos';
%
% Prompt for the name of a meta-kernel specifying
% all of the other kernels we need. Load the
% meta kernel.
%
meta = input( 'Enter meta-kernel name > ','s');
cspice_furnsh( meta )
%
% Prompt for the name of a DSK file.
%
dsk = input( 'Enter DSK name > ','s');
%
% Open the DSK file for read access.
% We use the DAS-level interface for
% this function.
%
handle = cspice_dasopr( dsk );
%
% Begin a forward search through the
% kernel, treating the file as a DLA.
% In this example, it's a very short
% search.
%
[dladsc, found] = cspice_dlabfs( handle );
if ~found
%
% We arrive here only if the kernel
% contains no segments. This is
% unexpected, but we're prepared for it.
%
cspice_kclear
fprintf( 'No segments found in DSK file %s\n', dsk )
return
end
%
% If we made it this far, `dladsc' is the
% DLA descriptor of the first segment.
%
%
% Get the DSK descriptor of the segment; from this
% descriptor we can obtain the ID of body-fixed frame
% associated with the segment. We'll need this frame
% later to compute illumination angles on the target
% body's reference ellipsoid.
%
dskdsc = cspice_dskgd( handle, dladsc );
fixref = cspice_frmnam( dskdsc(SPICE_DSK_FRMIDX) );
if ( strcmp(fixref, ' ') )
cspice_kclear
fprintf( ['Frame ID code # could not be mapped to ' ...
'a frame name %d\n'], dskdsc(SPICE_DSK_FRMIDX) )
return
end
%
% Now compute sub-points using both computation
% methods. We'll vary the aberration corrections
% and the epochs.
%
et0 = 0.0;
stepsize = 1.d6;
for i = 0:(NSAMP-1)
%
% Set the computation time for the ith sample.
%
et = et0 + i * stepsize;
timstr = cspice_timout( et, ...
'YYYY-MON-DD HR:MN:SC.### ::TDB(TDB)' );
fprintf( '\n\nObservation epoch: %s\n', timstr )
for coridx = 1:NCORR
abcorr = abcorrs( coridx );
fprintf( ' abcorr = %s\n', char(abcorr) );
for midx = 1:NMETHOD
%
% Select the computation method.
%
method = methods( midx );
fprintf( '\n Method =%s\n ', char(method) )
%
% Compute the sub-observer point using a plate
% model representation of the target's surface.
%
[xpt, alt, plid] = ...
cspice_subpt_pl02( handle, dladsc, method, ...
target, et, abcorr, ...
obsrvr );
%
% Compute the illumination angles at the sub-observer
% point. Also compute the light-of-sight visibility and
% shadowing flags.
%
[ trgepc, srfvec, phase, solar, emissn, visible, lit ] = ...
cspice_illum_plid_pl02( handle, dladsc, target, et, ...
abcorr, obsrvr, xpt, plid );
%
% Represent the surface point in latitudinal
% coordinates.
%
[ xr, xlon, xlat] = cspice_reclat( xpt );
fprintf( ...
'\n Sub-observer point on plate model surface:\n' )
fprintf( ' Planetocentric Longitude (deg): %f\n', ...
xlon * cspice_dpr() )
fprintf( ' Planetocentric Latitude (deg): %f\n', ...
xlat * cspice_dpr() )
fprintf( ...
'\n Illumination angles derived using a\n' )
fprintf( ' plate model surface:\n' )
fprintf( ...
' Phase angle (deg): %f\n', ...
phase * cspice_dpr() )
fprintf( ...
' Solar incidence angle (deg): %f\n', ...
solar * cspice_dpr() )
fprintf( ...
' Illumination flag : %d\n', ...
lit )
fprintf( ...
' Emission angle (deg): %f\n', ...
emissn * cspice_dpr() )
fprintf( ...
' Visibility flag : %d\n', ...
visible )
fprintf( ...
' Range to surface point (km): %f\n', ...
norm( srfvec ) )
%
% Compute the illumination angles using an ellipsoidal
% representation of the target's surface. The role of
% this representation is to provide an outward surface
% normal.
%
[trgepc, srfvec, phase, solar, emissn] = ...
cspice_ilumin( ILUM_METHOD, ...
target, et, FIXREF, ...
abcorr, obsrvr, xpt);
fprintf( ...
' Illumination angles derived using an\n' )
fprintf( ' ellipsoidal reference surface::\n' )
fprintf( ...
' Phase angle (deg): %f\n', ...
phase * cspice_dpr() )
fprintf( ...
' Solar incidence angle (deg): %f\n', ...
solar * cspice_dpr() )
fprintf( ...
' Emission angle (deg): %f\n', ...
emissn * cspice_dpr() )
%
% Now repeat our computations using the
% sub-solar point.
%
% Compute the sub-solar point using a plate model
% representation of the target's surface.
%
[xpt, dist, plid] = ...
cspice_subsol_pl02( handle, dladsc, method, ...
target, et, abcorr, ...
obsrvr );
%
% Compute the illumination angles at the sub-solar point.
% Also compute the light-of-sight visibility and
% shadowing flags.
%
[ trgepc, srfvec, phase, solar, emissn, visible, lit] = ...
cspice_illum_plid_pl02( handle, dladsc, target, et, ...
abcorr, obsrvr, xpt, plid );
%
% Represent the surface point in latitudinal
% coordinates.
%
[ xr, xlon, xlat] = cspice_reclat( xpt );
fprintf( '\n Sub-solar point on plate model surface:\n' )
fprintf( ' Planetocentric Longitude (deg): %f\n', ...
xlon * cspice_dpr() )
fprintf( ' Planetocentric Latitude (deg): %f\n', ...
xlat * cspice_dpr() )
fprintf( ...
'\n Illumination angles derived using a\n' )
fprintf( ' plate model surface:\n' )
fprintf( ...
' Phase angle (deg): %f\n', ...
phase * cspice_dpr() )
fprintf( ...
' Solar incidence angle (deg): %f\n', ...
solar * cspice_dpr() )
fprintf( ...
' Illumination flag : %d\n', ...
lit )
fprintf( ...
' Emission angle (deg): %f\n', ...
emissn * cspice_dpr() )
fprintf( ...
' Visibility flag : %d\n', ...
visible )
fprintf( ...
' Range to surface point (km): %f\n', ...
norm( srfvec ) )
%
% Compute the illumination angles using an ellipsoidal
% representation of the target's surface. The role of
% this representation is to provide an outward surface
% normal.
%
[ etrgep, esrfvc, phase, solar, emissn ] = ...
cspice_ilumin( ILUM_METHOD, target, et, fixref, ...
abcorr, obsrvr, xpt );
fprintf( ...
' Illumination angles derived using an\n' )
fprintf( ' ellipsoidal surface:\n' )
fprintf( ...
' Phase angle (deg): %f\n', ...
phase * cspice_dpr() )
fprintf( ...
' Solar incidence angle (deg): %f\n', ...
solar * cspice_dpr() )
fprintf( ...
' Emission angle (deg): %f\n\n', ...
emissn * cspice_dpr() )
end
end
end
%
% Close the DSK file. Unload all other kernels as well.
%
cspice_dascls( handle )
%
% It's always good form to unload kernels after use,
% particularly in Matlab due to data persistence.
%
cspice_kclear
MATLAB outputs:
Observation epoch: 2000-JAN-01 12:00:00.000 (TDB)
abcorr = NONE
Method =Intercept
Sub-observer point on plate model surface:
Planetocentric Longitude (deg): -0.348118
Planetocentric Latitude (deg): 0.008861
Illumination angles derived using a
plate model surface:
Phase angle (deg): 101.596824
Solar incidence angle (deg): 98.376877
Illumination flag : 0
Emission angle (deg): 9.812914
Visibility flag : 1
Range to surface point (km): 9501.835727
Illumination angles derived using an
ellipsoidal reference surface::
Phase angle (deg): 101.596824
Solar incidence angle (deg): 101.695444
Emission angle (deg): 0.104977
Sub-solar point on plate model surface:
Planetocentric Longitude (deg): 102.413905
Planetocentric Latitude (deg): -24.533127
Illumination angles derived using a
plate model surface:
Phase angle (deg): 101.665306
Solar incidence angle (deg): 13.068798
Illumination flag : 1
Emission angle (deg): 98.408735
Visibility flag : 0
Range to surface point (km): 9516.720964
Illumination angles derived using an
ellipsoidal surface:
Phase angle (deg): 101.665306
Solar incidence angle (deg): 11.594741
Emission angle (deg): 98.125499
Method =Ellipsoid near point
Sub-observer point on plate model surface:
Planetocentric Longitude (deg): -0.264850
Planetocentric Latitude (deg): 0.004180
Illumination angles derived using a
plate model surface:
Phase angle (deg): 101.596926
Solar incidence angle (deg): 98.376877
Illumination flag : 0
Emission angle (deg): 9.812985
Visibility flag : 1
Range to surface point (km): 9501.837763
Illumination angles derived using an
ellipsoidal reference surface::
Phase angle (deg): 101.596926
Solar incidence angle (deg): 101.593324
Emission angle (deg): 0.003834
Sub-solar point on plate model surface:
Planetocentric Longitude (deg): 105.857346
Planetocentric Latitude (deg): -16.270558
Illumination angles derived using a
plate model surface:
Phase angle (deg): 101.663675
Solar incidence angle (deg): 16.476730
Illumination flag : 1
Emission angle (deg): 118.124981
Visibility flag : 0
Range to surface point (km): 9517.506732
Illumination angles derived using an
ellipsoidal surface:
Phase angle (deg): 101.663675
Solar incidence angle (deg): 0.422781
Emission angle (deg): 101.541470
...
The term "illumination angles" refers to following set of
angles:
solar incidence angle Angle between the surface normal at the
specified surface point and the vector
from the surface point to the Sun.
emission angle Angle between the surface normal at the
specified surface point and the vector
from the surface point to the observer.
phase angle Angle between the vectors from the
surface point to the observing body and
from the surface point to the Sun.
The diagram below illustrates the geometric relationships defining
these angles. The labels for the solar incidence, emission, and
phase angles are "s.i.", "e.", and "phase".
*
Sun
surface normal vector
._ _.
|\ /| Sun vector
\ phase /
\ . . /
. .
\ ___ /
. \/ \/
_\ s.i./
. / \ /
. | e. \ /
* <--------------- * surface point on
viewing vector target body
location to viewing
(observer) location
Note that if the target-observer vector, the target normal vector
at the surface point, and the target-sun vector are coplanar, then
phase is the sum of incidence and emission. This is rarely true;
usually
phase angle < solar incidence angle + emission angle
All of the above angles can be computed using light time
corrections, light time and stellar aberration corrections, or
no aberration corrections. The way aberration corrections
are used is described below.
Care must be used in computing light time corrections. The
guiding principle used here is "describe what appears in
an image."
Observer-target body surface point vector
-----------------------------------------
Let `et' be the epoch at which an observation or remote
sensing measurement is made, and let et - lt ("lt" stands
for "light time") be the epoch at which the photons received
at `et' were emitted from the body (we use the term "emitted"
loosely here).
The correct observer-target vector points from the observer's
location at `et' to the surface point location at et - lt.
The target-observer vector points in the opposite direction.
Since light time corrections are not anti-symmetric, the correct
target-observer vector CANNOT be found by negating the light
time corrected position of the observer as seen from the
target body.
Target body's orientation
-------------------------
Using the definitions of `et' and `lt' above, the target
body's orientation at et-lt is used. The surface
normal is dependent on the target body's orientation, so
the body's orientation model must be evaluated for the correct
epoch.
Target body -- Sun vector
-------------------------
All surface features on the target body will appear in a
measurement made at `et' as they were at the target at epoch
et-lt. In particular, lighting on the target body is dependent
on the apparent location of the Sun as seen from the target body
at et-lt. So, a second light time correction is used in finding
the apparent location of the Sun.
Stellar aberration corrections, when used, are applied as follows:
Observer-target body vector
---------------------------
In addition to light time correction, stellar aberration is used
in computing the apparent target surface point position as seen
from the observer's location at time `et'. This apparent position
defines the observer-target surface point vector.
Target body-Sun vector
----------------------
The target body-Sun vector is the apparent position of the Sun,
corrected for light time and stellar aberration, as seen from
the target body at time et-lt. Note that the target body's
position is not affected by the stellar aberration correction
applied in finding its apparent position as seen by the
observer.
Once all of the vectors, as well as the target body's orientation,
have been computed with the proper aberration corrections, the
element of time is eliminated from the computation. The problem
becomes a purely geometric one and is described by the diagram above.
For important details concerning this module's function, please refer to
the CSPICE routine illum_plid_pl02.
MICE.REQ
ABCORR.REQ
DSK.REQ
PCK.REQ
SPK.REQ
TIME.REQ
-Mice Version 1.0.0, 04-APR-2017, NJB (JPL), EDW (JPL)
plate model surface point visibility and shadowing
illumination angles using DSK type 2 plate model
lighting angles using DSK type 2 plate model
phase angle using DSK type 2 plate model
emission angle using DSK type 2 plate model
solar incidence angle using DSK type 2 plate model
|


Warning - Class YiiMailMessage parent CComponent not found Warning - Class YiiMail parent CApplicationComponent not found
AbstractFilterableInputStream.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_ByteStream_AbstractFilterableInputStream", use another DocBlock to document the file
AbstractHeader.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_AbstractHeader", use another DocBlock to document the file
AbstractSmtpTransport.php
Warnings:
Warning on line 27 - DocBlock would be page-level, but precedes class "Swift_Transport_AbstractSmtpTransport", use another DocBlock to document the file
AntiFloodPlugin.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Plugins_AntiFloodPlugin", use another DocBlock to document the file
ArrayByteStream.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_ByteStream_ArrayByteStream", use another DocBlock to document the file
ArrayCharacterStream.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_CharacterStream_ArrayCharacterStream", use another DocBlock to document the file
ArrayKeyCache.php
Warnings:
Warning on line 23 - DocBlock would be page-level, but precedes class "Swift_KeyCache_ArrayKeyCache", use another DocBlock to document the file
ArrayLogger.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Plugins_Loggers_ArrayLogger", use another DocBlock to document the file
ArrayRecipientIterator.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Mailer_ArrayRecipientIterator", use another DocBlock to document the file
Attachment.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Attachment", use another DocBlock to document the file Warning on line 23 - DocBlock would be page-level, but precedes class "Swift_Mime_Attachment", use another DocBlock to document the file
Authenticator.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Transport_Esmtp_Authenticator", use another DocBlock to document the file
AuthHandler.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Transport_Esmtp_AuthHandler", use another DocBlock to document the file
BandwidthMonitorPlugin.php
Warnings:
Warning on line 27 - DocBlock would be page-level, but precedes class "Swift_Plugins_BandwidthMonitorPlugin", use another DocBlock to document the file
Base64ContentEncoder.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Mime_ContentEncoder_Base64ContentEncoder", use another DocBlock to document the file
Base64Encoder.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Encoder_Base64Encoder", use another DocBlock to document the file
Base64HeaderEncoder.php
Warnings:
Warning on line 35 - File "/repository/skiclubz/trunk/protected/extensions/yii-mail/vendors/swiftMailer/classes/Swift/Mime/HeaderEncoder/Base64HeaderEncoder.php" has no page-level DocBlock, use @package in the first DocBlock to create one
ByteArrayReplacementFilter.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_StreamFilters_ByteArrayReplacementFilter", use another DocBlock to document the file
CharacterReader.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_CharacterReader", use another DocBlock to document the file Warning on line 38 - Unknown tag "@int" used
CharacterReaderFactory.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_CharacterReaderFactory", use another DocBlock to document the file
CharacterStream.php
Warnings:
Warning on line 85 - File "/repository/skiclubz/trunk/protected/extensions/yii-mail/vendors/swiftMailer/classes/Swift/CharacterStream.php" has no page-level DocBlock, use @package in the first DocBlock to create one
CharsetObserver.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Mime_CharsetObserver", use another DocBlock to document the file
CommandEvent.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_CommandEvent", use another DocBlock to document the file
CommandListener.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_CommandListener", use another DocBlock to document the file
ContentEncoder.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Mime_ContentEncoder", use another DocBlock to document the file
CramMd5Authenticator.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Transport_Esmtp_Auth_CramMd5Authenticator", use another DocBlock to document the file
DateHeader.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_DateHeader", use another DocBlock to document the file
DecoratorPlugin.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Plugins_DecoratorPlugin", use another DocBlock to document the file
DependencyContainer.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_DependencyContainer", use another DocBlock to document the file
DependencyException.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_DependencyException", use another DocBlock to document the file
DiskKeyCache.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_KeyCache_DiskKeyCache", use another DocBlock to document the file
EchoLogger.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_Plugins_Loggers_EchoLogger", use another DocBlock to document the file
EmbeddedFile.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_EmbeddedFile", use another DocBlock to document the file Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Mime_EmbeddedFile", use another DocBlock to document the file
Encoder.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Encoder", use another DocBlock to document the file
Encoding.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Encoding", use another DocBlock to document the file
EncodingObserver.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Mime_EncodingObserver", use another DocBlock to document the file
EsmtpHandler.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Transport_EsmtpHandler", use another DocBlock to document the file
EsmtpTransport.php
Warnings:
Warning on line 27 - DocBlock would be page-level, but precedes class "Swift_Transport_EsmtpTransport", use another DocBlock to document the file
Event.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_Events_Event", use another DocBlock to document the file
EventDispatcher.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_EventDispatcher", use another DocBlock to document the file
EventListener.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Events_EventListener", use another DocBlock to document the file
EventObject.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_EventObject", use another DocBlock to document the file
FailoverTransport.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_FailoverTransport", use another DocBlock to document the file Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Transport_FailoverTransport", use another DocBlock to document the file
FileByteStream.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_ByteStream_FileByteStream", use another DocBlock to document the file
FileStream.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_FileStream", use another DocBlock to document the file
Filterable.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_Filterable", use another DocBlock to document the file
GenericFixedWidthReader.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_CharacterReader_GenericFixedWidthReader", use another DocBlock to document the file Warning on line 63 - Unknown tag "@int" used
Header.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Mime_Header", use another DocBlock to document the file
HeaderEncoder.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Mime_HeaderEncoder", use another DocBlock to document the file
HeaderFactory.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Mime_HeaderFactory", use another DocBlock to document the file
HeaderSet.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Mime_HeaderSet", use another DocBlock to document the file
HitReporter.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Plugins_Reporters_HitReporter", use another DocBlock to document the file
HtmlReporter.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Plugins_Reporters_HtmlReporter", use another DocBlock to document the file
IdentificationHeader.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_IdentificationHeader", use another DocBlock to document the file
Image.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Image", use another DocBlock to document the file
InputByteStream.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_InputByteStream", use another DocBlock to document the file
IoBuffer.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Transport_IoBuffer", use another DocBlock to document the file
IoException.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_IoException", use another DocBlock to document the file
KeyCache.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_KeyCache", use another DocBlock to document the file
KeyCacheInputStream.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_KeyCache_KeyCacheInputStream", use another DocBlock to document the file
LoadBalancedTransport.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_LoadBalancedTransport", use another DocBlock to document the file Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Transport_LoadBalancedTransport", use another DocBlock to document the file
Logger.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Plugins_Logger", use another DocBlock to document the file
LoggerPlugin.php
Warnings:
Warning on line 33 - DocBlock would be page-level, but precedes class "Swift_Plugins_LoggerPlugin", use another DocBlock to document the file
LoginAuthenticator.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Transport_Esmtp_Auth_LoginAuthenticator", use another DocBlock to document the file
MailboxHeader.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_MailboxHeader", use another DocBlock to document the file
Mailer.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Mailer", use another DocBlock to document the file
MailInvoker.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_Transport_MailInvoker", use another DocBlock to document the file
MailTransport.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_MailTransport", use another DocBlock to document the file Warning on line 31 - DocBlock would be page-level, but precedes class "Swift_Transport_MailTransport", use another DocBlock to document the file
Message.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Mime_Message", use another DocBlock to document the file Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Message", use another DocBlock to document the file
MimeEntity.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Mime_MimeEntity", use another DocBlock to document the file
MimePart.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_MimePart", use another DocBlock to document the file Warning on line 23 - DocBlock would be page-level, but precedes class "Swift_Mime_MimePart", use another DocBlock to document the file
NgCharacterStream.php
Warnings:
Warning on line 33 - DocBlock would be page-level, but precedes class "Swift_CharacterStream_NgCharacterStream", use another DocBlock to document the file
NullKeyCache.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_KeyCache_NullKeyCache", use another DocBlock to document the file
OutputByteStream.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_OutputByteStream", use another DocBlock to document the file
ParameterizedHeader.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Mime_ParameterizedHeader", use another DocBlock to document the file Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_ParameterizedHeader", use another DocBlock to document the file
PathHeader.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_PathHeader", use another DocBlock to document the file
PlainAuthenticator.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Transport_Esmtp_Auth_PlainAuthenticator", use another DocBlock to document the file
PlainContentEncoder.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Mime_ContentEncoder_PlainContentEncoder", use another DocBlock to document the file
Pop3Connection.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Plugins_Pop_Pop3Connection", use another DocBlock to document the file
Pop3Exception.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Plugins_Pop_Pop3Exception", use another DocBlock to document the file
PopBeforeSmtpPlugin.php
Warnings:
Warning on line 23 - DocBlock would be page-level, but precedes class "Swift_Plugins_PopBeforeSmtpPlugin", use another DocBlock to document the file
QpContentEncoder.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Mime_ContentEncoder_QpContentEncoder", use another DocBlock to document the file
QpEncoder.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Encoder_QpEncoder", use another DocBlock to document the file
QpHeaderEncoder.php
Warnings:
Warning on line 98 - File "/repository/skiclubz/trunk/protected/extensions/yii-mail/vendors/swiftMailer/classes/Swift/Mime/HeaderEncoder/QpHeaderEncoder.php" has no page-level DocBlock, use @package in the first DocBlock to create one
RecipientIterator.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Mailer_RecipientIterator", use another DocBlock to document the file
ReplacementFilterFactory.php
Warnings:
Warning on line 16 - DocBlock would be page-level, but precedes class "Swift_ReplacementFilterFactory", use another DocBlock to document the file
Replacements.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Plugins_Decorator_Replacements", use another DocBlock to document the file
Reporter.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Plugins_Reporter", use another DocBlock to document the file
ReporterPlugin.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Plugins_ReporterPlugin", use another DocBlock to document the file
ResponseEvent.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Events_ResponseEvent", use another DocBlock to document the file
ResponseListener.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_ResponseListener", use another DocBlock to document the file
Rfc2231Encoder.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Encoder_Rfc2231Encoder", use another DocBlock to document the file
RfcComplianceException.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_RfcComplianceException", use another DocBlock to document the file
SendEvent.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Events_SendEvent", use another DocBlock to document the file
SendListener.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_SendListener", use another DocBlock to document the file
SendmailTransport.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_SendmailTransport", use another DocBlock to document the file Warning on line 28 - DocBlock would be page-level, but precedes class "Swift_Transport_SendmailTransport", use another DocBlock to document the file
SimpleCharacterReaderFactory.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_CharacterReaderFactory_SimpleCharacterReaderFactory", use another DocBlock to document the file
SimpleEventDispatcher.php
Warnings:
Warning on line 27 - DocBlock would be page-level, but precedes class "Swift_Events_SimpleEventDispatcher", use another DocBlock to document the file
SimpleHeaderFactory.php
Warnings:
Warning on line 27 - DocBlock would be page-level, but precedes class "Swift_Mime_SimpleHeaderFactory", use another DocBlock to document the file
SimpleHeaderSet.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Mime_SimpleHeaderSet", use another DocBlock to document the file
SimpleKeyCacheInputStream.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_KeyCache_SimpleKeyCacheInputStream", use another DocBlock to document the file
SimpleMailInvoker.php
Warnings:
Warning on line 30 - DocBlock would be page-level, but precedes class "Swift_Transport_SimpleMailInvoker", use another DocBlock to document the file
SimpleMessage.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Mime_SimpleMessage", use another DocBlock to document the file
SimpleMimeEntity.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Mime_SimpleMimeEntity", use another DocBlock to document the file
Sleeper.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Plugins_Sleeper", use another DocBlock to document the file
SmtpAgent.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Transport_SmtpAgent", use another DocBlock to document the file
SmtpTransport.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_SmtpTransport", use another DocBlock to document the file
StreamBuffer.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Transport_StreamBuffer", use another DocBlock to document the file
StreamFilter.php
Warnings:
Warning on line 16 - DocBlock would be page-level, but precedes class "Swift_StreamFilter", use another DocBlock to document the file
StringReplacementFilter.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift_StreamFilters_StringReplacementFilter", use another DocBlock to document the file
StringReplacementFilterFactory.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_StreamFilters_StringReplacementFilterFactory", use another DocBlock to document the file
Swift.php
Warnings:
Warning on line 18 - DocBlock would be page-level, but precedes class "Swift", use another DocBlock to document the file
SwiftException.php
Warnings:
Warning on line 16 - DocBlock would be page-level, but precedes class "Swift_SwiftException", use another DocBlock to document the file
ThrottlerPlugin.php
Warnings:
Warning on line 24 - DocBlock would be page-level, but precedes class "Swift_Plugins_ThrottlerPlugin", use another DocBlock to document the file
Timer.php
Warnings:
Warning on line 17 - DocBlock would be page-level, but precedes class "Swift_Plugins_Timer", use another DocBlock to document the file
Transport.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Transport", use another DocBlock to document the file
TransportChangeEvent.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_Events_TransportChangeEvent", use another DocBlock to document the file
TransportChangeListener.php
Warnings:
Warning on line 22 - DocBlock would be page-level, but precedes class "Swift_Events_TransportChangeListener", use another DocBlock to document the file
TransportException.php
Warnings:
Warning on line 19 - DocBlock would be page-level, but precedes class "Swift_TransportException", use another DocBlock to document the file
TransportExceptionEvent.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_Events_TransportExceptionEvent", use another DocBlock to document the file
TransportExceptionListener.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Events_TransportExceptionListener", use another DocBlock to document the file
UnstructuredHeader.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_Mime_Headers_UnstructuredHeader", use another DocBlock to document the file
UsAsciiReader.php
Warnings:
Warning on line 20 - DocBlock would be page-level, but precedes class "Swift_CharacterReader_UsAsciiReader", use another DocBlock to document the file Warning on line 46 - Unknown tag "@int" used
Utf8Reader.php
Warnings:
Warning on line 21 - DocBlock would be page-level, but precedes class "Swift_CharacterReader_Utf8Reader", use another DocBlock to document the file Warning on line 147 - Unknown tag "@int" used
YiiMail.php
Warnings:
Warning on line 45 - no @package tag was used in a DocBlock for class YiiMail
YiiMailMessage.php
Warnings:
Warning on line 35 - no @package tag was used in a DocBlock for class YiiMailMessage
Documentation generated on Fri, 12 Nov 2010 20:45:32 +0000 by phpDocumentor 1.4.3


Use My Tech Stuff
Sign Up
Sign In
Use My Tech Stuff
Let your tech
make you money
or save money by renting locally
Why you'll love us
We help you
save money
by renting tech equipment locally. We offer
safe
and
secure
handling.
You get to choose
the day and time that works for you.
Download app


Mindfulness Triathlon
Join us for a Mindfulness Triathlon at the studio, from 9:45-12:45. This special morning includes a meditation class that includes Susan’s TIME OUT mindfulness training along with yoga Nidra lead by Susan Agrios then our Yin class to follow. Try THREE different meditative and stress busting activities in one morning. Sign up today for all three for just $50 (passes will be on hold), member pricing is available for $40. This unique experience is going to be run this month only.
Habitat for Humanity
Build your karma with us and the Habitat for Humanity project house build. The studio family will be building a house loaded with good karma from next summer. Sign up at the front desk, bring your friends and family and make a difference in the lives of some local families. All participants need to raise $165.00 each in donations, and you can make your donation through the web site or directly to habitat for humanity.


I think I have always had good communication
skills when working with other people. I have
lead team projects in Uni because I could
communicate well and make decisions. I enjoy
working with other people and companies, as
well as getting to know people in my personal
life.
I am good in job interviews and can communicate
clear and concisely.
As mentioned in my values, I believe a strength of
mine in my profession life is self awareness including
honesty and self reflection.
This ties into my communication skills where I can
happily work with people and remain "interested,
not interesting".
In my final year of University, I completed a
paper called Creative Workflows.
This paper consisted of how to manage your time,
money, task responsibility etc using a creative
workflow model in a long term project.
I genuinely gained an interest in this paper and
still practice the methodologies and management
skills when working on personal projects.
I have always enjoyed art particularly paiting
using acrylics, digital art on my Ipad, creating
and editing videos, and more recently, photography
(which I am really bad at).
All of these artistic skills I use in both my daily
habits, hobbies and also my professional/educational
life.
I began the Creative Technologies degree because I
knew I was a creative person and thrived in a creative
environment - not because I was particularly tech
savvy when I was 18... I loved coming up with creative
project ideas that generally included a mixture of art
and design and interactive technologies.
This included my final project in Uni which was a group
project called Horotiu. Horotiu was a screen-based,
interactive installation In Aotea Square that educated
the public on the Maori mythology and history of Auckland
CBD. This was done through hand-drawn animation (my
project partner), lighting design and interactivity.
When I was in first year of Uni, I was absolutely desperate for money and decided to work 3-4 days a week while studying full time. This did have an impact of my learning journey and grades and I definitely regret it. That's what Studylink is for!
I think what is most notable about Kiwi culture,
stemming from Maori culture, that has influenced my
values and identity is kaitiakatanga (being one with
the environment, and respecting the land) and
manaakitanga (being hospitable).
Kaitiakatanga has influenced me to value respectfulness
of myself and others, and further having gratitude,
empathy and mindfulness for the people around me;
collegues, friends, family.
Manaakitanga has influenced me to value the people around
me as individuals and treat them as my whanau. This also
ties into self aware in my actions of treating people;
being welcoming, “interested, not interesting”.
In a learning or career environment, my communication
skills and decision making skills has helped me become
the young, ambitious person that I am today.
I strived for a degree with high grades that I absolutely
loved, I worked alongside individuals, other businesses and
industry standard mentors to further my learning and career
development.
I am grateful to have an ambition to connect with the people
around me - everyone has something to offer, everyone has a
talent.
What I noticed in studying Creative Technologies is when
working in groups there always needs to be a chief decision
maker. This was something we practiced in the first year or so.
When it is hard to come up with project ideas or move into
the next phase of a project there can be several difficult
decision on where to navigate the project i.e do we include
this feature? is it useful
I found it was a good skill to quickly analyze the situation
and make a decision to continue the flow of project.
Our lecturers would always say, “just make a decision on
something and START IT, whatever it is, and then make more
decisions and KEEP GOING”
One of my strengths, being a good decision maker, I think will help me in my learning journey. But I am not necessarily a good problem solver (that I have noticed) which is what a developer is when programming. I am hoping to grow my problem solving skills throughout this course with all of the individual and group projects.
I remember in a group project in uni where
we were creating a hypothetical application
called Ecocery. Ecocery was a phone app to
help users purchase environmentally food
products when grocery shopping.
You would scan the barcode, and information
on the products ingredients, packaging, water
footprint and carbon footprint, and how
environmentally the brands company is as a
whole, would pop up on the screen and give
it an overall rating.
I decided to create the hypothetical app using
Wix, which contained a section dedicated to
informative article on how food impacts the
environment. One team member wrote an article
about transport for the website which I felt
was not relevant and shouldn't be on the website
as it is about food.
This did create tension between the team member
and myself but we came to a rational decision to
re-write an article together that was more relevant.
We got an A for the project!


Alexey Vasiliev, Railsware
Brought to you by Alexey Vasiliev, Railsware
PostgreSQL ("Postgres") - is an object-relational database management system (ORDBMS) with an emphasis on extensibility and standards-compliance. Based on the SQL language and supports many of the features of the standard SQL:2011. PostgreSQL evolved from the Ingres project at the University of California, Berkeley. In 1982 the leader of the Ingres team, Michael Stonebraker, left Berkeley to make a proprietary version of Ingres. He returned to Berkeley in 1985 and started a post-Ingres project
CREATE TABLE numbers (x INTEGER) PARTITION BY RANGE (x);
CREATE TABLE negatives PARTITION OF numbers FOR
VALUES FROM (MINVALUE) TO (0);
CREATE TABLE positives PARTITION OF numbers FOR
VALUES FROM (0) TO (MAXVALUE);
# INSERT INTO numbers VALUES (-3), (-1), (9), (99);
INSERT 0 4
# SELECT * FROM numbers;
x
----
-3
-1
9
99
(4 rows)
# SELECT * FROM negatives;
x
----
-3
-1
(2 rows)
# SELECT * FROM positives;
x
----
9
99
(2 rows)
# SELECT * FROM ONLY numbers;
x
---
(0 rows)
# CREATE TABLE book_history_2016_07
PARTITION OF book_history
FOR VALUES FROM ('2016-07-01 00:00:00')
TO ('2016-09-01 00:00:00');
ERROR: partition "book_history_2016_07" would
overlap partition "book_history_2016_08"
# CREATE PUBLICATION financials FOR TABLE
ONLY loans, ONLY fines;
origin# pg_dump libdata -Fc -f /netshare/libdata.dump
replica# pg_restore -d
libdata -s -t loans -t fines /netshare/libdata.dump
# CREATE SUBSCRIPTION financials
CONNECTION 'dbname=libdata user=postgres host=<IP_ADDRESS>'
PUBLICATION financials;
NOTICE: synchronized table states
NOTICE: created replication slot "financials" on publisher
CREATE SUBSCRIPTION
# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+---------------------
subid | 16475
subname | financials
pid | 167
relid |
received_lsn | 0/1FBEAF0
last_msg_send_time | 2017-06-07 00:59:44
last_msg_receipt_time | 2017-06-07 00:59:44
latest_end_lsn | 0/1FBEAF0
latest_end_time | 2017-06-07 00:59:44
# \timing
Timing is on.
# SELECT bid, count(*) FROM account_history
WHERE delta > 1000 group by bid;
...
Time: 324.903 ms
# set max_parallel_workers_per_gather=4;
SET
Time: 0.822 ms
# SELECT bid, count(*) FROM account_history
WHERE delta > 1000 GROUP BY bid;
...
Time: 72.864 ms
synchronous_standby_names = FIRST 2(node1,node2,node3);
synchronous_standby_names = ANY 2(node1,node2,node3);
$ explain (analyze on, verbose on) select group_id,
count(*) from data_from_origin group by group_id order by group_id;
QUERY PLAN
--------------------------------------------------------------------------------------
GroupAggregate (cost=100.00..222.22 rows=200 width=12) (actual time=55.823..119.840 rows=11 loops=1)
Output: group_id, count(*)
Group Key: data_from_origin.group_id
-> Foreign Scan on public.data_from_origin (cost=100.00..205.60 rows=2925 width=4)
(actual time=51.703..110.939 rows=100000 loops=1)
Output: id, group_id
Remote SQL: SELECT group_id FROM public.sample_data ORDER BY group_id ASC NULLS LAST
Execution time: 120.534 ms
(8 rows)
$ explain (analyze on, verbose on) select group_id, count(*)
from data_from_origin group by group_id order by group_id;
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Sort (cost=167.52..168.02 rows=200 width=12) (actual time=21.606..21.607 rows=11 loops=1)
Output: group_id, (count(*))
Sort Key: data_from_origin.group_id
Sort Method: quicksort Memory: 25kB
-> Foreign Scan (cost=114.62..159.88 rows=200 width=12)
(actual time=21.596..21.597 rows=11 loops=1)
Output: group_id, (count(*))
Relations: Aggregate on (public.data_from_origin)
Remote SQL: SELECT group_id, count(*) FROM public.sample_data GROUP BY group_id
Execution time: 21.900 ms
(10 rows)
$ create user test;
CREATE USER
$ alter user test with password 'abba1234';
ALTER USER
$ select usename, passwd from pg_shadow where usename = 'test';
usename | passwd
---------+-------------------------------------
test | md5b9ad53e3f2f85cd793091f661832fd34
(1 row)
To enable scram passwords, we will need to change, in postgresql.conf:
password_encryption = scram-sha-256
$ create user test2 with password 'abba1234';
CREATE ROLE
$ create user test3 with password 'abba1234';
CREATE ROLE
$ select usename, passwd from pg_shadow where usename ~ '^test[23]$';
usename | passwd
---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
test2 | scram-sha-256:jEpSN6AcvbKsRw==:4096:ff2ccc8e61b4b638b28dfb1c99e44df1a63a2c6a53424a6f4c2e448caeaa46cd:86ef4490e67117fca17e3cc7f7b8276ea8777a656cfb2e41e82037e4e98d128b
test3 | scram-sha-256:A1x/O56i589Puw==:4096:de83debb226eebda74a16ddf66f9c878115f3d4d73653bf863f3e8e9e95d95ff:ba05283f9a3620fa290c5ec916e8729d9e7c0f89f728b1eb0a6850f522a0eebc
(2 rows)
$ drop user test2;
DROP ROLE
$ create user test2 with password 'abba1234';
CREATE ROLE
$ select usename, passwd from pg_shadow where usename = 'test2';
usename | passwd
---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
test2 | scram-sha-256:vKJJkdipOsrasw==:4096:6648b76ebb17fa4e13b1900e62829d2a87ddede160954a7bc596cb688034b2b6:fa1321166eb3259fc8ae0ed73ed5725adb2b170ff784b3047d9318b466d3555b
(1 row)
SCRAM-SHA-256 provides a more secure password authentication method than MD5:
$ CREATE TABLE hoteldata AS SELECT xml
$$<hotels>
<hotel id="mancha">
<name>La Mancha</name>
<rooms>
<room id="201"><capacity>3</capacity><comment>Great view of the Channel</comment></room>
<room id="202"><capacity>5</capacity></room>
</rooms>
<personnel>
<person id="1025">
<name>Ferdinando Quijana</name><salary currency="PTA">45000</salary>
</person>
</personnel>
</hotel>
...
</hotels>$$ AS hotels;
$ SELECT xmltable.*
FROM hoteldata,
XMLTABLE ('/hotels/hotel/rooms/room' PASSING hotels
COLUMNS
id FOR ORDINALITY,
hotel_name text PATH '../../name' NOT NULL,
room_id int PATH '@id' NOT NULL,
capacity int,
comment text PATH 'comment' DEFAULT 'A regular room'
);
id | hotel_name | room_id | capacity | comment
----+------------+---------+----------+---------------------------
1 | La Mancha | 201 | 3 | Great view of the Channel
2 | La Mancha | 202 | 5 | A regular room
3 | Valparaíso | 201 | 2 | Very noisy
4 | Valparaíso | 202 | 2 | A regular room
(4 rows)
# CREATE INDEX bookdata_fts ON bookdata
USING gin (( to_tsvector('english',bookdata) ));
CREATE INDEX
# SELECT bookdata -> 'title'
FROM bookdata
WHERE to_tsvector('english',bookdata) @@ to_tsquery('duke');
------------------------------------------
"The Tattooed Duke"
"She Tempts the Duke"
"The Duke Is Mine"
"What I Did For a Duke"
# CREATE TABLE t (a INT, b INT);
# INSERT INTO t SELECT i % 100, i % 100 FROM
generate_series(1, 10000) s(i);
# ANALYZE t;
# SELECT relpages, reltuples FROM pg_class WHERE relname = 't';
relpages | reltuples
----------+-----------
45 | 10000
(1 row)
# EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1;
QUERY PLAN
-------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..170.00 rows=100 width=8)
(actual rows=100 loops=1)
Filter: (a = 1)
Rows Removed by Filter: 9900
Planning time: 0.222 ms
Execution time: 2.020 ms
(5 rows)
# EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t
WHERE a = 1 AND b = 1;
QUERY PLAN
-----------------------------------------------------------------------------
Seq Scan on t (cost=0.00..195.00 rows=1 width=8)
(actual rows=100 loops=1)
Filter: ((a = 1) AND (b = 1))
Rows Removed by Filter: 9900
Planning time: 0.130 ms
Execution time: 1.961 ms
(5 rows)
# CREATE STATISTICS stts (dependencies) ON a, b FROM t;
CREATE STATISTICS
# ANALYZE t;
ANALYZE
# EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t
WHERE a = 1 AND b = 1;
QUERY PLAN
-------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..195.00 rows=100 width=8)
(actual rows=100 loops=1)
Filter: ((a = 1) AND (b = 1))
Rows Removed by Filter: 9900
Planning time: 0.248 ms
Execution time: 1.969 ms
(5 rows)


Prices
Features
Prices
List of prices
Features
List of product features....
Prices
Features
Prices
List of prices
Features
List of product features....


Interested in getting involved in research? Want to sharpen your academic skills? Just wondering what it is your professors do all day? Then come join the UTSC Computer and Mathematical Sciences Undergraduate Research Group.
The CMS Undergraduate Research Group was founded to give students in our department an opportunity to explore and participate in research. To date, we have published 7 papers with 12 undergraduate co-authors, established an annual symposium, and had students present at local, national and international research conferences.
Sign up for our welcome sessions/reading group/e-mail list: HERE


|
ObjectAL
2.1
ObjectAL API Reference (iOS) for www.kobold2d.com developers
|
Provides two controls (interrupted and manuallySuspended) for suspending a slave object, and also propagates such control messages to interested listeners. More...
#import <OALSuspendHandler.h>
Public Member Functions | |
| (id) | - initWithTarget:selector: |
| Initialize a handler with the specified slave target and selector. | |
| (void) | - addSuspendListener: |
| Add a listener that will receive manual suspend and interrupt events. | |
| (void) | - removeSuspendListener: |
| Remove a registered listener. | |
Static Public Member Functions | |
| (OALSuspendHandler *) | + handlerWithTarget:selector: |
| Create a new handler with the specified slave target and selector. | |
Protected Attributes | |
| NSMutableArray * | listeners |
| Listeners that will receive manualSuspend and interrupt events. | |
| NSMutableArray * | manualSuspendStates |
| Holder for the state of manualSuspend in listeners when this object is manually suspended. | |
| __unsafe_unretained id | suspendStatusChangeTarget |
| Slave object that is notified when this object suspends or unsuspends. | |
| SEL | suspendStatusChangeSelector |
| Selector to be invoked on suspend or unsuspend. | |
| bool | manualSuspendLock |
| Holds the current "manually suspended" state. | |
| bool | interruptLock |
| Holds the current "interrupted" state. | |
Properties | |
| bool | manuallySuspended |
| If YES, the manual suspend control is set. | |
| bool | interrupted |
| If YES, the interrupt control is set. | |
| bool | suspended |
| If YES, the slave object is suspended. |
Provides two controls (interrupted and manuallySuspended) for suspending a slave object, and also propagates such control messages to interested listeners.
"interrupted" is meant to be set by the system when an interrupt occurs.
"manuallySuspended" is a user-settable control for suspending an object.
"manuallySuspended" also has an extra step in its processing: When set, the handler makes a note of what its listeners' "manuallySuspended" values are. When cleared, it will only clear a listener's "manuallySuspended" value if it was not set at suspend time. This allows for ad-hoc setting/clearing of "manuallySuspended" in the middle of a handler/listener graph rather than only from the top level.
When either control is set, the slave object will be suspended. When both are cleared, the slave object will be unsuspended.
| - (void) addSuspendListener: | (id<OALSuspendListener>) | listener |
Add a listener that will receive manual suspend and interrupt events.
| listener | The listener to register with this handler. |
| + (OALSuspendHandler *) handlerWithTarget: | (id) | target | |
| selector: | (SEL) | selector | |
Create a new handler with the specified slave target and selector.
The selector provided must take a single boolean value like so:
| target | The slave object that will receive suspend/unsuspend events. |
| selector | The selector for a "set suspended" method, taking a single boolean parameter. |
| - (id) initWithTarget: | (id) | target | |
| selector: | (SEL) | selector | |
Initialize a handler with the specified slave target and selector.
The selector provided must take a single boolean value like so:
| target | The slave object that will receive suspend/unsuspend events. |
| selector | The selector for a "set suspended" method, taking a single boolean parameter. |
| - (void) removeSuspendListener: | (id<OALSuspendListener>) | listener |
Remove a registered listener.
| listener | The listener to unregister from this handler. |
- (bool) interruptLock [protected] |
Holds the current "interrupted" state.
- (NSMutableArray*) listeners [protected] |
Listeners that will receive manualSuspend and interrupt events.
- (bool) manualSuspendLock [protected] |
Holds the current "manually suspended" state.
- (NSMutableArray*) manualSuspendStates [protected] |
Holder for the state of manualSuspend in listeners when this object is manually suspended.
- (SEL) suspendStatusChangeSelector [protected] |
Selector to be invoked on suspend or unsuspend.
Takes the signature: setSelected:(bool) value
- (__unsafe_unretained id) suspendStatusChangeTarget [protected] |
Slave object that is notified when this object suspends or unsuspends.
- (bool) interrupted [read, write, assign] |
If YES, the interrupt control is set.
- (bool) manuallySuspended [read, write, assign] |
If YES, the manual suspend control is set.
- (bool) suspended [read, assign] |
If YES, the slave object is suspended.


Arturo Goicochea
UX
Work
Blog
About
Post title here
My personal story of how I became a designer and who pushed me forward to do it.


what is this
On July 5, 2017, Vox Media's sports-focused site SBNation published an article by Jon Bois entitled "What football will look like in the future – 17776."
The meta description for the article reads, "It's clear that the sport of football needs to change. And the $64,000 question, my friends, is simple: 'how?' Something is terribly wrong. The writing's on the wall: youth participation in the sport is down, thanks in large part to their parents' concern for their health. In recent years, the NFL ... "
The article with the slug "17776-football," however, does not contain an update on the impact of CTE research on the popularity of the gridiron game. Upon clicking the article and attempting to read the first paragraph, the words "Something is terribly wrong" repeat, expand in size, and eventually completely obscure the screen.
This is the portal to a hypertext fiction that racked up over four million page views as an increasingly devoted group of football fans and nerds alike checked for updates to the story over the next ten days.
An internet culture writer by the name of Dr. #Content has written a comparative analysis of 17776 with Jon Bois' earlier works for SBNation, many of which blur the boundaries of sports writing, fiction, and internet art.
Dr. #Content astutely draws out how across works like The Tim Tebow CFL Chronicles and Breaking Madden, Bois consistently delights in the futility of human progress. E.g., in 17776, humanity has achieved immortality, reached its technological apex, and has nothing to do but play increasingly bizarre iterations of the game formerly known as American football.
Across his work, Bois also plays with and questions the complexity of our ultimately inconsequential societal structures surrounding both work and play, and the asymptotic definitions of progress, society, work, and entertainment.
The first embedded video in 17776, "what year is it," establishes the world of the fiction by scrolling through all of the US Presidents until 2057, incrementing the year of NFL Commissioner Roger Goodall welcoming you to the opening of the NFL Draft through 3600, and panning through Google Earth and satellite images, as well as headlines dated from the early 20th century about the "future of football," before revealing the iconic image of the Statue of Liberty submerged in the sea up to her waist, over whose receding figure the space probes Pioneer 9, Pioneer 10, and JUICE (the Jupiter Icy Moons Explorer, scheduled for launch in 2022) are introduced in the style of a 90s sitcom.
It's #goals. It's a touchdown. He sticks the landing.
An instant cult classic
17776 had all of the necessary qualities to become an instant internet cult classic.
One possible explanation is its visually stimulating, unpredictable multimedia elements, with splashes of self-referential Web 2.0 aesthetic, which redefined the genre of hypertext fiction.
Add in the characters: the humans and non-humans are immediately likeable and somehow relatable, despite being 15,000+ year old immortals and nonbinary sentient space probes.
And the central concept's surrealist take on sports, entertainment, and human existence in a time, to quote Bois, "so far away that nobody ever thinks about it," is wildly imaginative in its creation of new forms of sports entertainment, while referencing the threats of global warming and existential stagnation often enough to not be pure frivolity.
The format and tone of the story drew comparisons to Homestuck, a multimedia web comic that ran for 7 years and is infamous for the rabidity of its fandom – another quality that 17776 now shares, after being published for only ten days.
A cosplay of JUICE appeared on Twitter a mere three days into the fiction, and as 17776 was released, Tumblr exploded with theories, art, and fanfiction, as well as despair about the series’s imminent end.
17776 has its own subreddit, and its own fanfiction category on Archive Of Our Own.
10 months after the series' publication, the rate of fanart production has slowed, but there are still posts at least once a month on Tumblr, Reddit, or AO3 – including an automated JUICE-themed blog that posts the word "fart" once per day (JUICE's love of both Lunchables and rake-based slapstick, and general giving-no-fucks attitude quickly made the Jupter probe a fan favorite).
For a virtual experience with such a short run, its legacy is surprisingly strong. And as it approaches one year since its first publication, public attention to the story is expected to increase again.
For the love of the game
But it's no wonder the story became an immediate object of the internet's affection, as 17776 was explicitly made to be delighted in.
In an email to Poynter, Bois writes, "The goal as conceived was to give the reader a good time... That was literally the whole point."
He expanded on this in a Q&A published nine days after the series' end, in response to a question submitted by a fan about the choice to produce long-form fiction:
In the same Q&A, Jon Bois also cites Calvin & Hobbes as an inspiration, and there is definitely something to be said about playing Calvinball in the 17776 universe.
He also mentions The Legend of Zelda: Breath of the Wild, because "it is also about exploration for its own sake. You could get lost in that game forever without even bothering to achieve the main goal. (You might notice that nobody in 17776 ever scores a touchdown.)"
In her Medium article, "Jon Bois Set My Brain On Fire," Emma Phipps explains why the internet hungers for this kind of content and goes crazy for it when we get it. It's created without an ulterior motive. It isn't engineered for clicks and conversions. It's engineered for quirks, and for quality entertainment.
It's impossible to say whether speculation on the state of the world in 15,000 years will be accurate, and the plot points that humans mysteriously become ageless and that space probes gain sentience over this span of time are clearly not meant to be predictive.
It's not just the future of football, it's the future of fiction. It's exactly what you don't expect from SBNation, and that's why it's so fun. It's made for the love of the game.
What is the game, exactly? Maybe a better question is, what isn't?


For more information on Coil, a way of receiving streamed micropayments, see the Coil Website.
This page uses coil-monetizer.js to detect if Coil is supported by your browser, then report when streaming payment starts and stops
coil-monetizer.js is a small MIT licensed JS library by John Allsopp/Web Directions that provides this functionality.


Remove a mostly solid background until reaching a border.
Borders on the edge of your image must be cropped out.
Background color defaults to white
Contrast defaults to 1.5
See the code on GitHub
Drag Images here, paste, OR
Select images by URL
Note: Browsers may block some images from being loaded due to CORS security.


--- layout: sem title: Semester 4 sub1: Operating System sub2: Finite Automata and Formal Language sub3: Analysis and Design of Algorithms sub4: Graph Theory and Combinatorics sub5: Microprocessor sub6: Microprocessor Lab sub7: Analysis and Design of Algorithms Lab ---