The DC/OS Stateful Service SDK
Mesos is a powerful resource allocator, but writing a production stateful service can be complex, tedious, and error-prone. The DC/OS Stateful Service SDK provides a high-level interface for writing stateful services. Now, you can write a stateful service complete with persistent volumes, fault tolerance, and configuration management in about 100 lines of code. This SDK is the product of Mesosphere's experience writing production stateful services such as DC/OS Apache Kafka , DC/OS Apache Cassandra, and DC/OS Apache HDFS.
Read about the features to learn more about the DC/OS Stateful Service SDK.
In this tutorial, we'll build an example
service called data-store
. It is composed of a small number of
meta-data
nodes and a larger number of data
nodes. This structure
is meant to model a service with a small number of coordinating master
nodes and a large number of dependent agent nodes. Each task runs a
command that writes some data to a file, then sleeps.
The goal state for this fictional data-store
is to keep two
meta-data
and N data
nodes running, where, initially, N = 3.
meta-data
nodes must come up before data
nodes. The service
scales by starting more data
nodes.
This tutorial includes code snippets. The final source code is available at http://github.com/mesosphere/sdk-reference-framework.
A DC/OS service is composed of schedulers and executors. The
scheduler is run by Marathon, which supervises the scheduler,
restarting it upon failure. The scheduler, in turn, starts and
supervises the executors. If specified in the ServiceSpecification
,
the
executors will contain a persistent volume, which is a folder or
mount point on the agent that persists even after a task fails. This
allows a stateful service to recover with its data intactafter task
failure or temporary node failure.
In this tutorial, data-store
is the scheduler, and meta-data-{0,1}
and data-{0-1}
are the executors.
aws
CLIThe Java library for The DC/OS Stateful Services SDK is
dcos-commons
. Java projects using dcos-commons
can use any Java
build system, but for this tutorial, we'll assume you're using Gradle.
First, we create our build.gradle
file:
group 'com.mesosphere.sdk'
version '1.0-SNAPSHOT'
apply plugin: 'java'
apply plugin: 'application'
repositories {
mavenLocal()
mavenCentral()
maven {
url "http://downloads.mesosphere.com/maven/"
}
}
dependencies {
compile "mesosphere:dcos-commons:0.7.10-SNAPSHOT"
compile "org.slf4j:slf4j-simple:1.7.21"
}
task wrapper(type: Wrapper) {
gradleVersion = '3.1'
}
mainClassName = 'com.mesosphere.sdk.reference.scheduler.Main'
The first step to running a service is to create a
ServiceSpecification
, which defines the behavior of the service.
A ServiceSpecification
is mostly a list of TaskSet
s.
The tasks defined in this list are launched in order. We can use this
ordering to define tiers of services. In this example, we want all
meta-data
nodes to come up before any data
node:
private static final String TASK_METADATA_NAME = "meta-data";
private static final int TASK_METADATA_COUNT = Integer.valueOf(System.getenv("METADATA_COUNT"));
private static final double TASK_METADATA_CPU = Double.valueOf(System.getenv("METADATA_CPU"));
private static final double TASK_METADATA_MEM_MB = Double.valueOf(System.getenv("METADATA_MEM"));
private static final double TASK_METADATA_DISK_MB = Double.valueOf(System.getenv("METADATA_DISK"));
private static final String TASK_METADATA_URI = System.getenv("METADATA_URI");
private static final String TASK_METADATA_CMD = "bash meta-data";
private static final String TASK_DATA_NAME = "data";
private static final int TASK_DATA_COUNT = Integer.valueOf(System.getenv("DATA_COUNT"));
private static final double TASK_DATA_CPU = Double.valueOf(System.getenv("DATA_CPU"));
private static final double TASK_DATA_MEM_MB = Double.valueOf(System.getenv("DATA_MEM"));
private static final double TASK_DATA_DISK_MB = Double.valueOf(System.getenv("DATA_DISK"));
private static final String TASK_DATA_URI = System.getenv("DATA_URI");
private static final String TASK_DATA_CMD = "bash data";
private static ServiceSpecification getServiceSpecification() {
return new ServiceSpecification() {
@Override
public String getName() {
return SERVICE_NAME;
}
@Override
public List<TaskSet> getTaskSets() {
return Arrays.asList(
DefaultTaskSet.create(
TASK_METADATA_COUNT,
TASK_METADATA_NAME,
getCommand(TASK_METADATA_CMD, TASK_METADATA_URI),
getResources(TASK_METADATA_CPU, TASK_METADATA_MEM_MB),
getVolumes(TASK_METADATA_DISK_MB, TASK_METADATA_NAME),
Optional.of(TaskTypeGenerator.createAvoid(TASK_METADATA_NAME)),
Optional.of(getHealthCheck(TASK_METADATA_NAME))),
DefaultTaskSet.create(
TASK_DATA_COUNT,
TASK_DATA_NAME,
getCommand(TASK_DATA_CMD, TASK_DATA_URI),
getResources(TASK_DATA_CPU, TASK_DATA_MEM_MB),
getVolumes(TASK_DATA_DISK_MB, TASK_DATA_NAME),
Optional.of(TaskTypeGenerator.createAvoid(TASK_DATA_NAME)),
Optional.of(getHealthCheck(TASK_DATA_NAME))));
}
};
}
A TaskSet
contains the bulk of the definition. It
contains the command to run, the resources to run with, and the number
of tasks. As you can see, it is common for DC/OS services to read
their config from environment variables.
At a minimum, the command must contain a value
, which is the shell
command to invoke. It will likely also contain one or more URIs
pointing to resources to download before execution. In this example,
we're downloading the metadata
and data
binaries from an HTTP
server:
private static Protos.CommandInfo getCommand(String cmd, String uri) {
return Protos.CommandInfo.newBuilder()
.addUris(Protos.CommandInfo.URI.newBuilder().setValue(uri))
.setValue(cmd)
.build();
}
Resurces are specified via ResourceSpecification
s. Tasks must run
with at least cpus
and mem
resources, though we may specify any
Mesos resource, including ports
:
private static Collection<ResourceSpecification> getResources(double cpu, double memMb) {
return Arrays.asList(
new DefaultResourceSpecification(
"cpus",
ValueUtils.getValue(ResourceUtils.getUnreservedScalar("cpus", cpu)),
ROLE,
PRINCIPAL),
new DefaultResourceSpecification(
"mem",
ValueUtils.getValue(ResourceUtils.getUnreservedScalar("mem", memMb)),
ROLE,
PRINCIPAL));
}
In Mesos, disk
is just another resource, like cpus
and mem
.
However, stateful services must manage disk
differently. Rather
than simply accepting the resource like cpus
or mem
, the scheduler
must first create a
volume
from the disk resources so that it persists beyond the lifetime of the
task. The VolumeSpecification
is a high-level interface that
handles this for us:
private static Collection<VolumeSpecification> getVolumes(double diskMb, String taskName) {
VolumeSpecification volumeSpecification = new DefaultVolumeSpecification(
diskMb,
VolumeSpecification.Type.ROOT,
taskName + CONTAINER_PATH_SUFFIX,
ROLE,
PRINCIPAL);
return Arrays.asList(volumeSpecification);
}
Finally, we can attach a health check to our tasks. If the check fails, the Mesos agent will kill the task, and the scheduler will restart it.
private static Protos.HealthCheck getHealthCheck(String name) {
Protos.CommandInfo commandInfo = Protos.CommandInfo.newBuilder()
.setValue("stat %s%s/output".format(name, CONTAINER_PATH_SUFFIX))
.build()
return Protos.HealthCheck.newBuilder()
.setCommand(commandInfo)
.build();
}
Now that we have a ServiceSpecification
, we must define a Main class
that runs it. To do this, create a Service
object, and register the
ServiceSpecification
with it:
public class Main {
private static final int API_PORT = Integer.valueOf(System.getenv("PORT0"));
public static void main(String[] args) throws Exception {
new DefaultService(API_PORT).register(getServiceSpecification());
}
}
DefaultService
takes a single parameter, apiPort
. apiPort
specifies which
port its HTTP server will bind to. Upon registering the
ServiceSpecification
, our service will start its HTTP server,
register as a Mesos framework, and start launching tasks.
Now that we've defined our service, let's build and install it. The first thing we'll need is a DC/OS cluster.
Go to https://dcos.io/install/ to install a DC/OS cluster.
If you have not already installed the CLI, do so by following these instructions.
Now that we have our cluster and CLI, we can install our service. DC/OS services are deployed to users via DC/OS packages. The first step is to define our package.
A DC/OS package is a set of four files. You can learn more about the package format here, but, in summary, it looks like this:
The majority of the package definition resides in marathon.json.mustache. See the reference framework for an example.
Let's place these files in a directory in our project called
universe/
.
Now we build our project:
$ ./gradlew distZip
Then we must build our DC/OS package. DC/OS packages are stored in repos. The most common repo is the Mesosphere Universe, which is public. We would publish our package there if we wished to share it with the world. For now, we just want to create a simple repo containing our single package.
NOTE: The current workflow of creating a package and a repo is cumbersome. We're sorry about this. DC/OS 1.10, which is slated to be released in December 2016, will introduce the ability to install a package directly, rather than forcing you to wrap it in a repo.
~ $ cd /path/to/dcos-commons
dcos-commons $ ./tools/ci_upload.py \
data-store \
universe/ \
reference-scheduler/build/distributions/scheduler.zip
./ci_upload.py
uploads the artifact to S3, rewrites the package to
include links to the artifact, creates a repo containing that package,
and uploads that repo to S3. The end result is a URL for a DC/OS
repo.
We now add this repo to our cluster:
$ dcos package repo add --index=0 dev-repo <repo_url>
Then, install our package:
$ dcos package install data-store
Visit Services > data-store in the DC/OS UI to watch
data-store
deploying.
To verify that data-store
has completed deploying, make the
following HTTP request from the DC/OS CLI. To learn how to make
requests to the HTTP API,
please read the HTTP API section:
GET /v1/plan/status
This HTTP request will return JSON to indicate the status of the
service. If the deployment is complete, plan.status
will equal
"COMPLETE".
When deployment is complete, two meta-data
tasks and three data
tasks will be visible in the DC/OS Services UI.
To do a complete uninstall, we first uninstall our service using the DC/OS CLI. This stops and tears down the framework.
$ dcos package uninstall data-store
However, uninstalling the package does not remove persistent state like Zookeeper state and persistent volumes. Mesosphere provides a Docker image to remove persistent state:
local $ AUTH_TOKEN=$(dcos config show core.dcos_acs_token)
local $ dcos node ssh --master-proxy --leader
cluster $ docker run mesosphere/janitor /janitor.py \
-r data-store-role \
-p data-store-principal \
-z dcos-service-data-store \
--auth_token=$AUTH_TOKEN
For more information on the janitor image, see https://github.com/mesosphere/framework-cleaner.
As noted earlier, stateful services often have particular deployment requirements. These deployments may involve the initial creation of Tasks or a change in Task configuration or the scaling of a particular kind of task or an upgrade to a new version of a Task. Each of these scenarios comes with attendant risks and benefits. In some cases (as in initial install) you may be happy to have a service rollout without intervention. In others, as in a configuration update, one may wish to deploy some portion of a service and check stability before completing a deployment.
In order to provide the necessary flexibility and control necessary to achieve these outcomes, the SDK organizes deployment of tasks by means of Plans. Plans are composed of Phases which are composed of Blocks. A Block encapsulates the smallest element of work executed in a Plan and is the plan element which encapsulates the launching of Mesos Tasks.
Phases are groups of Blocks which have some semantic relationship. At
least two plans are generated automatically by the SDK when presented
with a ServiceSpecification
. These are the deployment and recovery
plans. The deployment plan is concerned with deploying Tasks. It
deploys Tasks for the first time, and when configuration updates are
indicated by a user. The recovery plan is concerned with defining the
necessary operations which must be performed when transient or permanent
failures are encountered.
Let us examine the deployment plan of the example data-store service after its initial installation has completed.
Executing the following command:
GET /v1/plan"
generates the following output:
{
"phases": [{
"id": "31a3ca99-bdbd-45dd-a8f0-cc93feade61e",
"name": "meta-data",
"blocks": [{
"id": "2a0db529-095b-4b63-8c56-075aa442c898",
"status": "COMPLETE",
"name": "meta-data-0",
"message": "Block: meta-data-0",
"has_decision_point": false
}, {
"id": "99210582-cdfb-4b63-95e9-19600f117dc7",
"status": "COMPLETE",
"name": "meta-data-1",
"message": "Block: meta-data-1",
"has_decision_point": false
}],
"status": "COMPLETE"
}, {
"id": "927ac279-b969-4106-9089-40264ae15dc4",
"name": "data",
"blocks": [{
"id": "efcf9dc0-488f-4f9e-ae0c-1ac16c401e0a",
"status": "COMPLETE",
"name": "data-0",
"message": "Block: data-0",
"has_decision_point": false
}, {
"id": "a0e0905b-d4da-4cec-84b9-461a60a92818",
"status": "COMPLETE",
"name": "data-1",
"message": "Block: data-1",
"has_decision_point": false
}, {
"id": "fa85a843-e6eb-4074-b353-875197a18adb",
"status": "COMPLETE",
"name": "data-2",
"message": "Block: data-2",
"has_decision_point": false
}],
"status": "COMPLETE"
}],
"errors": [],
"status": "COMPLETE"
}
The first thing to notice is that the TaskSet
s defined in a
ServiceSpecification
are mapped to deployment Phases. The data-store
example service has TaskSet
s encapsulating meta-data
and data
Tasks in that order. The deployment plan above has the respective
meta-data
and data
Phases.
In its default configuration, the two data
Tasks and three meta-data
Tasks are launched. We can see that a Block has been created
encapsulating each of those tasks. The names of Blocks map to the names
of the TaskSpecification
objects within a TaskSet
. The status of a
Block can be in one of 3 states. It may be PENDING
, IN_PROGRESS
, or
COMPLETE
.
By default all Phases and the Blocks within them are rolled out
serially. Each Block must reach a COMPLETE
state before the
next Block may be started. Beyond this automatic behavior, it is often
desirable to manually pause/resume a deployment. For example, in a
production setting multiple uncoordinated deployments may cause
unexpected effects, including causing unavailability or severely
degraded performance. In thes cases and others, the ability to pause
individual deployments while others continue without performing a full
rollback can be helpful.
The has_decision_point
fields above indicate whether a user has indicated
a desire to pause a deployment at a particular Block.
A Plan's execution may be paused or continued by POST commands executed
against the HTTP endpoints at the /v1/plan/interrupt
and /v1/plan/continue
respectively. For example:
POST /v1/plan/interrupt"
POST /v1/plan/continue"
Finally, beyond manual control of Plan execution behavior it may be
desirable in certain failure scenarios to either restart the execution
of a Block or force its completion. Restarting a Block in default
implementations simply sets a Block's status to PENDING
and allows the
normal Block processing system to do the necessary work to drive a Block
to completion. This can be accomplished by issuing a POST command to
the /v1/plan/restart
endpoint. For example to restart the Block associated with the first
data task data-0
one would issue the following command:
POST /v1/plan/restart?phase=927ac279-b969-4106-9089-40264ae15dc4&block=efcf9dc0-488f-4f9e-ae0c-1ac16c401e0a"
Forcing the completion of a block can be accomplished in a similar
manner by issuing a POST command against the /v1/plan/forceComplete
endpoint. For example to force the completion of the second meta-data
block one would issue the following command:
POST /v1/plan/forceComplete?phase=31a3ca99-bdbd-45dd-a8f0-cc93feade61&block=99210582-cdfb-4b63-95e9-19600f117dc7"
We saw in the Service Specification section that the service's configuration is read in through environment variables. You can use any source of configuration, but DC/OS Services are typically configured through environment variables. To make a configuration change, modify the corresponding environment variable, then restart the scheduler. When the scheduler comes back up, it will read its new configuration and transition to the new state.
For example, in order to scale the data-store
service from 3 data
nodes to 5, modify the DATA_COUNT
environment variable. To modify
it:
1) Go the the Services > data-store page of the DC/OS UI.
1) Click Edit.
1) Click the Environment Variables tab.
1) Change the value of DATA_COUNT
from 3 to 5.
1) Click Deploy Changes.
This will restart the scheduler with the updated environment. When
the scheduler starts up, it detects that it is already running 3
data
tasks and starts 2 more in order to reach the goal state of 5.
We should observe two more tasks starting, data-3
and data-4
.
While the above describes configuration of the scheduler itself via environment variables, there's also a need for configuration of the underlying service tasks themselves in a flexible way.
To simplify the common task of getting user-facing configuration to
service tasks, the developer may follow the following convention in
naming the environment variables for these configuration options:
TASKCFG_<TASK_TYPE>_<CFGNAME>
, where <TASK_TYPE>
has been
converted from the task type to fit the requirements of environment
variables:
For example, an option named FOO
for tasks of type index.mgr
should be named TASKCFG_INDEX_MGR_FOO
, while an option BAR
for
tasks of type data-node
should be named TASKCFG_DATA_NODE_BAR
.
These configuration options will automatically be forwarded to the
environments of the matching tasks as environment variables, with
the TASKCFG_<TASK_TYPE>_
prefixes removed. A special prefix of
TASKCFG_ALL_<NAME>
may be used for any options that should be
passed to every task type.
A common need for service developers is an easy way to write configuration files before launching tasks. To fulfill this need, the developer may provide configuration file template(s) in their TaskSet(s). These templates follow the mustache templating format, similar to what's used in DC/OS packaging. The templates will be automatically rendered against the task's environment (which is customized as described above), and then each written to relative file paths specified by the developer.
When a task fails, the scheduler will attempt to restart the on the same node, using the same persistent volume as the previous task.
There are two cases where you must manually restart tasks:
1) If an agent permanently fails or is ailing, the scheduler will never receive an offer with the expected persistent volume, and will thus never automatically restart the task. We must restart it manually on a different node. This is called replacing the task.
2) If a task is stuck or performing poorly, or we just want to restart it for debugging, we may need to restart the task manually on the same node.
You can perform both actions using the same endpoint:
POST /v1/tasks/restart/<task-name>?replace={true|false}
If replace=true
, this action will replace the task on a separate
node. If replace=false
, it will restart the task on the same node.
The DefaultScheduler
makes no intelligent placement decisions. It
will run a task on first offer it gets that satisfies the resource
constraints for that task.
Placement decisions may be customized using Placement Constraints, which are rules that specify how tasks should be placed in the cluster. These rules are enforced by filtering the resource offers returned by Mesos. Resources that do not conform to the rules are removed from the list.
You can define placement constraints on a
per-task basis by customizing the return value of
TaskSpecification.getPlacement()
:
public Optional<PlacementRuleGenerator> getPlacement() {
// avoid systems which are running an "index" task:
return Optional.of(TaskTypeGenerator.createAvoid("index"));
}
You can use some of the common PlacementRule
s
and/or PlacementRuleGenerator
implementations provided in the
offer.constrain
package. You can also create your own PlacementRule
s for custom
constraints. Custom constraints can take advantage of anything present
in the Mesos Offers
or in the other running TaskInfo
s.
The stdout
and stderr
streams for all tasks running in Mesos,
including the scheduler and executors, are captured and written to
files in that task's sandbox. You can view these files from the
Services tab of the DC/OS UI or from the CLI. Learn
more.
All code in dcos-commons
, including the DefaultScheduler
, uses
slf4j
to write logs to stderr
. To write your own logging code,
first create a LOGGER
:
private static final Logger LOGGER = LoggerFactory.getLogger(Main.class);
Then write to it:
LOGGER.info("Starting reference scheduler with args: " + Arrays.asList(args));
The contents of stdout
and stderr
for the executors is entirely
dependent on the command specified in our ServiceSpecification
.
dcos-commons
contains unit
tests written with junit
and mockito
. You can also create your own
unit tests.
The shakedown library is a tool for writing integration tests for DC/OS services. For an example, see the tests for DC/OS Kafka.
As of DC/OS 1.8, this section is only relevant to DC/OS Enterprise Edition, but support has recently been open-sourced and should soon be available in Open DC/OS. For more information, see the dcos-metrics repository and stop by the #day2ops channel on DC/OS Slack.
DC/OS Metrics automatically provides all Mesos containers with a
unique UDP endpoint for outputting statsd
-formatted metrics. The
endpoint
is advertised via two container environment variables:
STATSD_UDP_HOST
and STATSD_UDP_PORT
. Any metrics sent to this advertised endpoint
will automatically be tagged with the originating container and
forwarded upstream to the cluster's metrics infrastructure.
You can take advantage of this endpoint for your service scheduler as well as for the underlying service tasks themselves. For instance, you can configure your service's tasks to emit to the locally-advertised endpoint as they are launched.
Note: The environment-advertised endpoint is unique to each container and cannot be reused across containers.
The data sent to this endpoint should follow the standard statsd
text format, optionally with multiple newline-separated values
per UDP packet.
http://docs.datadoghq.com/guides/dogstatsd/#datagram-format
tags are also supported, so the application may also include its own
custom tags:
memory.usage_mb:5|g
frontend.query.latency_ms:46|g|#shard_id:6,section:frontpage
See also:
Mesos-DNS assigns every Mesos task a DNS address of the form
<task-name>.<framework-name>.mesos
. In our example (running 3 data
nodes), Mesos-DNS creates the following addresses:
meta-data-0.data-store.mesos
meta-data-1.data-store.mesos
meta-data-2.data-store.mesos
data-0.data-store.mesos
data-1.data-store.mesos
It also creates a DNS entry for the scheduler:
data-store.marathon.mesos
If the tasks listen on reserved port(s), clients will also need these port(s) in order to establish a connection. We can fetch these port(s) along with the DNS entry for a task via the following endpoint:
GET /v1/tasks/connection/{task-name}
This HTTP request returns:
{
"dns": "data-0.data-store.mesos",
"ports": "4388"
}
If the task has multiple ports reserved, they will be displayed as a
comma-delimited sequence of ranges. e.g. "8080,2000-3000"
.
This section is only relevant to DC/OS Enterprise Edition.
In a DC/OS Enterprise Edition cluster running in strict security mode, all schedulers must authenticate with the Mesos master using DC/OS service accounts. For instructions on creating a service account, read [this][https://docs.mesosphere.com/1.8/administration/id-and-access- mgt/service-auth/]
Mesos schedulers authenticate to the master by providing a principal
and secret
. In DC/OS, the principal
must be the DC/OS Service
Account ID, and the secret
must be the private key. To start the
scheduler with access to the private key, we must integrate with
Marathon's DC/OS secret support:
{
"env": {
"DCOS_SERVICE_ACCOUNT_CREDENTIAL": {"secret": "serviceCredential"}
},
"secrets": {
"serviceCredential": {
"source": <secret_name>
}
}
}
This causes Marathon to launch the task with the
DCOS_SERVICE_ACCOUNT_CREDENTIAL
environment variable set to the
contents of the service account's private key. The Mesos agent looks
for this environment variable and will inject it as the secret
in
the scheduler's registration request.
Services expose an HTTP API to support common operations. There are two ways to access this API.
The first is from clients running outside of DC/OS, such as from your local machine. These clients must authenticate. For example:
curl -H "Authorization: token=$(dcos config show core.dcos_acs_token)" \
"$(dcos config show core.dcos_url)/service/data-store/v1/plan/status"
To learn more about DC/OS Authentication, visit the Managing Authentication section of the DC/OS documentation.
The second way to access the HTTP API is from clients running inside the DC/OS cluster. These clients may bypass DC/OS authentication and access the scheduler directly:
curl "data-store.marathon.mesos:<port>/v1/plan/status"
Where is the port you gave to the DefaultService
constructor
in the Define a Service section.
Several API endpoints are listed in this tutorial and a full API is forthcoming.
Simple service definitions - A simple, declarative API to simplify resource offer configuration. Learn more.
Multi-tier service support - A scheduler created with the DC/OS Stateful Services SDK is aware of dependencies between tiers of processes, enabling one-click install and safe failure recovery. Learn more.
Deployment strategies - The DC/OS Stateful Services SDK supports diverse deployment strategies to fit the needs of schedulers. Learn more.
Configuration management - The DC/OS Stateful Services SDK can read configuration from an external source, detect configuration modifications, and control which configurations can be modified by the user. Learn more.
Interactive upgrade support - You can pause, continue, or abort an upgrade interactively in order to upgrade tasks safely. Learn more.
Fault tolerance - Schedulers built with the SDK are automatically configured to detect and restart failed tasks on the same node (to preserve state) and, if the node fails, restart it on a different node. Learn more.
Persistent volumes - The SDK automatically configures your scheduler to create persistent volumes, enabling stateful tasks. Learn more.
Mesos offers resources to the scheduler for launching tasks rather than launching tasks against a fixed API. Resource offers are more powerful and flexible than a declarative task launching API because schedulers can apply arbitrary logic to determine the set of resources they consume.
However, the majority of schedulers, especially schedulers for stateful services, only need a basic API. For these cases, declarative APIs are much simpler. A simple scheduler only needs to run N containers with M memory and C cpu, along with some set of persistent volumes, ports, etc.
For these cases, the DC/OS Stateful Services SDK provides a simple, declarative API built on top of Mesos resource offers. You define your service declaratively and the SDK manages installing and supervising the service using resource offers from Mesos.
You can think of this as doing for stateful services what Marathon does for stateless services, while still allowing you to drop down to lower layers when you need more flexibility.
Many stateful services have multiple interdependent tiers, each running different processes. For example, Apache HDFS is composed of NameNodes, JournalNodes, and DataNodes. JournalNodes start before NameNodes, which start before DataNodes. To support one-click install for users, as well as safe recovery from failures, the scheduler must be aware of these dependencies.
Many stateful services have strict deployment requirements. Some, including, for instance Apache Cassandra, require nodes to be added to the cluster one at at time. Others may permit parallel deployment. The DC/OS Stateful Services SDK includes deployment strategies that support these different requirements.
For any framework, at least two components must be configured: the scheduler and the service. Scheduler configuration includes things like node count, deployment strategies, and security parameters. Service configuration includes resource settings such memory, CPU, and ports, as well as any configuration passed on to the underlying service.
The DC/OS Stateful Services SDK includes logic for reading configuration from an external source (default: environment variables), detecting changes to the configuration, and redeploying any affected tasks. It also supports marking certain configuration parameters as "unmodifiable," so that the user can't change them after install time. For example, the disk size of permanent volumes cannot be modified because volume size is static.
Tasks must often be updated one at a time, and often depend on certain administrative tasks like backup/restore. You can choose to pause, continue, or abort an upgrade interactively.
There are two component failures that any scheduler must defend against: the scheduler and the service. The SDK sets up fault tolerance for your scheduler automatically.
The SDK abstracts away task reconciliation with the Mesos master in the case of task failure. In the case of service failure, the SDK configures your scheduler to restart the task on the same node or, if the node has failed, restarts the task on a different node. The scheduler's persistent volume is reused on restart. A new persistent volume is created when a node fails.
The mechanism to determine whether a task has permanently failed is time-based by default. When a task stays in a terminal state for some configurable duration, it is determined to have failed. The default duration is 20 minutes. Once tasks have been determined to have permanently failed, a second configurable parameter determines how many destructive task replacements may occur in a given time period. By default, no more than one task may be destructively replaced in any 10 minute period. Finally, automatic destructive recovery may be entirely suppressed.
Consider the simplest construct for the DefaultScheduler
, in which
automatic destructive recovery configuration is exposed:
DefaultScheduler create(
String frameworkName,
PlanManager deploymentPlanManager,
Optional<Integer> permanentFailureTimeoutSec,
Integer destructiveRecoveryDelaySec) {
The permanentFailureTimeoutSec
argument determines how long a task
must be in a terminal state before it is considered permanently failed.
If no value is present, automatic destructive recovery is turned off.
The destructiveRecoveryDelaySec
argument determines how much time must
pass between destructive task replacement events.
The parameters above are one implementation of a more general permanent task recovery scheme. The task recovery scheme has two major components: a safety constraint and a performance constraint. In the example above, the duration that must be waited until a task is considered permanently failed is the safety constraint. You can write a safety constraint that is more complex than a simple timeout.
In the example above, the recovery delay parameter is the performance constraint. Even if a large number of tasks could be safely destructively replaced, it could cause performance degradation as network traffic increases to reconstruct lost task state. In addition, you must be cautious when automating destructive recovery operations, so it is prudent to throttle the maximum rate of destruction.
Recovery, like deployment, is mediated by a plan. Use the endpoint below to view the status of the plan.
GET /v1/plans/recovery
If no failures of any kind have occurred, you will see output similar to the snippet below.
{
phases: [{
id: "128d7df9-8605-4e1a-b98b-478821b1aeda",
name: "recovery",
steps: [],
status: "COMPLETE"
}],
errors: [],
status: "COMPLETE"
}
If a task has crashed and been recovered, you will see a plan similar to:
{
phases: [{
id: "88d944d3-4fc2-4605-889f-96b5429fb8af",
name: "recovery",
steps: [{
id: "ed4d2209-ab19-4242-b7da-d10cdf9e443b",
status: "COMPLETE",
name: "data-2",
message: "org.apache.mesos.scheduler.recovery.DefaultRecoveryBlock: 'data-2 [ed4d2209-ab19-4242-b7da-d10cdf9e443b]' has status: 'COMPLETE'. RecoveryType: TRANSIENT"
}],
status: "COMPLETE"
}],
errors: [],
status: "COMPLETE"
}
Note in particular the message that contains
RecoveryType: TRANSIENT
for the step named data-2
. This message indicates a
recovery from a temporary failure. The task was able to be successfully
recovered in its previous location with all its old resources, including
persistent volumes. In the case of a permanent failure recovery, the
message would instead contain RecoveryType: PERMANENT
.
Schedulers must create persistent volumes that will live beyond the life a single task to tolerate failure, and they must reserve these volumes to prevent other frameworks from taking them. The SDK configures persistent volumes for your scheduler automatically.


pyspark.sql.
Column
A column in a DataFrame.
Column instances can be created by:
# 1. Select a column out of a DataFrame df.colName df["colName"] # 2. Create from an expression df.colName + 1 1 / df.colName
New in version 1.3.0.
Methods
alias(*alias, **kwargs)
alias
Returns this column aliased with a new name or names (in the case of expressions that return more than one column, such as explode).
asc()
asc
Returns a sort expression based on ascending order of the column.
asc_nulls_first()
asc_nulls_first
Returns a sort expression based on ascending order of the column, and null values return before non-null values.
asc_nulls_last()
asc_nulls_last
Returns a sort expression based on ascending order of the column, and null values appear after non-null values.
astype(dataType)
astype
astype() is an alias for cast().
astype()
cast()
between(lowerBound, upperBound)
between
True if the current column is between the lower bound and upper bound, inclusive.
bitwiseAND(other)
bitwiseAND
Compute bitwise AND of this expression with another expression.
bitwiseOR(other)
bitwiseOR
Compute bitwise OR of this expression with another expression.
bitwiseXOR(other)
bitwiseXOR
Compute bitwise XOR of this expression with another expression.
cast(dataType)
cast
Casts the column into type dataType.
dataType
contains(other)
contains
Contains the other element.
desc()
desc
Returns a sort expression based on the descending order of the column.
desc_nulls_first()
desc_nulls_first
Returns a sort expression based on the descending order of the column, and null values appear before non-null values.
desc_nulls_last()
desc_nulls_last
Returns a sort expression based on the descending order of the column, and null values appear after non-null values.
dropFields(*fieldNames)
dropFields
An expression that drops fields in StructType by name.
StructType
endswith(other)
endswith
String ends with.
eqNullSafe(other)
eqNullSafe
Equality test that is safe for null values.
getField(name)
getField
An expression that gets a field by name in a StructType.
getItem(key)
getItem
An expression that gets an item at position ordinal out of a list, or gets an item by key out of a dict.
ordinal
isNotNull()
isNotNull
True if the current expression is NOT null.
isNull()
isNull
True if the current expression is null.
isin(*cols)
isin
A boolean expression that is evaluated to true if the value of this expression is contained by the evaluated values of the arguments.
like(other)
like
SQL like expression.
name(*alias, **kwargs)
name
name() is an alias for alias().
name()
alias()
otherwise(value)
otherwise
Evaluates a list of conditions and returns one of multiple possible result expressions.
over(window)
over
Define a windowing column.
rlike(other)
rlike
SQL RLIKE expression (LIKE with Regex).
startswith(other)
startswith
String starts with.
substr(startPos, length)
substr
Return a Column which is a substring of the column.
when(condition, value)
when
withField(fieldName, col)
withField
An expression that adds/replaces a field in StructType by name.


Thrift module: social_coffee_service
This file contains the protocol interface for operations to query
friends and users relationships.
Constants
| Constant | Type | Value |
SOCIAL_COFFEE_VERSION_MAJOR | i16 | 1 |
Major version.
|
SOCIAL_COFFEE_VERSION_MINOR | i16 | 0 |
Minor version.
|
Type declarations
Typedef: ID
Base type: i32
Every resource is assigned a unique numeric identifier which
will not change for the life of the resource.
Data structures
Exception: SocialException
| Key | Field | Type | Description | Requiredness | Default value |
| 1 | message | string | | required | |
This exception is thrown when a call fails due to input data validation or
any internall error occurs e.g. database connection refused.
message: The string message indicating the type of error that occurred and the reason why it occurred.
Services
Service: SocialCoffeeService
Service: SocialCoffeeService
Function: SocialCoffeeService.ping
string
ping()
Returns a "pong" string.
@return
"pong" string.
@throws never
Function: SocialCoffeeService.get_friends
list<ID
>
get_friends(ID
id)
throws SocialException
Returns a list of user's friends with provided ID.
@param id
The ID of the user for whom the list of the friends should be retrieved.
@return
The list of user's friends IDs. If user has no friends empty list is returned.
@throws SocialException
- if ID is null
- if ID is not a number
-
- if ID is a non positive number
- if internall error occurs e.g. connection to a database could not be established
Function: SocialCoffeeService.create_friendship
bool
create_friendship(ID
usera,
ID
userb)
throws SocialException
Asks the service to make a new multual friendship relationship between users with IDs usera and userb.
It's an idempotent operation so it can be called multiple times.
@param usera
The ID of the user A.
@param userb
The ID of the user B.
@return
Boolean value indicating whether the operation created a new relationship or relationship already existed.
"true" if operation created a new friendship relationship, "false" otherwise.
@throws SocialException
- if any of IDs is null
- if any of IDs is not a number
-
- if any of IDs is a non positive number
- if both of IDs are equal
- if internall error occurs e.g. connection to a database could not be established
Function: SocialCoffeeService.remove_friendship
bool
remove_friendship(ID
usera,
ID
userb)
throws SocialException
Asks the service to remove a new friendship relationship between users with IDs usera and userb.
It's an idempotent operation so it can be called multiple times.
@param usera
The ID of the user A.
@param userb
The ID of the user B.
@return
Boolean value indicating whether the operation removed an already existed relationship or operation did nothing.
"true" if operation removed an already existed friendship relationship, "false" otherwise.
@throws SocialException
- if any of IDs is null
- if any of IDs is not a number
-
- if any of IDs is a non positive number
- if both of IDs are equal
- if internall error occurs e.g. connection to a database could not be established


{% load displayutils %} Automatic synchronization
Running tapiriik costs money: servers, backups, maintenance & more. $2 a year covers these costs so tapiriik will always run smoothly. Of course, I'd be much obliged if you threw in something extra.
I already paid / I want to transfer my payment or I have a promo code
No auto-renewal, I'll just send you an email once the year is up. Your payment will apply to all your accounts, present and future, and may be transferred at any time.


--- title: One Team Government 2017 --- {% extends 'layouts/default.html' %} {% block content %} {# SECTION ####################################################################### #} {{ ui.primaryHeading({ title: "Follow what's happening" })}} {# SECTION ####################################################################### #} {% call ui.pageSection({ id: 'about', heading: 'About One Team Gov' | safe }) %}
One Team Government brings together UK policymakers, service designers, digital professionals and cross-sector experts to talk openly and creatively about making government in the UK more effective by working together.
We call this 'one team government'. It’s the idea that by bringing teams together to work in a truly multidisciplinary way, we can:
The event is jointly sponsored by the Civil Service digital and policy professions. It’s being run by a cross-disciplinary team of policy and digital professionals from many departments, who were inspired by this blog post by a senior policy advisor on bringing policy and delivery closer together.
The event also has the backing of Jeremy Heywood as part of his vision of a Brilliant Civil Service.
The civil service is united by its values of integrity, honesty, objectivity and impartiality, but different professions are still divided in their skill sets and ways of working.
We want to bring together professionals who don't currently work seamlessly, to share and create specific ideas about how to work better together. Policy making and digital are our starting points but we’re not limited to these and welcome professionals from across government.
Our aim is to:


--- layout: archive title: Zulip Chat Archive permalink: /stream/113488-general/topic/apply.20in.20expression.html ---
Is there a way to apply
in the middle of an expression? Let me explain. Assume that lemma foo
tells me that Q
can be deduced from P
. Now, I have in the middle of a proof a goal of the form ∀x, Q x
, and I would like to reduce it to ∀x, P x
without introducing x
. Just like simp
would do instead of rw
, but for implications instead of equivalences. Is this possible?
Last updated: Apr 24 2020 at 19:02 UTC


\
Quantum Chromodynamics (QCD) in the \( u/d \) sector has approximate chiral symmetry but this symmetry is broken in two ways:
$$
\begin{equation*}
SU(2)_L \times SU(2)_R \approx SU(2)_V \times SU(2)_A \rightarrow SU(2)_V,
\end{equation*}
$$
that is, in the QCD ground state axial symmetry is broken while isospin symmetry is intact.
We obtain 3 Goldstone bosons: the pion family!
The chiral effective Lagrangian is given by an infinite series of terms with increasing number of derivatives and/or nucleon fields, with the dependence of each term on the pion field prescribed by the rules of broken chiral symmetry. Applying this Lagrangian to \( NN \) scattering generates an unlimited number of Feynman diagrams, which may suggest again an untractable problem. However, Weinberg showed that a systematic expansion of the nuclear amplitude exists in terms of \( (Q/\Lambda_\chi)^\nu \), where \( Q \) denotes a momentum or pion mass, \( \Lambda_\chi \approx 1 \) GeV is the chiral symmetry breaking scale, and \( \nu \geq 0 \). For a given order \( \nu \), the number of contributing terms is finite and calculable; these terms are uniquely defined and the prediction at each order is model-independent. By going to higher orders, the amplitude can be calculated to any desired accuracy.
The scheme just outlined has become known as chiral perturbation theory. Therefore, we want to describe the low-energy scenario of QCD by an Effective Field Theory (EFT). The steps to take:
The starting point for the derivation of the \( NN \) interaction is an effective chiral Lagrangian
$$
{\cal L}={\cal L}_{\pi N}+{\cal L}_{\pi\pi}+{\cal L}_{NN},
$$
which is given by
a series of terms of increasing chiral dimension,
$$
{\cal L}_{\pi N} = {\cal L}_{\pi N}^{(1)}+
{\cal L}_{\pi N}^{(2)}+{\cal L}_{\pi N}^{(3)} + \ldots ,
$$
$$
{\cal L}_{\pi\pi}={\cal L}_{\pi\pi}^{(2)}+ \ldots ,
$$
$$
{\cal L}_{NN} ={\cal L}_{NN}^{(0)}+{\cal L}_{NN}^{(2)}+{\cal L}_{NN}^{(4)} + \ldots,
$$
where the superscript refers to the number of derivatives or pion mass insertions
(chiral dimension). Good review: Epelbaum, Prog. Part. Nucl. Phys. 57, 654 (2006).
Common to apply the heavy baryon (HB) formulation of chiral perturbation theory in which the relativistic Lagrangian is subjected to an expansion in terms of powers of \( 1/M_N \) (kind of a nonrelativistic expansion), the lowest order of which is
$$
\begin{align*}
\widehat{\cal L}^{(1)}_{\pi N} & = \bar{N} \left(i {D}_0 - \frac{g_A}{2}\boldsymbol{\sigma} \cdot \boldsymbol{u}\right) N \\
&
\approx \bar{N} \left[ i \partial_0 - \frac{1}{4f_\pi^2} \boldsymbol{\tau} \cdot ( \boldsymbol{\pi}\times\partial_0 \boldsymbol{\pi})- \frac{g_A}{2f_\pi} \boldsymbol{\tau} \cdot (\boldsymbol{\sigma} \cdot \boldsymbol{\nabla} )\boldsymbol{\pi} \right] N + \ldots
\end{align*}
$$
For the parameters that occur in the leading order Lagrangian,
we apply \( M_N=938.919 \) MeV, \( m_\pi = 138.04 \) MeV,
\( f_\pi = 92.4 \) MeV, and
\( g_A = g_{\pi NN} \; f_\pi/M_N = 1.29 \),
which is equivalent to
\( g_{\pi NN}^2/4\pi = 13.67 \).
The chiral NN force has the general form
$$
\begin{equation*}
V_{\rm 2N} = V_{\pi} + V_{\rm cont},
\end{equation*}
$$
where \( V_{\rm cont} \) denotes the short-range terms represented by \( NN \) contact interactions
and \( V_{\pi} \) corresponds to the long-range part associated with the pion-exchange contributions
Both \( V_{\pi} \) and \( V_{\rm cont} \) are determined within the low-momentum expansion.
Notice that the nucleon kinetic energy contributes to \( \mathcal{L}^{(2)} \). The above terms determine the nuclear potential up to N2LO (with the exception of the NN contact terms at NLO) in the limit of exact isospin symmetry.
Consider now pion-exchange contributions to the potential
$$
\begin{equation*}
V_{\pi} = V_{1\pi} + V_{2\pi} + V_{3\pi} + \ldots \,,
\end{equation*}
$$
where one-, two- and three-pion exchange (3PE) contributions
\( V_{1\pi} \), \( V_{2\pi} \) and \( V_{3\pi} \) can be written in the low-momentum expansion as
$$
\begin{align*}
\tag{1}
V_{1\pi} &= V_{1\pi}^{(0)} + V_{1\pi}^{(2)} + V_{1\pi}^{(3)} + V_{1\pi}^{(4)} +\ldots \\
V_{2\pi} &= V_{2\pi}^{(2)} + V_{2\pi}^{(3)} + V_{2\pi}^{(4)} + \ldots \\
V_{3\pi} &= V_{3\pi}^{(4)} + \ldots \,.
\end{align*}
$$
Here, the superscripts denote the corresponding chiral order and the ellipses refer to
\( (Q/\Lambda)^5 \)- and higher order terms.
Contributions due to the exchange of four- and more pions are further suppressed:
\( n \)-pion exchange diagrams start to contribute at the order \( (Q/\Lambda)^{2n-2} \).
Notice further that in addition to isopin-invariant contributions there are
isospin–breaking corrections.
The static 1PE potential at N3LO has the form
$$
\begin{equation*}
V_{1\pi}^{(0)} + V_{1\pi}^{(2)} + V_{1\pi}^{(3)} + V_{1\pi}^{(4)}
= -\biggl(\frac{g_A}{2F_\pi}\biggr)^2 \, ( 1 + \delta )^2 \,
\tau_1 \cdot \tau_2 \,
\frac{\vec{\sigma}_1 \cdot\vec{q}\,\vec{\sigma}_2\cdot\vec{q}}
{\vec q \, ^2 + M_\pi^2}\,.
\end{equation*}
$$
The 2PE contributions are convenient to express as \( V_{2 \pi} \) in the form:
$$
\begin{align*}
V_{2 \pi} &= V_C + \tau_1 \cdot \tau_2 \, W_C + \left[
V_S + \tau_1 \cdot \tau_2 \, W_S \right] \, \vec \sigma_1 \cdot \vec \sigma_2
+ \left[ V_T + \tau_1 \cdot \tau_2 \, W_T \right]
\, \vec \sigma_1 \cdot \vec q \, \vec \sigma_2 \cdot \vec q \\
&+ \left[
V_{LS} + \tau_1 \cdot \tau_2 \, W_{LS} \right] \, i ( \vec \sigma_1 + \vec \sigma_2 )
\cdot ( \vec q \times \vec k )
\\ &+ \left[
V_{\sigma L} + \tau_1 \cdot \tau_2 \, W_{\sigma L} \right] \, \vec \sigma_1
\cdot (\vec q \times \vec k ) \vec \sigma_2 \cdot (\vec q \times \vec k ) \,,
\nonumber
\end{align*}
$$
where the superscripts \( C \), \( S \), \( T \), \( LS \) and \( \sigma L \) of the scalar functions
\( V_C \), \( \ldots \), \( W_{\sigma L} \) refer to central, spin-spin, tensor, spin-orbit and
quadratic spin-orbit components, respectively.
The first non-vanishing 3NF contribution appears at order \( \nu = 3 \), i.e. at N2LO. The contribution from graph (a)
$$
\begin{equation*}
\tag{2}
V^{\rm (3)}_{\rm 2 \pi}=\sum_{i \not= j \not= k} \frac{1}{2}\left(
\frac{g_A}{2 F_\pi} \right)^2 \frac{( \vec \sigma_i \cdot \vec q_{i}
)
(\vec \sigma_j \cdot \vec q_j )}{(\vec q_i\, ^2 + M_\pi^2 ) ( \vec
q_j\, ^2 + M_\pi^2)} F^{\alpha \beta}_{ijk} \tau_i^\alpha
\tau_j^\beta \,,
\end{equation*}
$$
where \( \vec q_i \equiv \vec p_i \, ' - \vec p_i \); \( \vec p_i \)
(\( \vec p_i \, ' \)) is the initial (final) momentum of the nucleon \( i \) and
$$
\begin{equation*}
F^{\alpha \beta}_{ijk} = \delta^{\alpha \beta} \left[ - \frac{4 c_1
M_\pi^2}{F_\pi^2} + \frac{2 c_3}{F_\pi^2}
\vec q_i \cdot \vec q_j \right] + \sum_{\gamma} \frac{c_4}{F_\pi^2} \epsilon^{\alpha
\beta \gamma} \tau_k^\gamma
\vec \sigma_k \cdot [ \vec q_i \times \vec q_j ]\,.
\end{equation*}
$$
The contributions from the remaining graphs (b) and (c) take the form
$$
\begin{align*}
\tag{3}
V^{\rm (3)}_{1 \pi, \; \rm cont} = - \sum_{i \not= j \not= k} \frac{g_A}{8
F_\pi^2} \, D \, \frac{\vec \sigma_j \cdot \vec q_j }{\vec q_j^2+ M_\pi^2}\left( \tau_i \cdot \tau_j \right) (\vec \sigma_i \cdot \vec q_j ),
\quad \quad \quad
V^{\rm (3)}_{\rm cont} = \frac{1}{2} \sum_{j \not= k} E \, ( \tau_j \cdot \tau_k ),
\end{align*}
$$
where \( D \) and \( E \) are the corresponding low-energy constants from the Lagrangian of order \( \nu=1 \).
| Chiral order | 2N force | 3N force | 4N force |
|---|---|---|---|
| \( \nu = 0 \) | \( V_{1 \pi}+V_{\rm cont} \) | \( - \) | \( - \) |
| \( \nu = 1 \) | \( - \) | \( - \) | \( - \) |
| \( \nu = 2 \) | \( V_{1 \pi} + V_{2 \pi} + V_{\rm cont} \) | \( - \) | \( - \) |
| \( \nu = 3 \) | \( V_{1 \pi} + V_{2 \pi} \) | \( V_{2 \pi} + V_{1 \pi, \; \rm cont} + V_{\rm cont} \) | \( - \) |
| \( \nu = 4 \) | \( V_{1 \pi} + V_{2 \pi} + V_{3 \pi} + V_{\rm cont} \) | Established | work in progress |


AMAZING PEOPLE ARE MAKING AMAZING DESIGNS IN A FUN ENVIRONMENT
Before we sign a contract or write a line of code our team will spend the necessary
time needed to
understand your product vision.
The outcome of this scoping session is a proposal or high-level statement of work.
Based on your requirements, we can provide a complete offering or just the pieces
you need.
Our design practice offers a full range of services including branding strategy, interaction and visual design and user experience testing. Througout your project, our designers create and implement visual designs and workflows, solicit user feedback and work with you to make sure what gets built is what is needed.
All engineers are fluent in the latest enterprise, mobile and web development
technologies.
They
collaborate with your team to write test and improve code on a daily basis using proven practices such as
test-driven development and pair programing.
Planning and development is iterative. Because we are constantly coding and testing the products we build are always ready to go live. This iterative process allows gor changes as business requirements evolve.


Salary Calculator
Add Employee
Submit
Employees
First Name
Last Name
ID
Title
Annual Salary
Remove Employee
Total Monthly:


|
c++ library collection
|
Superclass of all classes representing an input stream of bytes. More...
#include <inputstream.h>
Public Member Functions | |
| virtual | ~inputstream ()=default |
| Default virtual destructor. More... | |
| virtual void | read (void *buf, std::size_t len)=0 |
| Reads bytes from the input stream and stores them into the buffer. More... | |
| virtual void | skip (std::size_t n)=0 |
| Skips over and discards n bytes of data from this input stream. More... | |
| virtual std::size_t | available ()=0 |
| Returns an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking by the next invocation of a method for this input stream. More... | |
| virtual void | close ()=0 |
| Closes this input stream and releases any system resources associated with the stream. More... | |
| virtual bool | is_closed ()=0 |
| Returns if the inputstream is closed or available for further calls of input operations. More... | |
Superclass of all classes representing an input stream of bytes.
Applications that need to define a subclass of InputStream must always provide a method that returns the next byte of input.
|
virtualdefault |
Default virtual destructor.
Needed for correct deletion of instances of a derived classes through a pointer to base class.
|
pure virtual |
Returns an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking by the next invocation of a method for this input stream.
A single read or skip of this many bytes will not block, but may read or skip fewer bytes.
Note that while some implementations of inputstream will return the total number of bytes in the stream, many will not. It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.
A subclass' implementation of this method may choose to throw an IOException if this input stream has been closed by invoking the close() method.
This method should be overridden by subclasses.
Implemented in devfix::base::io::source.
|
pure virtual |
Closes this input stream and releases any system resources associated with the stream.
A closed stream cannot perform input operations and cannot be reopened.
Implemented in devfix::base::io::source.
|
pure virtual |
Returns if the inputstream is closed or available for further calls of input operations.
Implemented in devfix::base::io::source.
|
pure virtual |
Reads bytes from the input stream and stores them into the buffer.
This method blocks until input data is available, end of file is detected, or another error is thrown.
If len is zero, then no bytes are read. If no byte is available because the stream is at end of file, an error is thrown.
The first byte read is stored into element b[0], the next one into b[1], and so on. If no error was thrown, the number of bytes read is always equal to len.
Subclasses are encouraged to provide a more efficient implementation of this method.
| buf | the buffer into which the data is read. |
| len | the maximum number of bytes to read. |
Implemented in devfix::base::io::source.
|
pure virtual |
Skips over and discards n bytes of data from this input stream.
The skip method may, for a variety of reasons, end up skipping over some smaller number of bytes, possibly 0. This may result from any of a number of conditions; reaching end of file before n bytes have been skipped is only one possibility.
| n | the number of bytes to be skipped. |
Implemented in devfix::base::io::source.


I made a emontx v2.2 based on a meduino nano i had laying around, based on the solderpad drawing. This meduino nano is a arduino nano clone you can set on 3.3V of 5V - mine is set to 3.3V to be safe when connecting it via i2c to my raspberry Pi.
I use the 3Phase firmware found here on the forum. In this firmware one has to enter the calibration coefficients.
I bought a ideal power (euro plug) via the shop here. On the calibration page it says that Vcal is 228.268.
But when using this factor, i get measurements of 199 a 200V instead of +-240V.
Should i change these coëfficients or is something else wrong?
Re: Calibration - ideal power voltage adapter
With the voltage wrong by that amount, there may well be a problem somewhere.
Check these things:
1. The d.c. voltage at the input to the ADC. That should be VCC / 2.
2. The voltage from the adapter. That should be about 11 V - 11.5 V with an input of 240 V.
3. The alternating voltage at the input to the ADC. This is best measured across the 10 kΩ resistor that forms the bottom half of the potential divider. That should be one eleventh of the adapter voltage.
4. The voltage of the internal reference. To do this you need to load a test sketch. The Building Blocks "Calibration" article has all the information you need.
5. The accuracy of your meter on the ranges you used.
This should show you where the error has arisen.
There are several articles in Building Blocks about calibration and measurement errors. These should help you to calculate the correct calibration coefficient if the components you used are not the correct values, but if you are sure there is no fault, then by all means change the calibration coefficient to give you the correct reading.
Re: Calibration - ideal power voltage adapter
I checked those things and i also found a bad connection on my pcb :-s
I get these measuremenst:
1: DC: 2.26V
2: voltage adapter: 11.1V with mains power at this moment 223V
3: AC voltage over 10kOhm: 1V (seems ok, this is +- 1/11th of 11.1V)
for nr 4: the "5V" is actually 4.57V (getting power from usb from the Pi) / the "3.3V" measures 3.32V. Arduino says that VCC is 3.21V
With this i get get voltage reading in the range 206-209V (mains 223V - the 238 from last night must have been a peek?)
What i am uncertain about is the VCC i used: now i connected everything (CTs and powersensor) to the "5V". But now i notice on the solderpad that VCC= 3.3V. Did i connect it wrong? On my meduino i have the 2 voltages available: "3.3V" and "5V"
Re: Calibration - ideal power voltage adapter
I don't know the Meduino, so I can't comment about that. The 5V from the RPi is out of specification, so maybe you are drawing too much current from it? I don't know what you are allowed, but the data sheets should tell you.
You can run the Atmel 328P at any voltage up to (I think - check the data sheet) 6 V. We choose to run the emonTx at 3.3 V mainly because that simplifies the interface to the RFM12B radio module and makes battery operation from two 1.5 V cells easy.
It also looks as if you have got your inputs mixed up and you have not followed the emonTx circuit exactly. The d.c voltage at the ADC input should be 1.65 V if it is reporting that the supply is 3.3 V (approx - you say it says 3.21 but that is a calibration issue). If you wish, you can run calypso-rae's sketch RawSamplesTool_4ss_2 (http://openenergymonitor.org/emon/node/1757) which should draw the voltage waveform. If the waveforms are offset from the centre and the voltage clips on the positive peak, that is a sure indication that the input circuit is wrong.
I suggest you check the input circuit carefully and then go through the calibration procedure. The standard emonLib library methods measure the ADC voltage reference with respect to the internal band-gap reference, so the feed from the RPi being low should be corrected in the software.
Re: Calibration - ideal power voltage adapter
Found the problem thanks to your help: i was running the atmega at 3.3V but was using the 5V(4.x V) for the sensors.
When i switched to 3.3V for the sensors, the voltage reading was spot on: less than 1V difference with my handheld multimeter.


Grace Brewster Murray Hopper (née Murray; December 9, 1906 – January 1, 1992) was an American computer scientist and United States Navy rear admiral.[1] One of the first programmers of the Harvard Mark I computer, she was a pioneer of computer programming who invented one of the first compiler related tools. She popularized the idea of machine-independent programming languages, which led to the development of COBOL, an early high-level programming language still in use today.
Hopper had attempted to enlist in the Navy during World War II, but she was rejected by the military because she was 34 years of age and thus too old to enlist. She instead joined the Navy Reserves. Hopper began her computing career when she worked on the Harvard Mark I team that was led by Howard H. Aiken. In 1949, she joined the Eckert–Mauchly Computer Corporation and was part of the development team that designed the UNIVAC I computer in 1944. It was at Eckert–Mauchly that she began developing the compiler. She believed that computer code could be written in English by using a programming language that was based on English words. The compiler would convert that code into machine code that would be understood by computers. By 1952, Hopper finished her program linker (originally called a compiler), which was written for the A-0 System.[2][3][4][5]
In 1954, Eckert–Mauchly chose Hopper to lead their department for automatic programming, and she led the release of some of the first compiled languages like FLOW-MATIC. In 1959, she participated in the CODASYL consortium, which consulted Hopper to guide them in creating a machine-independent programming language. This led to the COBOL language, which was inspired by her idea of a language being based on English words. In 1966, she retired from the Naval Reserve, but in 1967, the Navy recalled her to active duty. She retired from the Navy in 1986 and found work as a consultant for the Digital Equipment Corporation, sharing her computing experiences.
Owing to her accomplishments and her naval rank, she was sometimes referred to as "Amazing Grace".[6][7] The U.S. Navy Arleigh Burke-class guided-missile destroyer USS Hopper was named for her, as was the Cray XE6 "Hopper" supercomputer at NERSC.[8] During her lifetime, Hopper was awarded 40 honorary degrees from universities across the world. A college at Yale University is named in her honor. In 1991, she received the National Medal of Technology. On November 22, 2016, she was posthumously awarded the Presidential Medal of Freedom by President Barack Obama.[9]
"Humans are allergic to change. They love to say, 'We've always done it this way.' I try to fight that. That's why I have a clock on my wall that runs counter-clockwise."See more
Grace Murray Hopper Rear Admiral Grace M. Hopper, 1984
Nickname(s) "Amazing Grace" Born December 9, 1906 Allegiance United States of America


Hashes
This module does not have a toplevel documentation block.
module Hash
This module does not have a toplevel documentation block.
type hash
let createHash: string => hash
let updateWithString: (hash, string) => unit
module LegacyMd5
This module does not have a toplevel documentation block.


Listeners: 125
00:00 / 00:00
HIJACK. is hosting an end of the year event on Friday, December 20th to commemorate the first year of the event, and it's promising to be our biggest one yet. Get your alcohol ready, grab you're waifu pillow, and be sure to tune in!
Also check the previous news post for holiday stream information.
It's about that time of year again. Christmas and New Years party time soon. Check the full post for details.
The schedule is still being fleshed out, check back every few days for potential updates.
UPDATED FOR NYE TIMES
Post updated for December's Hijack


Show create form...
Hide create form...
Create a post
Category:
General
Politics
Sports
Archived?:
Event date:
Duration:
Launched?:
News
Event
Create News
Create Event
Filter by feed type:
All
News
Events


Lorem the It is a long established fact that a reader will be distracted by the readable content of a page when looking at its layout. The point of using Lorem Ipsum is that it has a more-or-less normal distribution of letters, as opposed to using 'Content here, content here', making it look like readable English.
Our you can use the grid system with 2 columns like this;
Our you can use the grid system with 3 columns like this;


Elections entitles citizens to choose their President. Democracy means government for the people and by the people. During the 2016 November presidential elections, public views towards the future leader fluctuated quickly as interviews, response to world events and other issues were addressed by the top election candidates like Donald Trump, Hillary Clinton, Bernie Sanders and Ben Carson. Twitter provides us with access to views about the elections across the globe. We analyzed recent tweets regarding the top candidates in 2016 presidential elections and tried to predict public’s sentiments towards each candidate and opinions and emotions towards the elections.
We focused on tweets with reference to the presidential elections and its candidates. We downloaded over 900,000 tweets based off recent tweets and assessed the sentiments. Our Keywords were “Donald Trump”, “Hillary Clinton”, “Politics”, “elections”, “political candidates”, etc.
Data Source: Using Python and Twitter API, we built a crawler that downloaded the tweets.
Process Text: Our project analyzed the feelings of Twitter’s younger, tech-savvy audience. The tweets sometimes contained words like “be”, “at”, “the” etc. that do not express any sentiment. So, we had to linguistically process the data.
Data Analysis: MongoDB and R programming was used to analyze the Twitter Data.
Analysis of Maps: Using the entry for latitude - longitude coordinates and user-inputted locations, we showed the concentration of tweets from each city relative to the total number of tweets we have about each candidate.


Help System
Menu for the XCL12 Package
Menu for the XCL12 Package
- calwfp
- Run the WF/PC calibration code on an input image.
- checkwfpc
- Perform consistency checks on a WF/PC reference file.
- combine
- Combine images using various algorithms & pixel rejection schemes
- crrej
- Combine images to make a cosmic ray free image
- dqfpar
@ Select DQF error flags (pset).
- engextr
- Extract info. from WF/PC engineering data (.X0H and .X0D) files
- metric
- Translate WFPC pixel coordinates to RA & Dec with geometric
- noisemodel
- Determine noise model parameters from CCD frames.
- noisepar
@ Set parameters describing noise model (pset).
- pixcoord
- Compute pixel coordinates of stars in an image.
- qwmosaic
- Quick mosaic of the four WFPC frames into one image.
- seam
- Smooth the boundaries between mosaicked WFPC frames.
- u_calib
+ Tasks for deriving the WFPC-2 instrument calibration.
- w_calib
+ Tasks for deriving the WFPC instrument calibration.
- wfixup
- Interpolate over bad columns in a WFPC frame.
- wmosaic
- Mosaic the four WFPC frames into one image
- wstatistics
- Compute & print WFPC image pixel statistics.
- (Type
"help wfpc option=sysdoc" for detailed information about the `wfpc'


The internet is one of the greatest technologies ever to be created.The Internet (or internet) is the global system of interconnected computer networks that uses the Internet protocol suite (TCP/IP) to communicate between networks and devices. It is a network of networks that consists of private, public, academic, business, and government networks of local to global scope, linked by a broad array of electronic, wireless, and optical networking technologies.
In 1998 it was responsible for 1/3 total of the US economic growth.
More email is exchanged over the internet than 1st class mail delivered by the post office.
There are approximately 5.6 Billion searches on Google alone per day.
Learn more


The SBLIM CIM Client for Java has a broad set of configuration options that influence the runtime behavior of the client.
The SBLIM CIM Client for Java can be configured by a configuration file which follows the Java properties approach. So,
key=value
entries can be used to define values for the many available properties.
The file name of the configuration file is sblim-cim-client2.properties
. The client searches by default
these directories in the given order:
/etc/java
If the file is found once, the search stops and that file is used as input. So it is not possible to use two configuration files in parallel. If properties are not defined in the used configuration file, the default values are taken.
The user may override the default search location by specifying the JVM system property sblim.wbem.configURL
:
javaw -jar myapp.jar -Dsblim.wbem.configURL=file:/root/myproperties
System.setProperty(WBEMConfigurationProperties.CONFIG_URL, "file:/root/myproperties");
WBEMConfiguration
class will load the configuration
file in its static initializer and any change of the property afterwards won't have any effect.Note that sblim.wbem.configURL
contains a URL, so you're not restricted to a local file but can load the properties file
from an HTTP server or some other remote location.
The configuration file contains documentation and declarations of all recognized configuration properties. The declarations are commented out by default. To change a property delete the leading # from the declaration and set the appropriate value. Here is an example:
# Specifies the XML parser for parsing CIM-XML responses. # The SAX parser is the default choice since it is fast, resource saving # and interoperable. The streaming algorithm of the PULL parser uses the # fewest possible resources but at the prize to keep the CIMOMs response # open for a long time. That works with many but not all CIMOMs. The DOM # parser is slow and resource hungry but nice to debug. # # Type: Discrete # Recognition: Anytime # Range: DOM, PULL, SAX # Default: SAX # sblim.wbem.cimxmlParser=PULL
The sample will use the value PULL
for the property sblim.wbem.cimxmlParser
. The lines starting
with a #
are comments and will be ignored.
All configuration properties can be set during runtime. The interface
WBEMConfigurationProperties
contains constants for every property together with detailed documentation on each
property.
The global settings have JVM scope. Most properties are set via System.setProperty()
, a few ones via Security.setProperty()
(see
documentation of corresponding properties). The documentation also explains when a property change will be recognized.
The code that loads the configuration file calls System.setProperty()
or Security.setProperty()
as well to engage the
configuration.
When you try to set the settings that have recognition "startup" like sblim.wbem.configURL
or sblim.wbem.logFileLevel
keep in
mind that these settings are evaluated in the static initializers of the internal classes
WBEMConfiguration
or LogAndTraceBroker
.
These classes are referenced by many classes of the CIM Client. Therefore you have to ensure that you set these properties before you reference a
CIM Client class in your code (what will trigger the class loader and thus the static initializers).
It is possible to override the global configuration for an individual
WBEMClient
instance. These settings are shared between all threads using that client instance. In order to do this cast the
WBEMClient
to
WBEMClientSBLIM
and call
setProperty()
. Note that most properties will have no effect if set after the
initialize()
method was called.
It is possible to override the global configuration for an individual
WBEMListener
instance. These settings are shared between all threads using that listener instance. In order to do this cast the
WBEMListener
to
WBEMListenerSBLIM
and call
setProperty()
. Note that most properties will have no effect if set after the
addListener()
method was called. It is also possible to set a listener's properties by creating a new java.util.Properties
object and passing it to the WBEMListenerSBLIM
variant of
addListener()
that accepts properties.
Imagine you've multiple threads using the same client instance concurrently and you want to reconfigure the instance in one thread, but keep the other threads
unaffected. This is what the local settings do. They override the client and global settings, but are recognized by the current thread only. You can set
a local property by casting the WBEMClient
to WBEMClientSBLIM
and
calling
setLocalProperty()
. Local settings are inherited from parent thread to child thread: When the child thread is created it receives the initial values
from its parent thread. Afterwards the local settings of parent and child are completely independent.
The client has four possible layers for any configuration property. They override each other in the following order:
The global settings can be initialized either from a configuration file or via method calls. Client, listener and local settings are initialized via method calls only. The default values are compile time constants and not subject to change.


Members
apiCall
Sends request to the API.
applyVariables
Calls the API with specific query.
changeLanguage
Handles the change of language:
Replaces state.variables
Replaces viewSpecificVariable with translated equivalent
filterHospitals
Determines which Hospitals to pass to MAPS.js according to type & enum filters,
saves the list into filteredHospitals in the state.
filteringOnViewChange
Decides if hospitals habe to be filtered depending on the change of view and the active tab on that view.
getViewSpecificVariable
Determines which selectedVariable of the state to use, depending on the currently selected view.
initApiCall
Initialises the state variables with a call to the API.
setCSVData
Set CSV data
setFilterHospitals
Set given state variable to selected hospitals
setGraphView
Setter for the graphView state variable.
setHospitalsByEnums
Set hospitalsByEnums to the selected Hospital Variable
setHospitalsByType
Set hospitalsByType to selected Hospital Type
setLinRegHospitalsByType
Set LinRegHospitalsByType to selected Hospital Type
setMapView
Setter for the mapView state variable.
setVariable
Sets the state variable selectedVariable to the selected variable from a DropdownMenu Component (or two if lin. reg.),
setView
Setter for the view state variable.
setYear
Setter for the selectedYear state variable.
setYears
Setting state.years to list of available years in given objects for selected Variable
Methods
componentDidMount()
is invoked immediately after the component is mounted
makes intitial API call
render() → {JSX}
render - renders the component to the screen
Returns:
JSX of the component
- Type
- JSX


If possible Web-RTC would be a great protocol to build mmv2 on
MM2 compiled to WASM and wrapped in a WebRTC layer running in Chromium on Raspberry Pi 3, totally can do.
Raspberry Pi 3 [webtcp or ws2s, Chromium [WASM MM2 <-> JS layer implementing WebRTC API]] <-> PC [WebRTC <-> GUI].
Plus WASM version of MM2 might make it easier to embed MM2 in a GUI.
(edited)


{% extends "base.html" %} {% block title %}
create a stakeholder management plan by adding stakeholders, deliverables, and associations between the two.


<EMAIL_ADDRESS>+64 9 923 4715
Mailing Address Private Bag 92019 Auckland Mail Centre Auckland 1142 New Zealand
Courier Address The University of Auckland 1 Grafton Road Auckland 1010 New Zealand


library(dplyr)
library(ggplot2)
library(rrricanes)
library(rrricanesdata)
library(sp)
key <- "AL092008"
adv <- 42
fstadv <- fstadv %>% filter(Key == key, Adv <= adv)
gis_adv <- gis_advisory(key = key, advisory = adv) %>% gis_download()
## OGR data source with driver: ESRI Shapefile
## Source: "/tmp/RtmprMbmxG", layer: "al092008.042_5day_lin"
## with 2 features
## It has 9 fields
## OGR data source with driver: ESRI Shapefile
## Source: "/tmp/RtmprMbmxG", layer: "al092008.042_5day_pgn"
## with 2 features
## It has 9 fields
## OGR data source with driver: ESRI Shapefile
## Source: "/tmp/RtmprMbmxG", layer: "al092008.042_5day_pts"
## with 13 features
## It has 20 fields
## OGR data source with driver: ESRI Shapefile
## Source: "/tmp/RtmprMbmxG", layer: "al092008.042_ww_wwlin"
## with 5 features
## It has 10 fields
Get bounding box of the forecast polygon.
bbox <- bbox(gis_adv$al092008_042_5day_pgn)
Generate a base plot of the Atlantic ocean.
(bp <- al_tracking_chart(color = "black", fill = "white", size = 0.1, res = 50))
## Regions defined for each Polygons
## Regions defined for each Polygons
I like to add a little cushion for the map inset and forecast cone data.
lat_min <- bbox[2,1] - 5
lat_max <- bbox[2,2] + 5
lon_min <- bbox[1,1] - 10
lon_max <- bbox[1,2] + 10
Build a thin tracking map for the inset.
bp_inset <- ggplotGrob(bp +
geom_rect(mapping = aes(xmin = lon_min, xmax = lon_max,
ymin = lat_min, ymax = lat_max),
color = "red", alpha = 0) +
theme_bw() +
theme(axis.title = element_blank(),
axis.ticks = element_blank(),
axis.text.x = element_blank(),
axis.text.y = element_blank(),
plot.margin = margin(0, 0, 0, 0, "pt")))
Modify original bp
zoomed in on our area of interest.
(bp <- bp +
coord_equal(xlim = c(lon_min, lon_max),
ylim = c(lat_min, lat_max)) +
scale_x_continuous(expand = c(0, 0)) +
scale_y_continuous(expand = c(0, 0)) +
labs(x = "Lon",
y = "Lat",
caption = sprintf("rrricanes %s", packageVersion("rrricanes"))))
Combine bp
and bp_inset
to finalize initial base plot. bp
will be a base plot without the inset. bpi
will have the inset.
(bpi <- bp + annotation_custom(grob = bp_inset, xmin = lon_max - 5,
xmax = lon_max - 1, ymin = -Inf,
ymax = lat_min + 5))
Lines and Polygons spatial dataframes can be helpfully converted using shp_to_df
. The original spatial dataframes can be plotted directly in ggplot2
but, to my understanding, access to the other variables are not available.
# Convert object SpatialLinesDataframe to dataframe
shp_storm_lin <- shp_to_df(gis_adv$al092008_042_5day_lin)
shp_storm_ww <- shp_to_df(gis_adv$al092008_042_ww_wwlin)
# Convert object SpatialPolygonsDataframe to dataframe
shp_storm_pgn <- shp_to_df(gis_adv$al092008_042_5day_pgn)
Points dataframes can just be converted with tibble::as_data_frame
.
# Convert object SpatialPointsDataframe to dataframe
shp_storm_pts <- as_data_frame(gis_adv$al092008_042_5day_pts)
Modify shp_storm_pts$DVLBL
with full strings and ordered factor.
shp_storm_pts$DVLBL <- factor(shp_storm_pts$DVLBL,
levels = c("D", "S", "H"),
labels = c("Tropical Depression",
"Tropical Storm",
"Hurricane"))
Same with shp_storm_pts$TCWW
:
shp_storm_ww$TCWW <- factor(shp_storm_ww$TCWW,
levels = c("TWA", "TWR", "HWA", "HWR"),
labels = c("Tropical Storm Watch",
"Tropical Storm Warning",
"Hurricane Watch",
"Hurricane Warning"))
bpi + geom_polygon(data = shp_storm_pgn,
aes(x = long, y = lat, group = group),
alpha = 0.15, fill = "orange") +
geom_path(data = shp_storm_lin, aes(x = long, y = lat, group = group)) +
geom_point(data = shp_storm_pts, aes(x = LON, y = LAT, fill = DVLBL,
shape = DVLBL, size = MAXWIND)) +
geom_path(data = shp_storm_ww, aes(x = long, y = lat, color = TCWW,
group = group), size = 1) +
scale_shape_manual(values = c(21, 21, 21, 21)) +
guides(shape = guide_legend(override.aes = list(size = 3)),
size = guide_legend(nrow = 1)) +
theme(legend.position = "bottom",
legend.box = "vertical")
Very often, areas that are under a hurricane watch may also be under a tropical storm warning. The chart above does not show the hurricane watch area.


Plug v1.4.3 Plug.Crypto.MessageEncryptor View Source
MessageEncryptor
is a simple way to encrypt values which get stored
somewhere you don’t trust.
The encrypted key, initialization vector, cipher text, and cipher tag are base64url encoded and returned to you.
This can be used in situations similar to the Plug.Crypto.MessageVerifier
, but where
you don’t want users to be able to determine the value of the payload.
Example
secret_key_base = "072d1e0157c008193fe48a670cce031faa4e..."
encrypted_cookie_salt = "encrypted cookie"
encrypted_signed_cookie_salt = "signed encrypted cookie"
secret = KeyGenerator.generate(secret_key_base, encrypted_cookie_salt)
sign_secret = KeyGenerator.generate(secret_key_base, encrypted_signed_cookie_salt)
data = "José"
encrypted = MessageEncryptor.encrypt(data, secret, sign_secret)
decrypted = MessageEncryptor.decrypt(encrypted, secret, sign_secret)
decrypted # => {:ok, "José"}
Link to this section Summary
Link to this section Functions
Decrypts a message using authenticated encryption.
Encrypts a message using authenticated encryption.
WARNING: This function is deprecated in favor of encrypt/3
.
Encrypts and signs a message.
WARNING: This function is deprecated in favor of decrypt/3
.
Decrypts and verifies a message.
We need to verify the message in order to avoid padding attacks. Reference: http://www.limited-entropy.com/padding-oracle-attacks


Thank you for purchasing RGDMURL. As the owner of this cl1p you have access to features that normal cl1ps do not have.
NOTE: to complete this transaction you must click the following link to log into or create a cl1p account.
To access these features you must be logged into your cl1p account.
Thanks again for buying a cl1p!
Rob Mayhew


subject = "{{ subject }}" == A new booking has been made ! Get all the details about that booking : Full name : {{ booking.full_name }} ==
Full name : {{ booking.full_name }}


Nepalwildlife package brings together a list of wild animals and plants found in Nepal. It contains 1 tibble named nepal_wildlife
.
You can install the released version of Nepalwildlife from Github with:
install.packages("devtools")
devtools::install("abhinabkadel/Nepalwildlife")
How many species fall under different taxonomic groups in Nepal? Let’s solve it using the dataset:
library(Nepalwildlife)
library(tidyverse)
nepal_wildlife %>%
count (`Taxonomic Group`)
#> # A tibble: 8 x 2
#> `Taxonomic Group` n
#> <chr> <int>
#> 1 Amphibians 58
#> 2 Birds 852
#> 3 Butterflies 26
#> 4 Conifers 23
#> 5 Mammals 217
#> 6 Reptiles 44
#> 7 Sphingid moths 174
#> 8 Turtles (non-marine) 15
library(devtools)
create_package(pathname/Nepalwildlife)
. This created a folder named Nepalwildlife with skeleton for the package contents such as DESCRIPTION and an R project file.library(usethis)
use_data_raw()
nepal_wildlife.R
in the folder, which converts the csv to a tibble in the .R file.
usethis::use_data()
at the bottom of this R script to create a .rda data object in the data folder"nepal_wildlife"
@export
tag because I am not creating any function and it was advised in class not to do so.document()
use_testthat()
to create a tests folder in the root directoryuse_test("nepal_wildlife")
creates an R file with my tests in it.expect_
statements to check if:
test()
usethis::use_mit_license("Abhinab Kadel")
use_package()
. The following packages are listed under the @import option:
use_readme_rmd( )
and build it using build_readme( )
.use_vignette("nepal_wildlife")
and build it using build_vignette()
.Nepalwildlife
usethis::use_code_of_conduct()
to create a code of conduct text. Then, paste it to the README file (see below)use_news_md()
usethis::use_version()
and select minor increment to set the package version to 0.1.0
usethis::use_pkgdown()
pkgdown::build_site()
Please note that the Nepalwildlife project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.


Create Your Account
Sign up to get started
Create Account
Cancel
or
Already have an account?
Login Now
Go Back


| DOSE: |
9.0 mg |
smoked |
5-MeO-DMT |
(powder / crystals) |
About a week ago i discoverd a variety of legal drugs. First i bought some fly agaric mushrooms. After they came in and i ate about 7g and i have to say i was very dissapointed, it just gave me a small body high similar to what a small amount of hash would give me so i decided to sell the rest of my stash to the dumbasses around town for like $20.00 a bag.
Then an old hippie friend of mine said something about how nothing is as trippy as 5MEO-DMT. I did a lot of research on this drug and then acquired some. inside the envelope was a small zip lock bag labeled 5MEO-DMT and it had a small amount of yellowish crystal/powder in it. immediately after its arrival me and the son of the old hippie dude went to another friends apartment to test it out. I went first since it was mine and i put a very small amount on some tin foil and smoked it like dope. It broke down into a liquid like meth does also, but the first hit just made me feel kind of weird and my heart started beating fast.
 I smoked this just like i did before and as i inhaled the smoke i was already feeling fuzzy and everything was distorted. i held in the hit for about 20-25 seconds and upon exhaling i was tripping so hard i didnt even know what tripping was any more. My sitters said that when i exhaled my eyes got glossy and crossed and i fell back onto the couch. i had no idea what was going on or even what i was.
The best way i can describe it is that my entire universe was compressed into an infinatly small piece of matter and suddenly it exploded like the big bang or something. I was the universe, I was everywhere and nowhere, everything and nothing all at the same time. The trip must have lasted for at least an hour in my head but when i came to and knew what was going on only 4 or 5 minutes had passed. After i came to i was still tripping for a good 30-45 minutes.
All in all i think this is a very fun drug.
Cheers, B-rabbit
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


My name is Francisco Sencion and I am a self-taught Network Engineer & Software developer that's passionate about technology in general. I am interested in being part of an organization with a culture built around their customers and employees. Below are some of my career interests:
A network automation and configuration management web application to help manage configurations and automate network related tasks.
AutoNetWeb uses Bootstrap4 for a mobile-first layout, with JavaScript for page manipulation. On the backend it uses Django & Python to handle user inputs and interact with the database and network devices.
I am available for hire, please reach out if you have any opportunities available.


Interface ScenarioMarketData
-
- All Known Implementing Classes:
BuiltScenarioMarketData
,ImmutableScenarioMarketData
public interface ScenarioMarketData
Provides access to market data across one or more scenarios.Market data is looked up using subclasses of
MarketDataId
. All data is valid for a single date, defined bygetValuationDate()
.There are two ways to access the available market data.
The first way is to use the access methods on this interface that return the data associated with a single identifier for all scenarios. The two key methods are
getValue(MarketDataId)
andgetScenarioValue(ScenarioMarketDataId)
.The second way is to use the method
scenarios()
orscenario(int)
. These return all the data associated with a single scenario. This approach is convenient for single scenario pricers.The standard implementation is
ImmutableScenarioMarketData
.
-
-
Method Summary
All Methods Static Methods Instance Methods Abstract Methods Default Methods Modifier and Type Method Description default ScenarioMarketData
combinedWith(ScenarioMarketData other)
Returns set of market data which combines the data from this set of data with another set.default boolean
containsValue(MarketDataId<?> id)
Checks if this market data contains a value for the specified identifier.static ScenarioMarketData
empty()
Obtains a market data instance that contains no data and has no scenarios.<T> Set<MarketDataId<T>>
findIds(MarketDataName<T> name)
Finds the market data identifiers associated with the specified name.<T> Optional<MarketDataBox<T>>
findValue(MarketDataId<T> id)
Finds the market data value associated with the specified identifier.Set<MarketDataId<?>>
getIds()
Gets the market data identifiers.int
getScenarioCount()
Gets the number of scenarios.default <T,U extends ScenarioArray<T>>
UgetScenarioValue(ScenarioMarketDataId<T,U> id)
Gets an object containing market data for multiple scenarios.LocalDateDoubleTimeSeries
getTimeSeries(ObservableId id)
Gets the time-series associated with the specified identifier, empty if not found.Set<ObservableId>
getTimeSeriesIds()
Gets the time-series identifiers.MarketDataBox<LocalDate>
getValuationDate()
Gets a box that can provide the valuation date of each scenario.default <T> MarketDataBox<T>
getValue(MarketDataId<T> id)
Gets the market data value associated with the specified identifier.static ScenarioMarketData
of(int scenarioCount, MarketData marketData)
Obtains an instance by wrapping a single set of market data.static ScenarioMarketData
of(int scenarioCount, MarketDataBox<LocalDate> valuationDate, Map<? extends MarketDataId<?>,MarketDataBox<?>> values, Map<? extends ObservableId,LocalDateDoubleTimeSeries> timeSeries)
Obtains an instance from a valuation date, map of values and time-series.static ScenarioMarketData
of(int scenarioCount, LocalDate valuationDate, Map<? extends MarketDataId<?>,MarketDataBox<?>> values, Map<? extends ObservableId,LocalDateDoubleTimeSeries> timeSeries)
Obtains an instance from a valuation date, map of values and time-series.default MarketData
scenario(int scenarioIndex)
Returns market data for a single scenario.default Stream<MarketData>
scenarios()
Returns a stream of market data, one for each scenario.default <T> ScenarioMarketData
withPerturbation(MarketDataId<T> id, ScenarioPerturbation<T> perturbation, ReferenceData refData)
Returns a copy of this market data with the specified value perturbed.default <T> ScenarioMarketData
withValue(MarketDataId<T> id, MarketDataBox<T> value)
Returns a copy of this market data with the specified value.
-
-
-
Method Detail
-
of
static ScenarioMarketData of(int scenarioCount, LocalDate valuationDate, Map<? extends MarketDataId<?>,MarketDataBox<?>> values, Map<? extends ObservableId,LocalDateDoubleTimeSeries> timeSeries)
Obtains an instance from a valuation date, map of values and time-series.The valuation date and map of values must have the same number of scenarios.
- Parameters:
scenarioCount
- the number of scenariosvaluationDate
- the valuation dates associated with all scenariosvalues
- the market data values, one for each scenariotimeSeries
- the time-series- Returns:
- a set of market data containing the values in the map
-
of
static ScenarioMarketData of(int scenarioCount, MarketDataBox<LocalDate> valuationDate, Map<? extends MarketDataId<?>,MarketDataBox<?>> values, Map<? extends ObservableId,LocalDateDoubleTimeSeries> timeSeries)
Obtains an instance from a valuation date, map of values and time-series.The valuation date and map of values must have the same number of scenarios.
- Parameters:
scenarioCount
- the number of scenariosvaluationDate
- the valuation dates associated with the market data, one for each scenariovalues
- the market data values, one for each scenariotimeSeries
- the time-series- Returns:
- a set of market data containing the values in the map
-
of
static ScenarioMarketData of(int scenarioCount, MarketData marketData)
Obtains an instance by wrapping a single set of market data.The result will consist of a
ScenarioMarketData
that returns the specified market data for each scenario.This can be used in association with the
withPerturbation
method to take a base set of market data and create a complete set of perturbations. SeeMarketDataFactory
for the ability to apply multiple perturbations, including perturbations to calibration inputs, such as quotes.- Parameters:
scenarioCount
- the number of scenarios, one or moremarketData
- the single set of market data- Returns:
- a set of market data containing the values in the map
-
empty
static ScenarioMarketData empty()
Obtains a market data instance that contains no data and has no scenarios.- Returns:
- an empty instance
-
getValuationDate
MarketDataBox<LocalDate> getValuationDate()
Gets a box that can provide the valuation date of each scenario.- Returns:
- the valuation dates of the scenarios
-
getScenarioCount
int getScenarioCount()
Gets the number of scenarios.- Returns:
- the number of scenarios
-
scenarios
default Stream<MarketData> scenarios()
Returns a stream of market data, one for each scenario.The stream will return instances of
MarketData
, where each represents a single scenario view of the complete set of data.- Returns:
- the stream of market data, one for the each scenario
- Throws:
IndexOutOfBoundsException
- if the index is invalid
-
scenario
default MarketData scenario(int scenarioIndex)
Returns market data for a single scenario.This returns a view of the market data for the single specified scenario.
- Parameters:
scenarioIndex
- the scenario index- Returns:
- the market data for the specified scenario
- Throws:
IndexOutOfBoundsException
- if the index is invalid
-
containsValue
default boolean containsValue(MarketDataId<?> id)
Checks if this market data contains a value for the specified identifier.- Parameters:
id
- the identifier to find- Returns:
- true if the market data contains a value for the identifier
-
getValue
default <T> MarketDataBox<T> getValue(MarketDataId<T> id)
Gets the market data value associated with the specified identifier.The result is a box that provides data for all scenarios. If this market data instance contains the identifier, the value will be returned. Otherwise, an exception will be thrown.
- Type Parameters:
T
- the type of the market data value- Parameters:
id
- the identifier to find- Returns:
- the market data value box providing data for all scenarios
- Throws:
MarketDataNotFoundException
- if the identifier is not found
-
findValue
<T> Optional<MarketDataBox<T>> findValue(MarketDataId<T> id)
Finds the market data value associated with the specified identifier.The result is a box that provides data for all scenarios. If this market data instance contains the identifier, the value will be returned. Otherwise, an empty optional will be returned.
- Type Parameters:
T
- the type of the market data value- Parameters:
id
- the identifier to find- Returns:
- the market data value box providing data for all scenarios, empty if not found
-
getIds
Set<MarketDataId<?>> getIds()
Gets the market data identifiers.- Returns:
- the set of market data identifiers
-
findIds
<T> Set<MarketDataId<T>> findIds(MarketDataName<T> name)
Finds the market data identifiers associated with the specified name.This returns the unique identifiers that refer to the specified name. There may be more than one identifier associated with a name as the name is not unique.
- Type Parameters:
T
- the type of the market data value- Parameters:
name
- the name to find- Returns:
- the set of market data identifiers, empty if name not found
-
getScenarioValue
default <T,U extends ScenarioArray<T>> U getScenarioValue(ScenarioMarketDataId<T,U> id)
Gets an object containing market data for multiple scenarios.There are many possible ways to store scenario market data for a data type. For example, if the single values are doubles, the scenario value might simply be a
List<Double>
or it might be a wrapper class that stores the values more efficiently in adouble[]
.If the market data contains a single value for the identifier or a scenario value of the wrong type, a value of the required type is created by invoking
ScenarioMarketDataId.createScenarioValue(com.opengamma.strata.data.scenario.MarketDataBox<T>, int)
.Normally this should not be necessary. It is assumed the required scenario values will be created by the perturbations that create scenario data. However there is no mechanism in the market data system to guarantee that scenario values of a particular type are available. If they are not they are created on demand.
Values returned from this method might be cached for efficiency.
- Type Parameters:
T
- the type of the individual market data values used when performing calculations for one scenarioU
- the type of the object containing the market data for all scenarios- Parameters:
id
- the identifier to find- Returns:
- an object containing market data for multiple scenarios
- Throws:
IllegalArgumentException
- if no value is found
-
combinedWith
default ScenarioMarketData combinedWith(ScenarioMarketData other)
Returns set of market data which combines the data from this set of data with another set.If the same item of data is available in both sets, it will be taken from this set.
Both sets of data must contain the same number of scenarios, or one of them must have one scenario. If one of the sets of data has one scenario, the combined set will have the scenario count of the other set.
- Parameters:
other
- another set of market data- Returns:
- a set of market data combining the data in this set with the data in the other
-
getTimeSeriesIds
Set<ObservableId> getTimeSeriesIds()
Gets the time-series identifiers.Time series are not affected by scenarios, therefore there is a single time-series for each identifier which is shared between all scenarios.
- Returns:
- the set of observable identifiers
-
getTimeSeries
LocalDateDoubleTimeSeries getTimeSeries(ObservableId id)
Gets the time-series associated with the specified identifier, empty if not found.Time series are not affected by scenarios, therefore there is a single time-series for each identifier which is shared between all scenarios.
- Parameters:
id
- the identifier to find- Returns:
- the time-series, empty if no time-series found
-
withValue
default <T> ScenarioMarketData withValue(MarketDataId<T> id, MarketDataBox<T> value)
Returns a copy of this market data with the specified value.When the result is queried for the specified identifier, the specified value will be returned.
The number of scenarios in the box must match this market data.
For example, this method could be used to replace a curve with a bumped curve.
- Type Parameters:
T
- the type of the market data value- Parameters:
id
- the identifiervalue
- the value to associate with the identifier- Returns:
- the derived market data with the specified identifier and value
- Throws:
IllegalArgumentException
- if the scenario count does not match
-
withPerturbation
default <T> ScenarioMarketData withPerturbation(MarketDataId<T> id, ScenarioPerturbation<T> perturbation, ReferenceData refData)
Returns a copy of this market data with the specified value perturbed.This finds the market data value using the identifier, throwing an exception if not found. It then perturbs the value and returns a new instance containing the value.
The number of scenarios of the perturbation must match this market data.
This method is intended for one off perturbations of calibrated market data, such as curves. See
MarketDataFactory
for the ability to apply multiple perturbations, including perturbations to calibration inputs, such as quotes.This instance is immutable and unaffected by this method call.
- Type Parameters:
T
- the type of the market data value- Parameters:
id
- the identifier to perturbperturbation
- the perturbation to applyrefData
- the reference data- Returns:
- a parameterized data instance based on this with the specified perturbation applied
- Throws:
IllegalArgumentException
- if the scenario count does not matchMarketDataNotFoundException
- if the identifier is not foundRuntimeException
- if unable to perform the perturbation
-
-


Services
Below are listed some of the services I offer. If you don’t see the one you’re looking for please get in touch, I love accommodating special requests to make your occasion special.
-
${
services
.map(service => `
- ${service.name} `) .join('\n') }