| 1 | /* =========================================================== | |
| 2 | * JFreeChart : a free chart library for the Java(tm) platform | |
| 3 | * =========================================================== | |
| 4 | * | |
| 5 | * (C) Copyright 2000-2013, by Object Refinery Limited and Contributors. | |
| 6 | * | |
| 7 | * Project Info: http://www.jfree.org/jfreechart/index.html | |
| 8 | * | |
| 9 | * This library is free software; you can redistribute it and/or modify it | |
| 10 | * under the terms of the GNU Lesser General Public License as published by | |
| 11 | * the Free Software Foundation; either version 2.1 of the License, or | |
| 12 | * (at your option) any later version. | |
| 13 | * | |
| 14 | * This library is distributed in the hope that it will be useful, but | |
| 15 | * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY | |
| 16 | * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public | |
| 17 | * License for more details. | |
| 18 | * | |
| 19 | * You should have received a copy of the GNU Lesser General Public | |
| 20 | * License along with this library; if not, write to the Free Software | |
| 21 | * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, | |
| 22 | * USA. | |
| 23 | * | |
| 24 | * [Oracle and Java are registered trademarks of Oracle and/or its affiliates. | |
| 25 | * Other names may be trademarks of their respective owners.] | |
| 26 | * | |
| 27 | * ----------------- | |
| 28 | * OHLCDataItem.java | |
| 29 | * ----------------- | |
| 30 | * (C) Copyright 2003-2013, by Object Refinery Limited. | |
| 31 | * | |
| 32 | * Original Author: David Gilbert (for Object Refinery Limited); | |
| 33 | * Contributor(s): -; | |
| 34 | * | |
| 35 | * Changes | |
| 36 | * ------- | |
| 37 | * 03-Dec-2003 : Version 1 (DG); | |
| 38 | * 29-Apr-2005 : Added equals() method (DG); | |
| 39 | * 02-Jul-2013 : Use ParamChecks (DG); | |
| 40 | * | |
| 41 | */ | |
| 42 | ||
| 43 | package org.jfree.data.xy; | |
| 44 | ||
| 45 | import java.io.Serializable; | |
| 46 | import java.util.Date; | |
| 47 | import org.jfree.chart.util.Args; | |
| 48 | ||
| 49 | /** | |
| 50 | * Represents a single (open-high-low-close) data item in | |
| 51 | * an {@link DefaultOHLCDataset}. This data item is commonly used | |
| 52 | * to summarise the trading activity of a financial commodity for | |
| 53 | * a fixed period (most often one day). | |
| 54 | */ | |
| 55 | public class OHLCDataItem implements Comparable, Serializable { | |
| 56 | ||
| 57 | /** For serialization. */ | |
| 58 | private static final long serialVersionUID =<PHONE_NUMBER>401169901L; | |
| 59 | ||
| 60 | /** The date. */ | |
| 61 | private Date date; | |
| 62 | ||
| 63 | /** The open value. */ | |
| 64 | private Number open; | |
| 65 | ||
| 66 | /** The high value. */ | |
| 67 | private Number high; | |
| 68 | ||
| 69 | /** The low value. */ | |
| 70 | private Number low; | |
| 71 | ||
| 72 | /** The close value. */ | |
| 73 | private Number close; | |
| 74 | ||
| 75 | /** The trading volume (number of shares, contracts or whatever). */ | |
| 76 | private Number volume; | |
| 77 | ||
| 78 | /** | |
| 79 | * Creates a new item. | |
| 80 | * | |
| 81 | * @param date the date ({@code null} not permitted). | |
| 82 | * @param open the open value. | |
| 83 | * @param high the high value. | |
| 84 | * @param low the low value. | |
| 85 | * @param close the close value. | |
| 86 | * @param volume the volume. | |
| 87 | */ | |
| 88 | public OHLCDataItem(Date date, double open, double high, double low, | |
| 89 | double close, double volume) { | |
| 90 |
1
1. |
Args.nullNotPermitted(date, "date"); |
| 91 |
1
1. |
this.date = date; |
| 92 |
2
1. 2. |
this.open = new Double(open); |
| 93 |
2
1. 2. |
this.high = new Double(high); |
| 94 |
2
1. 2. |
this.low = new Double(low); |
| 95 |
2
1. 2. |
this.close = new Double(close); |
| 96 |
2
1. 2. |
this.volume = new Double(volume); |
| 97 | } | |
| 98 | ||
| 99 | /** | |
| 100 | * Returns the date that the data item relates to. | |
| 101 | * | |
| 102 | * @return The date (never {@code null}). | |
| 103 | */ | |
| 104 | public Date getDate() { | |
| 105 |
2
1. getDate : replaced return value with null for org/jfree/data/xy/OHLCDataItem::getDate → NO_COVERAGE 2. getDate : mutated return of Object value for org/jfree/data/xy/OHLCDataItem::getDate to ( if (x != null) null else throw new RuntimeException ) → NO_COVERAGE |
return this.date; |
| 106 | } | |
| 107 | ||
| 108 | /** | |
| 109 | * Returns the open value. | |
| 110 | * | |
| 111 | * @return The open value (never {@code null}). | |
| 112 | */ | |
| 113 | public Number getOpen() { | |
| 114 |
2
1. getOpen : replaced return value with null for org/jfree/data/xy/OHLCDataItem::getOpen → NO_COVERAGE 2. getOpen : mutated return of Object value for org/jfree/data/xy/OHLCDataItem::getOpen to ( if (x != null) null else throw new RuntimeException ) → NO_COVERAGE |
return this.open; |
| 115 | } | |
| 116 | ||
| 117 | /** | |
| 118 | * Returns the high value. | |
| 119 | * | |
| 120 | * @return The high value (never {@code null}). | |
| 121 | */ | |
| 122 | public Number getHigh() { | |
| 123 |
2
1. getHigh : replaced return value with null for org/jfree/data/xy/OHLCDataItem::getHigh → NO_COVERAGE 2. getHigh : mutated return of Object value for org/jfree/data/xy/OHLCDataItem::getHigh to ( if (x != null) null else throw new RuntimeException ) → NO_COVERAGE |
return this.high; |
| 124 | } | |
| 125 | ||
| 126 | /** | |
| 127 | * Returns the low value. | |
| 128 | * | |
| 129 | * @return The low value (never {@code null}). | |
| 130 | */ | |
| 131 | public Number getLow() { | |
| 132 |
2
1. getLow : replaced return value with null for org/jfree/data/xy/OHLCDataItem::getLow → NO_COVERAGE 2. getLow : mutated return of Object value for org/jfree/data/xy/OHLCDataItem::getLow to ( if (x != null) null else throw new RuntimeException ) → NO_COVERAGE |
return this.low; |
| 133 | } | |
| 134 | ||
| 135 | /** | |
| 136 | * Returns the close value. | |
| 137 | * | |
| 138 | * @return The close value (never {@code null}). | |
| 139 | */ | |
| 140 | public Number getClose() { | |
| 141 |
2
1. getClose : replaced return value with null for org/jfree/data/xy/OHLCDataItem::getClose → NO_COVERAGE 2. getClose : mutated return of Object value for org/jfree/data/xy/OHLCDataItem::getClose to ( if (x != null) null else throw new RuntimeException ) → NO_COVERAGE |
return this.close; |
| 142 | } | |
| 143 | ||
| 144 | /** | |
| 145 | * Returns the volume. | |
| 146 | * | |
| 147 | * @return The volume (never {@code null}). | |
| 148 | */ | |
| 149 | public Number getVolume() { | |
| 150 |
2
1. getVolume : replaced return value with null for org/jfree/data/xy/OHLCDataItem::getVolume → NO_COVERAGE 2. getVolume : mutated return of Object value for org/jfree/data/xy/OHLCDataItem::getVolume to ( if (x != null) null else throw new RuntimeException ) → NO_COVERAGE |
return this.volume; |
| 151 | } | |
| 152 | ||
| 153 | /** | |
| 154 | * Checks this instance for equality with an arbitrary object. | |
| 155 | * | |
| 156 | * @param obj the object ({@code null} permitted). | |
| 157 | * | |
| 158 | * @return A boolean. | |
| 159 | */ | |
| 160 | @Override | |
| 161 | public boolean equals(Object obj) { | |
| 162 |
2
1. equals : negated conditional → SURVIVED 2. equals : removed conditional - replaced equality check with true → SURVIVED |
if (obj == this) { |
| 163 |
3
1. equals : replaced boolean return with false for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 1 with 0 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return true; |
| 164 | } | |
| 165 |
3
1. equals : removed conditional - replaced equality check with false → SURVIVED 2. equals : negated conditional → KILLED 3. equals : removed conditional - replaced equality check with true → KILLED |
if (!(obj instanceof OHLCDataItem)) { |
| 166 |
3
1. equals : replaced boolean return with true for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 0 with 1 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return false; |
| 167 | } | |
| 168 | OHLCDataItem that = (OHLCDataItem) obj; | |
| 169 |
4
1. equals : removed conditional - replaced equality check with false → SURVIVED 2. equals : negated conditional → KILLED 3. equals : removed call to java/util/Date::equals → KILLED 4. equals : removed conditional - replaced equality check with true → KILLED |
if (!this.date.equals(that.date)) { |
| 170 |
3
1. equals : replaced boolean return with true for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 0 with 1 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return false; |
| 171 | } | |
| 172 |
4
1. equals : removed conditional - replaced equality check with false → SURVIVED 2. equals : negated conditional → KILLED 3. equals : removed call to java/lang/Object::equals → KILLED 4. equals : removed conditional - replaced equality check with true → KILLED |
if (!this.high.equals(that.high)) { |
| 173 |
3
1. equals : replaced boolean return with true for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 0 with 1 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return false; |
| 174 | } | |
| 175 |
4
1. equals : removed conditional - replaced equality check with false → SURVIVED 2. equals : negated conditional → KILLED 3. equals : removed call to java/lang/Object::equals → KILLED 4. equals : removed conditional - replaced equality check with true → KILLED |
if (!this.low.equals(that.low)) { |
| 176 |
3
1. equals : replaced boolean return with true for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 0 with 1 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return false; |
| 177 | } | |
| 178 |
4
1. equals : removed conditional - replaced equality check with false → SURVIVED 2. equals : negated conditional → KILLED 3. equals : removed call to java/lang/Object::equals → KILLED 4. equals : removed conditional - replaced equality check with true → KILLED |
if (!this.open.equals(that.open)) { |
| 179 |
3
1. equals : replaced boolean return with true for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 0 with 1 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return false; |
| 180 | } | |
| 181 |
4
1. equals : removed conditional - replaced equality check with false → SURVIVED 2. equals : negated conditional → KILLED 3. equals : removed call to java/lang/Object::equals → KILLED 4. equals : removed conditional - replaced equality check with true → KILLED |
if (!this.close.equals(that.close)) { |
| 182 |
3
1. equals : replaced boolean return with true for org/jfree/data/xy/OHLCDataItem::equals → NO_COVERAGE 2. equals : Substituted 0 with 1 → NO_COVERAGE 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return false; |
| 183 | } | |
| 184 |
3
1. equals : replaced boolean return with false for org/jfree/data/xy/OHLCDataItem::equals → KILLED 2. equals : Substituted 1 with 0 → KILLED 3. equals : replaced return of integer sized value with (x == 0 ? 1 : 0) → KILLED |
return true; |
| 185 | } | |
| 186 | ||
| 187 | /** | |
| 188 | * Compares this object with the specified object for order. Returns a | |
| 189 | * negative integer, zero, or a positive integer as this object is less | |
| 190 | * than, equal to, or greater than the specified object. | |
| 191 | * | |
| 192 | * @param object the object to compare to. | |
| 193 | * | |
| 194 | * @return A negative integer, zero, or a positive integer as this object | |
| 195 | * is less than, equal to, or greater than the specified object. | |
| 196 | */ | |
| 197 | @Override | |
| 198 | public int compareTo(Object object) { | |
| 199 |
3
1. compareTo : negated conditional → NO_COVERAGE 2. compareTo : removed conditional - replaced equality check with false → NO_COVERAGE 3. compareTo : removed conditional - replaced equality check with true → NO_COVERAGE |
if (object instanceof OHLCDataItem) { |
| 200 | OHLCDataItem item = (OHLCDataItem) object; | |
| 201 |
3
1. compareTo : removed call to java/util/Date::compareTo → NO_COVERAGE 2. compareTo : replaced int return with 0 for org/jfree/data/xy/OHLCDataItem::compareTo → NO_COVERAGE 3. compareTo : replaced return of integer sized value with (x == 0 ? 1 : 0) → NO_COVERAGE |
return this.date.compareTo(item.date); |
| 202 | } | |
| 203 | else { | |
| 204 |
1
1. compareTo : removed call to java/lang/ClassCastException::<init> → NO_COVERAGE |
throw new ClassCastException("OHLCDataItem.compareTo()."); |
| 205 | } | |
| 206 | } | |
| 207 | ||
| 208 | } | |
Mutations | ||
| 90 |
1.1 |
|
| 91 |
1.1 |
|
| 92 |
1.1 2.2 |
|
| 93 |
1.1 2.2 |
|
| 94 |
1.1 2.2 |
|
| 95 |
1.1 2.2 |
|
| 96 |
1.1 2.2 |
|
| 105 |
1.1 2.2 |
|
| 114 |
1.1 2.2 |
|
| 123 |
1.1 2.2 |
|
| 132 |
1.1 2.2 |
|
| 141 |
1.1 2.2 |
|
| 150 |
1.1 2.2 |
|
| 162 |
1.1 2.2 |
|
| 163 |
1.1 2.2 3.3 |
|
| 165 |
1.1 2.2 3.3 |
|
| 166 |
1.1 2.2 3.3 |
|
| 169 |
1.1 2.2 3.3 4.4 |
|
| 170 |
1.1 2.2 3.3 |
|
| 172 |
1.1 2.2 3.3 4.4 |
|
| 173 |
1.1 2.2 3.3 |
|
| 175 |
1.1 2.2 3.3 4.4 |
|
| 176 |
1.1 2.2 3.3 |
|
| 178 |
1.1 2.2 3.3 4.4 |
|
| 179 |
1.1 2.2 3.3 |
|
| 181 |
1.1 2.2 3.3 4.4 |
|
| 182 |
1.1 2.2 3.3 |
|
| 184 |
1.1 2.2 3.3 |
|
| 199 |
1.1 2.2 3.3 |
|
| 201 |
1.1 2.2 3.3 |
|
| 204 |
1.1 |


@desc()
The Typesafe Reactive Platform enables continuous delivery while also reducing risk.
- Type-safety minimizes the chances of something going wrong in production.
- Through a containerless deployment model, redeployments are quick and easy.
- Play Framework is RESTful by default and has built-in JSON support making it a great choice for micro-services which help teams delivery faster.


Powered by jQuery.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero.
Purchase nowBased on Twitter Bootstrap.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero.
Purchase nowModern beautiful design.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero.
Purchase nowAwesome. Tweaked it a bit and got myself an ideal landing page.
John Doe, somesite.com
Awesome. It's just great!
John Smith, site.com
This is so nice. Really a joy to work with. Love my new site!
Ana, mysite.net


Using resource-based policies for AWS Lambda
AWS Lambda supports resource-based permissions policies for Lambda functions and layers. Resource-based policies let you grant usage permission to other AWS accounts on a per-resource basis. You also use a resource-based policy to allow an AWS service to invoke your function on your behalf.
For Lambda functions, you can grant an account permission to invoke or manage a function. You can add multiple statements to grant access to several accounts, or let any account invoke your function. You can also use the policy to grant invoke permission to an AWS service that invokes a function in response to activity in your account.
To view a function's resource-based policy
-
Open the Functions page
on the Lambda console. -
Choose a function.
-
Choose Permissions.
-
The resource-based policy shows the permissions that are applied when another account or AWS service attempts to access the function. The following example shows a statement that allows Amazon S3 to invoke a function named
my-function
for a bucket namedmy-bucket
in account123456789012
.Example Resource-based policy
{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "lambda-allow-s3-my-function", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function” "Condition": { "StringEquals": { "AWS:SourceAccount": "123456789012" }, "ArnLike": { "AWS:SourceArn": "arn:aws:s3:::my-bucket" } } } ] }
For Lambda layers, you can only use a resource-based policy on a specific layer version, instead of the entire layer. In addition to policies that grant permission to a single account or multiple accounts, for layers, you can also grant permission to all accounts in an organization.
You can only update resource-based policies for Lambda resources within the scope of the AddPermission and AddLayerVersionPermission API actions. Currently, you can't author policies for your Lambda resources in JSON, or use conditions that don't map to parameters for those actions.
Resource-based policies apply to a single function, version, alias, or layer version. They grant permission to one or more services and accounts. For trusted accounts that you want to have access to multiple resources, or to use API actions that resource-based policies don't support, you can use cross-account roles.
Topics
Granting function access to AWS services
When you use an AWS service to invoke your function, you grant permission in a statement on a resource-based policy. You can apply the statement to the entire function to be invoked or managed, or limit the statement to a single version or alias.
When you add a trigger to your function with the Lambda console, the console updates the function's resource-based policy to allow the service to invoke it. To grant permissions to other accounts or services that aren't available in the Lambda console, you can use the AWS CLI.
Add a statement with the add-permission
command. The simplest resource-based policy statement
allows a service to invoke a function. The following command grants Amazon SNS permission
to invoke a function named
my-function
.
aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id sns \ --principal sns.amazonaws.com --output text
You should see the following output:
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
This lets Amazon SNS call the lambda:Invoke
API for the function, but it doesn't restrict the Amazon SNS topic that
triggers the invocation. To ensure that your function is only invoked by a specific
resource, specify the Amazon
Resource Name (ARN) of the resource with the source-arn
option. The following command only allows
Amazon SNS to invoke the function for subscriptions to a topic named my-topic
.
aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id sns-my-topic \ --principal sns.amazonaws.com --source-arn arn:aws:sns:
us-east-2:123456789012:my-topic
Some services can invoke functions in other accounts. If you specify a source ARN
that has your account ID in
it, that isn't an issue. For Amazon S3, however, the source is a bucket whose ARN
doesn't have an account ID in it.
It's possible that you could delete the bucket and another account could create a
bucket with the same name. Use
the source-account
option with your account ID to ensure that only resources in your account can
invoke the function.
aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id s3-account \ --principal s3.amazonaws.com --source-arn arn:aws:s3:::
my-bucket-123456
--source-account123456789012
Granting function access to other accounts
To grant permissions to another AWS account, specify the account ID as the principal
. The
following example grants account<PHONE_NUMBER>21
permission to invoke my-function
with the
prod
alias.
aws lambda add-permission --function-name my-function:
prod
--statement-id xaccount --action lambda:InvokeFunction \ --principal210987654321
--output text
You should see the following output:
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::210987654321:root"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
The resource-based policy grants permission for the other account to access the function, but doesn't allow users in that account to exceed their permissions. Users in the other account must have the corresponding user permissions to use the Lambda API.
To limit access to a user or role in another account, specify the full ARN of the
identity as the principal.
For example, arn:aws:iam::123456789012:user/developer
.
The alias limits which version the other account can invoke. It requires the other account to include the alias in the function ARN.
aws lambda invoke --function-name arn:aws:lambda:us-west-2:123456789012:function:my-function:prod out
You should see the following output:
{ "StatusCode": 200, "ExecutedVersion": "1" }
The function owner can then update the alias to point to a new version without the caller needing to change the way they invoke your function. This ensures that the other account doesn't need to change its code to use the new version, and it only has permission to invoke the version of the function associated with the alias.
You can grant cross-account access for most API actions that operate on an existing function. For example, you could grant access to lambda:ListAliases
to let an account get a list of aliases, or lambda:GetFunction
to let them download your function
code. Add each permission separately, or use lambda:*
to grant access to all actions for the
specified function.
Cross-account APIs
Currently, Lambda doesn’t currently support cross-account actions for all of its APIs via resource-based policies. The following APIs are supported:
To grant other accounts permission for multiple functions, or for actions that don't operate on a function, we recommend that you use IAM roles.
Granting layer access to other accounts
To grant layer-usage permission to another account, add a statement to the layer version's
permissions policy
with the add-layer-version-permission
command. In each statement, you can grant permission to a
single account, all accounts, or an organization.
aws lambda add-layer-version-permission --layer-name xray-sdk-nodejs --statement-id xaccount \ --action lambda:GetLayerVersion --principal<PHONE_NUMBER>21 --version-number 1 --output text
You should see the following output:
e210ffdc-e901-43b0-824b-5fcd0dd26d16 {"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::210987654321:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:xray-sdk-nodejs:1"}
Permissions apply only to a single version of a layer. Repeat the process each time that you create a new layer version.
To grant permission to all accounts in an organization, use the organization-id
option. The
following example grants all accounts in an organization permission to use version
3 of a layer.
aws lambda add-layer-version-permission --layer-name my-layer \ --statement-id engineering-org --version-number 3 --principal '*' \ --action lambda:GetLayerVersion --organization-id o-t194hfs8cz --output text
You should see the following output:
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
To grant permission to all AWS accounts, use *
for the principal, and omit the organization ID.
For multiple accounts or organizations, you need to add multiple statements.
Cleaning up resource-based policies
To view a function's resource-based policy, use the get-policy
command.
aws lambda get-policy --function-name my-function --output text
You should see the following output:
{"Version":"2012-10-17","Id":"default","Statement":[{"Sid":"sns","Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function","Condition":{"ArnLike":{"AWS:SourceArn":"arn:aws:sns:us-east-2:123456789012:lambda*"}}}]} 7c681fc9-b791-4e91-acdf-eb847fdaa0f0
For versions and aliases, append the version number or alias to the function name.
aws lambda get-policy --function-name my-function:PROD
To remove permissions from your function, use remove-permission
.
aws lambda remove-permission --function-name example --statement-id sns
Use the get-layer-version-policy
command to view the permissions on a layer.
aws lambda get-layer-version-policy --layer-name my-layer --version-number 3 --output text
You should see the following output:
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-west-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
Use remove-layer-version-permission
to remove statements from the policy.
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org


I build things
for the better.
About
Full stack embedded system design, from high speed multi-layer PCB design, low level test, FreeRTOS and Linux driver, all the way to user application and user interface.
I am always passionate about technology, and curious about the things behind these technologies. This is why I choose to be an EECS student, to have the knowledge from ground up, trying to answer all the questions I may have.
As a undergrad student of Penn State University, I am currently seeking summer internship. My previous work experience has proved my ability to solve real life problem using the skills and knowledge I gained from buidling independent projects in the last 9 years.
Education
Double major in Computer Science and Electrical Engineering
- Overall GPA 3.75/4.0
- Major GPA 4.0/4.0
- Dean's List
- MC-REU scholarship
Experience
- Designed a mainboard for a embedded system with i.MX ARM processors
- Ported Linux CSI platform driver to target custom board
- Debugged a newly designed development platform
- Wrote documents for the application API
- Wrote a series of digital logic and FPGA tutorial
- Wrote DIY guide for several open source hardware projects
- Wrote a series of STM32 MCU software design tutorial
- Reviewed several open source single board computers
Projects
A simple watch with OLED display. Battery last for several days.
- AT89C51 microcontroller
- Written in C
- 128x64 Graphical OLED display
My first project using STM32 microcontroller.
- STM32 ARM Cortex-M System Controller
- Written in C
- Bitbang direct drive 320x240 Graphical LCD
- Serial communication with PC side software written in Delphi
My first project. Using accelerometer to control cursor movement.
- Written in Delphi
- Compatible with ThinkPad from T41 to T400


There is perhaps nothing more satisfying than seeing the pieces of a puzzle come together. This is the case for actual puzzles, which I am…
A deeper inspection into compilation vs. interpretation
There is perhaps nothing more satisfying than seeing the pieces of a puzzle come together. This is the case for actual puzzles, which I am pretty bad at because I always seem to lose pieces under the couch, and more metaphorical puzzles, which I am generally better at what with no pieces to lose in strange places.
The puzzle of learning is certainly one of the more complicated enigmas out there. Learning a new thing is hard because you’re trying to constantly piece together ideas and construct concepts without always necessarily knowing how those parts fit into the larger whole. It can be difficult to try to wrap your head around something new when you constantly find yourself wondering what this new thing has to do with the broader picture that you’re already familiar with. It’s a little bit like finding a random puzzle piece and then trying to find the pieces that fit around it, but not necessarily knowing how those pieces fit into the big picture.
The same is true for learning a specific topic, like computer science. Oftentimes, it can feel like you’re picking up little bit of information — a data structure here, an algorithm there — without always knowing how one piece connects to another. I tend to think that this is the reason that learning computer science is so hard: there just aren’t very many resources that can construct the picture of the field with all of these perfectly pieces fit into one another.
However, every so often, if you really stick with a topic for long enough, you’ll find that some pieces will start to come together. And as we round out this series together, it’s time for that to finally happen!
When we first started this series nearly a year ago, the very first topic that we explored was something that is often thought of as the “cornerstone” of computer science: binary. We learned that, at their very core, binary is the language that every computer speaks and understands. Our machines, at the end of the day, each run on ones and zeros.
Since then, we’ve explored different data structures, like trees, graphs, and linked lists, as well as sorting algorithms and traversal or searching algorithms.
We started with some source code and now we’re here.
We’ve gone around the world when it comes to core concepts in computing as well as computer science. But there’s one question that we haven’t really answered yet, even though it’s possible that we’ve been thinking about it this whole year: How on earth do we go from our code into the one’s and zero’s of our computer?
Well, before we get too far into how the code we write gets turned into binary, let’s clarify what we really mean when we use the term binary in this context. The “binary” code that a computer reads and understands is generally referred to as machine language or machine code, which is a set of instructions given to a machine and run by a its central processing unit (or CPU).
An important thing to note is that there are different kinds of machine code, some of which are literally 0’s and 1’s, and others of which are decimals or hexadecimals (which we already know a lot about!). Regardless of which exact format a machine language is written in, it has to be fairly rudimentary because it needs to be understood by or computer. This is why machine languages are referred to as low level languages, because they need to be simplified enough to be processed by our machine’s CPU, which we already know is just a bunch of switches, internally.
We can think of low level languages as the “mother-tongues” of our computer; machine code should be directly readable by our machine, and shouldn’t ever need to be translated by them.
But how do we go from our code to a machine-friendly (machine code) version of the exact same thing? Well, the code that we write as programmers and the machine code that a computer’s processor reads are nothing more than two different types of languages. If we think about it, all we really need to do is translate between these two languages.
Now comes another problem: we have no idea how to translate between our code and machine code! Okay, just kidding — this isn’t really a problem. Because we have two helpful friends who can help us out here.
Translators make our source text understandable to our machines!
In order for us to transform our source code into some computer-readable machine code in a binary format, we’ll need to rely on translators to help us make our source text understandable to our machines.
A translator, which is also sometimes called a programming language processor, is nothing more than a program that translates a source language into a target language, while maintaining the logical structure of the code that it is translating.
We’re already a little bit familiar with one kind of translator already, even though we might not know it just yet. Previously in this series, we’ve looked at the lexical and syntax analysis phases (the front end) of the compiler, and the different data structures involved in the process.
As it turns out, the compiler is a kind of translator! There is another translator, too, whose name often gets thrown around in conjunction with the compiler’s, called the interpreter. Both the compiler and the interpreter make or code readable to our computers, but in very different ways.
But let’s first start with what we already know, first: the compiler.
The compiler: a definition.
The compiler is nothing more than a program that takes a high level language — the language that we write our code in — and converts it into machine code. The compiler has many moving parts to it (or rather, within it), including, potentially, a scanner, a lexer/tokenizer, and a parser. But at the end of the day, even with its complexity, it’s just a program that turns our code into machine-readable code.
However, even though its job might seem simple when we put it like this, the way that a compiler does this important task is worth highlighting.
How the compiler does its job.
For most cases, the compiler does the job of translating our code into
machine code in one fell swoop. In other words, the compiler translates
all of a programmer’s source code before the source code can ever be
executed or run. It takes our source code and converts it into a single
file that is written in machine code. It is that very machine code file —
called an executable file and often ending with
an .exe
extension — which actually allows us to run the
original code that we wrote.
The most important idiosyncrasy of a compiler is the fact that it takes a source text, and translates it into machine code binary in “one shot”. It returns the translated, compiled file to the programmer, who will be able to run their code via the outputted executable.
The executable file returned by the compiler can be run again and again once it has been translated; the compiler doesn’t need to be around for any subsequent reruns!
Once the compiler translates all the source code into machine code, the compiler’s job is done. The programmer can run the compiled code as many times as they want, with whichever inputs that they’d like to use. They can also share this compiled code with others, without ever having to share their original source code.
Grace Hopper, © TechCrunch
The concept behind this specific translator— as well as the term “compiler” itself — was coined by the illustrious Grace Hopper, back in 1952, in the most interesting of circumstances.
At the time, Hopper had been working at the Eckert-Mauchly Computer Corporation, helping develop the UNIVAC I computer as a mathematician on the team. Effectively, she was working on turning mathematical code into its own language (A-0 System language).
However, she had bigger ideas. She wanted to write an entirely new programming language that would words in English, rather than the limited number of mathematical symbols. However, when she shared this idea with her colleages. They shot her down, and told her that her idea wasn’t possible because “computers didn’t understand English”. But she was not deterred.
After three years of working on this team, Hopper had her very first working compiler. But no one believed that she had actually done it! In her biography, Grace Hopper : Navy Admiral and Computer Pioneer, she explains:
I had a running compiler and nobody would touch it. … they carefully told me, computers could only do arithmetic; they could not do programs.
It’s a good thing that Grace Hopper didn’t listen to any of those nonbelievers, because she ended up continuing her work and developing one of the earliest high level programming languages, called COBOL. She also won the Presidential Medal of Freedom, among many, many, many other accomplishments.
Indeed, if she had listened to all of those pepole, she would have likely never taken computing to an entirely new level with her early work in constructing and designing the very first compiler. Grace Hopper’s work on the first compiler laid the groundwork for the another translator that came into existence a few years later: the interpreter.
In 1958, a few years after Grace Hopper’s work on the compiler, some students at MIT were in a lab, working with an IBM 704 computer, a fairly new technology that had been introduced just four years earlier. One of these students, named Steve Russell, was working on a project called the MIT Artificial Intelligence Project, with his professor, John McCarthy.
Russell was working with the Lisp programming language at the time, and he
had read a paper written by his professor on the subject. He came up with
the idea to transform the eval
function in Lisp into machine
code, which set him on the path to creating the first Lisp interpreter,
which was used to evaluate expressions in the language — the equivalent of
running a program in Lisp at the time.
Steve Russell, © mass:werk
Indeed, Hopper’s work directly impacted Russell’s invention. The first version of the Lisp interpreter was compiled by hand. In an interview with the Computer History Museum in 2008, Russell explains how compilers played into his work at MIT:
And my remembrance is that John [McCarthy] sort of came in one day, in late September or October or something like, that with the universal M-expression, that is the Lisp interpreter written out as an M-expression, and we sort of looked at it and said, “Oh yeah, that’ll work,” and I looked at it and said, “Oh, that’s just a matter of doing more hand compiling, like I’ve been doing. I can do that.”
…I got something working before Christmas, which was a useable interpreter; no garbage collector, but there weren’t any big programs yet.
Russell and his colleagues would go on to hand-compile the first two version of the Lisp interpreter. Today, most programmers wouldn’t even dream of hand-compiling any of their code! Indeed, many of us interact with an interpreter and use it multiple times in application development — we just might not always be aware of it.
So, what exactly is an interpreter? It’s about time for an official definition!
The interpreter: a definition.
An interpreter is also a translator, just like a compiler, in that it takes a high level language (our source text) and converts it into machine code. However, it does something slightly different: it actually runs and executes the code that it translates immediately (inline) as it translates.
We can think of an interpreter as the more “methodical” translator in the family. Rather than doing the work of translating our code into machine language in one single shot, it’s far more systematic about how it works.
An interpreter does its job piece by piece. It will translate a section of our source text at a time, rather than translating it all at once.
How the interpreter does its job.
Unlike a compiler, it doesn’t translate everything and hand over a file to us, the programmers, to execute. Instead, an interpreter will translate a single line/section of code at a time. Once it has finished translating one line, it will take the machine code version of it, and run it immediately.
Another way of thinking about it is that once a piece of code has been translated by the interpreter, only then can it be run. This seems fairly intuitive at first thought, because of course how can an interpreter run a line of code without knowing what it means in binary/machine code? But, if we think about it more deeply, there are other implications. Only once the interpreter finishes running one line of code successfully will it actually move onto the next line. We can imagine how this may or may not be a good thing, depending on what we’re trying to do.
For example, imagine we want to run our program with 10 different inputs. Our interpreter would have to run our program 10 times, interpreting it line by line, for each of our inputs. However, if we made a fatal flaw in our code, our interpreter could catch it for us the moment that it happens because it has literally just tried to run our (broken) line of code after it translated it!
By now, we might start to be able to see how both the interpreter and the compiler have tradeoffs. We’ve seen how different tools have pros and cons to them time and again in this series, and it’s probably a hallmark trait within the world of computer science. Keeping with this theme, let’s weigh the fundamental differences between interpretation and compilation as translation techniques.
The differences between interpretation and compilation and their respective translators tells us a lot about how these two programs are implemented. If we compare these two methodologies, we’ll start to see how they both accomplish the same task, but in fundamentally very different ways.
The illustration below illustrates this in a more obvious way.
Compilation vs. interpretation: the tradeoffs.
Because of these major differences, compiled code — code that is translated and run using the compilation process — tends to run a bit faster than interpreted code. This is because the work of translating the source text into machine code has already been done, before the code is ever executed.
Compiled code as compared to interpreted code.
On the flip side, interpreted code is far more flexible, since the interpreter stays around for the course of the translation “process” to read and process our code.
Flexibility in this context means being able to change our code and being able to immediately run it afterwards. There is no need to recompile our code if we make a change; the interpreter will just pick up on that chance, and reinterpret the code, making it a much more interactive form of translation. Using an interpreter makes it much easier to test out small (or big!) changes in a source file.
The benefits of compilation as compared to interpretation.
However, when it comes to interpretation, we actually need the source code in order to be able to do anything. It definitely is easier to test out changes and debug issues, but the source text has to be accessible, first and foremost. With compilation, this isn’t the case. Once we have compiled our code into an executable file, we don’t ever have to worry about the source code again — unless, of course, we need to recompile.
This can often make a compiler the “safer” choice, because our source code is not exposed; rather, the only output is the executable file itself, which is just 1’s and 0’s, and doesn’t ever show anyone how we wrote our code or what it actually ever said, since it’s all machine language at that point.
Compilation and interpretation play into our roles not just as developers of software, but also as consumers of it.
The easy and speed of compilation, in action.
For example, whenever we download a file, or run a program from an
.exe
file, we’re relying on the creators of some software to
have compiled an executable for us.
Using compilation, we can easily distribute a program as an executable file. This will allow someone else to run the exact same code as us, but without ever actually showing them or giving them our literal code itself. A consumer of a compiled file never needs to see a source text, because they can simply be given an executable file to run on their own, local machine.
However, the issue with distributing a compiled file is creating files that are compatible on different platforms (like a Windows operating system versus OS X). As programmers, it’s our job to make sure our compiled executables run successfully on various platforms, and sometimes, this means recompiling our code!
The efficiency and benefits of interpretation, in action.
On the other hand, when we use interpretation, we can distribute our source code directly, rather than worrying about platform-specific executables, or thinking about how we’ll go about compiling binaries for everyone to use.
However, in this case, we’ll need the consumer of our program to download an interpreter — which often actually just comes along with a language — and be sure that the interpreter exists on their machine(s). Once they have the interpreter, they can see our original source code, take that code, and then rely on their own version of the interpreter to run it locally.
In this scenario, we rely on the interpreter to make the compatible on all platforms, and we, as programmers and consumers, don’t need to think about it. Also, if something goes wrong (either something in the source that we wrote, or something relating to their own platform), the consumer of our code can figure out what the issue is much more easily than with a compiled file. The interpreter will make it easy to debug any problems, regardless of who is running our code.
But, regardless of whether we choose compilation or interpretation, the end goal is the same: to speak a language that our computers can understand! As it turns out, at the end of the day, it really just all is binary.
Because both interpreters and compilers have been around for many years now, there are a good amount of resources out there on both of these types of translators. From an implementation perspective, there are many different approaches to writing a compiler versus an interpreter. But, if you’re looking to simply learn more or dig a little deeper, these resources are a good place to start.


QTabletEvent Class Reference
Inherits QInputEvent.
Constructor
- void QTabletEvent(Type t, QPointF pos, QPointF globalPos, int device, int pointerType, qreal pressure, int xTilt, int yTilt, qreal tangentialPressure, qreal rotation, int z, KeyboardModifiers keyState, qint64 uniqueID)
Constructor Properties
- prototype: The QTabletEvent prototype object
- UnknownPointer
- Pen
- Cursor
- Eraser
- PointerType( value )
- NoDevice
- Puck
- Stylus
- Airbrush
- FourDMouse
- XFreeEraser
- RotationStylus
- TabletDevice( value )
Prototype Object Properties
The QTabletEvent prototype object inherits properties from the QInputEvent prototype object and also has the following properties.
- TabletDevice device()
- QPoint globalPos()
- QPointF globalPosF()
- int globalX()
- int globalY()
- qreal hiResGlobalX()
- qreal hiResGlobalY()
- PointerType pointerType()
- QPoint pos()
- QPointF posF()
- qreal pressure()
- qreal rotation()
- qreal tangentialPressure()
- qint64 uniqueId()
- int x()
- int xTilt()
- int y()
- int yTilt()
- int z()
Instance Properties
QTabletEvent objects have no special properties beyond those inherited from the QTabletEvent prototype object.


17 references to Clear
System.Management.Automation (17)
engine\CommandCompletion\CommandCompletion.cs (6)
193
powershell.Commands.
Clear
();
268
powershell.Commands.
Clear
();
447
powershell.Commands.
Clear
();
473
powershell.Commands.
Clear
();
483
powershell.Commands.
Clear
();
510
powershell.Commands.
Clear
();
engine\CommandCompletion\CompletionCompleters.cs (1)
173
powershell.Commands.
Clear
();
engine\parser\SymbolResolver.cs (1)
522
UsingStatementResolvePowerShell.Commands.
Clear
();
engine\remoting\server\ServerPowerShellDriver.cs (1)
343
LocalPowerShell.Commands.
Clear
();
engine\remoting\server\ServerRunspacePoolDriver.cs (3)
1448
commands.
Clear
();
1539
commands.
Clear
();
2724
powershell.Commands.
Clear
();
engine\SessionStateContainer.cs (1)
4812
ps.Commands.
Clear
();
namespaces\FileSystemProvider.cs (3)
7487
ps.Commands.
Clear
();
7492
ps.Commands.
Clear
();
7513
ps.Commands.
Clear
();
utils\PowerShellExecutionHelper.cs (1)
163
CurrentPowerShell.Commands.
Clear
();


Pamodoro technique
I foud all the reading materials on this topic are very very interesting and helpful. I've heard about Pamodoro technique before and have attempted to apply this technique to my working/studying schedules. I also think that tiny habit technique makes so much sense and will work well if combined together with pamodoro.
Pamodoro technique
I would like to learn more about the counterintuitive concept particularly a couple of points; "less time to be more productive and make it painful for not to do".


Hello!
Hey! This is #SPARTIFY - a service for collective listening to music from Spotify. First, let's log in ...
{% load static %}
#comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comeback #comebackHey! This is #SPARTIFY - a service for collective listening to music from Spotify. First, let's log in ...


This example is taken from the standard set of ESP examples
This example shows how you can use SAS Event Stream Processing Streamviewer to visualize an event stream of data obtained from a set of boats. The model
identifies two geographical areas of interest. One area is an exclusion zone that the boats identified are not permitted to enter. The other is an area
where a speed restriction has been applied. For convenience, it is recommended that you upload the preprepared model XML file to SAS Event Stream Processing Studio.
For demonstration purposes, this example uses CSV files containing historical data. When a model similar to the one used in this example is deployed in a live
environment, real-time data sources might be used instead. Before attempting to follow the steps in this example to create a sailing data dashboard, ensure that
the model is working correctly in test mode. This includes ensuring that the model’s publisher connectors are correctly configured. The CSV files
listed previously must be in a location on the server on which SAS Event Stream Processing is running
This example uses six files listed below:
- The XML file (sailing_example.xml) is the project used in the example.
- geoArea.csv is an input file. This file contains events relating to the defined areas of interest.
- boat1.csv is an input file. This file contains the event stream of boat 1. The event stream contains time-stamped geographical coordinates of the boat’s movements.
- boat2.csv is an input file. This file contains the event stream of boat 2. The event stream contains time-stamped geographical coordinates of the boat’s movements.
- boat3.csv is an input file. This file contains the event stream of boat 3. The event stream contains time-stamped geographical coordinates of the boat’s movements.
- boat4.csv is an input file. This file contains the event stream of boat 4. The event stream contains time-stamped geographical coordinates of the boat’s movements.
The ESP model contains the following windows:
- Four Source windows that receive event streams from the four boats identified: The Mayflower, The Bounty, The Beagle, and The Santa Maria.
- One Source window that receives an event stream defining the areas of interest that the boats are not permitted to enter: Areas_Of_Interest.
- One Geofence window that defines the areas of interest: Geofence_Area_Check.
- One Copy window that is used to transition the model from stateless to stateful.
- Two Filter windows that identify if any of the boats have entered the exclusion zone and speed restriction zone and if any of the boats were
speeding: Filter_Inside_Exclusion_Zone and Last_Speeding_Event
- Two Aggregate windows that aggregate the last exclusion violation and the last speeding event: Last_Exclusion_Violation and Last_Speeding_Event


RoomQuake 2017
Portals
RoomQuake
2017 offers a set of four portals:
1.
A portal for teachers to configure their classrooms, configure simulated
earthquakes, and deliver those earthquakes according to user-defined schedules.
This portal also allows the teacher to designate the current activity (see below). Typically,
teachers access this portal using their personal computers.
2.
A portal for simulated seismographs.
Typically, 3-5 computers are distributed around the classroom.
3.
A portal for students
to submit their interpretations (readings) of seismograms associated with
simulated earthquakes. Typically, students access this portal using their
personal or tablet computers, or mobile phones.
4.
A portal for a big
picture, which aggregates student readings and presents their (filtered)
distributions and means in real time as students submit those readings.
Typically, an additional computer connected to a projector or large display is
used.
5.
A portal for managers
to configure the seismogram waveform (experts only!).
Access
to portals for participants (teachers and students) are provided by specialized
URLs:
Teacher portal:
https://tinyurl.com/yalznluk
Student portal:
https://tinyurl.com/ycspkvvs
Manager portal:
https://tinyurl.com/ybuugp6p
Access
to shared portals (seismograph, public display) are provided by a common URL:
Shared portals:
https://tinyurl.com/ya7ouaeg
Activities
RoomQuake
2017 is organized around three activities:
1.
During the planning
activity, teachers can configure the classroom and develop a schedule for simulated earthquakes.
2.
During the instant
quake activity, teachers can specify and deliver individual simulated
earthquakes to seismographs independent of scheduled quakes. Scheduled quakes
are ignored during this activity.
3.
During the scheduled
quakes activity, simulated quakes are delivered to seismographs according
to the schedule defined during
planning. Teachers can also modify the schedule during this activity;
modifications take effect immediately.
Design
Each
portal offers a number of resources
(represented as tabs on the interface). The specific set of resources available
through a portal depends on the current activity. When the teacher changes the activity, all portals are automatically updated
to reflect the appropriate set of resources. The current activity and portal
always appear at the top of the page.
Table:
Resources available to each portal during different activities
|
|
activity |
||
|
portal |
planning |
instant quakes |
scheduled quakes |
|
teacher |
change activity configure room build schedule overview (this document) |
change activity configure room initiate individual quakes overview |
change activity configure room edit schedule overview |
|
student |
none |
report readings |
report readings |
|
seismograph |
none |
seismograph simulator |
seismograph simulator |
|
big picture |
none |
aggregate view |
aggregate view |
|
manager |
seismogram attributes |
seismogram attributes |
seismogram attributes |
Resources
activity
Use:
Click on the activity tab to see the list of available activities (the current activity
is highlighted). Clicking on an activity switches RoomQuake to that activity
type and updates all portals according to the design (above).
room (configure classroom)
Use:
All units are in meters. Choose a
corner in your classroom to serve as the origin of your coordinate system.
Click on the dimension fields (left and top) to specify the length of the room
along each dimension. Position the computers that you want to serve as
seismographs around the room, and measure their position within the coordinate
system. Enter the coordinates of your seismograph computers by typing in the
text fields below the map of the room. (You do not need to use five
seismographs; simply leave the X and Y fields blank for seismographs you do not
wish to use.) Click on "Save configuration" to save the room layout
configuration.
overview
Use:
A copy of this document.
schedule
Use:
This resource is used to build or edit a schedule of simulated earthquakes which will be delivered during the
"scheduled quakes" activity. The "room" display (left)
shows the locations of the scheduled events (brown dots). Add an event using
the "Add event" button. Edit the date, time, epicenter, and magnitude
of the events using pull-down menus and text fields in the block of controls in
the upper right portion of the screen. Use the "scissors" icon to
delete an event. (Past events are made available on the seismographs via a
"scrollback" feature, and should not
generally be deleted.) Click on "pick" to select an event; you may
then click on the room map to choose an epicenter. Click on "Save
schedule" to save or update the schedule; saved changes take place
immediately.
portal (select a new portal)
Use:
The portal tab allows you to select a different portal for use. When you are
using the teacher portal, you have access to all other portals (this is to
allow teachers to preview what the other portals will look like directly on
their computers). When you use other portals, the list of
available portals that you can choose are limited.
seismograph
Use:
Simulated seismograph display. Default view is "live recording" of
current ground motion at location of this seismograph. Historical events can be
examined by using the "Back" and "Forward" buttons;
clicking "Forward" when viewing the most recent historical event will
bring the seismograph back to "live" display. Click the "Live"
button to return to the real-time seismograph at any time. The seismograph will
also switch to "live" display if a new even occurs while user is
reviewing history.
instant (individual simulated earthquakes)
Use:
Generate an individual simulated earthquake. Choose an epicenter by typing in
the Epicenter X and Y fields (upper right) or by clicking on the room map (an
"explosion" symbol will designate the location of the selected
epicenter). Select the desired magnitude from the pulldown
menu. Click the "Generate quake" button to initiate the simulated
event and send it to the classroom seismographs. The "Event History"
list shows the list of "instant quakes" that have
been generated and are available through the "scrollback"
feature on the seismographs. Click the "Clear demo quakes" to erase
that list and make those prior quakes unavailable through the scrollback feature.
readings (submit estimates of event parameters)
Use:
Used by students to submit estimates of event parameters based on their
interpretations of simulated seismograms. Select seismograph for which you are
reporting, and fill in the fields to construct your estimate. Click
"Submit estimate" to send add estimate to aggregate resource (usually
shown on the "big picture" display).
aggregate
Use:
Real-time display reflecting student estimated readings of event parameters.
Map displays concentric circles around selected seismographs reflecting student
estimates of event distance (gray), and a red circle representing the mean of
all student estimates (brown). Use distance filters (when individual
seismographs are selected) to remove outliers (this is this is particularly
helpful for addressing student input errors). Bottom panel displays frequency
distribution of event time estimates (larger circles = higher frequency). Clear
all reading (and start over) by clicking the "Clear readings" button.
seismogram (configure the characteristics of seismograms)
Use:
For experts only; this is for the geoscientists! Allows user
to control seismogram parameters. Click Save changes to update values; active
seismographs immediately respond based on parameter changes. Save command
ignored (with warning) if parameters will not allow the seismogram to be
depicted within seismograph window.
Last
update: October 15, 2017


You can embed your personal chatbox in your own blog or website by pasting the embed code below
If you just want to share chatbox in a separate url, use the link below


Here are some frequently asked questions and some standard responses, please feel free to add new questions (and answers!), or amend the response to make it clearer or more complete.
1) Why has all the coding been moved out of main?
In order to increase the modularity of the code, many tasks that were previously in main and input (input/output, initialisations, diagnostics etc.) have been moved to the relevant physical module. Thus, main should not vary as much between model versions. Also, changes to a module (to the number of prognostic variables, the functionality etc.) should now only concern that module and not the rest of the model. This should make it easier to 'plug and play' new functionality.
2) Why is modular code so great anyway?
So that if you want to change something, you only need to do it in the part of the code directly affected. There should be much less unforseen consequences to seemingly minor changes.
3) Why are there three files for every module, why not just one?
There are generally three logical parts of each module: a common block (that owns the variables on the main model grid and/or saves output from a module that might be used by another part of the code), the local physics (for instance, the pure 1D column physics) and the drivers (the programs that access the local physics routines, do initiallisation etc.). The reason that they are in seperate files is mainly because of the logical dependencies between the main model and module variables. Consider a situation where the module needs information from another module - i.e. there is a USE statement in one of the drivers. Conceivably, that module might USE a variable from this module also. Since we now use an automatically generated list of dependencies in the makefile, this would create a circular dependency if the USE statements and the variable definitions were in the same file. Therefore, at minimum the common block and the drivers must be seperated. We choose generally to make the local physics a seperate file also because it is not usually dependent on anything except the CONSTANT module and possibly the main model common block. Thus it does not need to be recompiled everytime something in the drivers or common block changes. However, sometimes the local physics is in the same file as the COM module.
4) How do I know where do find definitions and declarations then?
The rules are relatively simple (but not yet implemented 100% of the time).
5) Why doesn't the model produce 'nice' output as it runs?
The GISS GCM output is of the form of accumulation files, and since the accumulated quantities are neither averaged or scaled, looking directly at these 'acc' files is not very illuminating. So it is a fact that the running output is not 'nice'. However there are a number of reasons why we do it this way. Firstly, the accumulated arrays are generally the basic model values. The 'nice' diagnostics that are required are generally a function of a number of these variables. Accumualted arrays and files can be concatenated very easily (and thus averaged trivially) without having to worry about the length of time each array was accumulated (say a different number of days in two different months). The average of derived quantities (such as the albedo) is not the same as the quantity derived from the average (which is usually what is required). Accumulated arrays allow you to do both depending on what is needed. A great many diagnostics can be derived after the fact, without having to have thought about them ahead of time.
6) Something is wrong with the advection, my tracers are going haywire!
This is not a problem in the advection. The GISS dynamical core is unique in that it uses more information than just the mean tracer amount in a particular grid-box. We currently use two flavours of tracer advection, the linear and the quadratic upstream schemes. The linear scheme carries 3 first order moments along with the mean, while the quadratic scheme carries an additional 6 second order moments. These can be thought of as representing the spatial gradients of the tracer concentration at the centre of a gridbox. Thus a higher degree of accuracy for the tracer distribution in the box can be found as a Taylor series expansion in the moments. This is used in the advection routines to accurately move tracer mass from box to box. However, as should be clear, if the moments are incorrect or corrupted in any way, the advection will be compromised, even to the point where negaitve tracer amounts might appear. This is usually what has happened when the model crashes after advecting tracers.
What could cause the the moments to be corrupted? Generally, the coding of the tracers did not consider the effects on the moments of a particular physical process. The most serious omission is not to reduce the moments in the same proportion as the tracer mass is reduced. This omission can leave tracer moments significantly larger than the mean tracer amount, and implies a sub-grid scale tracer profile that is not positive definite. Please read the document Using tracer moments in the GISS GCM for further information on how to use the moments in a useful fashion.
7) The model crashed in the dynamics near the pole. What should I do?
Occasionally (every 15-20 model years), the model will produce very fast velocities in the lower stratosphere near the pole (levels 7 or 8 for the standard layering). This will produce a number of warnings from the advection (such as limitq warning: abs(a)>1) and then finally a crash (limitq error: new sn < 0"). There are a number of things you can do to get past such an error: i) Go back to the last monthly rsf file and use ISTART=4, ii) change DT to a smaller value (like 180 sec), run past the crash for a couple of days, and then increase DT back to normal afterwards.
The second option is more straightforward and can be dealt with automatically (see here for more details). The first option is not guaranteed to work unless the number of hours that have elapsed from the start of the run to the end of the last month are not an integer multiple of NRAD. (This is to ensure that the model will follow a different path). If there is a problem, then going back to the previous months restart file generally works.
Please make a note in the rundeck that this happened, and how you fixed it.
8) Why should I switch to using modelE?
It is of course up to you. However, there are a number of reasons why it makes sense for you to make the effort involved in upgrading.
All numbers in the GCM should be accurate to the degree of their representation, however, many are not. This mostly stems from the automatic conversion that takes place when a single precision or integer number is converted to a double precision variable. In the following examples the double precision variables will only be accurate to 6 or so decimal places (instead of the 12 or so expected).
REAL*8 X X = 0.1 => 0.10000000149011612 X = 1/3 => 0. (integer division) X = 1./3. => 0.3333333432674408 X = 1./3 => 0.3333333432674408 X = 0.3333333333333333 => 0.3333333432674408 (!!!!)
To get double precision results you must use 'd' ie. X=0.1d0 or 1d-1 X=1d0/3d0 or 1./3d0 or even 1d0/3
Note that for decimals expressable exactly in binary formulation, there are no problems, ie. X=0.5 is the same as X=5d-1. Where integer division is concerned, the integer is converted to the type of the numerator (I think). Thus 1./IM gives only single precision. REAL*8 :: FIM = IM, BYIM = 1./FIM gives double precision (since the denominator is already double precision).
On some compilers there is a compiler option (such as -r8) that removes these problems, but not all. Hence for maximum portability we are trying to be explicit about writing those 'd0's out.
10) Why does GISS use the line number format for fortran files?
Line number format is the practive of using the first 8 characters of a line to insert line number information in a 'F8.3' format.
Historically, this is a holdover from the days of the punchcard when all lines required a line number. Subsequently, it was used at GISS to make additions/corrections to files without having to copy the entire rest of the code (the update system). Further refinements have led to functional updates that allow the 'piggy-backing' of specific functionality (such as tracer code, or ocean coupling) on top of the underlying model code in a relatively model-version independent way. We have also found it very useful in tracking bugs, notifying users about code changes and referencing in general.
In modelE line number format has been replaced by the CVS revision control system and preprocessing options.
11) Is line number format is 'harder' to edit?
Since the format is written in ASCII is just as easy as any other text format to edit in any standard editor. In addition we have tools which work very well that a) allow standard fortran mode in Emacs to work with line-numbers (giss-fortran-mode.el) b) utilities that fill-in any missing line numbers, so that you don't ever need to put them in by hand (fillnum). This could be combined with the makefile, so that the it would occur automatically c) you can choose whatever format you like to edit (.U file, a .f file (line numbers first or last)) with options to upd
12) Don't revision control systems (rcs or cvs) provide equal functionality?
One part of the update file system (of which line numbers are part) is indeed to save space and store only changes from a base file and this is replicated - and improved upon with rcs or cvs. However, the other part of the system involves the addition of functionality that is generally independent of the base code (i.e the tracer code, the stratospheric code, the coupling to the ocean, options for diagnostic output etc), which can be applied directly to any version of the base code, hopefully with only minimal changes. This is not replicated by standard rcs/cvs systems (and indeed they do not try). This functionality is to some extent similar to the use of pre-processor directives, but as the number of options grow (as they will), this produces unwieldy and overly complicated base code. Thirdly, line numbers are a very easy way to refer to code sections, either to describe what is going on, or to refer to specific lines, for instance, when a bug is discovered.
13) Will the update system ever change?
We have already seen an increase in functionality of the update system that have made it much more useful for precisely the functions that rcs/cvs does not cover. However, for the new modelE code that was built directly in CVS, it will probably not be re-introduced.
We replaced parameter lists JC and RC and corresponding common blocks with a Parameter Database.
The following goals were pursued:
We created a module which keeps a database of all parameters used in the model and provided a library of interface routines. These interface routines are used to get the values of parameters from the database (or to set new parameters in the database). Rundeck parameters are loaded automatically (with one call in INPUT) into this database when the program starts. This database is saved to restart file each time when restart file is written.
For each parameter the database keeps its name as a character
string and its value (or list of values for an array). To get a value
of a parameter "my_param"
and assign it to the
variable var
one would do:
call get_param( "my_param", var )
If one wants
to create a new parameter in the database with the name
"new_par"
and set it to the value var one would do:
call set_param( "new_par", var )
It is recommended that you use the same name for the variable and for its name in the database, i.e.:
call set_param( "new_par", new_par ) call get_param( "my_param", my_param )
This will improve the readability of the code.
At the restart first all parameters from the rundeck are loaded to the database with the names as they appear in the rundeck. Then the restart file is read and those parameters which were saved to it and were not present in the rundeck are added to the database. If some parameter was present both in the rundeck and in the restart file then preference will be given to the rundeck and restart file value will be ignored. This is done so that you can always overwrite certain parameters using rundeck.
5) So what are the actual interfaces?
Rundeck: All parameters have been moved out of the namelist block
to a new block which starts with &&PARAMETERS
and ends with
&&END_PARAMETERS
This block is being read by a special parser
(not a namelist). The syntax of this block is similar to that of the
namelist with following restrictions:
'abc'
)
2*123
) are not supported
integer, real*8, character*1
to
character*16
'
) strings are present on the line then the
data are character
strings
.
) are present then the data is real*8
integer
PARAM library:
The library utilizes Fortran 90 interface blocks in
such a way that the type of parameters (i.e. integer, real*8,
character
) is recognized automatically, so the the names of
subroutines are the same for all types. If the dimension of the
parameter is given then it is treated as an array. If dimension is
omitted then it is a scalar. Beware that Fortran 90 treats scalars
and arrays of dimension one differently, so if you confuse them it
may generate an error.
The formal arguments in the subroutines below are:
name
- character*(*)
- the name of the parameter which is a
character string no longer than 32 bytes
value
- a scalar variable or a linear array of type: integer,
real*8,character*1 to character*16
dim
- integer
- dimension of an array, should be omitted for
scalars
opt
- character*1
- an optional "option" (opt='o'
means "overwrite")
kunut
- integer
- unit number for reading/writing
flag
- logical
- reading "overwrite" option
Simple copy routines to copy parameters to/from database:
set_param( name, value, dim, opt )
- put a parameter with the name
<name> and the value <value> to the database
get_param( name, value, dim )
- copy the value of the parameter
<name> from the database to the variable <value>
These functions will check if the parameter is present in the database and will generate an error if you are trying to get parameter which is not in the database or if you are trying to set parameter which is already set. If you really need to overwrite parameter which is already in the database use opt='o'. Otherwise <opt> should be omitted.
Query logical function:
is_set_param( name )
- returns .true.
if parameter <name> is
present in the database, .false.
otherwise
A convenient function which is a combination of those above:
sync_param( name, value, dim )
- literally consists of the following
lines:
if( is_set_param( name ) ) then get_param( name, value, dim ) else set_param( name, value, dim ) endif
So what it does, it checks if parameter <name> is in database and if so copies it to the <value>. Otherwise it leaves <value> unchanged and copies it to the database with the name <name>. This function is provided as a convenient tool, since this is what you will do most often. At the restart each module will check if certain parameters were provided in the rundeck or in the restart file (i.e. they are in the database already) and use those values. If not then it will use default values and will also copy them to the database so that they are saved to the restart file for future reference.
Subroutines to work with pointers:
alloc_param( name, pvalue, initval, dim )
- allocates space in the
database for the parameter <name>, fills it with data provided
in <initval> and returns pointer to it in <pvalue>
get_pparam( name, pvalue, dim )
- returns pointer <pvalue>
to the parameter data of the parameter <name> in the database
These functions are provided as an additional tool and actually are not needed if parameters in the database are treated as "parameters", i.e. they are set only once at the beginning of the run and then used as constants. But it appeared that some data which was in "parameters" common block was changed during the run (some actually quite often and in different places). To keep the parameter database up-to-date with those changes one would have to call "set_param" each time after the data is changed which is rather awkward. Instead one can use pointers to the parameter data in the database. Pointers in Fortran 90 are nothing else but aliases of the objects they point to. So if you get a pointer to a parameter from the database and then work with it as if it were a regular variable, you will automatically update it in the database and there will be no need to call "set_param". So this subroutines can be used if one wants to keep a dynamic variable in the database (so that it is automatically saved to the restart file).
Reading/writing subroutines:
read_param( kunit, ovrwrt )
- reads the parameter database from
the unit <kunit>
write_param( kunit )
- writes the parameter database to the unit
<kunit>
The arguments:
kunit
- integer
- the unit number from/to
reading/writing is performed
ovrwrt
- logical - if .true. then
reading overwrites those parameters that are already in the database.
If .false. then those parameters which are already in the database
are left unchanged and only new parameters are added.
Other useful subroutines:
print_param( kunit )
- does formatted output to the unit <kunit>
in a way similar to namelist
The argument:
kunit
- integer, inetnt(in)
- the unit number
corresponding to the file to which we want print the database
query_param( n, name, dim, ptype )
- returns the the information
about the parameter by its number in the database <n>. It
returns 'EMPTY' in the <name> if parameter with such <n>
doesn't exist (i.e. if <n> is bigger then the number of
parameters)
The name is always converted to the low case. It returns 'EMPTY' (upper case) if <n> doesn't correspond to any parameter
dim
- integer, intent(out)
- returns the dimension of the
parameter (i.e. <dim> = 1 for scalars, <dim> > 1 for
arrays)
ptype
- character*1, intent(out)
- returns the type of the
parameter: 'i'
- for integer 'r'
- for real*8
'c'
- for character
Parser subroutine:
parse_params( kunit )
- parse the information in the file <kunit>
and load the parameters into the database. It overwrites the existing
parameters.
The argument:
kunit
- integer
- the unit number corresponding to
the file with the rundeck information (it should contain a block
starting with &&PARAMETERS and ending with &&END_PARAMETERS)
This subroutine is actually located in a separate module PARSER, but it seemed logical to describe it here.
Here is an example of typical usage of "query_param". One should keep in mind that though "get_param" is a generic interface one should call it with the arguments of correct type to extract the information. That's why one needs to use "select case" below.
subroutine ex_param ! this is an example subroutine which shows how to loop ! over all parameters in the database ! it does the same thing as print_param USE PARAM integer, parameter :: MAXDIM=64 character*32 name integer n, dim character*1 ptype integer ic(MAXDIM) real*8 rc(MAXDIM) character*16 cc(MAXDIM) n = 1 print *, 'printing parameter database' do call query_param( n, name, dim, ptype ) if (name == 'EMPTY' ) exit if ( dim > MAXDIM ) then print *, 'dim of param ',name,' is > MAXDIM' stop 'MAXDIM too small' endif select case( ptype ) case ('i') !integer call get_param( name, ic, dim ) print *, name, ( ic(i), i=1, dim ) case ('r') !real call get_param( name, rc, dim ) print *, name, ( rc(i), i=1, dim ) case ('c') !character call get_param( name, cc, dim ) print *, name, (cc(i), i=1, dim ) end select n = n + 1 enddo end subroutine ex_param
The preprocessor is a program that runs before the actual compiler starts and does certain editing to the source code according to preprocessing instructions. All preprocessing instructions start with # in the first column. The most typical example of preprocessor usage in Fortran code would be:
............... some fortran code .............. #ifdef OPTION_A ............... fortran code specific for OPTION_A .............. #endif .............. more fortran code ..............
In the above example the code between #ifdef OPTION_A and #endif will be taken into account only if the name OPTION_A was defined (with the instruction #define OPTION_A) somewhere earlier in the file. Otherwise it will be treated as commented out. So preprocessor allows you to optionally include/exclude certain parts of the code. There are also other useful preprocessing commands, like name substitution. Though with name substitutions one should be very careful in fixed format Fortran, since it is easy to create a line which after substitutions will be longer then 72 characters. The following is a list of typical preprocessing instructions: #define #undef #include #ifdef #ifndef #if #else #endif SGI manual pages provide good explanations to those instructions. On SGI type man cpp.
2) How to set up global preprocessing options in a rundeck?
Your rundeck may contain an optional block which starts with a line Preprocessor Options and ends with a line End Preprocessor Options. Everything between those lines is treated as a set of preprocessing definitions and will be included into corresponding source files. Here is a simple example of preprocessing block:
Preprocessor Options #define TRACERS_ON ! include tracers code End Preprocessor Options
It defines the name TRACERS_ON. The text which starts from '!' is considered as comment and is ignored. Trailing spaces and empty lines are also ignored.
3) How to use global preprocessing options in a source file?
If you want to use global preprocessing options in a certain source file you should include a line:
#include "rundeck_opts.h"at the very beginning of such file. Otherwise all global preprocessing names will stay undefined (the compiler will not give any warnings about this). A typical use of a preprocessing option would be:
#include "rundeck_opts.h" .......... some code #ifdef TRACERS_ON some tracers code here #endif some code
The code between #ifdef TRACERS_ON and #endif will be included only when global name TRACERS_ON is defined in a rundeck. Otherwise this code will be ignored by the compiler.
When the Makefile starts to compile the model it reads the global preprocessing options block from the rundeck and compares it to the contents of the file rundeck_opts.h. If they are identical the file rundeck_opts.h is left unchanged. Otherwise it is overwritten with the new preprocessing block. File rundeck_opts.h should be included into each source file which wants to use global preprocessing options. This is done by putting a line
#include "rundeck_opts.h"in the beginning of the source file. Note that one should use CPP include (i.e. #include, which starts from the first position), and not the Fortran include. When the Makefile checks dependencies it takes into account dependency on rundeck_opts.h, so that when rundeck_opts.h is changed all files which #include it are automatically recompiled.
5) Any recommendations on usage?
There is an understanding that global preprocessing options should be used only when there is no other convenient way to reach the same goal. One should keep in mind that once the global preprocessing block in a rundeck is changed, all files that include rundeck_opts.h will be recompiled which most probably will force the recompile of the entire model. So one should limit such options to those which would not change too often from rundeck to rundeck. This functionality is introduced mainly for the options which are global (i.e. used in many source files at the same time) and which need to be documented (that's why this block is in a rundeck). Typical example would be an option which controls inclusion of tracers code into the model (as in example above). There is also a general convention that the names defined by preprocessor are constructed of capital letters only with '_' introduced for readability, like: USE_OPTION_A . I suggest that we observe it. This helps to distinguish them from the rest of the code which is usually in lower case. And yes, names used by preprocessor are case-sensitive (unlike names in Fortran).


Belem Zhang, Intel
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
<input id="invalid" type="date" value="invalid_value">

宗旨：以中文（简体或繁体）协调及讨论 HTML5 规范以及 HTML5 相关的规范，收集这些规范的评论与问题，以及在这些规范中文环境下的特殊测试案例。
加入：寄一封标题为「subscribe」的信至<EMAIL_ADDRESS>http://www.w3.org/html/ig/zh/testharness.js
and testharnessreport.js

/resources
directory at root level
sudo ln -s [path/to/resources/dir] /resources
id="log"
should exist in test file
test(test_function, name, properties)
async_test()
is also defined by testharness.js
for asychronous testingtestharness.js
test()
testharness.js
will display PASS/FAIL for each call to test()
test(test_function, name, properties)
test_function
must be an object, not a function calltest_function
should be testharness assert method
test(function() { assert_true(true) }, name, properties)
test(test_function, name, properties)
name
is a string that identifies the testname
should be short, unique, and must not changename
will be displayed in the test results table
test(function() { assert_true(true) }, "test_name", properties)
test(test_function, name, properties)
properties
is an object that overrides defaultsproperties
is an optional argumenttimeout
and metadata
test(function() { assert_true(true) },
"test_name",
{ timeout:1000, assert: 'This should always be true.' }
)
testharness.js
provides a number of assert methods
testharness.js
test_function
for test()
description
argument that is only output if the assertion fails
test()
assert_equals(actual, expected, description)
actual
: The actual value from the functionality being testedexpected
: The expected valuedescription
(optional): Output only if the assertion fails
assert_equals(getData("myElement"), 100, "Expected value for myElement is 100")
User agents must not allow the user to set the value
to a non-empty string that is not a valid date string.
<!DOCTYPE html>
<meta charset='utf-8'>
<title>[Test Area]: [Title/Scope of Test]</title>
<link rel="author" title="[Name of Author]" href="mailto: or http://..">
<link rel="help" href="http://www.w3.org/TR/[link to tested section]">
...

testharness.js
and testharnessreport.js
imported/resources
directory at root level
 <input id="invalid_value" type="date" value="invalid-date">

myDiv
div used as test element - translate applied in JSlog
div used as container for test resultstest()
uses assert_equals
as test_function
assert_equals
actual argument supplied by API call<!DOCTYPE html> <meta charset='utf-8'> <title>HTML Test: Forms date state</title> <link rel="author" title="your name" href="mailto<EMAIL_ADDRESS><link rel="help" href="http://www.w3.org/html/wg/drafts/html/CR/forms.html#date-state-(type=date)">
 <input id="invalid_value" type="date" value="invalid-date">

You have completed a W3C JavaScript Test.
Q: Which of the path to the testharness scripts is expected?
Q: Which of the path to the testharness scripts is expected?


Need a means of navigation that is familiar and consistent.
The navigation drawer provides a familiar means of navigation along with access to additional account features, for example, the ability to switch accounts, access settings, and sign out.
In addition to the Material Design Navigation Drawer component, this example leverages the following components:
md-list
md-icons


{% if team|length < 4 %}{% if pending and pending|length < 3 %}
{% trans "Teams of three people or less are somewhat small and provide more work for everyone. Why don't you invite some more team members?" %}
{% endif %}{% endif %}
{% trans "To invite more members to your team, enter an email address below." %}
{% for member in team %}
{{ member.get_display_name }}
{% if member != request.user or team|length > 1 %}
{% endif %}


{% extends "foreign/foreign_base.html" %} {% block main_content %}
Latest Foreign Agents Registration Act documents from the Department of Justice. Click here for an explanation of these records.


{% if (page.description) %}
{% endif %} {% if (page.images) %}
{% endif %}
Blog
Keith can think and write at the same time!
Recipes
All this and he cooks!
Travel
Does Keith have spilkes or what?
Tech
On occasion, Keith writes neat code.
Share |
Search
{{ content }}


Remoting classes for Caucho's Hessian and Burlap protocols. Provides a proxy factory for accessing Hessian/Burlap services, and an exporter for making beans available for Hessian/Burlap clients.


Your Colony lasted 0.
The most effient ant was who walked an average of mm to bring food home.
At it's peak, your colony had ants.


TABLE OF INTERACTIONS WITH
ALFUZOSIN
See also: alpha blockers for urological use
See also: medications leading to orthostatic hypotension
From the French ANSM drug interactions document of September 2016, p. 9
ALFUZOSIN RxNorm: 17300 ATC: G04CA01 |
STRONG INHIBITORS OF CYP3A4 CLASS CODE: J02-J05 |
Risk of increase of the plasma concentrations of the alfuzosin and of its undesirable effects. . |
CONTRAINDICATION |
ALFUZOSIN RxNorm: 17300 ATC: G04CA01 |
OMBITASVIR + PARITAPÉVIR CLASS CODE: OMPA |
Increase of the plasma concentrations of the alfuzosin by decrease of its hepatic metabolism by the therapy with the two medications. |
CONTRAINDICATION |


{% extends "base.html" %} {% block title %}Review for Publication{% endblock %} {% block head %} {% endblock %} {% block body %}
{{error}}
{% else %}Review the changes to the Code since the last publication and write a public summary of the changes. When the changes look good, click the publish button.


These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements.
Check existence of HFiles in v1 format. Usage is as following:
usage: HFileV1Detector [-h] [-n <arg>] [-p <arg>] -h,--help Help -n,--numberOfThreads <arg> Number of threads to use while processing HFiles. -p,--path <arg> Path to a table, or hbase installation In case no option is provided, it processes hbase.rootdir using 10 threads. Example: To detect any HFileV1 in a given hbase installation '/myhbase': $ $HBASE_HOME/bin/hbase org.apache.hadoop.hbase.util.HFileV1Detector -p /myhbase
This change removes implicit write access to the META and ACL tables for any user with GLOBAL CREATE or ADMIN privilege. Users with GLOBAL CREATE will not be able to elevate their privileges unexpectedly through direct access to the ACL table. A GLOBAL ADMIN will still correctly be allowed to grant themselves any desired privilege.


Preparation time
30 mins to 1 hour
Cooking time
30 mins to 1 hour
Serves
Serves 4
Push the boat out with this classic shellfish platter.
For the garlic and chilli butter, put the butter, garlic, chillies and herbs in a large glass bowl. Season with salt and pepper and mix well. Spoon the butter onto a piece of cling film, roll it into a log shape, twist the ends and place in the fridge to set.
Preheat the oven to 200C/180C Fan/Gas 6.
For the mayonnaise, cut a square of kitchen foil big enough to wrap the garlic in a single layer. Put the garlic on the foil, drizzle over the olive oil, sprinkle with the thyme and season with pepper and ½ teaspoon of salt. Seal the parcel and roast for 20–25 minutes.
Put the egg yolks, mustard and vinegar in a food processor and blend. Slowly pour in the sunflower oil with the motor running, until a mayonnaise is formed. You may not need all the oil? Squeeze the roasted garlic out of its skin into the mayonnaise and blend again
Discard any mussels and clams that fail to close when you tap them against the side of the sink. Put them and all the other shellfish in a large baking tray. Cut the butter log into thin slices and dot it over the shellfish. Roast for 15–20 minutes. Discard any mussels and clams that fail to open.
Meanwhile, for the socca bread, put the gram flour in a large bowl. Add the salt and olive oil, then gradually pour in enough water to make a batter with the consistency of double cream. Heat a medium frying pan and add a glug of oil. Pour in a little of the batter to make a layer around 0.5cm/1/4in thick. Cook for 1–2 minutes, turn over, then cook for another 2 minutes. Keep warm, and repeat the cooking until all the batter has been used up.
To serve, put the shellfish on a large platter, sprinkle with parsley and serve with the garlic mayonnaise and bread.


http://bit.ly/riid-dcco15-slides
DrupalCamp Colorado 2015
Front-end Developer for Aten Design Group
jnettik on
Twitter - GitHub - Drupal.org
Fill our designs with them.
Blob them into WYSIWYG editors.
Drupal can distance us from a lot the complexity.
Images come with a lot of unique properties.
At their simplest, images are small pockets of structured content.
src
attributealt
attributetitle
attributeImages make up an increasing majority of every page on the internet.
Like every other part of what we do, responsive web design forced us to start thinking about these things, and so much more.
On top of the things mentioned above, we also need to consider...
Images on the web are a complex problem. We can't expect a simple solution.
Current solutions are not simple...
... however, Drupal does make things simpler.
Disclaimer: This is not an in depth explaination of responsive image solutions.
There are much better resources, many of which are linked to in the resources slide.
img
tagThis is required for every solution. Every other technique builds on to HTML's core img
tag.
srcset
attributeAttribute to inform the browser of alternate image sources.
Best used when trying to address resolution use cases.
srcset
attributesrcset
comes in two flavors:
picture
elementNew element in HTML5 to define different image sources based on varying criteria.
srcset
allows the browser to make educated decisions on source.
picture
dictates to the browser which source we want.
Best when used for art direction or browser support use cases.
picture
elementMedia condition: stripped down media queries.
srcset
: defines the source to use at this condition.
Drupal has awesome modules to ease a lot of this complexity.
Image Styles: Create all the different image sizes and crops for us.
Breakpoints: Allows you to expose site breakpoints to Drupal, and group them by components.
Picture: Maps image styles to breakpoints. Creates image field formatters for both srcset
with sizes
and picture
element. And it includes picturefill 2 polyfill for older browser support.


This data does not leave your browser. It is only for demonstration purposes.
This is just an example and not meant to be taken seriously.


GIRLFIGHT A film review by Steve Rhodes Copyright 2000 Steve Rhodes RATING (0 TO ****): **
One more fight at school and Diana, played with sullen intensity by newcomer Michelle Rodriguez, will be expelled. Living in a Brooklyn ghetto and with a dead-end life, Diana decides to channel her energy into boxing at the gym like her brother (Ray Santiago).
Once she begins to fight, the angry and depressed Diana begins to find some relief from her surroundings. Although the seedy gym, The Brooklyn Boys' Club, where she trains is even more rundown than the miniscule apartment she shares with her father (Paul Calderon) and brother, she gets the fulfillment from her sport that she has never gotten from school. Rodriguez's impressive acting debut, however, is the only real reason to see GIRLFIGHT.
Although first-time writer and director Karyn Kusama spent 5 years preparing this project, the script is significantly underdeveloped and the director sets a lethargic pace. Think of the film as ROCKY ON VALIUM. There's lots of brooding teenage angst, but remarkably little ever happens. Only in a dramatic confrontation scene with her father, in which she tells him, "Everything I know about losing I learned from you, Dad," does the movie have much emotional impact.
The picture follows a completely formulaic arc toward the big concluding match. The gym features lots of clichéd signs ("Champions are made not born." "Winners never quit, and quitters never win."), even though the movie wants badly to be taken as something more than another Rocky Balboa story. Nevertheless, the movie is one-idea story -- girl rather than boy as young boxer -- that never gets fleshed out beyond its concept.
Diana's boyfriend is a handsome fighter named Adrian (Santiago Douglas). Want to bet on whom she boxes in the concluding match? Want to bet who is going to win?
The only surprise is how the final fight is edited. After waiting for an entire movie for it come alive, the ending bout happens so fast that, if you blink a few times, you'll miss it. I told actor Santiago Douglas, who was at our screening, that I did not like the way it was edited down to almost nothing. He rolled his eyes and said only, "I agree. I agree."
GIRLFIGHT runs 1:50. It is rated R for language and would be acceptable for teenagers.
Email<EMAIL_ADDRESS>Web: http://www.InternetReviews.com
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Kennedy Consultancy is a full service Global Market Research and Strategy Consulting firm with over 35 years of industry experience. Headquartered in Clonoulty County Tipperary and with on-the-ground offices worldwide, Kennedy Consultancy is uniquely positioned to offer clients in-depth insight into the global marketplace. We deliver the around-the-clock project management and client servicing that is essential in a 24/7 global economy.
Blockchain


--- layout: base css: [/css/water_balance.css] js: [/js/pxloader.min.js, /js/water_balance_objects.js, /js/water_balance.js] ---
Live the life of a crab!
This game simulates Dr Bliss’s discoveries about blackback land crab salinity levels to survive. She discovered that the ideal salinity level for a blackback land crab is 15%, and that above 35% is very harmful to the crab and causes the crab’s eyestalks to bulge, as the game shows. When the crab’s salinity level passes 35%, the simulator crab dies, replicating the real life of the crab.
Your character is the red crab. Your goal is to beat the black crab by maintaining a salinity level of 15% and staying fed.
Use the arrow keys to move around the sand dunes. To increase salinity, take a dip in the salt water pools. Stay out of the water to decrease.
Keep track of your saline level through the percentage in the top left corner. To eat, go to the blades of grass around the water pools and press SPACE. The black crab likes to steal the food for himself and burrow away somewhere else, so watch out! Maintain a hunger level above 0% to stay alive!