text:
# Upgrading ddtrace

# From 0.x to 1.0

Upgrading `ddtrace` from 0.x to 1.x introduces some breaking changes which are outlined below.

**How to upgrade basic usage**

For users with a basic implementation (configuration file + out-of-the-box instrumentation), only minor changes to your configuration file are required: most applications take just minutes to update. Check out the following sections for a step-by-step guide.

- [Configuration](#1.0-configuration)
  - [`require` paths have changed](#1.0-configuration-requires)
  - [Settings have been renamed](#1.0-configuration-settings)
  - [Activating instrumentation](#1.0-configuration-instrumentation)
- [Instrumentation](#1.0-instrumentation)
  - [Service naming](#1.0-instrumentation-service-naming)

**Additional upgrades for advanced usage**

For users with an advanced implementation of `ddtrace` (custom instrumentation, sampling or processing behavior, etc), some additional namespace and behavioral changes may be required. See the following sections for details about what features changed and how to use them.

- [Namespacing](#1.0-namespacing)
- [Trace API](#1.0-trace-api)
  - [Removed `Datadog.tracer`](#1.0-trace-api-removed-tracer)
  - [Removed access to `Datadog::Context`](#1.0-trace-api-removed-context)
  - [Manual tracing & trace model](#1.0-trace-api-manual-tracing)
  - [Accessing trace state](#1.0-trace-api-trace-state)
  - [Distributed tracing](#1.0-trace-api-distributed)
    - [Over HTTP](#1.0-trace-api-distributed-http)
    - [Over gRPC](#1.0-trace-api-distributed-grpc)
    - [Between threads](#1.0-trace-api-distributed-threads)
  - [Sampling](#1.0-trace-api-sampling)
  - [Processing pipeline](#1.0-trace-api-pipeline)

**Appendix**

For a comprehensive list of everything that changed, the appendix hosts some helpful and detailed tables with recommendations.

  - [Namespace mappings](#1.0-appendix-namespace)
    - [Constants](#1.0-appendix-namespace-constants)
  - [Breaking changes](#1.0-appendix-breaking-changes)

Upgrading basic usage

Configuration

`require` paths have changed

If you `require` any of the following paths, update them accordingly:

| 0.x `require` path          | 1.0 `require` path          |
|-----------------------------|-----------------------------|
| `ddtrace/opentelemetry`     | Removed                     |
| `ddtrace/opentracer`        | `datadog/opentracer`        |
| `ddtrace/profiling/preload` | `datadog/profiling/preload` |

Using `require 'ddtrace'` will load all features by default. To load individual features, you may use the following paths instead:

| Feature     | 1.0 `require` path   |
|-------------|----------------------|
| AppSec      | `datadog/appsec`     |
| CI          | `datadog/ci`         |
| OpenTracing | `datadog/opentracer` |
| Profiling   | `datadog/profiling`  |
| Tracing     | `datadog/tracing`    |

Settings have been renamed

Configuration settings have been sorted into smaller configuration groups, by feature.

 - `Datadog.configure { |c| c.* }`: Datadog configuration settings
 - `Datadog.configure { |c| c.tracing.* }`: Tracing configuration settings
 - `Datadog.configure { |c| c.profiling.* }`: Profiling configuration settings
 - `Datadog.configure { |c| c.ci.* }`: CI configuration settings

For existing applications, configuration files should be updated accordingly. For example:

```ruby
# config/initializers/datadog.rb
require 'ddtrace'

### Old 0.x ###
Datadog.configure do |c|
  # Global settings
  c.tracer.hostname = '<IP_ADDRESS>'
  c.tracer.port = 8126
  c.runtime_metrics_enabled = true
  c.service = 'billing-api'

  # Tracing settings
  c.analytics.enabled = true
  c.tracer.partial_flush.enabled = true

  # CI settings
  c.ci_mode = (ENV['DD_ENV'] == 'ci')

  # Instrumentation
  c.use :rails
  c.use :redis, service_name: 'billing-redis'
  c.use :rspec
end

### New 1.0 ###
Datadog.configure do |c|
  # Global settings
  c.agent.host = '<IP_ADDRESS>'
  c.agent.port = 8126
  c.runtime_metrics.enabled = true
  c.service = 'billing-api'

  # Tracing settings
  c.tracing.analytics.enabled = true
  c.tracing.partial_flush.enabled = true

  # CI settings
  c.ci.enabled = (ENV['DD_ENV'] == 'ci')

  # Instrumentation
  c.tracing.instrument :rails
  c.tracing.instrument :redis, service_name: 'billing-redis'
  c.ci.instrument :rspec
end
```

Check out the table below for a list of common mappings:

| 0.x setting                            | 1.0 setting                     |
|----------------------------------------|---------------------------------|
| `analytics.enabled`                    | `tracing.analytics.enabled`     |
| `ci_mode.context_flush`                | `ci.context_flush`              |
| `ci_mode.enabled`                      | `ci.enabled`                    |
| `ci_mode.writer_options`               | `ci.writer_options`             |
| `distributed_tracing`                  | `tracing.distributed_tracing`   |
| `logger=`                              | `logger.instance=`              |
| `profiling.exporter.transport_options` | Removed                         |
| `report_hostname`                      | `tracing.report_hostname`       |
| `runtime_metrics_enabled`              | `runtime_metrics.enabled`       |
| `runtime_metrics(options)`             | Removed                         |
| `sampling`                             | `tracing.sampling`              |
| `test_mode`                            | `tracing.test_mode`             |
| `tracer=`                              | Removed                         |
| `tracer.debug`                         | `diagnostics.debug`             |
| `tracer.enabled`                       | `tracing.enabled`               |
| `tracer.env`                           | `env`                           |
| `tracer.hostname`                      | `agent.host`                    |
| `tracer.instance`                      | `tracing.instance`              |
| `tracer.log`                           | `logger.instance`               |
| `tracer.partial_flush`                 | `tracing.partial_flush.enabled` |
| `tracer.port`                          | `agent.port`                    |
| `tracer.sampler`                       | `tracing.sampler`               |
| `tracer.tags`                          | `tags`                          |
| `tracer.transport_options`             | `tracing.transport_options`     |
| `tracer.transport_options(options)`    | Removed                         |
| `tracer.writer`                        | `tracing.writer`                |
| `tracer.writer_options`                | `tracing.writer_options`        |
| `use`                                  | `tracing.instrument`            |

Activating instrumentation

 - The `use` function has been renamed to `instrument`.
 - `instrument` has been namespaced within the feature to which it belongs.

As an example:

```ruby
### Old 0.x ###
Datadog.configure do |c|
  # Tracing instrumentation
  c.use :rails

  # CI instrumentation
  c.use :cucumber
end

### New 1.0 ###
Datadog.configure do |c|
  # Tracing instrumentation
  c.tracing.instrument :rails

  # CI instrumentation
  c.ci.instrument :cucumber
end
```

Similarly, if you were accessing configuration for instrumentation, you will need to use the appropriate namespace:

```ruby
### Old 0.x ###
Datadog.configuration[:rails][:service_name]
Datadog.configuration[:cucumber][:service_name]

### New 1.0 ###
Datadog.configuration.tracing[:rails][:service_name]
Datadog.configuration.ci[:cucumber][:service_name]
```

Instrumentation

Service naming

**Define an application service name**

We recommend setting the application's service name with `DD_SERVICE`, or by adding the following configuration:

```ruby
Datadog.configure do |c|
  c.service = 'billing-api' # Or DD_SERVICE. Defaults to process name.
end
```

If this is not set, it will default to the process name.

**Update service names for your integrations**

Spans now inherit the global `service` name by default, unless otherwise explicitly set. This means, generally speaking, spans generated by Datadog integrations will default to the global `service` name, unless the `service_name` setting is configured for that integration.

Spans that describe external services (e.g. `mysql`) will continue to default to some other name that describes the external service instead. (e.g. `mysql`)

```ruby
### Old 0.x ###
Datadog.configure do |c|
  # Instrumentation that measures internal behavior
  c.use :rails, service_name: 'billing-api'
  c.use :resque, service_name: 'billing-api'
  c.use :sidekiq, service_name: 'billing-api'

  # Instrumentation that measures external services
  c.use :active_record, service_name: 'billing-api_mysql' # Defaults to DB type e.g. mysql
  c.use :http, service_name: 'billing-api_http' # Defaults to net/http
  c.use :redis, service_name: 'billing-api_redis' # Defaults to redis
end

### New 1.0 ###
Datadog.configure do |c|
  c.service = 'billing-api'

  # Instrumentation that measures internal behavior
  # now inherits the application's service name.
  c.tracing.instrument :rails
  c.tracing.instrument :resque
  c.tracing.instrument :sidekiq

  # Instrumentation that measures external services
  # defaults to adapter-specific names. You may still override
  # these names with the `service_name:` option.
  c.tracing.instrument :active_record, service_name: 'billing-api_mysql' # Defaults to DB type e.g. mysql
  c.tracing.instrument :http, service_name: 'billing-api_http' # Defaults to net/http
  c.tracing.instrument :redis, service_name: 'billing-api_redis' # Defaults to redis
end
```

**Update Rails instrumentation**

If your application activates and configures `rails` instrumentation, you will need to adjust your settings slightly.

The following options have been removed; instead, configure the underlying instrumentation directly.

| 0.x setting                                 | 1.0 setting                                                    |
|---------------------------------------------|----------------------------------------------------------------|
| `use :rails, cache_service: <SERVICE>`      | `tracing.instrument :active_support, cache_service: <SERVICE>` |
| `use :rails, controller_service: <SERVICE>` | `tracing.instrument :action_pack, service_name: <SERVICE>`     |
| `use :rails, database_service: <SERVICE>`   | `tracing.instrument :active_record, service_name: <SERVICE>`   |
| `use :rails, job_service: <SERVICE>`        | `tracing.instrument :active_job, service_name: <SERVICE>`      |
| `use :rails, log_injection: true`           | `tracing.log_injection = true` (Is `true` by default.)         |

```ruby
### Old 0.x ###
Datadog.configure do |c|
  c.use :rails, service_name: 'billing-api',
                cache_service: 'billing-api-cache',
                controller_service: 'billing-api-controllers',
                database_service: 'billing-api-db',
                job_service: 'billing-api-jobs',
                log_injection: true
end

### New 1.0 ###
Datadog.configure do |c|
  c.service = 'billing-api'

  c.tracing.instrument :rails
  c.tracing.instrument :active_support, cache_service: 'billing-api-cache'
  c.tracing.instrument :action_pack, service_name: 'billing-api-controllers'
  c.tracing.instrument :active_record, service_name: 'billing-api-db'
  c.tracing.instrument :active_job, service_name: 'billing-api-jobs'
end
```

Upgrading advanced usage

Namespacing

Many files and constants within `ddtrace` have been recategorized by feature. The new categorization scheme is as follows:

| Feature          | Namespace                | File path               |
|------------------|--------------------------|-------------------------|
| Globals          | `Datadog`                | `ddtrace`               |
|                  |                          |                         |
| CI               | `Datadog::CI`            | `datadog/ci`            |
| Core (Internals) | `Datadog::Core`          | `datadog/core`          |
| OpenTelemetry    | `Datadog::OpenTelemetry` | `datadog/opentelemetry` |
| OpenTracing      | `Datadog::OpenTracer`    | `datadog/opentracer`    |
| Profiling        | `Datadog::Profiling`     | `datadog/profiling`     |
| Security         | `Datadog::AppSec`        | `datadog/appsec`        |
| Tracing          | `Datadog::Tracing`       | `datadog/trace`         |

As a result, if your application referenced file paths or constants affected by this change, they will need to be updated. Check out the [namespace mappings](#1.0-appendix-namespace) for some common cases and how to update them.

Trace API

Usage of `Datadog.tracer` has been replaced with the `Datadog::Tracing` trace API. This module contains most of the functions that `Datadog.tracer` had, and most use cases will map one-to-one.

For example:

```ruby
### Old 0.x ###
Datadog.tracer.trace
Datadog.tracer.active_span
Datadog.tracer.active_correlation.to_s

### New 1.0 ###
Datadog::Tracing.trace
Datadog::Tracing.active_span
Datadog::Tracing.log_correlation

# ...and more...
```

See the table below for most common mappings:

| 0.x usage                                                                                | 1.0 usage                                   | Note                                                                |
|----------------------------------------------------------------------------------------------|---------------------------------------------|---------------------------------------------------------------------|
| `Datadog.tracer.active_correlation.to_s`                                                     | `Datadog::Tracing.log_correlation`          | Returns `String` with trace identifiers for logging.                |
| `Datadog.tracer.active_correlation`                                                          | `Datadog::Tracing.correlation`              | Returns `Datadog::Tracing::Correlation::Identifier`                 |
| `Datadog.tracer.active_root_span`                                                            | Removed                                     | Consider `Datadog::Tracing.active_trace` instead.                   |
| `Datadog.tracer.active_span.context.sampling_priority = Datadog::Ext::Priority::USER_KEEP`   | `Datadog::Tracing.keep!`                    | See [sampling](#1.0-trace-api-sampling) for details.                |
| `Datadog.tracer.active_span.context.sampling_priority = Datadog::Ext::Priority::USER_REJECT` | `Datadog::Tracing.reject!`                  | See [sampling](#1.0-trace-api-sampling) for details.                |
| `Datadog.tracer.active_span.context`                                                         | Removed                                     | Consider `Datadog::Tracing.active_trace` instead.                   |
| `Datadog.tracer.active_span`                                                                 | `Datadog::Tracing.active_span`              | See [trace state](#1.0-trace-api-trace-state) for details.          |
| `Datadog.tracer.call_context`                                                                | Removed                                     | See [trace state](#1.0-trace-api-trace-state) for details.          |
| `Datadog.tracer.configure(options)`                                                          | `Datadog.configure { \|c\| ... }`           | Use configuration API instead.                                      |
| `Datadog.tracer.provider.context = context`                                                  | `Datadog::Tracing.continue_trace!(digest)`  | See [distributed tracing](#1.0-trace-api-distributed) for details.  |
| `Datadog.tracer.set_tags(tags)`                                                              | `Datadog.configure { \|c\| c.tags = tags }` |                                                                     |
| `Datadog.tracer.shutdown!`                                                                   | `Datadog::Tracing.shutdown!`                |                                                                     |
| `Datadog.tracer.start_span`                                                                  | `Datadog::Tracing.trace`                    | See [manual tracing](#1.0-trace-api-manual-tracing) for details.    |
| `Datadog.tracer.trace`                                                                       | `Datadog::Tracing.trace`                    | See [manual tracing](#1.0-trace-api-manual-tracing) for details.    |

Also check out the functions defined within `Datadog::Tracing` in our [public API](https://www.rubydoc.info/gems/ddtrace/) for more details on their usage.

Removed `Datadog.tracer`

Many of the functions accessed directly through `Datadog.tracer` have been moved to `Datadog::Tracing` instead.

Removed access to `Datadog::Context`

Direct usage of `Datadog::Context` has been removed. Previously, it was used to modify or access active trace state. Most use cases have been replaced by our [public trace API](https://www.rubydoc.info/gems/ddtrace/).

Manual tracing & trace model

Manual tracing is now done through the [public API](https://www.rubydoc.info/gems/ddtrace/).

Whereas in 0.x, the block would provide a `Datadog::Span` as `span`, in 1.0, the block provides a `Datadog::Tracing::SpanOperation` as `span` and `Datadog::Tracing::TraceOperation` as `trace`.

```ruby
### Old 0.x ###
Datadog.tracer.trace('my.job') do |span|
  # Do work...
  # span => #<Datadog::Tracing::Span>
end

### New 1.0 ###
Datadog::Tracing.trace('my.job') do |span, trace|
  # Do work...
  # span => #<Datadog::Tracing::SpanOperation>
  # trace => #<Datadog::Tracing::TraceOperation>
end
```

The provided `span` is nearly identical in behavior, except access to some fields (like `context`) been removed. Instead, the provided `trace`, which models the trace itself, grants access to new functions, of which some replace old `span` behavior.

For more details about new behaviors and the trace model, see [this pull request](https://github.com/DataDog/dd-trace-rb/pull/1783).

Accessing trace state

The public API provides new functions to access active trace data:

```ruby
### Old 0.x ###
# Retuns the active context (contains trace state)
Datadog.tracer.call_context
# Returns the active Span
Datadog.tracer.active_span
# Returns an immutable set of identifiers for the current trace state
Datadog.tracer.active_correlation

### New 1.0 ###
# Retuns the active TraceOperation for the current thread (contains trace state)
Datadog::Tracing.active_trace
# Returns the active SpanOperation for the current thread (contains span state)
Datadog::Tracing.active_span
# Returns an immutable set of identifiers for the current trace state
Datadog::Tracing.correlation
```

Use of `active_root_span` has been removed.

Distributed tracing

Previously, distributed tracing required building new `Datadog::Context` objects, then replacing the context within the tracer.

Instead, users must use `TraceDigest` objects derived from a trace. `TraceDigest` represents the state of a trace. It can be used to propagate a trace across execution boundaries (processes, threads) or to continue a trace locally.

```ruby
### Old 0.x ###
# Get trace continuation from active trace
env = {}
Datadog::HTTPPropagator.inject(Datadog.tracer.call_context, env)
context = Datadog::HTTPPropagator.extract(env)

# Continue a trace: implicit continuation
Datadog.tracer.provider.context = context

# Next trace inherits trace properties
Datadog.tracer.trace('my.job') do |span|
  span.trace_id == context.trace_id
end

### New 1.0 ###
# Get trace continuation from active trace
trace_digest = Datadog::Tracing.active_trace.to_digest

# Continue a trace: implicit continuation
# Digest will be "consumed" by the next `trace` operation
Datadog::Tracing.continue_trace!(trace_digest)

# Next trace inherits trace properties
Datadog::Tracing.trace('my.job') do |span, trace|
  trace.id == trace_digest.trace_id
end

# Second trace does NOT inherit trace properties
Datadog::Tracing.trace('my.job') do |span, trace|
  trace.id != trace_digest.trace_id
end
```

New in 1.0, it's also possible to explicitly assign a trace block to continue from a specific trace, rather than implicitly inherit an active context. This gives users fine-grained control in applications where multiple traces run concurrently in the same execution context:

```ruby
### New 1.0 ###
# Get trace continuation from active trace
trace_digest = Datadog::Tracing.active_trace.to_digest

# Continue a trace: explicit continuation
# Inherits trace properties from the trace digest
Datadog::Tracing.trace('my.job', continue_from: trace_digest) do |span, trace|
  trace.id == trace_digest.trace_id
end

# Continue a trace: explicit continuation (using #continue_trace!)
Datadog::Tracing.continue_trace!(trace_digest) do
  # Traces implicitly continue within the block
  Datadog::Tracing.trace('my.job') do |span, trace|
    trace.id == trace_digest.trace_id
  end
end
```

Over HTTP

To propagate active trace to a remote service:

```ruby
### Old 0.x ###
headers = {}
context = Datadog.tracer.call_context
Datadog::HTTPPropagator.inject!(context, headers)

outgoing = Net::HTTP::Get.new(uri)
headers.each { |name, value| outgoing[name] = value }

### New 1.0 ###
headers = {}
trace_digest = Datadog::Tracing.active_trace.to_digest
Datadog::Tracing::Propagation::HTTP.inject!(trace_digest, headers)

outgoing = Net::HTTP::Get.new(uri)
headers.each { |name, value| outgoing[name] = value }
```

To continue a trace from a remote service:

```ruby
### Old 0.x ###
incoming = Rack::Request.new(env)
context = Datadog::HTTPPropagator.extract(incoming.env)
Datadog.tracer.provider.context = context

### New 1.0 ###
incoming = Rack::Request.new(env)
trace_digest = Datadog::Tracing::Propagation::HTTP.extract(incoming.env)
Datadog::Tracing.continue_trace!(trace_digest)
```

Over gRPC

To propagate active trace to a remote service:

```ruby
### Old 0.x ###
context = Datadog.tracer.call_context
Datadog::GRPCPropagator.inject!(context, metadata)

### New 1.0 ###
trace_digest = Datadog::Tracing.active_trace.to_digest
Datadog::Tracing::Propagation::GRPC.inject!(trace_digest, metadata)
```

To continue a trace from a remote service:

```ruby
### Old 0.x ###
context = Datadog::GRPCPropagator.extract(metadata)
Datadog.tracer.provider.context = context

### New 1.0 ###
trace_digest = Datadog::Tracing::Propagation::GRPC.extract(metadata)
Datadog::Tracing.continue_trace!(trace_digest)
```

Between threads

Traces do not implicitly propagate across threads, as they are considered different execution contexts.

However, if you wish to do this, trace propagation across threads is similar to cross-process. A `TraceDigest` should be produced by the parent thread and consumed by the child thread.

NOTE: The same `TraceOperation` object should never be shared between threads; this would create race conditions.

```ruby
### New 1.0 ###
# Get trace digest
trace = Datadog::Tracing.active_trace

# NOTE: We must produce the digest BEFORE starting the thread.
#       Otherwise if it's lazily evaluated within the thread,
#       the thread's trace may follow the wrong parent span.
trace_digest = trace.to_digest

Thread.new do
  # Inherits trace properties from the trace digest
  Datadog::Tracing.trace('my.job', continue_from: trace_digest) do |span, trace|
    trace.id == trace_digest.trace_id
  end
end
```

Sampling

Accessing `call_context` to set explicit sampling has been removed.

Instead, use the `TraceOperation` to set the sampling decision.

```ruby
### Old 0.x ###
# From within the trace:
Datadog.tracer.trace('web.request') do |span|
  span.context.sampling_priority = Datadog::Ext::Priority::USER_REJECT if env.path == '/healthcheck'
end

# From outside the trace:
# Keeps current trace
Datadog.tracer.active_span.context.sampling_priority = Datadog::Ext::Priority::USER_KEEP
# Drops current trace
Datadog.tracer.active_span.context.sampling_priority = Datadog::Ext::Priority::USER_REJECT

### New 1.0 ###
# From within the trace:
Datadog::Tracing.trace('web.request') do |span, trace|
  trace.reject! if env.path == '/healthcheck'
end

# From outside the trace:
Datadog::Tracing.keep! # Keeps current trace
Datadog::Tracing.reject! # Drops current trace
```

Processing pipeline

When using a trace processor in the processing pipeline, the block provides a `TraceSegment` as `trace` (instead of `Array[Datadog::Span]`.) This object can be directly mutated.

```ruby
### Old 0.x ###
Datadog::Pipeline.before_flush do |trace|
  # Processing logic...
  trace # => Array[Datadog::Span]
end

### New 1.0 ###
Datadog::Tracing.before_flush do |trace|
   # Processing logic...
   trace # => #<Datadog::Tracing::TraceSegment>
end
```

Appendix

Namespace mappings

Constants

| `0.x Constant`                                                  | `1.0 Constant`                                                                          |
|-----------------------------------------------------------------|-----------------------------------------------------------------------------------------|
| `Datadog::AllSampler`                                           | `Datadog::Tracing::Sampling::AllSampler`                                                |
| `Datadog::Buffer`                                               | `Datadog::Core::Buffer::Random`                                                         |
| `Datadog::Chunker`                                              | `Datadog::Core::Chunker`                                                                |
| `Datadog::Configuration`                                        | `Datadog::Core::Configuration`                                                          |
| `Datadog::ContextFlush`                                         | `Datadog::Tracing::Flush`                                                               |
| `Datadog::CRubyBuffer`                                          | `Datadog::Core::Buffer::CRuby`                                                          |
| `Datadog::Diagnostics`                                          | `Datadog::Core::Diagnostics`                                                            |
| `Datadog::DistributedTracing`                                   | `Datadog::Tracing::Distributed`                                                         |
| `Datadog::Encoding`                                             | `Datadog::Core::Encoding`                                                               |
| `Datadog::Error`                                                | `Datadog::Core::Error`                                                                  |
| `Datadog::Ext::Analytics::ENV_TRACE_ANALYTICS_ENABLED`          | `Datadog::Tracing::Configuration::Ext::Analytics::ENV_TRACE_ANALYTICS_ENABLED`          |
| `Datadog::Ext::Analytics`                                       | `Datadog::Tracing::Metadata::Ext::Analytics`                                            |
| `Datadog::Ext::AppTypes`                                        | `Datadog::Tracing::Metadata::Ext::AppTypes`                                             |
| `Datadog::Ext::Correlation::ENV_LOGS_INJECTION_ENABLED`         | `Datadog::Tracing::Configuration::Ext::Correlation::ENV_LOGS_INJECTION_ENABLED`         |
| `Datadog::Ext::Correlation`                                     | `Datadog::Tracing::Correlation::Identifier`                                             |
| `Datadog::Ext::Diagnostics`                                     | `Datadog::Core::Diagnostics::Ext`                                                       |
| `Datadog::Ext::Distributed::ENV_PROPAGATION_STYLE_EXTRACT`      | `Datadog::Tracing::Configuration::Ext::Distributed::ENV_PROPAGATION_STYLE_EXTRACT`      |
| `Datadog::Ext::Distributed::ENV_PROPAGATION_STYLE_INJECT`       | `Datadog::Tracing::Configuration::Ext::Distributed::ENV_PROPAGATION_STYLE_INJECT`       |
| `Datadog::Ext::Distributed::PROPAGATION_STYLE_B3_SINGLE_HEADER` | `Datadog::Tracing::Configuration::Ext::Distributed::PROPAGATION_STYLE_B3_SINGLE_HEADER` |
| `Datadog::Ext::Distributed::PROPAGATION_STYLE_B3`               | `Datadog::Tracing::Configuration::Ext::Distributed::PROPAGATION_STYLE_B3`               |
| `Datadog::Ext::Distributed::PROPAGATION_STYLE_DATADOG`          | `Datadog::Tracing::Configuration::Ext::Distributed::PROPAGATION_STYLE_DATADOG`          |
| `Datadog::Ext::Distributed`                                     | `Datadog::Tracing::Metadata::Ext::Distributed`                                          |
| `Datadog::Ext::DistributedTracing::TAG_ORIGIN`                  | `Datadog::Tracing::Metadata::Ext::Distributed::TAG_ORIGIN`                              |
| `Datadog::Ext::DistributedTracing::TAG_SAMPLING_PRIORITY`       | `Datadog::Tracing::Metadata::Ext::Distributed::TAG_SAMPLING_PRIORITY`                   |
| `Datadog::Ext::DistributedTracing`                              | `Datadog::Tracing::Distributed::Headers::Ext`                                           |
| `Datadog::Ext::Environment`                                     | `Datadog::Core::Environment::Ext`                                                       |
| `Datadog::Ext::Errors`                                          | `Datadog::Tracing::Metadata::Ext::Errors`                                               |
| `Datadog::Ext::Git`                                             | `Datadog::Core::Git::Ext`                                                               |
| `Datadog::Ext::HTTP`                                            | `Datadog::Tracing::Metadata::Ext::HTTP`                                                 |
| `Datadog::Ext::Integration`                                     | `Datadog::Tracing::Metadata::Ext`                                                       |
| `Datadog::Ext::NET::ENV_REPORT_HOSTNAME`                        | `Datadog::Tracing::Configuration::Ext::NET::ENV_REPORT_HOSTNAME`                        |
| `Datadog::Ext::NET`                                             | `Datadog::Tracing::Metadata::Ext::NET`                                                  |
| `Datadog::Ext::Priority`                                        | `Datadog::Tracing::Sampling::Ext::Priority`                                             |
| `Datadog::Ext::Runtime`                                         | `Datadog::Core::Runtime::Ext`                                                           |
| `Datadog::Ext::Sampling::ENV_RATE_LIMIT`                        | `Datadog::Tracing::Configuration::Ext::Sampling::ENV_RATE_LIMIT`                        |
| `Datadog::Ext::Sampling::ENV_SAMPLE_RATE`                       | `Datadog::Tracing::Configuration::Ext::Sampling::ENV_SAMPLE_RATE`                       |
| `Datadog::Ext::Sampling`                                        | `Datadog::Tracing::Metadata::Ext::Sampling`                                             |
| `Datadog::Ext::SQL`                                             | `Datadog::Tracing::Metadata::Ext::SQL`                                                  |
| `Datadog::Ext::Test`                                            | `Datadog::Tracing::Configuration::Ext::Test`                                            |
| `Datadog::Ext::Transport::HTTP::ENV_DEFAULT_HOST`               | `Datadog::Core::Configuration::Ext::Transport::ENV_DEFAULT_HOST`                     |
| `Datadog::Ext::Transport::HTTP::ENV_DEFAULT_PORT`               | `Datadog::Tracing::Configuration::Ext::Transport::ENV_DEFAULT_PORT`                     |
| `Datadog::Ext::Transport::HTTP::ENV_DEFAULT_URL`                | `Datadog::Tracing::Configuration::Ext::Transport::ENV_DEFAULT_URL`                      |
| `Datadog::Ext::Transport`                                       | `Datadog::Transport::Ext`                                                               |
| `Datadog::GRPCPropagator`                                       | `Datadog::Tracing::Propagation::GRPC`                                                   |
| `Datadog::HTTPPropagator`                                       | `Datadog::Tracing::Propagation::HTTP`                                                   |
| `Datadog::Logger`                                               | `Datadog::Core::Logger`                                                                 |
| `Datadog::Metrics`                                              | `Datadog::Core::Metrics::Client`                                                        |
| `Datadog::PrioritySampler`                                      | `Datadog::Tracing::Sampling::PrioritySampler`                                           |
| `Datadog::Quantization`                                         | `Datadog::Contrib::Utils::Quantization`                                                 |
| `Datadog::RateByKeySampler`                                     | `Datadog::Tracing::Sampling::RateByKeySampler`                                          |
| `Datadog::RateByServiceSampler`                                 | `Datadog::Tracing::Sampling::RateByServiceSampler`                                      |
| `Datadog::RateSampler`                                          | `Datadog::Tracing::Sampling::RateSampler`                                               |
| `Datadog::Runtime`                                              | `Datadog::Core::Runtime`                                                                |
| `Datadog::Sampler`                                              | `Datadog::Tracing::Sampling::Sampler`                                                   |
| `Datadog::Tagging::Analytics`                                   | `Datadog::Tracing::Metadata::Analytics`                                                 |
| `Datadog::Tagging::Metadata`                                    | `Datadog::Tracing::Metadata::Tagging`                                                   |
| `Datadog::ThreadSafeBuffer`                                     | `Datadog::Core::Buffer::ThreadSafe`                                                     |
| `Datadog::Utils`                                                | `Datadog::Core::Utils`                                                                  |
| `Datadog::Vendor::ActiveRecord`                                 | `Datadog::Contrib::ActiveRecord::Vendor`                                                |
| `Datadog::Vendor::Multipart`                                    | `Datadog::Core::Vendor::Multipart`                                                      |
| `Datadog::Worker`                                               | `Datadog::Core::Worker`                                                                 |
| `Datadog::Workers`                                              | `Datadog::Core::Workers`                                                                |

Breaking changes

| **Category**                          | **Type** | **Description**                                                                                | **Change / Alternative**                                                                                |
|---------------------------------------|----------|---------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| General                               | Changed  | Many constants have been moved from `Datadog` to `Datadog::Core`, `Datadog::Tracing`                                | Update your references to these [new namespaces](#1.0-appendix-namespace-constants) where appropriate.                                                                    |
| General                               | Changed  | Some `require` paths have been moved from `ddtrace` to `datadog`                                                    | Update your references to these [new paths](#1.0-appendix-namespace-requires) where appropriate.                                                                          |
| General                               | Removed  | Support for trace agent API v0.2                                                                                | Use v0.4 instead (default behavior.)                                                                                |
| General                               | Removed  | `Datadog.configure` can no longer be called without a block                                                         | Remove uses of `Datadog.configure` without a block.                                                                                |
| CI API                                | Changed  | `DD_TRACE_CI_MODE_ENABLED` environment variable is now `DD_TRACE_CI_ENABLED`                                        | Use `DD_TRACE_CI_ENABLED` instead.                                                                                |
| Configuration                         | Changed  | Many settings have been namespaced under specific categories                                                        | Update your configuration to these [new settings](#1.0-configuration-settings) where appropriate.                                                                         |
| Configuration                         | Removed  | `Datadog.configure(client, options)`                                                                                | Use `Datadog.configure_onto(client, options)` instead.                                                                                |
| Configuration                         | Removed  | `DD_#{integration}_ANALYTICS_ENABLED` and `DD_#{integration}_ANALYTICS_SAMPLE_RATE` environment variables           | Use `DD_TRACE_#{integration}_ANALYTICS_ENABLED` and `DD_TRACE_#{integration}_ANALYTICS_SAMPLE_RATE` instead.                                                              |
| Configuration                         | Removed  | `DD_PROPAGATION_INJECT_STYLE` and `DD_PROPAGATION_EXTRACT_STYLE` environment variables                              | Use `DD_TRACE_PROPAGATION_STYLE_INJECT` and `DD_TRACE_PROPAGATION_STYLE_EXTRACT` instead.                                                                                |
| Integrations                          | Changed  | `-` in HTTP header tag names are kept, and no longer replaced with `_`                                              | For example: `http.response.headers.content_type` is changed to `http.response.headers.content-type`.                                                                     |
| Integrations                          | Changed  | `Contrib::Configurable#default_configuration` moved to `Tracing::Contrib::Configurable#new_configuration`           | Use `Tracing::Contrib::Configurable#new_configuration` instead.                                                                                |
| Integrations                          | Changed  | `Datadog.configuration.registry` moved to `Datadog.registry`                                                        | Use `Datadog.registry` instead.                                                                                |
| Integrations                          | Changed  | `service_name` option from each integration uses the default service name, unless it represents an external service | Set `c.service` or `DD_SERVICE`, and remove `service_name` option from integration to inherit default service name. Set `service_name` option on integration to override. |
| Integrations                          | Removed  | `tracer` integration option from all integrations                                                                   | Remove this option from your configuration.                                                                                |
| Integrations - ActiveJob              | Removed  | `log_injection` option                                                                                | Use `c.tracing.log_injection` instead.                                                                                |
| Integrations - ActiveModelSerializers | Removed  | service_name configuration                                                                                | Remove this option from your configuration.                                                                                |
| Integrations - ConcurrentRuby         | Removed  | unused option `service_name`                                                                                | Remove this option from your configuration.                                                                                |
| Integrations - Presto                 | Changed  | `out.host` tag now contains only client hostname. Before it contained `"#{hostname}:#{port}"`.                      |                                                                                |
| Integrations - Rails                  | Changed  | `service_name` does not propagate to sub-components (e.g. `c.use :rails, cache_service: 'my-cache'`)                | Use `c.service` instead.                                                                                |
| Integrations - Rails                  | Changed  | Sub-components service_name options are now consistently called `:service_name`                                     | Update your configuration to use `:service_name`.                                                                                |
| Integrations - Rails                  | Changed  | Trace-logging correlation is enabled by default                                                                     | Can be disabled using the environment variable `DD_LOGS_INJECTION=false`.                                                                                |
| Integrations - Rails                  | Removed  | `log_injection` option.                                                                                | Use global `c.tracing.log_injection` instead.                                                                                |
| Integrations - Rails                  | Removed  | `orm_service_name` option.                                                                                | Remove this option from your configuration.                                                                                |
| Integrations - Rails                  | Removed  | 3.0 and 3.1 support.                                                                                | Not supported.                                                                                |
| Integrations - Resque                 | Removed  | `workers` option. (All Resque workers are now automatically instrumented.)                                          | Remove this option from your configuration.                                                                                |
| Tracing API                           | Changed  | `Correlation#to_s` to `Correlation#to_log_format`                                                                   | Use `Datadog::Tracing.log_correlation` instead.                                                                                |
| Tracing API                           | Changed  | `Tracer#trace` implements keyword args                                                                              | Omit invalid options from `trace` calls.                                                                                |
| Tracing API                           | Changed  | Distributed tracing takes and returns `TraceDigest` instead of `Context`                                            | Update your usage of distributed tracing to use `continue_from` and `to_digest`.                                                                                |
| Tracing API                           | Changed  | Rules for RuleSampler now return `TraceOperation` instead of `Span`                                                 | Update Rule sampler usage to use `TraceOperation`.                                                                                |
| Tracing API                           | Changed  | Trace processors return `TraceSegment` instead of `Array[Span]`                                                     | Update pipeline callbacks to use `TraceSegment instead.                                                                                |
| Tracing API                           | Removed  | `child_of:` option from `Tracer#trace`                                                                              | Not supported.                                                                                |
| Tracing API                           | Removed  | `Datadog.tracer`                                                                                | Use methods in `Datadog::Tracing` instead.                                                                                |
| Tracing API                           | Removed  | `Pin.get_from(client)`                                                                                | Use `Datadog::Tracing.configure_for(client)` instead.                                                                                |
| Tracing API                           | Removed  | `Pin.new(service, config: { option: value }).onto(client)`                                                          | Use `Datadog.configure_onto(client, service_name: service, option: value)` instead.                                                                              |
| Tracing API                           | Removed  | `Pipeline.before_flush`                                                                                | Use `Datadog::Tracing.before_flush` instead.                                                                                |
| Tracing API                           | Removed  | `SpanOperation#context`                                                                                | Use `Datadog::Tracing.active_trace` instead.                                                                                |
| Tracing API                           | Removed  | `SpanOperation#parent`/`SpanOperation#parent=`                                                                      | Not supported.                                                                                |
| Tracing API                           | Removed  | `SpanOperation#sampled`                                                                                | Use `Datadog::Tracing::TraceOperation#sampled?` instead.                                                                                |
| Tracing API                           | Removed  | `Tracer#active_correlation.to_log_format`                                                                           | Use `Datadog::Tracing.log_correlation` instead.                                                                                |
| Tracing API                           | Removed  | `Tracer#active_correlation`                                                                                | Use `Datadog::Tracing.correlation` instead.                                                                                |
| Tracing API                           | Removed  | `Tracer#active_root_span`                                                                                | Use `Datadog::Tracing.active_trace` instead.                                                                                |
| Tracing API                           | Removed  | `Tracer#build_span`                                                                                | Use `Datadog::Tracing.trace` instead.                                                                                |
| Tracing API                           | Removed  | `Tracer#call_context`                                                                                | Use `Datadog::Tracing.active_trace` instead.                                                                                |
| Tracing API                           | Removed  | `Tracer#configure`                                                                                | Not supported.                                                                                |
| Tracing API                           | Removed  | `Tracer#services`                                                                                | Not supported.                                                                                |
| Tracing API                           | Removed  | `Tracer#set_service_info`                                                                                | Not supported.                                                                                |
| Tracing API                           | Removed  | `Tracer#start_span`                                                                                | Use `Datadog::Tracing.trace` instead.                                                                                |
| Tracing API                           | Removed  | `Writer#write` and `SyncWriter#write` `services` argument                                                           | Not supported.                                                                                |

gha_license_id: NOASSERTION


text:
# Kernel Manual

## 1. Simulation Parameters
| Item | Value | Description |
| --- | :---: | --- |
| Simulation frame frequency | 200Hz | epochs per simulation second |
| Operation frequency | 20Hz | rate at which new commands are received per simulation second |
| Scale | 10mm/px | 8×5m real-world field dimensions corresponds to 800×500px window |
| Car size | 60×50px | 600×500mm real-world |
| Maximum speed of car front/back | 1.5px/epoch | 3m/s real-world |
| Maximum speed of car left/right | 1px/epoch | 2m/s real-world |
| Maximum chassis rotation speed | 200°/s | - |
| Maximum speed of gimbal rotation | 600°/s | - |
| Bullet speed | 12.5px/epoch | 25m/s real-world |
| Barrel heat settlement frequency | 10Hz | - |

## 2. Implementation Notes

1. The speed of the chassis and pan/tilt will gradually increase to the maximum after pressing
the corresponding command, and the speed will gradually decrease after the command is stopped.

2. The default team is divided into blue cars 1, 3 and red cars 2, 4. The game mode can be changed by setting `robot_count`.
For example, `robot_count=2` is a 1v1 confrontation and `robot_count=3` is a 2v1 confrontation.

3. `pygame` module is used only for visualization and will not be used if `render=False`.

4. In user-controlled operation `.play()`, only one car can be controlled at a time.

5. There is a rebound effect, but it does not fully comply with the laws of physics.

6. When the center of a car is within a preset area of a zone, the corresponding buff/debuff will be applied.

## 3. Game Configuration

All constants in `modules/constants.py` may be modified for a different game experience.

license: MIT

branch_name: refs/heads/main

extension: md

gha_license_id: MIT

license_type: permissive


text:
# 0. Pre-requisite:
## 0.1. SSH to EC2 from your device (Windows/Mac)
## 0.2. Enable two-factor authentication with RobinHood & Google Authenticator mobile App:
- Check this [Tutorial](https://robinhood.com/us/en/support/articles/twofactor-authentication/)

# 1. Working with AWS EC2
## 1.1. Set up EC2 instance
    sudo apt-get update
    sudo apt-get install build-essential python3-venv unzip sqlite3 -y
    sudo apt-get install mysql-server mysql-client -y
    sudo apt-get install python3-mysqldb libmysqlclient-dev python3-dev -y

## 1.2. Set up Python virtual environment
    python3 -m venv f-venv
    source f-venv/bin/activate
    pip install wheel

- Note: `pip install -r requirement.txt` is moved to the next step

## 1.3. Get Django project
    wget https://github.com/qz-fordham/algo-trading-microservice/archive/main.zip
    unzip main.zip
    cd algo-trading-microservice-main/algo_trading/
    pip install -r requirement.txt

# 2. Working with AWS RDS (MySQL)
## 2.1. Remote access RDS to create Database on MySQL server
    mysql -u admin -h MYSQL-HOST-NAME-OF-YOURS -p
    CREATE DATABASE algo_trading_db;

- Note: Make sure you use correct RDS instance hostname to replace `MYSQL-HOST-NAME-OF-YOURS`

# 3. Configure Django Project
## 3.1. Manually login once with your robinhood account (RobinHood will cache your credential)
    python
    import robin_stocks as rbh
    rbh.login(username, password, mfa_code=xxxxxx)
## 3.2. Update database setting in settings.py
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.sqlite3',
            'NAME': 'algo_trading_db',
            'USER': 'admin',
            'PASSWORD': 'password123',
            'HOST': '',
            'PORT': '3306',
        }
    }

- Note: Make sure you add EC2 public DNS to the `HOST` field

## 3.3. Update allowed_host in settings.py
- Add ec2 hostname to `ALLOWED_HOSTS` (use the ame hostname as previous step)

## 3.4. Start broker
    python manage.py migrate
    python manage.py makemigrations
    python manage.py runserver <IP_ADDRESS>:8000

# 4. Update EC2 instance security setting so that site can be visited from anywhere
## 4.1. Update EC2 instance security group inbound, e.g.
- Add Custom TCP - 8000 (source <IP_ADDRESS>/0). If that's the port Django is running on.

# 5. Now you can access the website from your browser

repository: qz-fordham/algo-trading-microservice

repo_name: qz-fordham/algo-trading-microservice


text:
# UAIS
[![MIT license](https://img.shields.io/badge/License-MIT-brightgreen.svg)](https://github.com/UndergraduateArtificialIntelligenceClub/website/blob/master/LICENSE)
[![Webiste](https://img.shields.io/website?down_color=red&down_message=down&up_color=green&up_message=up&url=https%3A%2F%2Fuais.dev)](https://uais.dev/)
[![Compile Website](https://github.com/UndergraduateArtificialIntelligenceClub/website/workflows/Deploy%20Website/badge.svg)](https://github.com/UndergraduateArtificialIntelligenceClub/website/actions)
[![Node Version](https://img.shields.io/node/v/astro)](https://nodejs.org/en/download/)
[![Pull Requests Closed](https://img.shields.io/github/issues-pr-closed/UndergraduateArtificialIntelligenceClub/website)](https://github.com/UndergraduateArtificialIntelligenceClub/website/pulls)

If you have any **feature requests**, please **open an issue** with the `enhancement` label.
If you would like to **contribute**, please **contact** either [@NickNissen](https://github.com/NickNissen) or [@giancarlopernudisegura](https://github.com/giancarlopernudisegura) on [slack](https://albertaundergradai.slack.com) on the `#website` channel.

## Development Environment Setup
The website is made with [Nuxt.js](https://nuxtjs.org/), a static site generator based on [Vue](https://vuejs.org/).

### Install Node.js
#### Windows
Go to [nodejs.org](https://nodejs.org/en/download/).
#### Ubuntu
```sh
sudo apt-get update
sudo apt-get install nodejs npm
```
#### Arch Linux
```sh
sudo pacman -S nodejs npm
```

### Install Project Dependencies
```sh
npm i
```

### Run local server
```sh
npm run dev
```

## Website Development Priorities
For a more information, check out **Tasks** under the **Projects** tab.
- Projects application form
- Onborading checklist

## Dreams
- annonymized voting

branch_name: refs/heads/master

gha_language: Astro


text:
# ndefence - internal security log parser and firewall, written in golang

A humble golang application to generate daily data from log file entries
from common servers, such as nginx or apache. In addition, it will try
to refine and potentially block IPs that attempt too many connections.

Specifically it takes IPv4 address data from the access.log files and
conducts the following:

* hostname lookup
* whois lookup
* records server requests of HTML code 302

This program checks for high counts of anonymous connections, and it will
add them to firewall those addresses if they appear to come from unusual
sources.

Feel free to fork it and use it for other projects if you find it
useful.

# Requirements

The following is needed in order for this to function as intended:

* Linux kernel 4.0+
* cron
* golang 1.6+
* host
* apache / nginx
* whois

Older kernels could still give some kind of result, but I *think* most of
the newer versions of golang require newer kernels. Feel free to email me if
this is incorrect.

# Installation

0) Build this program as you would a simple golang module.

    make

1) Install this program on your server.

    make install

2) Adjust the cron job to set the choice of server (default is nginx).

    vim /etc/cron.d/ndefence

Alternatively, if you are running Arch Linux w/ systemd, you can use the
included ndefence.service instead. However, the cron job is recommended
since it has greater compatibility with more distros.

# Uninstallation

1) To remove this program from your system.

    make uninstall

2) Consider cleaning up any remaining logs, if they are no longer needed.

    rm /var/www/html/data/blocked.log

    rm /var/www/html/data/ip.log

    rm /var/www/html/data/redirect.log

    rm /var/www/html/data/whois.log

# TODOs

* Hostname check on the IP addresses as soon as they access the server
* Create a systemd service that works better with alternative distros
* Consider adding the ability to block IPv6 addresses as well

# Author

Written by Robert Bisewski at Ibis Cybernetics. For more information, contact:

* Website -> www.ibiscybernetics.com

* Email -><EMAIL_ADDRESS>

repository: rbisewski/ndefence

repo_name: rbisewski/ndefence


text:
This is a general CLI workspace based on the lightweight Alpine distribution of Linux and runnable with Docker.

Pick a directory and mount it into the container filesystem.

It will give you default:

* java
* ruby
* node
* npm
* git

and some useful linux utilities.

# References

[Linux Directory Standard](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)

repository: coatsnmore/docker-workspace

repo_name: coatsnmore/docker-workspace


text:
Based on Revision 74 of original filter-dkimsign at http://imperialat.at/dev/filter-dkimsign/

INSTALLING on Fedora
--------------------

**NOTE: [libopensmtpd](https://github.com/murty2/libopensmtpd) must be install first.**

\# Make sure these are installed first: make gcc mandoc

sudo dnf install make gcc mandoc

make -f Makefile.gnu

sudo make -f Makefile.gnu install

\# You can remove rpms you installed: sudo dnf erase make gcc mandoc

## How to use the new option -D

filter-dkimsign -d domain.com -D -k keyfile -s selector

Here, domain determined from From: header will be used in DKIM signing. If domain from From: header cannot be determined, then it will fallback to domain.com (the argument of -d)

The benefit of using -D option is that you do not have to specify -d option 100 times, assuming you have 100 domains.

**CAUTION: If you use -D option, first make sure that domain (used in From: header) has DKIM configured for it in DNS properly. Otherwise mail can bounce (unless your domain has proper DMARC configuration and your SPF alignment succeeds)**

license: ISC


text:
---
layout: base
title:  'Statistics of NounType in UD_Classical_Chinese-Kyoto'
udver: '2'
---

## Treebank Statistics: UD_Classical_Chinese-Kyoto: Features: `NounType`

This feature is language-specific.
It occurs with 1 different values: `Class`.

345 tokens (0%) have a non-empty value of `NounType`.
32 types (1%) occur at least once with a non-empty value of `NounType`.
32 lemmas (1%) occur at least once with a non-empty value of `NounType`.
The feature is used with 1 part-of-speech tags: <tt>NOUN</tt> (345; 0% instances).

### `NOUN`

345 <tt>NOUN</tt> tokens (1% of all `NOUN` tokens) have a non-empty value of `NounType`.

The most frequent other feature values with which `NOUN` and `NounType` co-occurred: <tt>Case</tt><tt>=EMPTY</tt> (345; 100%).

`NOUN` tokens may have the following values of `NounType`:

* `Class` (345; 100% of non-empty `NounType`): 里、 方、 尺、 寸、 畝、 升、 步、 个、 尋、 扶

`NounType` seems to be **lexical feature** of `NOUN`. 100% lemmas (32) occur only with one value of `NounType`.

## Relations with Agreement in `NounType`

The 10 most frequent relations where parent and child node agree in `NounType`:
<tt>NOUN --[<tt>conj</tt>]--> NOUN</tt> (5; 83%).

branch_name: refs/heads/pages-source


text:
# FEEL Engine

The core FEEL engine (parser and interpreter). Usually, it is integrated in a project as library. In the project, the engine is either called directly (i.e. `engine.evalExpression(..)`) or using the script engine API.

## Usage

Add the engine as dependency to your project:

```xml
<dependency>
  <groupId>org.camunda.feel</groupId>
  <artifactId>feel-engine</artifactId>
  <version>${VERSION}</version>
</dependency>
```

Or copy the [jar file](https://github.com/camunda/feel-scala/releases) _(feel-engine-${VERSION}-complete.jar)_ directly.

### Standalone

Create a new instance of the class 'FeelEngine'. Use this instance to parse and evaluate a given expression or unary tests.

Using Scala:

```scala
object MyProgram {

  val engine = new FeelEngine

  def feel(expression: String, context: Map[String, Any]) {

    val result: Either[Failure, Boolean] = engine.evalSimpleUnaryTests(expression, context)
    // or
    val result: Either[Failure, Any] = engine.evalExpression(expression, context)

    // handle result
    result
        .right.map(value => println(s"result is: $value"))
        .left.map(failure => println(s"failure: $failure"))
  }
}
```

Or using Java:

```java
 public class MyProgram {

    public static void main(String[] args) {

        final FeelEngine engine = new FeelEngine.Builder()
            .valueMapper(SpiServiceLoader.loadValueMapper())
            .functionProvider(SpiServiceLoader.loadFunctionProvider())
            .build();

        final Map<String, Object> variables = Collections.singletonMap("x", 21);
        final Either<FeelEngine.Failure, Object> result = engine.evalExpression(expression, variables);

        if (result.isRight()) {
            final Object value = result.right().get();
            System.out.println("result is " + value);
        } else {
            final FeelEngine.Failure failure = result.left().get();
            throw new RuntimeException(failure.message());
        }
    }
}
```

Enable FEEL External-Functions in the configuration:

```
new FeelEngine(configuration = Configuration(externalFunctionsEnabled = true))
// or
new FeelEngine.Builder().enableExternalFunctions(true).build()
```

:warning: Enabling external functions is not recommended because external functions make it possible to call arbitrary Java methods. This poses a potential security risk. Enabling this feature can be safe if you have full control of the expressions that will be evaluated (i.e. none of them are entered by a user or generated by an external system). In all other cases this feature is considered unsafe. It is recommended to use the (Function Provider SPI)[https://camunda.github.io/feel-scala/function-provider-spi] instead.

### Script Engine

Call the engine via Java script engine API [JSR 223](https://www.jcp.org/en/jsr/detail?id=223).

```scala
object MyProgram {

  val scriptEngineManager = new ScriptEngineManager

  def feel(script: String, context: ScriptContext) {

    val scriptEngine: FeelScriptEngine = scriptEngineManager.getEngineByName("feel")

    val result: Object = scriptEngine.eval(script, context)
    // ...
  }

}
```

The engine is registered under the names:

* `feel`
* `http://www.omg.org/spec/FEEL/20140401` (qualified name)
* `feel-scala`

You can also evaluate unary tests instead of an expression by using one of the names:

* `feel-unary-tests`
* `feel-scala-unary-tests`

repository: aravindhrs/feel-scala

repo_name: aravindhrs/feel-scala


text:
# ActionRunner
ActionRunner is a library aimed at rookie to low tier FRC teams, or teams who simply do not have good programming. It's easy to use, extremely flexible, and can be used to run multiple autonomous modes easily and (semi-) elegantly!

### Usage
```java
public class Robot extends IterativeRobot {
    //This is a simple example to show off
    //What this library is capable of

    DifferentialDrive drive = new DifferentialDrive(0, 1);
    SendableChooser<ActionRunner> autoChooser = new SendableChooser<>();

    public void robotInit() {
        ActionRunner baselineAuto = new ActionRunner();
        baselineAuto.addAction(() -> {
            //Go forward at 25% speed for 5 seconds
            drive.arcadeDrive(0.25, 0);

            return Timer.hasPeriodElapsed(5);
        });
        baselineAuto.addAction(() -> {
            //Turn right as 25% speed for 2 seconds
            drive.arcadeDrive(0, 0.25);

            return Timer.hasPeriodElapsed(2);
        });
        baselineAuto.onActionComplete(() -> {
            //Stop the robot after every action
            drive.arcadeDrive(0, 0);

            return Timer.hasPeriodElapsed(1);
        });

        autoChooser.addObject(baselineAuto);
        SmartDashboard.putData("autonomous", autoChooser);
    }

    public void autonomousInit() {
        autoChooser.getSelected().initialize();
    }

    public void autonomousPeriodic() {
        autoChooser.getSelected().update();
        //This next thing is optional but I'd do it
        SmartDashboard.putBoolean("autonomous done", autoChooser.getSelected().isDone());
    }
}
```
***Note:*** This is not the code everyone should write for this. Don't copy/paste this code and hope for the best. It's up to *you* to use it the way *you* need to.

### Installation
As of right now there are 2 ways to use ActionRunner.
1. Download the JAR
    1. Click on releases
    2. Download the JAR that should *hopefully* be there
    3. Add the JAR to your classpath in eclipse (I don't know that one, I use gradle and [gradlerio](https://github.com/Open-RIO/GradleRIO).)
2. Copy and paste the sources
    1. Make a new package in the project and name it `frc.team2186.actionrunner`
    2. Copy and paste the sources into that package

### Building
For the more adventurous of you, you can try building this library. ActionRunner uses gradle as it's build system, so the process for building looks something like this.
1. Clone the directory
2. Open a command line or terminal in the cloned directory
3. Run `gradlew build`
4. The built JAR should be in build/libs

### Author
ActionRunner was written by [Kenny Raisbeck](https://github.com/drwaterycat). ActionRunner is governed by the [MIT License](LICENSE). Copyright 2018.

repository: DrWateryCat/ActionRunner

repo_name: DrWateryCat/ActionRunner


text:
# SDBSCAN
This repository contains the algorithm implementation in our work [A novel density-based clustering algorithm using nearest neighbor graph](https://www.sciencedirect.com/science/article/pii/S0031320320300121?via%3Dihub).
## How to use
The SDBSCAN package inherits from sklearn classes, and thus drops in neatly next to other sklearn cluster algorithms with an identical calling API.

```
from sdbscan import SDBSCAN
from sklearn.datasets import make_blobs

data, _ = make_blobs(1000, centers=2)

labels = SDBSCAN(min_samples=20,
                 noise_percent=0.05
                 ).fit_predict(data)
```

## Additional functionality
This repository also contains the implementation of a fast *k*-NN graph construction algorithm based on [annoy libary](https://github.com/spotify/annoy) in "fastKNN.py". While it is more efficient than the kneighbors_graph() function in sklearn, the accuracy of the constructed *k*-NN graph is reduced, which may affect the performance of clustering.
You can change the *k*-NN graph construct algorithm in sdbscan() function which located in sdbscan.py.

## Dependencies
To use SDBSCAN, you should install the dependencies below:

- [scikit-learn](https://scikit-learn.org/)
- [Numpy](https://numpy.org/)
- [Pandas](https://pandas.pydata.org/)
- [Annoy](https://github.com/spotify/annoy) (if using fastKNN function)

## Citing

To reference the SDBSCAN algorithm developed in this library please cite our paper published in Pattern Recognition.

```
@article{LI2020107206,
title = "A novel density-based clustering algorithm using nearest neighbor graph",
journal = "Pattern Recognition",
volume = "102",
pages = "107206",
year = "2020",
issn = "0031-3203",
doi = "https://doi.org/10.1016/j.patcog.2020.107206",
url = "http://www.sciencedirect.com/science/article/pii/S0031320320300121",
author = "Hao Li and Xiaojie Liu and Tao Li and Rundong Gan",
}
```


text:
# tbl - `cat` for csv files

`tbl` lets you print out csv files to your terminal, formatted and "prettified".

A lot of the hard work is done with the [rapidtables](https://github.com/alttch/rapidtables) package, check it out!

cat             |  tbl
-------------------------|-------------------------
![](docs_content/cat.png)  |  ![](docs_content/rstgrid.png)

Check out this recorded example:
[![asciicast](https://asciinema.org/a/268740.png)](https://asciinema.org/a/268740)
## Requirements
* Python 3.4+

## Installation
```shell
pip install --user clitbl
```

## Usage options
Use ```tbl -h / tbl --help``` to see help.

* The most common use it to just print the table
```shell
tbl file.csv
```
* `--headers`
The headers options lets you explicitly specify the headers for the table. Use this option when you csv files does
not include headers, (e.g [exampleFile](example_csv/no_headers.csv)
```shell
tbl file.csv --headers '#Index#Item#Cost#Tax#Total'
```
* `--select`
The select options lets you select what columns to print (similar to SQL SELECT)
```shell
tbl file.csv --select '#Item#Tax'
```
:exclamation: Both `headers` and `select` use the first charcter as a separator,
it can be any character (kinda like a `sed` expressions)
:exclamation: The headers specified with this option are case-sensitive
:star2: The `headers` and `select` headers can be used together

* `--format` (defualt: rstgrid)
The format options lets you specify the format used when printing the table.
The available formats are:

| rstgrid | rst | md | simple |
|-------|-------|-----------|-------|
|![](docs_content/rstgrid.png)|![](docs_content/rst.png)|![](docs_content/md.png)|![](docs_content/simple.png)|

## Restrictions
There are several cases `tbl` does not support:
* Duplicated headers, all headers must be distinct
* Very long headers, while tbl can wrap long paragraph of text in a cell,
it cannot wrap text in the headers, which may lead to disfigured output

:exclamation: This is not the use case for tbl anyway, but dont try to print huge tables (several GBs),
as tbl (and rapidtable) read the entire table to memory before printing

\* Example csv were downloaded from [here](https://people.sc.fsu.edu/~jburkardt/data/csv/csv.html)

repository: Ronserruya/tbl

gha_language: Python

repo_name: Ronserruya/tbl


text:
# Zoo viewer

Zoo viewer is an interactive web-based visualizer of zoos (partially ordered sets).

## Installation

The front-end is purely client-side, which means that it is ready to use by accessing the files on a web browser.
In order to add a database, simply edit the *index.html* file to add a the following line in the zoo list:

	<option value="http://url-of-the-database.json">Name of the zoo</option>

## Databases

There are currently four databases compatible with the zoo viewer.
* [The computability menagerie](https://www.math.wisc.edu/~jmiller/menagerie.json) maintained by Joe Miller
* [The reverse mathematics zoo](http://ludovicpatey.com/zooviewer/data/rmzoo.json) maintained by Eric Astor
* [The enumeration reducibility zoo](https://www.math.wisc.edu/~jmiller/e-verse.json) maintained by Joe Miller and Mariya Soskova
* [The randomness zoo](http://ludovicpatey.com/zooviewer/data/randomness.json) of Antoine Taveneaux

## Screenshot

Here is a preview of the interface with the enumeration reducibility zoo.

![Enumeration reducibility zoo](https://github.com/LudovicPatey/zooviewer/raw/master/imgs/screenshot.png)

## Database format

The whole database is in JSON.

### Zoo

The root of the JSON object consists of two keys:

    {
		"nodes" : { "key1" : node1, "key2" : node2, ... },
		"meta" : { ... }
    }

The *nodes* key contains a *dictionary* of nodes, that is, a map of keys to nodes, which defines the graph model.
The *meta* key specifies meta information, such as the coloring functions of the nodes, or some rendering options.

### Node

A node is a vertex in the graph. It is a pet in the zoo. It has the following shape:

	{
		"uid" : unique id,
	    	"label" : string,
	    	"definition" : longer string (with possible TeX),
		"edges": {
			"key1" : Edge
			"key2" : Edge
		},
		"properties" : {
			"property1" : Property
			...
		},
		"tags" : [ "tag1", "tag2", ... ]
	}

The *uid* is a unique numerical identifier.  It gives the nodes a linear order structure.

> **Note:** The linear order is used by the viewer whenever it needs to choose between equivalent nodes which one is *primary*. Given a group of equivalent nodes, the one with smallest uid is chosen as priulary.

The *label* is a short string with with possible TeX and '\n' for multiline labels. It specifies the label of the vertex to be displayed in the graph. A longer string which possible TeX is provided by *definition*.

The *edges* key contains a dictionary of edges, whose keys are the node keys of the destination.

> **Note:** There should be a key for every destination node, even for the source node. An edge does not mean that an arrow is supposed to be displayed. It is supposed to contain various properties, from which the viewer will decide whether it should display an arrow or not.

The *properties* key contains a dictionary of properties (to be defined later), which are zoo-specific. For example, in a human zoo, the properties might be the age, or the profession.

The *tags* key contains a list of tag keys. See the tags section to settle the possible tags. A tag is a way to classify nodes. The user will have the possibility to restrict the vertices to some tags.

> **Note:** The main difference between a tag and a property, is that a tag is supposed to be an arbitrary human classification, while a property has to be justified by a proof.

### Edge

An edge is an information related to an ordered pair (source node, destination node). It is of the form

	{
		"srcKey" : key of source node,
		"dstKey" : key of destination node,
		"properties" : {
			"property1" : Property
			...
		}
	}

Every pair of nodes has an edge, even the pairs whose source equals the destination, and representing a loop edge. Whether there will actually be an arrow or not depends on the edge kind functions (defined below) which will take a decision based on the *properties* key.

*srcKey* is the key of the source node, while *dstKey* is the key of the destination node. The *properties* key contains a dictionnary of zoo-specific properties, based on which the viewer will show an arrow or not. See below for the definition of a property.

### Property

A property represents a fact (about a node, or an edge), which has to be justified by a proof, or a reference to a proof.
It is of the form

	{
		"uid" : unique id,
		"value" : anything (null if open),
		"justification" : {
			"weight" : the weight
			"direct": string with a direct justification (with possible TeX and HTML),
			"composite" : array of property uids for a composite justification
		}
	}

The *uid* is a unique numerical identifier.  It is used for the composite justifications, which refer to other properties.

The *value* key contains the value of the property, or null if it is not known.

The *justification* contains the information justifying the fact that this property has this particular value. There are two kind of justifications: the direct ones, and the composite ones. A direct justification is specified by the key *direct* which will contain a text justifying the value of the property. An obvious direct justification is specified by an empty string. A composite justification will contain an array of uids of other properties, which altogether are sufficient to justify the value of the current property. A typical composite justification is the justification of an arrow obtained by transitivity of two other arrows. Either *direct*, or *composite* must be equal to null. Moreover, *weight* equals 1 if and only if the justification is direct.

### Meta

The *meta* key in the root contains meta information, such as the coloring functions of the nodes, or the edge kinds... It is of the form

	 {
	 	"tags" : [ ... ],
		"edgeKinds" : [ ... ],
		"colorings" : [ ... ],
		"patches" : { ... }, // optional
		"about" : {
			"version" : 1, // optional
			"description" : "" // optional
		},
		"graphviz" = {
	        	"rankdir" : "TB" // optional. TB, BT, LR, RL
		}
	 }

The *tags*, *edgeKinds* and *coloring* keys contain respectively a list of tags, edge kinds, and of colorings (described below).

The *about* key is optional, and contains a dictionnary of informations about the graph. In particular, *description* contains a brief description (with possible TeX and HTML) of the database. It could basically contain some information about the zoo keeper, his email, a link to the source database, ... The *version* key should contain an integer, and is purely informative, as it is not used currently by the front-end.

The *graphviz* key contains a dictionary of options for graphviz, the rendering engine. The only option supported yet is *rankdir*, which specifies the orientation of the graph (TB for Top-Bottom, BT for Bottom-Top, LR for Left-Right and RL for... guess what).

The *patches* key is optional, and contains a dictionnary of "patches". See the patches section below.

### Tag

A tag represents a cluster of nodes. There are two kinds of tags: the static ones and the dynamical ones. The static ones are specified by a key. Any node having the tag key among its tags list will be tagged by it. A dynamical tag is specified by a filtering function. In general, a tag is of the form

	{
		"label" : "A string with possible Tex",
		"key" : "my key", // optional
		"functionBody" : "...", // optional
		"default" : true // optional
	}

The *label* key is the label of the tag to be displayed in the filter panel. It may contain TeX.

The *key* label is optional, and contains a short string in the case of a static tag. For a dynamical tag, the *functionBody* key must be specified, and must contain the body of a javascript function, with *node* as a free variable, and returning a boolean specifying whether the node should receive the tag or not.

The *default* key contains a boolean specifying whether or not the tag should be checked by default in the panel. In other words, it says whether the nodes tagged by this tag should be displayed by default or not.

### Coloring

	{
		"label" : "Name of the coloring",
		"colors" : [
			{ "color" : "lightblue", "label" : "Explanation 1" },
			{ "color" : "lightgreen", "label" : "Explanation 2" },
			...
		],
		"coloring" : "..."
	}

The *label* is the name of the coloring, to be displayed as a list, so that the user can choose which coloring to use.

The *colors* key contains a list of colors that the coloring function might output. A color is specified by some HTML color, and a label which will be displayed in the legend of the graph.

The *coloring* key must contain the body of a javascript function, with *node* as a free variable, and returning a color. For example, it could be

	"return node.properties.age.value > 5 ? 'lightblue' : 'lightgreen'"

### Edge kind

A same set of nodes might be related to each other by various kind of relations. An edge kind represents a kind of relation. For example, in reverse mathematics, one might consider implication over RCA, or the Weihrauch reduction.

	{
		"label" : "Name of the edge kind",
		"functionBody" : "...",
		"node" : { ... } // Optional
	}

The *label* should be a short string which will be displayed in a list, so that the user can choose which edge kind to use.

The *functionBody* key contains the body of a javascript function, with *node* as a free variable. It is supposed to return 0, 1 or 2, depending on whether there is provably no arrow (return 0), there is provably an arrow (return 1), or it is currently an open question (return 2). For example, it could be

	"if(!edge.properties.implication.value == null) return 2;
	return edge.properties.implication.value ? 1 : 0;"

Here, we suppose that the edges have an *implication* property, specifying whether the source implies the destination, and equal to null if it is unknown.

> **Important:** An edge kind should be a transitive relation. In other words, the transitive closure of the arrows should be precomputed by the JSON file.

The *node* key may contain an *Edge kind node* (see below). This information is useful only if there are multiple edge kinds. This enables the viewer to display, once fixed a pair of standard node, a graph of edge kind relations. This way, the user will be able to compare the edge kinds for which the given pair has an implication, or not.

### Edge kind node

An edge kind node is of the form

	{
		"label" : "a label which may contain some Tex",
		"key" : "a short unique string",
		"edges" : [ ... ]
	}

The *label* key is the string which will be displayed in the graph of edge kinds, when comparing two fixed standard nodes over various edge kinds. It may contain some TeX.

The *key* key is a short string which is unique among the edge kinds. This is used for the edges relation.

The *edges* key contains a list of other edge kind keys. There is an arrow from an edge kind to another edge kind if having an implication of the first kind implies having an implication of the second kind. The relation between edge kinds in not transitive.

### Patch

There are some places in the front-end were the zookeeper needs to replace the standard formatting functions by some custom functions. A patch is a javascript function specified in the JSON database, and which will replace a function in the front-end. It is part of the dictionary *patches* of the *meta* key. It is of the form

	"patches" : {
		"patch key" : "function body"
	}

There are a few patch keys, whose extensive list is available in [scripts/tools/patches.js](https://github.com/LudovicPatey/zooviewer/raw/master/scripts/tools/patches.js). The value is a string of a javascript function body whose free variables are the same as the corresponding function in [scripts/tools/patches.js]. The original function is available at "patch key.original". For example, you can set

	"patches" : {
		"panel.contextual.property" : "var ret = Patches['panel.contextual.property.original'].call(this, key, property); return 'customized ' + ret;"
	}

This patch will add the prefix "customized " to every property description in the contextual panel.

## Credits

This visualizer has many inspirations.
The whole story started with the computability diagram of Bjørn Kjos-Hanssen available [here](http://www.math.wisc.edu/~jmiller/Menagerie/bn1g.pdf). Joe Miller developped a command line tool for managing a subset of the computability diagram, and extracting the open questions, among others. The [computability menagerie](http://menagerie.math.wisc.edu/) was born. Mushfeq Khan created a web interactive visualizer of the computability menagerie. Damir Dzhafarov modified the command line tool of the computability menagerie to create a [reverse mathematics zoo](http://rmzoo.math.uconn.edu). This [tool](http://rmzoo.math.uconn.edu) was largely rewritten and improved by Eric Astor. Last, facing the need of a new scalable and generalized visualiser, Joe Miller and Ludovic Patey designed a new interactive interface.

Many people have helped with the various zoos, by commenting on the code, contributing facts, suggesting new features, or just expressing their interest. Thanks in particular to David Belanger, Peter Cholak, Stephen Flood, Denis Hirschfeldt, Steffen Lempp, Antonio Montalbán, Carl Mummert, Sam Sanders, Mariya Soskova and Ted Slaman.

repository: ericastor/zooviewer

repo_name: ericastor/zooviewer


text:
Quality statement 2: Inhaler technique {.title}
--------------------------------------

### Quality statement {.title}

People with chronic obstructive pulmonary disease (COPD) who are
prescribed an inhaler have their inhaler technique assessed when
starting treatment and then regularly during treatment. **[2011, updated
2016]**

### Rationale {.title}

Bronchodilator therapy is usually delivered using a hand‑held inhaler
device. People with COPD need to use their inhaler correctly to receive
the optimal treatment dose. Assessing inhaler technique should happen at
the first prescription once a person has been taught the correct
technique, and then be reassessed regularly (for example, at their
annual review, if their treatment changes or after an acute
exacerbation) throughout the duration of a person's treatment in
primary, community and secondary care services.

### Quality measures {.title}

#### Structure {.title}

a) Evidence of local arrangements and written clinical protocols to
ensure that people with COPD who are prescribed an inhaler have their
technique assessed at the start of treatment and then regularly during
their treatment.

***Data source:*** Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

b) Evidence of local arrangements and written clinical protocols to
ensure that healthcare professionals in primary, community and secondary
care services are trained and competent in teaching inhaler technique.

***Data source:*** Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

#### Process {.title}

a) Proportion of people with COPD prescribed an inhaler who have their
inhaler technique assessed at the start of treatment.

Numerator – the number in the denominator who have their inhaler
technique assessed at the start of treatment.

Denominator – the number of people with COPD prescribed an inhaler.

***Data source:*** Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

b) Proportion of people with COPD prescribed an inhaler who have their
inhaler technique assessed at their annual review.

Numerator – the number in the denominator whose last inhaler annual
review was no longer than 12 months since the previous one or since
inhaler initiation.

Denominator – the number of people with COPD prescribed an inhaler for
more than 12 months.

***Data source:*** Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

c) Proportion of people with COPD prescribed an inhaler who have their
inhaler technique assessed after a change in treatment.

Numerator – the number in the denominator who had their inhaler
technique assessed after a change in treatment.

Denominator – the number of people with COPD prescribed an inhaler who
have had their inhaler changed.

***Data source:*** Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

d) Proportion of people with COPD prescribed an inhaler who have their
inhaler technique assessed after an acute exacerbation.

Numerator – the number in the denominator who had their inhaler
technique assessed after an acute exacerbation.

Denominator – the number of people with COPD prescribed an inhaler who
have had an acute exacerbation.

***Data source:*** Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

#### Outcome {.title}

a) Exacerbation rates.

***Data source:***Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

b) Hospital admissions.

***Data source:***Local data collection. Royal College of Physicians'
[National COPD Audit
Programme](https://www.rcplondon.ac.uk/projects/national-copd-audit-programme-starting-2013).

### What the quality statement means for service providers, healthcare professionals and commissioners {.title}

**Service providers** (primary care services, community services and
secondary care services) ensure that systems are in place and healthcare
professionals are trained and competent to teach people with COPD who
are prescribed an inhaler the correct inhaler technique and to assess
their inhaler technique when starting treatment and regularly during
their treatment.

**Healthcare professionals** (nurses, GPs, secondary care doctors,
physiotherapists, occupational therapists and pharmacists) ensure that
they provide training in the correct inhaler technique to people with
COPD when they have been prescribed an inhaler. Healthcare professionals
ensure that they assess the person's inhaler technique when starting
treatment and regularly during their treatment.

**Commissioners** (clinical commissioning groups) ensure that they
commission services in which people with COPD who are prescribed an
inhaler are trained and assessed in the correct inhaler technique when
they start treatment, and have their technique reassessed regularly
during their treatment.

### What the quality statement means for patients, service users and carers {.title}

**People with COPD** who are given an inhaler have a check to make sure
that they can use it correctly when they start treatment and at least
once a year at their annual review. They should also have a check if
their treatment changes or after a sudden flare up of their symptoms
(called an acute exacerbation).

### Source guidance {.title}

-   [Chronic obstructive pulmonary
    disease](http://www.nice.org.uk/guidance/cg101) (2010) NICE
    guideline CG101, recommendations <IP_ADDRESS>, <IP_ADDRESS> and <IP_ADDRESS>

### Equality and diversity considerations {.title}

Elderly people, or people with learning disabilities, physical
disabilities or cognitive impairment may experience difficulties
learning and retaining the adequate inhaler technique to ensure that
they get the optimal treatment dose. An individual patient assessment
should be carried out before choosing the most appropriate device for
delivery of inhaled therapy.

license: Unlicense

repository: forki/ld-utilities

gha_license_id: Unlicense

repo_name: forki/ld-utilities


text:
---
layout: default
permalink: /abstracts/soicher
---

## Leonard Soicher

### Exploiting graph symmetry in the computation of chromatic number

I will discuss the recent GRAPE package functionality which exploits
the automorphism group of a graph in the computation of its chromatic
number. In particular, I will point out the GAP permutation group machinery
which is used.


text:
CppAwait
========

CppAwait is a C++ library that enables writing asynchronous code in a natural (sequential) form.

It solves the code flow inversion typical of asynchronous APIs. So -- instead of chaining callbacks, dealing with state and error codes -- you can use plain conditionals, loops and exception handlers to express your asynchronous algorithm.

The goal: make it easier to write responsive applications that have to deal with laggy network & file I/O.

How it works
============

CppAwait provides an _await_ construct similar to the one from C# 5 (see [MSDN](http://msdn.microsoft.com/en-us/library/hh191443.aspx)). Upon reaching an _await_ expression the C# compiler automatically transforms the rest of the method into a task continuation. In C++ a similar effect can be achieved through coroutines (which CppAwait implements on top of Boost.Context). Calling _await()_ will suspend a coroutine until the associated task completes. The program is free to do other work while coroutine is suspended.

Your program needs a run loop to manage asynchronous operations.

Here is a snippet showing typical library use. It connects and transfers some data to a TCP server:

    ut::Awaitable awt;

    tcp::resolver::iterator outEndpoints;
    awt = ut::asio::asyncResolve(resolver, query, outEndpoints);
    awt.await();

    for (auto it = outEndpoints; it != tcp::resolver::iterator(); ++it) {
        tcp::endpoint ep = *it;
        awt = ut::asio::asyncConnect(socket, ep);

        try {
            awt.await();
            break; // connected
        } catch (const std::exception&) {
            // try next endpoint
        }
    }
    if (!socket.is_open()) {
        throw SocketError("failed to connect socket");
    }

    // write an HTTP request
    awt = ut::asio::asyncWrite(socket, request);
    awt.await();

    // read response
    awt = ut::asio::asyncReadUntil(socket, outResponse, std::string("\r\n"));
    awt.await();

The _Awaitable_ class is a generic wrapper for asynchronous operations. All asynchronous methods return an _Awaitable_. Its _await()_ method yields control to the main loop until the _Awaitable_ completes or fails, at which point the coroutine resumes. If operation failed the associated exception gets thrown. Note there is no return value -- output parameters such as _endpoints_ must be passed by reference.

_Awaitables_ compose easily, just like regular functions. More complex patterns are supported through _awaitAll()_ / _awaitAny()_.

Another snippet. Download and archive some files, allowing for archival while next download is in progress:

    std::vector<std::string> urls = { ... };

    ut::Awaitable awtArchive;

    for (std::string url : urls) {
        // holds fetched document
        std::unique_ptr<std::vector<char> > document;

        ut::Awaitable awtFetch = asyncFetch(url, &document);

        // doesn't block, instead it yields. the coroutine
        // gets resumed when fetch done or on exception.
        awtFetch.await();

        if (!awtArchive.isNil()) {
            awtArchive.await();
        }
        awtArchive = asyncArchive(std::move(document));
    }

There are several [examples](/Examples) included. See [stock client](/Examples/ex_stockClient.cpp) for a direct comparison between classic async and the await pattern.

Features
========

- coroutines, iterable generators

- composable awaitables

- support for exceptions

- can adapt any asynchronous API

- Boost.Asio wrappers

- pluggable into any program with a run loop

- good performance with stack pooling

- customizable logging

- portable

Installation
============

1. __Install [Boost](http://www.boost.org/users/download/).__ To use CppAwait you need Boost 1.54+ with _Boost.Context_, _Boost.Coroutine_ and _Boost.System_ compiled [[*]](#msvc10). Quick guide:

   - download Boost archive
   - ./bootstrap
   - ./b2 --build-type=minimal --with-context --with-coroutine --with-chrono --with-thread --toolset=your-toolset stage

2. __Install [CMake](http://www.cmake.org/cmake/resources/software.html) 2.8+__

3. __Build CppAwait__:

   - mkdir build\_dir ; cd build\_dir
   - cmake -G "your-generator" -DBOOST\_INCLUDEDIR="path-to-boost" -DBOOST\_LIBRARYDIR="path-to-boost-libs" "path-to-CppAwait"
   - open solution / make

(*) Visual C++ 2010 doesn't implement the thread library. In this case _Boost.Chrono_ and _Boost.Thread_ are also required to compile the examples.

Portability
===========

The library is supported on Windows / Linux with any of these compilers:

   - Visual C++ 2010 or later
   - GCC 4.6.2 or later

Boost.Context includes assembly code for ARM / MIPS / PowerPC32 / PowerPC64 / X86-32 / X86-64.

Porting to additional platforms (e.g. iOS, Android) should be trivial.

Authors
=======

Valentin Milea<EMAIL_ADDRESS>

License
=======

    Copyright 2012-2013 Valentin Milea

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

repository: navrocky/CppAwait

repo_name: navrocky/CppAwait


text:
# ClientInformation

This component provides the user with information about the app and lib versions as well as the user's device ID. The device ID is only shown if the user touches and holds on the component for 5 seconds. Additionally a message is posted in #app_debug_logging and debug logging is enabled.

## Getting Started

```jsx
import ClientInformation from 'Components/ClientInformation';

<ClientInformation />
```

## Props

### client (required)

_Type_: `shape`
_Values_: `{ isFetching: [bool], appVersion: [string], libVersion: [string], deviceId: [string] }`

The data for this props comes from the client connector.

### enableDebugLogging (required)

_Type_: `function`

Will be called when debug logging shall be enabled.

repository: Bettina-Baumert/theme-gmd

repo_name: Bettina-Baumert/theme-gmd