text:
# Federated Optimization

This directory contains source code for evaluating federated learning with
different optimizers on various models and tasks. The code was developed for a
paper, "Adaptive Federated Optimization"
([arXiv link](https://arxiv.org/abs/2003.00295)). For a more general look at
using TensorFlow Federated for research, see
[Using TFF for Federated Learning Research](https://www.tensorflow.org/federated/tff_for_research).

Some pip packages are required by this library, and may need to be installed:

```
pip install absl-py
pip install attr
pip install dm-tree
pip install numpy
pip install pandas
pip install tensorflow
pip install tensorflow-federated
```

We also require [Bazel](https://www.bazel.build/) in order to run the code.
Please see the guide
[here](https://docs.bazel.build/versions/master/install.html) for installation
instructions.

### Directory structure

This directory is broken up into six task directories. Each task directory
contains task-specific libraries (such as libraries for loading the correct
dataset), as well as libraries for performing federated and non-federated
(centralized) training. These are in the `optimization/{task}` folders.

A single binary for running these tasks can be found at
`main/federated_trainer.py`. This binary will, according to `absl` flags, run
any of the six task-specific federated training libraries.

There is also a `shared` directory with utilities specific to these experiments,
such as implementations of metrics used for evaluation.

### Example usage

Suppose we wish to train a convolutional network on EMNIST for purposes of
character recognition (`emnist_cr`), using federated optimization. Various
aspects of the federated training procedure can be customized via `absl` flags.
For example, from this directory one could run:

```
bazel run main:federated_trainer -- --task=emnist_cr --total_rounds=100
--client_optimizer=sgd --client_learning_rate=0.1 --client_batch_size=20
--server_optimizer=sgd --server_learning_rate=1.0 --clients_per_round=10
--client_epochs_per_round=1 --experiment_name=emnist_fedavg_experiment
```

This will run 100 communication rounds of federated training, using SGD on both
the client and server, with learning rates of 0.1 and 1.0 respectively. The
experiment uses 10 clients in each round, and performs 1 training epoch on each
client's dataset. Each client will use a batch size of 10 The `experiment_name`
flag is for the purposes of writing metrics.

To try using Adam at the server, we could instead set `--server_optimizer=adam`.
Other parameters that can be set include the batch size on the clients, the
momentum parameters for various optimizers, and the number of total
communication rounds.

### Task and dataset summary

Below we give a summary of the datasets, tasks, and models used in this
directory.

<!-- mdformat off(This table is sensitive to automatic formatting changes) -->

| Directory        | Dataset        | Model                             | Task Summary              |
|------------------|----------------|-----------------------------------|---------------------------|
| cifar100         | [CIFAR-100](https://www.tensorflow.org/federated/api_docs/python/tff/simulation/datasets/cifar100/load_data)      | ResNet-18 (with GroupNorm layers) | Image classification      |
| emnist           | [EMNIST](https://www.tensorflow.org/federated/api_docs/python/tff/simulation/datasets/emnist/load_data)         | CNN (with dropout)                | Digit recognition         |
| emnist_ae        | [EMNIST](https://www.tensorflow.org/federated/api_docs/python/tff/simulation/datasets/emnist/load_data)         | Bottleneck network                | Autoencoder               |
| shakespeare      | [Shakespeare](https://www.tensorflow.org/federated/api_docs/python/tff/simulation/datasets/shakespeare/load_data)    | RNN with 2 LSTM layers            | Next-character prediction |
| stackoverflow    | [Stack Overflow](https://www.tensorflow.org/federated/api_docs/python/tff/simulation/datasets/stackoverflow/load_data) | RNN with 1 LSTM layer             | Next-word prediction      |
| stackoverflow_lr | [Stack Overflow](https://www.tensorflow.org/federated/api_docs/python/tff/simulation/datasets/stackoverflow/load_data) | Logistic regression classifier    | Tag prediction            |

<!-- mdformat on -->

### Using different optimizers

In our work, we compare 5 primary optimization methods: **FedAvg**, **FedAvgM**,
**FedAdagrad**, **FedAdam**, and **FedYogi**. The first two use SGD on both
client and server (with **FedAvgM** using server momentum of 0.9) and the last
three use an adaptive optimizer on the server. To recreate our experimental
results for each optimizer, use the following optimizer-specific flags:

*   **FedAvg**: `--server_optimizer=sgd --server_sgd_momentum=0.0`
*   **FedAvgM**: `--server_optimizer=sgd --server_sgd_momentum=0.9`
*   **FedAdagrad**: `--server_optimizer=adagrad
    --server_adagrad_initial_accumulator_value=0.0`
*   **FedAdam**: `--server_optimizer=adam`
*   **FedYogi**: `--server_optimizer=yogi
    --server_yogi_initial_accumulator_value=0.0`

Note that for adaptive optimizers, one should also set the parameter tau in the
full description of our algorithms (see the accompanying paper). This parameter
is referred to as epsilon in our code, and can be set via `--server_{adaptive
optimizer}_epsilon={tau value}`. In general, we recommend a value of at least
0.001 in most tasks. The best values for each task/optimizer are fully
documented in the accompanying paper.

For FedAdagrad and FedYogi, we use implementations of Adagrad and Yogi that
allow one to select the `initial_accumulator_value` (see the Keras documentation
on
[Adagrad](https://www.tensorflow.org/api_docs/python/tf/keras/optimizers/Adagrad)).
For all experiments, we used initial accumulator values of 0 (which is the
implicit value set by default in the Keras implementation of
[Adam](https://www.tensorflow.org/api_docs/python/tf/keras/optimizers/Adam)).
While this can be tuned, we recommend first tuning other values, especially the
`epsilon` value.

In all of the cases above, the `--client_learning_rate` and
`--server_learning_rate` must be set as well. For a detailed reference of the
best hyperparameters for each optimizer and task, see the appendix in our
accompanying paper.

### Other hyperparameters and reproducibility

All other hyperparameters are set by default to the values used in the `Constant
learning rates` experiments of Section 5 in our paper. This includes the batch
size, the number of clients per round, the number of client epochs, and model
parameter flags. While they can be set for different behavior (such as varying
the number of client epochs), they should not be changed if one wishes to
reproduce the results from our paper. Thus, to recreate our experiments, one can
use the command

```
bazel run main:federated_trainer -- {optimizer flags}
--experiment_name={experiment name}
```

where the optimizer flags are discussed above. The metrics of the training
procedure are logged and written to the directory `tmp/fed_opt/{experiment
name}`.

While we have attempted to make our results as reproducible as possible by even
setting a seed to recreate which clients were sampled at each round (governed by
`--client_dataset_seed`), we note that randomness in client sampling and
heterogeneity across clients can lead to greater variance than in centralized
machine learning settings. We also note that choices of optimizer
hyperparameters are often vital.

repository: mhalawad/federated

repo_name: mhalawad/federated


text:
This document describes the actions that have to be executed successfully for
both of anthill's CRDs to be considered reconciled. They are implemented as
`reconciler.Action` objects, and are enumerated in a `reconciler.Procedure`
object. Procedure level actions are ones that modify state and should have a
corresponding entry populated in
`.Status.ReconcileActions map[string]reconciler.Result`.
Top level actions are executed in an arbitrary order so they must define any
prerequisite actions explicitly.
An action may be a top-level action and still defined as a prerequisite and the
caching implementation will ensure that it is executed a maximum of once per
Procedure execution.

# GlusterCluster actions

![Action Graph](deploy_procedure.dot.png)

## etcdClusterReconciled

prereqs:

- [etcdCRDRegistered](#etcdCRDRegistered)

## etcdCRDRegistered

## csiAttacherReconciled

## csiNodePluginReconciled

## csiProvisionerReconciled

## glusterClusterServicesReconciled

prereqs:

- [glusterNodesReconciled](#glusterNodesReconciled)

## glusterNodesReconciled

prereqs:

- [etcdClusterReconciled](#etcdClusterReconciled)

## managedDevicesReconciled

- [glusterClusterServicesReconciled](#glusterClusterServicesReconciled)

# GlusterNode actions

![Action Graph](deploy_procedure.dot.2.png)

`GlusterNode` CRs can be created manually or by the `GlusterCluster` Controller
according to a `template`.`GlusterCluster`s that consume local storage via
`hostPath` require their `GlusterNode`s to be created manually and have
`nodeAffinity` set in a way that it will only be scheduled on that node.

## statefulSetReconciled

repository: gluster/anthill

branch_name: refs/heads/master

extension: md

gha_language: Go

license_type: permissive

repo_name: gluster/anthill


text:
# Weather Widget

A very simple weather widget, intended as a demo for the React Hooks API.

Weather Icons courtesy of [owfont](http://websygen.github.io/owfont/).

Project bootstrapped with [Create React App](https://github.com/facebook/create-react-app). I wouldn't normally use this
as I feel it is overkill, however, it's a quick way to get up and running with a demo app.

## Run me!

This project uses [Yarn 2 zero-installs](https://next.yarnpkg.com/features/zero-installs), so simply clone/fork the repo, then:

```
yarn start
```

This runs the app in development mode (using webpack server with hot-reloading). Open [http://localhost:3000](http://localhost:3000) to view in a browser.

Any lint errors will be visible in the console.

## Widget me!

If you want to see it as a desktop widget, give OpenFin a try:

```
# Run this in one terminal
yarn start

# Run this in another terminal
yarn dlx -p openfin-cli openfin --launch --config openfin.json
```

## Learn More

- Learn about [React](https://reactjs.org/) and its [Hooks API](https://reactjs.org/docs/hooks-reference.html)
- Read about [Create React App](https://facebook.github.io/create-react-app/docs/getting-started)

license: Unlicense

repository: chriswilty/weather-widget

gha_language: JavaScript

gha_license_id: Unlicense

repo_name: chriswilty/weather-widget


text:
# Exporters (also called generators)

Exporters get two php arrays:

- head
- body

and generate target string based on them.

Exporter must have at least 3 methods:

- setHead (will set head of the table)
- setBody (will set body of the table)
- getTarget (should return output string in right format)

See Exporter/ExporterInterface for details.

## Built-in exporters

There are several built-in exporters:

- json
- xml
- html_table
- html_ul
- ascii_table
- csv

You can override this exporters by setting up your class parameter.
You can also modify them by extending in your exporter.

## Writing your own exporters

To create your own exporter you must create class with three methods mentioned above: setHead, setBody, getTarget

For example:

``` php
use Pvessel\TableConverterBundle\Exporter\ExporterInterface;

class ExcelExporter implements ExporterInterface
{
    public function setHead(array $oneDimensionArray)
    {
        // this can be good place to "pregeneration" of table header
    }

    public function setBody(array $twoDimensionArray)
    {
        // this can be good place to "pregeneration" of table content
    }

    public function getTarget()
    {
        // generate your output string here
        return $string
    }
}
```

Then let TableConverterBundle know about it by adding "pvessel_array_converter.exporter" tag with alias to service file in your bundle.

For example:

``` yaml
    my_own_bundle.table_exporter.excel:
        class: Vendor\MyOwnBundle\Importer\ExcelExporter
        tags:
            -  { name: pvessel_table_converter.exporter, alias: excel }
```

Use your importer alias when you want to convert table.

For example:

``` php
$convertedTable = $this->container->get('pvessel_table_converter.manager')
                                  ->setSource($xmlString)
                                  ->convert('xml', 'excel')
                                  ->getTarget();
```

This should return your table in excel format.

[Back to the index](index.md)

license: MIT

repository: pvessel/table-converter-bundle

repo_name: pvessel/table-converter-bundle


text:
---
title: Miami will consider marking the
tags:
  - Jun 1915
---

Miami will consider marking the waterway to Key West.

Newspapers: **Daily Miami Metropolis, The Miami Metropolis (daily), The Daily Metropolis or Miami Daily Metropolis**

Page: **2**, Section: **N/A**


text:
# vim-node-inspect
Interactive node debugger for (n)vim.

## Description
Node debugging capabilities for (n)vim using the devtools protocol. Under the hood it wraps a modified version of node-inspect *(https://github.com/nodejs/node-inspect)*.

[![asciicast](https://asciinema.org/a/NOCL8Fc3LcQjVDD0CIR08I698.svg)](https://asciinema.org/a/NOCL8Fc3LcQjVDD0CIR08I698)

## Requirements
Vim**8.1+**/Recent Neovim.
Node in the path.

## Installation
Install with your favorite package manager. For vim-plug its
```
Plug 'eliba2/vim-node-inspect'
```

## How to use
Either start a node script or attach to an already running script. Both can be done manually (NodeIndpectStart/NodeInspectRun) or using the configuration file vim-node-config.json. The later is encouraged.

For full documentation see :h vim-node-inspect.

### Starting Manually ###

Either start debugging a local js file (via NodeInspectStart or NodeInspectRun) or connect to a running instance using NodeInspectConnect. In the later case the target must start with --inspect (e.g. node --inspect server.js).

### Using the configuration file ###

Use the configuration file to define the starting method. Create a file named **"vim-node-config.json"** in the current working directory. The format is json, and the available options are:

**"request"** - either "launch" or "attach". The former is for executing a script. The second is for connecting to a running node instance.

**"program"** - in the case of "launch", this is the script's filename and must be present.

A sample configuration for launch would be:
```
{
	"request": "launch",
	"program": "/Users/eli/Tests/test.js",
	"args": ["first", "second"],
	"cwd": "/path/to/dir"
}
```

Use absolute paths. "${workspaceFolder}" can be used, it equals to the current working directory (:pwd).

**"args"** - an array list of script arguments. Relevant only to "launch", optional.

**"address"** - in the case of "attach", this is the address to connect to. Can be omitted, in this case it defaults to "<IP_ADDRESS>".

**"port"** - in the case of "attach", this is the port to connect to. Must be present.

**"cwd"** - working directory for running the script. Defaults to (n)vims current directory. Optional.

**"envFile"** - path to a file containing environment variables. Optional.

**"env"** - JSON object containing environment variables definition. Takes precedence over envFile. Optional.

A sample configuration for attach would be:

```
{
	"request": "attach",
	"port": 9229
}
```

### Exiting ###

**NodeInspectStop** will stop debugging and close the debugging windows. It will kill the node session in the case it was launched.

Pressing Crtl+D or CTRL+C twice in the command window has a similar effect.

### Automatically restarting the debug session ###

When using an application to monitor changes and restart the node session (such as nodemon or pm2) it is useful to restart the debug session as well. This can be done with the restart parameter, relevant only to an attach request:

```
{
	"request": "attach",
	"port": 9229,
	"restart": true
}
```

### Other possible configuration file locations

It is possible to have several config files in case the workspace has several projects who share the same root. In case the configuration file is not found in the current working directory, the curent buffer's directory is searched all the way to the top (as long it is a descendant of the working directory).

### Multiple configurations

Multiple configurations can be defined by setting a **"configurations"** object which lists the possible configurations, each having a **"name"** key which uniquly identifies it. **"NodeInspectStart"** or **"NodeInspectRun"** must be used followed by at least one parameter which is the configuration name. Other starting parameters might follow.

A sample configuration would be:
```
{
	"configurations": [
		{
			"name": "connect",
			"request": "attach",
			"port": 9229
		},
		{
			"name": "run",
			"request": "launch",
			"program": "${workspaceFolder}/server.js"
		}
	]
}

```

Usage in this case would be either *NodeInspectStart "run"* or *NodeInspectStart "connect"* .

## Available Commands

The following commands are available:

**NodeInspectStart [config name] [args]** - Starts debugger, paused

**NodeInspectRun [config name] [args]** - Continue / Start and run immediatly

**NodeInspectConnect host:port** - Connect to a running instance

**NodeInspectStepOver** - Step over

**NodeInspectStepInto** - Step into

**NodeInspectStepOut** - Step out

**NodeInspectStop** - Stop debugging (and kill the node instance)

**NodeInspectToggleBreakpoint** - Toggle breakpoint

**NodeInspectRemoveAllBreakpoints** - Removes all breakpoints

**NodeInspectAddWatch** - Add the word under the cursor to the watch window

**NodeInspectToggleWindow** - Show/Hide the node inspect window

There are no default bindings; the following is added for convinience:
```
nnoremap <silent><F4> :NodeInspectStart<cr>
nnoremap <silent><F5> :NodeInspectRun<cr>
nnoremap <silent><F6> :NodeInspectConnect("<IP_ADDRESS>:9229")<cr>
nnoremap <silent><F7> :NodeInspectStepInto<cr>
nnoremap <silent><F8> :NodeInspectStepOver<cr>
nnoremap <silent><F9> :NodeInspectToggleBreakpoint<cr>
nnoremap <silent><F10> :NodeInspectStop<cr>
```

## Breakpoints

The plugin saves your breakpoint's locations between Vim sessions. Once the plugin is started it will try and re-activate the breakpoints for the current location, that's for all the breakpoints which root in the current working directory.

Note breakpoints are triggered through Vim and resolved in node, so resolved locations might differ from the triggered ones.
The breakpoints signs appear in the resolved locations.

## Watches

There are two ways to add a watch. One is to use the *NodeInspectAddWatch* command which will add the word under the cursor as a watch. The other is by directly editing the watch window: this will resolve the watches, one per line.
Remove a watch by deleting it from the watch window.

### Auto watches

The variables in the current scope will be automatically displayed in the watches window prefixed by an 'A'. This behavior can be disabled by setting g:nodeinspect_auto_watch to 0 (1 is default).

## Connecting to a running container

You'll need to configure the local and remote directories when connecting to a remote host or the local instance will set the wrong breakpoints locations. Use the configuration file to set these directories, such as:

```
{
	"request": "attach",
	"port": 9229,
  	"localRoot": "/Users/eli/projects/my-test-project",
  	"remoteRoot": "/app"
}
```
Make sure to use full paths.

## Other Customizations

The debugger windows appear on the bottom by default. Change it by using

```
let g:nodeinspect_window_pos = 'right'|'left'|'bottom'
```

The command window starts in repl mode by default. It gives you a javascript shell corresponding to the current scope. If you are familiar with node-inspect and/or want to use the command mode - which enables executing debugging commands manually - use the following setting:

```
let g:nodeinspect_start_repl = 0
```

## Remarks
In beta. Means its useful; things may change or fail.

Tested on Linux (debian), OSX, Windows.

## Roadmap

* Debugging window
	* Detachable
	* position change
* Watches
	* Auto watches
	* Open/Close properties
	* On the fly evaluation (popup)
* Breakpoints
	* Breakpoints window
* Call stack
	* Auto jump
* Windows Support

## Contributing

PR are welcome. Open a new issue in case you find a bug; you can also create a PR fixing it yourself of course.
Please follow the general code style (look@the code) and in your pull request explain the reason for the proposed change.

## License
MIT.


text:
# Tank game

## Description
This is a 2D game that is about tank fighting. The game is not finished. There are now twenty tanks and one test map.  You can create your own map in the map editor.

## Tanks
Each tank has different properties (speed, health, driving speed, shell speed, ...). Now in the game are heavy, medium, light and TD tanks. The tank explodes and starts burning after their destruction.

## Map editor
You can create your own map. There are some basic block, by left mouse button you placed on the ground. By right mouse button you can changing your view position. You can also add some objects (tree, rock, house, ...). Double right mouse button click open menu with objects that can be added. Each map must have seted up position where will spawn player.

## Author
* Martin Krčma


text:
Serling Enterprises buys long steel rods and cuts them into shorter rods, which it then sells. Each cut is free. Given a rod of length  `n`  and an array of prices  `v`, where  `v[i]`  stands for the price of a piece with a length of  `i`, determine the maximum revenue that you can obtain by cutting up the rod and selling the pieces.

Example

For  `n = 4`  and  `v = [0, 2, 4, 7, 7]`, the output should be
`rodCutting(n, v) = 9`.

A rod with a length of  `4`  costs  `7`. You can cut it into  `4`  pieces of length  `1`  - this variant will have a revenue of  `8`. You can cut it into  `2`  pieces of length  `2`  - this variant will also have a revenue of  `8`. You can also cut it into pieces of lengths  `1`  and  `3`  - this variant will have a revenue of  `2 + 7 = 9`, which is the maximum possible.

Input/Output

-   **[execution time limit] 4 seconds (js)**

-   **[input] integer n**

    An integer that represents the length of the original steel rod.

    _Guaranteed constraints:_
    `1 ≤ n ≤ 1000`.

-   **[input] array.integer v**

    An array of integer prices, where  `v[i]`  stands for the price of a piece that has a length of  `i`.

    _Guaranteed constraints:_
    `v.length = n + 1`,
    `v[0] = 0`,
    `0 ≤ v[i] ≤ 1000, i ≠ 0`.

-   **[output] integer**

    -   The maximum revenue possible.

repository: M-Ekrim/codeSignal

repo_name: M-Ekrim/codeSignal


text:
---
title: Destroy TiDB Clusters in Kubernetes
summary: Learn how to delete TiDB Cluster in Kubernetes.
category: how-to
---

# Destroy TiDB Clusters in Kubernetes

This document describes how to deploy TiDB clusters in Kubernetes.

To destroy a TiDB cluster in Kubernetes, run the following commands:

{{< copyable "shell-regular" >}}

```shell
helm delete <release-name> --purge
```

The above commands only removes the runining Pod with the data still retained. If you want the data to be deleted as well, you can use the following commands:

> **Warning:**
>
> The following commands deletes your data completely. Please be cautious.

{{< copyable "shell-regular" >}}

```shell
kubectl delete pvc -n <namespace> -l app.kubernetes.io/instance=<release-name>,app.kubernetes.io/managed-by=tidb-operator
```

{{< copyable "shell-regular" >}}

```shell
kubectl get pv -l app.kubernetes.io/namespace=<namespace>,app.kubernetes.io/managed-by=tidb-operator,app.kubernetes.io/instance=<release-name> -o name | xargs -I {} kubectl patch {} -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
```

repository: weekface/docs-tidb-operator

repo_name: weekface/docs-tidb-operator


text:
---
layout: default
---

# 1993-12-24 - Privacy and Public Libraries

## Header Data

From: Michael Edward Marotta<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 672aa1fa4f80315c68c24c77131dadcdc3db0db80bf6a93b8cdad136784f5925

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1993-12-24 17:51:33 UTC

Raw Date: Fri, 24 Dec 93 09:51:33 PST

## Raw message

```
{% raw  %}From: Michael Edward Marotta<EMAIL_ADDRESS>Date: Fri, 24 Dec 93 09:51:33 PST
To<EMAIL_ADDRESS>Subject: Privacy and Public Libraries
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

YOUR PUBLIC LIBRARIES AND YOUR PERSONAL PRIVACY
by Michael E. Marotta<EMAIL_ADDRESS>
Generally speaking, librarians are very sensitive to the issues
surrounding privacy.  As a rule, they protect the privacy of
their patrons and they especially resist law enforcement requests
for information about anyone's reading habits.

There are some exceptions.

A librarian can be coersed or cajoled into releasing privileged
information.  Unless they are very sure of their principles, an
effective police interrogator will break down their resistance.
Possible ploys run from pleas for professional assistance in
criminal cases to good cop/bad cop.

Here in Michigan, we have 455 MPA 1982, "The Michigan Library
Privacy Act."  In a recent case involving a librarian I met, the
sheriff harassed the staff at a small, rural library.  They
refered him to her.  She told him that her hands were tied: she
was forbidden by law from doing what he asked.  He went away.  I
have heard of other librarians in other states going to jail,
having no law to fall back on.

Also, here in Livingston County, we have MANUAL cards.  You write
your name.  I can look at any book and see who read it.  This is
a violation of the law.  Since no remedies obtain, I can't get a
lawyer interested.  My protest to the library was met with "We
are changing. It will take some time."   Furthermore, when
working onsite at a Ford Motor Company plant in Louisville, I
discoverd that the Shelby County Library also relies on hand-
written checkout cards.  However, here in Fowlerville, the
librarian instituted card numbers several years ago, so our
village of 3,000 is in compliance.  Is yours?

{% endraw %}
```

## Thread

+ Return to [December 1993](/archive/1993/12)

+ Return to "[Michael Edward Marotta <mercury@well.sf.ca.us>](/authors/michael_edward_marotta_mercury_at_well_sf_ca_us_)"

+ 1993-12-24 (Fri, 24 Dec 93 09:51:33 PST) - Privacy and Public Libraries - _Michael Edward Marotta<EMAIL_ADDRESS>

gha_license_id: MIT


text:
# Illumos Telegraf Plugins

This is a collection of Illumos-specific
[Telegraf](https://github.com/influxdata/telegraf) input plugins which I wrote
because I needed them.

They work fine on my OmniOS boxes, collecting the information which I wanted
to see, and presenting it in a way I think is useful. I'm not sure exactly how
well they will work on SmartOS, but my guess would be "fine".

Things to note.

* Most of the plugins use KStats, and the KStat values are sent "as is". That
  is, I do not calculate rates inside Telegraf. Things like CPU usage, which
  the kernel measures as "total time spent on CPU" will just go up and up. I
  don't mind this because my graphing software
  ([Wavefront](https://wavefront.com)) lets me wrap the series in a `rate()`
  function.
* The testing sample is very small. You may have hardware which produces
  different KStats to mine, so you may be missing tags in places. I'm thinking
  specifically of disks, but who knows what else.
* Some of the plugins (e.g. memory) will work on an x86 Solaris system, but
  some (e.g. SMF) won't.  I'd be delighted to receive  PRs if
  anyone modifies the code to work right across SunOS.
* I have no interest in getting any of these plugins merged with the official
  Telegraf distribution. Illumos is a serious minority interest these days,
  and I can't imagine the Telegraf people have any desire to be encumbered
  with support for it. There are also difficulties in testing and
  cross-compilation, because the KStats module uses CGo. If someone wants to
  chase this, make a fork, or in any way improve the end-user experience, help
  yourself.
* You can only run the tests on an Illumos box. Properly mocking all the KStat
  calls wasn't something I wanted to get involved in.

All of that said, I've found the plugins reliable and useful.

## Building

This isn't a self-contained software package. It's effectively a big patch to
Telegraf, and you'll have to do a little work to build it.

First, of course, you need a build environment. I use and OmniOS `lipkg`
zone with the following packages.

```
developer/build/gnu-make
developer/versioning/git
ooce/developer/go-116
```

I also have `golangci-lint` installed, because I am an insane masochist who
apparently doesn't think Go has enough petty and arbitrary rules built into
it.

Get the Telegraf source and pick a release. I use 1.16.3. 1.17 requires
substantially more hacking around to build, and 1.18 allocates a huge amount
of swap, which I don't like.

```
$ git clone https://github.com/influxdata/telegraf.git
$ cd telegraf
$ git checkout v1.16.3
$ vi plugins/inputs/all/all.go
```

and add these lines to the `inputs()`. Feel free to omit any you don't need:
the fewer plugins you try to build, the lower your chance of failure!  Get it with `git tag`, or
look at [the releases
page](https://github.com/snltd/illumos-telegraf-plugins/releases). Don't
forget the `v`! For example:

```
github.com/snltd/illumos-telegraf-plugins v0.2.0
```

Now you can build Telegraf.

```
$ gmake
```

This may well fail, and you might have to start removing stuff from the
various `all.go` files. For 1.16.3, I had to take the `starlark` line out of
`plugins/processors/all/all.go`. After that, `gmake` succeeded, and I got a
`telegraf` binary.

Once you have a binary, the [`smf` directory](smf) contains just enough SMF to
get you going.

## The Plugins

### cpu
CPU usage, presented in nanoseconds, as per the kstats. It's up to you and
your graphing software to make rates, percentages, or whatever you find
useful. Can report per-zone CPU usage if running in the global.

### disk_health
Uses the `device_error` kstats to keep track of disk errors. Tries its best to
tag the metrics with information about the disks like vendor, serial number
etc.

### fma
A very experimental plugin which parses the output of `fmadm(1m)` and
`fmstat(1m)` to produce information on system failures.

### io
Gets data about IO throughput.

### memory
Aggregates virtual memory information from a number of kstats and, if you want
it, the output of `swap(1m)`. Swapping/paging info defaults to per-cpu, but
can be aggregated to save point rate.

### network
Collects network KStats. If Telegraf is running in the global zone, the plugin
can present per-zone statistics.

### nfs_client
Basic measurement of NFS client stats, for all NFS protocol versions. Each
zone has its own set of KStats, so if you want per-zone NFS stats, you'll have
to run Telegraf in the zones.

### nfs_server
NFS server KStats. Not much more to say.

## patches
Tells you how many of your installed packages are ready for upgrade.

### smf
Parses the output of `svcs(1m)` to count the number of SMF services in
particular states. Also reports errant services with sufficient tagging to
easily track them down and fix them.

### zfs_arc
Reports ZFS ARC statistics.

### zones
Turns `zoneadm list` into numbers, and tells you how old your zones are.

### zpool
High-level ZFS pool statistics from the output of `zpool list`.

## Contributing

Fork it, fix it, push it, PR it. I expect tests!

repository: frcrodrig/illumos-telegraf-plugins

branch_name: refs/heads/main

repo_name: frcrodrig/illumos-telegraf-plugins


text:
# Slack Message

[![GitHub](https://badge.fury.io/gh/someimportantcompany%2Fgithub-actions-slack-message.svg)](https://badge.fury.io/gh/someimportantcompany%2Fgithub-actions-slack-message)
[![CICD](https://github.com/someimportantcompany/github-actions-slack-message/workflows/CICD/badge.svg?branch=master&event=push)](https://github.com/someimportantcompany/github-actions-slack-message/actions?query=workflow%3ACICD)
[![Coverage](https://coveralls.io/repos/github/someimportantcompany/github-actions-slack-message/badge.svg)](https://coveralls.io/github/someimportantcompany/github-actions-slack-message)

Send messages to Slack from GitHub Actions.

This action sends message to Slack during your GitHub Actions workflow. It takes a minimalist approach, showing a handful of metadata options like repository, branch & commit. You can optionally update message in-place to reduce noise in your Slack channel.

## Usage

```yml
- uses: someimportantcompany/github-actions-slack-message@v1
  with:
    channel: ${{ env.SLACK_CHANNEL }}
    bot-token: ${{ secrets.SLACK_BOT_TOKEN }}
    text: Firing a bot-token message

- uses: someimportantcompany/github-actions-slack-message@v1
  with:
    webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
    text: Firing a webhook message
```

![Individual messages](./Screenshot%202020-08-30%20at%2022.49.56.png)

- Including a `color` wraps your message in a (soon to be deprecated) `attachments` block.
- Links refer back to your repository, the branch & the commit.

### Updating an existing message

If you are planning to send multiple Slack messages per invocation, and you'd prefer to update a single message instead of posting multiple messages, you can pass the first Slack message's `message-id` to future calls, thus updating in place. **A `bot-token` is required to update messages.**

```yml
- uses: someimportantcompany/github-actions-slack-message@v1
  id: slack
  with:
    channel: ${{ env.SLACK_CHANNEL }}
    bot-token: ${{ secrets.SLACK_BOT_TOKEN }}
    text: Deployment started

- run: npm run deploy

- uses: someimportantcompany/github-actions-slack-message@v1
  with:
    channel: ${{ env.SLACK_CHANNEL }}
    bot-token: ${{ secrets.SLACK_BOT_TOKEN }}
    text: Deployment finished
    color: good
    message-id: ${{ steps.slack.outputs.message-id }}
```

![Updating message](./Screenshot%202020-08-30%20at%2022.48.56.gif)

### Additional colors

Alongside the Slack default colors `good`, `warning` & `danger`, this action supports some additional colors for convenience:

| Key | Value |
| ---- | ---- |
| `success` | `good` |
| `failure` | `danger` |
| `info` | ![#17a2b8](https://via.placeholder.com/25/17a2b8/000000?text=+) |
| `gray` | ![#B6B6B6](https://via.placeholder.com/25/B6B6B6/000000?text=+) |
| `grey` | ![#B6B6B6](https://via.placeholder.com/25/B6B6B6/000000?text=+) |
| `orange` | ![#FF4500](https://via.placeholder.com/25/FF4500/000000?text=+) |
| `purple` | ![#9400D3](https://via.placeholder.com/25/9400D3/000000?text=+) |

```yml
- uses: someimportantcompany/github-actions-slack-message@v1
  with:
    webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
    text: Build finished
    color: good # Slack already-supported color

- uses: someimportantcompany/github-actions-slack-message@v1
  with:
    webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
    text: Build failed
    color: failed # Aliased color
```

### Running if-success or if-failure

Using built-in Actions conditionals, you can send an error if the job succeeded or failed.

```yml
- uses: someimportantcompany/github-actions-slack-message@v1
  if: success()
  with:
    webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
    text: Build passed
    color: success
- uses: someimportantcompany/github-actions-slack-message@v1
  if: failure()
  with:
    webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
    text: Build failed
    color: failure
```

## Inputs

| Key | Description |
| ---- | ---- |
| `text` | **Required**. The text to send to Slack, see [Slack's documentation for formatting](https://api.slack.com/reference/surfaces/formatting#basics). |
| `color` | Specify the color of the Slack attachment. |
| `bot-token` | **Required if** `webhook-url` was not provided - a Slack bot token to send messages with. |
| `webhook-url` | **Required if** `bot-token` was not provided - a Slack webhook URL to send messages to. |
| `channel` | A channel to send messages to - required if `bot-token` was provided. |
| `message-id` | The ID of the existing Slack message to update - only valid if `bot-token` was provided. |
| `image-url` | The image URL for attachment |
| `thumb-url` | The thumb URL for attachment |

## Outputs

| Key | Description |
| ---- | ---- |
| `message-id` | The ID of the message sent to Slack - pass to the `message-id` input to update. |

## Setup

To use this GitHub Action with your Slack workspace, you'll need a [Slack bot token](https://api.slack.com/methods/chat.postMessage) or [Slack webhook URL](https://api.slack.com/messaging/webhooks), both can be generated by [making a Slack app](https://api.slack.com/authentication/basics).


text:
# SBTi Temperature Alignment tool
This package helps companies and financial institutions to assess the temperature alignment of current
targets, commitments, and investment and lending portfolios, and to use this information to develop
targets for official validation by the SBTi.

This tool can be used either as a standalone Python package or as an API.

## Structure
The folder structure for this project is as follows:

    .
    ├── .github                 # Github specific files (Github Actions workflows)
    ├── app                     # Flask app files for the API endpoints
    ├── docs                    # Documentation files (Sphinx)
    ├── config                  # Config files for the Docker container
    ├── SBTi                    # The main Python package for the temperature alignment tool
    └── test                    # Automated unit tests for the SBTi package (Nose2 tests)

## Installation
The SBTi package may be installed using PIP. If you'd like to install it locally use the following command. For testing or production please see the deployment section for further instructions

```bash
pip install -e .
```

## Development
For development purposes, install the SBTi package using the following command:
```bash
pip install -e .[dev]
```

### Testing
Each class should be unit tested. The unit tests are written using the Nose2 framework.
The setup.py script should have already installed Nose2, so now you may run the tests as follows:
```bash
nose2 -v
```

## Deployment
The alignment tool can be used either as an standalone Python package or as an REST API.
The API can be deployed as a Docker container. To do this a Docker file is provided.

In order to run the docker container locally on none linux machines one needs to install [Docker Desktop](https://www.docker.com/products/docker-desktop) available for Mac and Windows

Both the master and DEV branch have public images at docker hub.

```bash
docker run -d -p 5000:8080 sbti/sbti_tool:latest # to run  the latest stable release
```
or
```bash
docker run -d -p 5000:8080 sbti/sbti_tool:DEV # to run the latest DEV version
```
The UI should now be available at [http://localhost:5000/](http://localhost:5000/) and check [http://localhost:5000/docs/](http://localhost:5000/docs/) for the API documentation

To build an run the docker container locally use the following command:
```bash
docker-compose up -d --build
```

### Amazon Web Services
These instructions assume that you've installed and configured the Amazon [AWS CLI tools](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) and the [ECS CLI tools](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_Configuration.html) with an IAM account that has at least write access to ECS and EC2 and the capability of creating AIM roles.

1. Create a repository.
```bash
aws ecr create-repository --repository-name sbti-ecs
```

*Output:*

```
{
    "repository": {
        "registryId": "aws_account_id",
        "repositoryName": "sbti-ecs",
        "repositoryArn": "arn:aws:ecr:region:aws_account_id:repository/sbti-ecs",
        "createdAt":<PHONE_NUMBER>.0,
        "repositoryUri": "aws_account_id.dkr.ecr.region.amazonaws.com/sbti-ecs"
    }
}
```

2. Create your own AWS docker compose launch file
```bash
cp docker-compose_aws_example.yml docker-compose_aws.yml
```
2. Update the docker-compose_aws.yml file with the repository URI.
3. Build the docker image
```bash
docker-compose -f docker-compose_aws.yml build
```
4. Check if the image has indeed been build
```bash
docker image ls
```
5. Push the image to the repository
```bash
docker-compose -f docker-compose_aws.yml push
```
6. Configure the cluster. You can update the region and names as you see fit
```bash
ecs-cli configure --cluster sbti-ecs-cluster --region eu-central-1 --config-name sbti-ecs-conf --cfn-stack-name sbti-ecs-stack --default-launch-type ec2
```
7. Create a new key pair. The result of this command is a key. Store this safely as you can later use it to access your instance through SSH.
```bash
aws ec2 create-key-pair --key-name sbti
```
8. Create the instance that'll run the image. Here we used 1 server of type t2.medium. Change this as you see fit.
```bash
ecs-cli up --keypair sbti --capability-iam --size 1 --instance-type t2.medium --cluster-config sbti-ecs-conf
```
9. Update the server and make it run the docker image.
```bash
ecs-cli compose -f docker-compose_aws.yml up --cluster-config sbti-ecs-conf
```
10. Now that the instance is running we can't access it yet. That's because NGINX only listens to localhost. We need to change this to make sure it's accessible on the WWW.
11. Login to the Amazon AWS console
12. Go to the EC2 service
13. In the instance list find the instance running the Docker image
14. Copy the public IP address of the instance
15. In ```config/flask-site-nginx.conf``` update the server name to the public IP.
16. Now we need to rebuild and re-upload the image.

```bash
docker-compose -f docker-compose_aws.yml build --no-cache
docker-compose -f docker-compose_aws.yml push
ecs-cli compose -f docker-compose_aws.yml up --cluster-config sbti-ecs-conf --force-update
```
17. You should now be able to access the API.

> :warning: This will make the API publicly available on the world wide web! Please note that this API is not protected in any way. Therefore it's recommended to run your instance in a private subnet and only access it through there. Alternatively you can change the security group settings to only allow incoming connections from your local IP or company VPN.

repository: jdhoffa/SBTi

repo_name: jdhoffa/SBTi


text:
# Parsing to CoNLL with spaCy, spacy-stanza, and spacy-udpipe

This module allows you to parse text into CoNLL-U format. You can use it as a command line tool, or embed it in your
 own scripts by adding it as a custom pipeline component to a spaCy, `spacy-stanza`, or `spacy-udpipe` pipeline. It
 also provides an easy-to-use function to quickly initialize a parser as well as a ConllParser class with built-in
 functionality to parse files or text.

Note that the module simply takes a parser's output and puts it in a formatted string adhering to the linked ConLL-U
 format. The output tags depend on the spaCy model used. If you want Universal Depencies tags as output, I advise you
 to use this library in combination with [spacy-stanza](https://github.com/explosion/spacy-stanza), which is a spaCy
 interface using `stanza` and its models behind the scenes. Those models use the Universal Dependencies formalism and
 yield state-of-the-art performance. `stanza` is a new and improved version of `stanfordnlp`. As an alternative to the
 Stanford models, you can use the spaCy wrapper for `UDPipe`, [spacy-udpipe](https://github.com/TakeLab/spacy-udpipe),
 which is slightly less accurate than `stanza` but much faster.

## Installation

By default, this package automatically installs only [spaCy](https://spacy.io/usage/models#section-quickstart) as
 dependency. Because [spaCy's models](https://spacy.io/usage/models) are not necessarily trained on Universal
 Dependencies conventions, their output labels are not UD either. By using `spacy-stanza` or `spacy-udpipe`, we get
 the easy-to-use interface of spaCy as a wrapper around `stanza` and `UDPipe` respectively, including their models that
 *are* trained on UD data.

**NOTE**: `spacy-stanza` and `spacy-udpipe` are not installed automatically as a dependency for this library, because
 it might be too much overhead for those who don't need UD. If you wish to use their functionality, you have to install
them manually or use one of the available options as described  below.

If you want to retrieve CoNLL info as a `pandas` DataFrame, this library will automatically export it if it detects
 that `pandas` is installed. See the Usage section for more.

To install the library, simply use pip.

```shell
# only includes spacy by default
pip install spacy_conll
```

A number of options are available to make installation of additional dependencies easier:

```shell
# include spacy-stanza and spacy-udpipe
pip install spacy_conll[parsers]
# include pandas
pip install spacy_conll[pd]
# include pandas, spacy-stanza and spacy-udpipe
pip install spacy_conll[all]
# include pandas, spacy-stanza and spacy-udpipe and additional libaries for testing and formatting
pip install spacy_conll[dev]
```

## Usage

When the ConllFormatter is added to a spaCy pipeline, it adds CoNLL properties for `Token`, sentence `Span` and `Doc`.
 Note that arbitrary Span's are not included and do not receive these properties.

On all three of these levels, two custom properties are exposed by default, `._.conll` and its string
 representation `._.conll_str`. However, if you have `pandas` installed, then `._.conll_pd` will
 be added automatically, too!

-   `._.conll`: raw CoNLL format
    -   in Token: a dictionary containing all the expected CoNLL fields as keys and the parsed properties as values.
    -   in sentence Span: a list of its tokens' `._.conll` dictionaries (list of dictionaries).
    -   in a Doc: a list of its sentences' `._.conll` lists (list of list of dictionaries).

-   `._.conll_str`: string representation of the CoNLL format
    -   in Token: tab-separated representation of the contents of the CoNLL fields ending with a newline.
    -   in sentence Span: the expected CoNLL format where each row represents a token. When
        `ConllFormatter(include_headers=True)` is used, two header lines are included as well, as per the
        [CoNLL format](https://universaldependencies.org/format.html#sentence-boundaries-and-comments).
    -   in Doc: all its sentences' `._.conll_str` combined and separated by new lines.

-   `._.conll_pd`: `pandas` representation of the CoNLL format
    -   in Token: a Series representation of this token's CoNLL properties.
    -   in sentence Span: a DataFrame representation of this sentence, with the CoNLL names as column headers.
    -   in Doc: a concatenation of its sentences' DataFrame's, leading to a new a DataFrame whose index is reset.

You can use `spacy_conll` in your own Python code as a custom pipeline component, or you can use the built-in
 command-line script which offers typically needed functionality. See the following section for more.

### In Python

This library offers the ConllFormatter class which serves as a custom spaCy pipeline component. It can be instantiated
 as follows. It is important that you import `spacy_conll` before adding the pipe!

```python
import spacy
nlp = spacy.load("en_core_web_sm")
nlp.add_pipe("conll_formatter", last=True)
```

Because this library supports different spaCy wrappers (`spacy`, `stanza`, and `udpipe`), a convenience function is
 available as well. With `utils.init_parser` you can easily instantiate a parser with a single line. You can
 find the function's signature below. Have a look at the [source code](spacy_conll/utils.py) to read more about all the
 possible arguments or try out the [examples](examples/).

**NOTE**: `is_tokenized` does not work for `spacy-udpipe`. Using `is_tokenized` for `spacy-stanza` also affects sentence
 segmentation, effectively *only* splitting on new lines. With `spacy`, `is_tokenized` disables sentence splitting completely.

```python
def init_parser(
    model_or_lang: str,
    parser: str,
    *,
    is_tokenized: bool = False,
    disable_sbd: bool = False,
    exclude_spacy_components: Optional[List[str]] = None,
    parser_opts: Optional[Dict] = None,
    **kwargs,
)
```

For instance, if you want to load a Dutch `stanza` model in silent mode with the CoNLL formatter already attached, you
 can simply use the following snippet. `parser_opts` is passed to the `stanza` pipeline initialisation automatically.
 Any other keyword arguments (`kwargs`), on the other hand, are passed to the `ConllFormatter` initialisation.

```python
from spacy_conll import init_parser

nlp = init_parser("nl", "stanza", parser_opts={"verbose": False})
```

The `ConllFormatter` allows you to customize the extension names, and you can also specify conversion maps for the
output properties.

To illustrate, here is an advanced example, showing the more complex options:

- `ext_names`: changes the attribute names to a custom key by using a dictionary.
-  `conversion_maps`: a two-level dictionary that looks like `{field_name: {tag_name: replacement}}`. In
   other words, you can specify in which field a certain value should be replaced by another. This is especially useful
   when you are not satisfied with the tagset of a model and wish to change some tags to an alternative0.
- `field_names`: allows you to change the default CoNLL-U field names to your own custom names. Similar to the
   conversion map above, you should use any of the default field names as keys and add your own key as value.
   Possible keys are : "ID", "FORM", "LEMMA", "UPOS", "XPOS", "FEATS", "HEAD", "DEPREL", "DEPS", "MISC".

The example below

- shows how to manually add the component;
- changes the custom attribute `conll_pd` to pandas (`conll_pd` only availabe if `pandas` is installed);
- converts any `nsubj` deprel tag to `subj`.

```python
import spacy

nlp = spacy.load("en_core_web_sm")
config = {"ext_names": {"conll_pd": "pandas"},
          "conversion_maps": {"deprel": {"nsubj": "subj"}}}
nlp.add_pipe("conll_formatter", config=config, last=True)
doc = nlp("I like cookies.")
print(doc._.pandas)
```

This is the same as:

```python
from spacy_conll import init_parser

nlp = init_parser("en_core_web_sm",
                  "spacy",
                  ext_names={"conll_pd": "pandas"},
                  conversion_maps={"deprel": {"nsubj": "subj"}})
doc = nlp("I like cookies.")
print(doc._.pandas)
```

The snippets above will output a pandas DataFrame by using `._.pandas` rather than the standard
`._.conll_pd`, and all occurrences of `nsubj` in the deprel field are replaced by `subj`.

```
   ID     FORM   LEMMA    UPOS    XPOS                                       FEATS  HEAD DEPREL DEPS           MISC
0   1        I       I    PRON     PRP  Case=Nom|Number=Sing|Person=1|PronType=Prs     2   subj    _              _
1   2     like    like    VERB     VBP                     Tense=Pres|VerbForm=Fin     0   ROOT    _              _
2   3  cookies  cookie    NOUN     NNS                                 Number=Plur     2   dobj    _  SpaceAfter=No
3   4        .       .   PUNCT       .                              PunctType=Peri     2  punct    _  SpaceAfter=No
```

Another initialization example that would replace the column names "UPOS" with "upostag" amd "XPOS" with "xpostag":

```python
import spacy

nlp = spacy.load("en_core_web_sm")
config = {"field_names": {"UPOS": "upostag", "XPOS": "xpostag"}}
nlp.add_pipe("conll_formatter", config=config, last=True)
```

#### Reading CoNLL into a spaCy object

It is possible to read a CoNLL string or text file and parse it as a spaCy object. This can be useful if you have raw
CoNLL data that you wish to process in different ways. The process is straightforward.

```python
from spacy_conll import init_parser
from spacy_conll.parser import ConllParser

nlp = ConllParser(init_parser("en_core_web_sm", "spacy"))

doc = nlp.parse_conll_file_as_spacy("path/to/your/conll-sample.txt")
'''
or straight from raw text:
conllstr = """
# text = From the AP comes this story :
1	From	from	ADP	IN	_	3	case	3:case	_
2	the	the	DET	DT	Definite=Def|PronType=Art	3	det	3:det	_
3	AP	AP	PROPN	NNP	Number=Sing	4	obl	4:obl:from	_
4	comes	come	VERB	VBZ	Mood=Ind|Number=Sing|Person=3|Tense=Pres|VerbForm=Fin	0	root	0:root	_
5	this	this	DET	DT	Number=Sing|PronType=Dem	6	det	6:det	_
6	story	story	NOUN	NN	Number=Sing	4	nsubj	4:nsubj	_
"""
doc = nlp.parse_conll_text_as_spacy(conllstr)
'''

# Multiple CoNLL entries (separated by two newlines) will be included as different sentences in the resulting Doc
for sent in doc.sents:
    for token in sent:
        print(token.text, token.dep_, token.pos_)
```

### Command line

Upon installation, a command-line script is added under tha alias `parse-as-conll`. You can use it to parse a
string or file into CoNLL format given a number of options.

```shell
parse-as-conll -h
usage: parse-as-conll [-h] [-f INPUT_FILE] [-a INPUT_ENCODING] [-b INPUT_STR] [-o OUTPUT_FILE]
                  [-c OUTPUT_ENCODING] [-s] [-t] [-d] [-e] [-j N_PROCESS] [-v]
                  [--ignore_pipe_errors] [--no_split_on_newline]
                  model_or_lang {spacy,stanza,udpipe}

Parse an input string or input file to CoNLL-U format using a spaCy-wrapped parser. The output
can be written to stdout or a file, or both.

positional arguments:
  model_or_lang         Model or language to use. SpaCy models must be pre-installed, stanza
                        and udpipe models will be downloaded automatically
  {spacy,stanza,udpipe}
                        Which parser to use. Parsers other than 'spacy' need to be installed
                        separately. For 'stanza' you need 'spacy-stanza', and for 'udpipe' the
                        'spacy-udpipe' library is required.

optional arguments:
  -h, --help            show this help message and exit
  -f INPUT_FILE, --input_file INPUT_FILE
                        Path to file with sentences to parse. Has precedence over 'input_str'.
                        (default: None)
  -a INPUT_ENCODING, --input_encoding INPUT_ENCODING
                        Encoding of the input file. Default value is system default. (default:
                        cp1252)
  -b INPUT_STR, --input_str INPUT_STR
                        Input string to parse. (default: None)
  -o OUTPUT_FILE, --output_file OUTPUT_FILE
                        Path to output file. If not specified, the output will be printed on
                        standard output. (default: None)
  -c OUTPUT_ENCODING, --output_encoding OUTPUT_ENCODING
                        Encoding of the output file. Default value is system default. (default:
                        cp1252)
  -s, --disable_sbd     Whether to disable spaCy automatic sentence boundary detection. In
                        practice, disabling means that every line will be parsed as one
                        sentence, regardless of its actual content. When 'is_tokenized' is
                        enabled, 'disable_sbd' is enabled automatically (see 'is_tokenized').
                        Only works when using 'spacy' as 'parser'. (default: False)
  -t, --is_tokenized    Whether your text has already been tokenized (space-seperated). Setting
                        this option has as an important consequence that no sentence splitting
                        at all will be done except splitting on new lines. So if your input is
                        a file, and you want to use pretokenised text, make sure that each line
                        contains exactly one sentence. (default: False)
  -d, --include_headers
                        Whether to include headers before the output of every sentence. These
                        headers include the sentence text and the sentence ID as per the CoNLL
                        format. (default: False)
  -e, --no_force_counting
                        Whether to disable force counting the 'sent_id', starting from 1 and
                        increasing for each sentence. Instead, 'sent_id' will depend on how
                        spaCy returns the sentences. Must have 'include_headers' enabled.
                        (default: False)
  -j N_PROCESS, --n_process N_PROCESS
                        Number of processes to use in nlp.pipe(). -1 will use as many cores as
                        available. Might not work for a 'parser' other than 'spacy' depending
                        on your environment. (default: 1)
  -v, --verbose         Whether to always print the output to stdout, regardless of
                        'output_file'. (default: False)
  --ignore_pipe_errors  Whether to ignore a priori errors concerning 'n_process' By default we
                        try to determine whether processing works on your system and stop
                        execution if we think it doesn't. If you know what you are doing, you
                        can ignore such pre-emptive errors, though, and run the code as-is,
                        which will then throw the default Python errors when applicable.
                        (default: False)
  --no_split_on_newline
                        By default, the input file or string is split on newlines for faster
                        processing of the split up parts. If you want to disable that behavior,
                        you can use this flag. (default: False)
```

For example, parsing a single line, multi-sentence string:

```shell
parse-as-conll en_core_web_sm spacy --input_str "I like cookies. What about you?"        PUNCT   .              PUNCT   .       PunctType=Peri  2       punct   _       SpaceAfter=No
```

For example, parsing a large input file and writing output to a given output file, using four processes:

```shell
parse-as-conll en_core_web_sm spacy --input_file large-input.txt --output_file large-conll-output.txt --include_headers --disable_sbd -j 4
```

## Credits

The first version of this library was inspired by initial work by [rgalhama](https://github.com/rgalhama/spaCy2CoNLLU)
 and has evolved a lot since then.

gha_language: Python


text:
The Denizen Scripting Language - Spigot Impl
--------------------------------------------

An implementation of the Denizen Scripting Language for Spigot servers, with strong Citizens interlinks to emphasize the power of using Denizen with NPCs!

**Version 1.2.5**: Compatible with Spigot 1.16.5, 1.17.1, 1.18.2, and 1.19!

**Learn about Denizen from the Beginner's guide:** https://guide.denizenscript.com/guides/background/index.html

#### Download Links:

- **Release builds**: https://ci.citizensnpcs.co/job/Denizen/
- **Developmental builds**: https://ci.citizensnpcs.co/job/Denizen_Developmental/
- **SpigotMC - VERY SLOW releases**: https://www.spigotmc.org/resources/denizen.21039/

#### Need help using Denizen? Try one of these places:

- **Discord** - chat room (Modern, strongly recommended): https://discord.gg/Q6pZGSR
- **Denizen Home Page** - a link directory (Modern): https://denizenscript.com/
- **Forum and script sharing** (Modern): https://forum.denizenscript.com/
- **Meta Documentation** - command/tag/event/etc. search (Modern): https://meta.denizenscript.com/
- **Beginner's Guide** - text form (Modern): https://guide.denizenscript.com/

#### Also check out:

- **Citizens2 (NPC support)**: https://github.com/CitizensDev/Citizens2/
- **Depenizen (Other plugin support)**: https://github.com/DenizenScript/Depenizen
- **dDiscordBot (Adds a Discord bot to Denizen)**: https://github.com/DenizenScript/dDiscordBot
- **Webizen (Adds a webserver to Denizen)**: https://github.com/DenizenScript/Webizen
- **DenizenCore (Our core, needed for building)**: https://github.com/DenizenScript/Denizen-Core
- **DenizenVSCode (extension for writing Denizen scripts in VS Code)**: https://github.com/DenizenScript/DenizenVSCode

### Building

- Built against JDK 17, using maven `pom.xml` as project file.
- Requires building all listed versions of Spigot via Spigot BuildTools: https://www.spigotmc.org/wiki/buildtools/

### Licensing pre-note:

This is an open source project, provided entirely freely, for everyone to use and contribute to.

If you make any changes that could benefit the community as a whole, please contribute upstream.

### The short of the license is:

You can do basically whatever you want, except you may not hold any developer liable for what you do with the software.

### Previous License

Copyright (C) 2012-2013 Aufdemrand, All Rights Reserved.

Copyright (C) 2013-2019 The Denizen Script Team, All Rights Reserved.

### The long version of the license follows:

The MIT License (MIT)

Copyright (c) 2019-2022 The Denizen Script Team

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

 IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

branch_name: refs/heads/dev

gha_language: Java


text:
---
layout: post
title: 'Two counterintuitive results'
date: 2021-08-12 00:01:00 +0000
tags:
  math
  puzzles
  science
---

Via Hacker News: [lecture notes](https://timroughgarden.org/notes.html)
from several of Tim Roughgarden's courses at Stanford, particularly CS269I "Incentives in Computer Science."
They're worth reading from start to finish. Here are two gems I thought were especially neat.

## Braess's paradox

From [Lecture 7](http://timroughgarden.org/f16/l/l7.pdf): Suppose a heavy weight is
suspended from a fixed hook by a system of springs and strings. (A string's length is
constant as long as it carries any load; a spring's length is roughly proportional to
the load it carries.) The springs and strings are interconnected among themselves in
some clever way, but ultimately they all end up connected to the fixed hook at the top,
and all connected to a single point on the weight at the bottom. So the whole assembly
is pretty much vertically linear.

Now find one of the strings and cut it. If it was carrying no load, then we expect nothing
to happen. If it was loaded, then its load is suddenly redistributed among the other
strings and springs, in some way that depends on how the system
is interconnected. We might reasonably expect the weight to drop a little bit further
down as a result. (Or crash to the floor, if the string we cut was the [min-cut](https://en.wikipedia.org/wiki/Minimum_cut).)

But would you think that the weight could _rise_ as a result of cutting one of the loaded
strings? It turns out that it totally can — and [here's video proof!](https://www.youtube.com/watch?v=gwS8jiVOWps)

The trick is that the loaded string is the last thing keeping two springs in series;
cutting the string puts the springs in parallel, where they can each take half the load,
and become shorter as a result. Here's Tim Roughgarden's diagram of the situation:

![](/blog/images/2021-08-12-braess-paradox.png)

Vice versa, if you start with the system on the right, you'll find that "hitching up"
two pieces of the system with a short piece of string causes the weight to drop further
down. (Anyone got a video of that?) This paradox has practical applications for the design
of roads and other networks: Counterintuitively, adding a few high-speed links _might_ alter
traffic patterns so that the whole network gets slower, and removing a link _might_ make a
slow network faster. Of course, it _might_ not work that way either — certainly we don't
want it to work that way, if we do our jobs right — but the paradox shows that we really
need to think about how to do it right.

## Two urns

From [Lecture 10](http://timroughgarden.org/f16/l/l10.pdf), another paradox involving
"Herding and Information Cascades."

Suppose we have two urns.
The "red urn" has two red balls and one blue ball.
The "blue urn" has two blue balls and one red ball.
The experimenter picks one of these urns uniformly at random, and throws away the other one
— we'll never see it again.

Now here come an infinite number of players. The first player draws a random ball from the urn,
privately observes its color, and puts it back. The first player then guesses out loud whether the
urn is the "red urn" or the "blue urn." Then, the second player does the same thing (but notice
that the second player has slightly more information than the first player: he knows what the
first player guessed). Then the third player does the same as the first two (but with yet more
knowledge). And so on, forever. Each player's (selfish) goal is to maximize their own likelihood
of guessing correctly.

Obviously the first player should just guess the color of the ball they observed; they'll
have a 2/3 chance of guessing correctly. The second player, knowing this, will have the benefit
of two independent observations: Player 1's and his own. If his observation agrees with Player 1's
(both red or both blue), obviously he'll guess that color; if his observation disagrees, then
we've got one red ball and one blue, so he might as well guess the color he observed.
Player 2 ends up always guessing his own ball's color, and thus also guesses right 2/3 of the time.

Player 3 knows that Players 1 and 2 simply guessed the colors they saw. If they disagreed, then
Player 3 doesn't really have any more information than Player 1, and should just guess the color
he observed. But if the first two players _agreed_ in their observations, then Player 3 has the
benefit of _three_ independent observations! If those observations were RRR or RRB, then Player 3
should logically guess "red"; if BBR or BBB, he should logically guess "blue." In other words,
if Players 1 and 2 agreed, then Player 3 should disregard his own observation and simply follow
the herd. (And then Player 4 follows the same logic as Player 3, and so on ad infinitum.)

The results are that each individual player maximizes their chances of guessing correctly;
and in fact the _expected value_ averaged over all the players goes up as well; but the
distribution of outcomes changes drastically.

![](/blog/images/2021-08-12-urns.png)

In four-ninths of the games, Players 1 and 2
guess correctly, and thus so does everyone else — 100% success! In one-ninth of the games,
Players 1 and 2 both happen to guess incorrectly (by unluckily drawing the odd ball), and
thus _so does everyone else_ — 100% failure!

> The other four-ninths of the time, Players 1 and 2 disagree, and so we end up recursing:
> 16/81 of the time we score only one wrong guess; 4/81 of the time we score only one right
> guess; and 16/81 of the time Players 3 and 4 disagree, so we end up recursing... and so on.
> To generate the histograms above, I used [this C++ and Python code](/blog/code/2021-08-12-urns.cpp)
> to do some quick simulations with only 100 players instead of an infinite number.

So the players' strategy is both the selfishly optimal and (as far as I know) the globally optimal strategy;
yet, it has this awkward property that as often as one-ninth of the time _literally nobody_
guesses the urn correctly — something that would never happen if all the players guessed
individually without communicating.

This paradox (or whatever you'd call it) has practical applications for restaurant reviews,
conference submission reviews...

repository: Quuxplusone/blog

gha_language: HTML

repo_name: Quuxplusone/blog


text:
# GWC (Go Web Client)
[![Go Report Card](https://goreportcard.com/badge/github.com/delicb/gwc)](https://goreportcard.com/report/github.com/delicb/gwc)
[![Build Status](https://travis-ci.org/delicb/gwc.svg?branch=master)](https://travis-ci.org/delicb/gwc)
[![codecov](https://codecov.io/gh/delicb/gwc/branch/master/graph/badge.svg)](https://codecov.io/gh/delicb/gwc)
![status](https://img.shields.io/badge/status-beta-orange.svg)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](http://godoc.org/github.com/delicb/gwc)

GWC is GoLang HTTP client based on [Cliware](https://github.com/delicb/cliware)
client middleware management library and its [middlewares](https://github.com/delicb/cliware-middlewares).

Basic idea is to use same middleware mechanism on client side as many projects
use it for server development.

Because it is based on middlewares client is very pluggable. However, even out
of box it should support most common use cases.

# Install
Run `go get github.com/delicb/gwc` in terminal.

# Example
There is testable example in this repository. It basically does following:
```go
package gwc

import (
	"fmt"
	"net/http"

    "github.com/delicb/gwc"
	"github.com/delicb/cliware-middlewares/headers"
	"github.com/delicb/cliware-middlewares/errors"
)

type HTTPBinResponse struct {
	Headers struct {
		UserAgent string `json:"User-Agent"`
	} `json:"headers"`
}

func main() {
	respBody := new(HTTPBinResponse)

	client := gwc.New(
		http.DefaultClient,
		// Add user agent header, it will be applied to all requests
		headers.Add("User-Agent", "example-client"),
		errors.Errors(),
	)
	// send request
	resp, err := client.Get().URL("https://httpbin.org/get").Send()

	// check errors
	// because of errors middleware included in client, ever status codes
	// 400+ will be turned into errors.
	if err != nil {
		panic(err)
	}

	resp.JSON(respBody)
	fmt.Println(respBody.Headers.UserAgent)
	// output: example-client
}

```

In this example we create new GWC instance with some middlewares (in this case
we set `User-Agent` header to each request sent using this middleware).

We use client to send request and (after some error checking) we deserialize
JSON body to structure.

# State
This is early development, not stable, backward compatibility not guarantied.

Currently, `GWC` requires `GoLang 1.7` to work. However, in the future I will
not hesitate from using new language features. Therefor, make sure to vendor
this library if you intend to use it.

# Contribution
Any contribution is welcome. If you find this code useful, please let me know.
If you find bugs - feel free to open an issue, or, even better, new pull request.

# Credits
Idea and bunch of implementation details were taken from cool GoLang HTTP client
[Gentleman](https://github.com/h2non/gentleman).

Difference is that GWC is based on Cliware, which supports `context` for client
requests and has more simple idea of middleware. Also, GWC is lacking some
features that Gentleman has (like mux). For now I do not plan on adding them
to GWC, but I might write middleware that support similar functionality in the
future.

repository: delicb/gwc

repo_name: delicb/gwc


text:
![FirstNet Local Control](images/logo-FirstNet-local-control.svg)
=======

### Prerequisites

* Node v8.6 or higher from [https://nodejs.org/](https://nodejs.org/).
* Git command line client from [https://git-scm.com/](https://git-scm.com/).

### Development

`npm install` will download the Node dependencies. `npm start` will start webpack-dev-server.

After dev server starts, a browser window will open on your default browser and attempt to navigate to the portal.

You must have valid user credentials to access the portals. If you have a valid bearer token, you may bypass login by supplying the token to an authentication service. Query string parameters may be used: `/oauth/validate?id_token=`

### Deployment

`npm run build`

By default, this will build for the `prod` environment. There are four predefined environments in the Webpack configuration files. The environment may be set using the custom argument `--env=[environment]`. For example, to run a dev build, use `npm run build -- --env=dev`.

* `prod`, intended for production.
* `stage`, intended for User Acceptance Testing (UAT).
* `qa`, intended for internal testing.
* `dev`, intended for development.


text:
Title: Cloud Firewall Examples
----
Stability: 4
----
Text:

<colgroup><col width='24'><col></colgroup>
	Beta
Cloud Firewall is in beta at this time.

These examples are meant to outline some common use-cases for the firewall. Note that all instances need to have their firewall property set for rules to apply to them:

$ sdc-enablemachinefirewall <machine-id>

Recall that for instances that have Cloud Firewall feature enabled, the default policy is always:

allow incoming ping requests

block all other incoming traffic

allow all outgoing traffic

The examples here are not mutually exclusive. You can combine the rules in the examples as you see fit.

Allow SSH Traffic

Allow HTTP Traffic

Multiple Web and Database Server Setup

Bastion Host Setup

Allow SSH Traffic

To allow SSH access from any IP address to all instances in a datacenter, create the following rule:

$ sdc-createfirewallrule --enabled \
                         --rule "FROM any TO all vms ALLOW tcp PORT 22"
{
  "id": "589f1458-d42b-4bad-9613-d738ce074225",
  "rule": "FROM any TO all vms ALLOW tcp PORT 22",
  "enabled": true
}

To allow SSH to one instance with ID ba2c95e9-1cdf-4295-8253-3fee371374d9, create this rule. Note that without the <tt>--enabled</tt> option, this rule is disabled when it is created.

sdc-createfirewallrule --rule "FROM any TO vm ba2c95e9-1cdf-4295-8253-3fee371374d9 ALLOW tcp PORT 22"
{
  "id": "0b3adeaf-cfd9-4cbc-a566-148f569c050c",
  "rule": "FROM any TO vm ba2c95e9-1cdf-4295-8253-3fee371374d9 ALLOW tcp PORT 22",
  "enabled": false
}

To enable the rule, use this command:

$ sdc-enablefirewallrule 0b3adeaf-cfd9-4cbc-a566-148f569c050c
{
  "id": "0b3adeaf-cfd9-4cbc-a566-148f569c050c",
  "rule": "FROM any TO vm ba2c95e9-1cdf-4295-8253-3fee371374d9 ALLOW tcp PORT 22",
  "enabled": true
}

You can see that both of these rules allow SSH traffic from the Internet. If there is more than one rule that affects incoming traffic, the least restrictive one applies. In this case, the rule that allows SSH traffic to all instances in the datacenter is applied.

If you were to disable that rule, however, only the second rule would apply.

Allow HTTP Traffic

To allow HTTP connections from any IP addresss to all instances in a datacenter, create the following rule:

$ sdc-createfirewallrule --enabled \
                         --rule "FROM any TO all vms ALLOW tcp PORT 80"
{
  "id": "d4f01808-dd52-4fb8-b0e8-951d888e1aaa",
  "rule": "FROM any TO all vms ALLOW tcp PORT 80",
  "enabled": true
}

To allow both HTTP and HTTPS connections to all instances in a datacenter, update the rule to include port 443:

$ sdc-updatefirewallrule --rule "FROM any TO all vms ALLOW tcp (PORT 80 AND PORT 443)" d4f01808-dd52-4fb8-b0e8-951d888e1aaa
{
  "id": "d4f01808-dd52-4fb8-b0e8-951d888e1aaa",
  "rule": "FROM any TO all vms ALLOW tcp (PORT 80 AND PORT 443)",
  "enabled": true
}

Multiple Web and Database Server Setup

Suppose that you run a website in which two web servers talk to two database servers. You can use tags to identify each kind of instance.

Give each of the web server a <tt>role</tt> tag with the value <tt>www</tt>:

$ sdc-addmachinetags --tag "role=www" d06bb2bd-e18d-63c0-acce-b125ee36b9e0
{
  "role": "www"
}

And give the database servers a <tt>role</tt> tag with the value <tt>db</tt>.

$ sdc-addmachinetags --tag "role=db" 2171717d-a15c-6a6d-83ae-f1610f552c13
{
  "role": "db"
}

We now need to create firewall rules to control access to these instances.  Recall that by default, instances with Cloud Firewall enabled block all incoming TCP and UDP traffic. We now need to open up the necessary ports for each instance role.

First, we want to allow communication between the web servers and the database

servers. We do so by creating this rule:

$ sdc-createfirewallrule --enabled \
                         --rule "FROM tag role = www TO tag role = db ALLOW tcp PORT 5432"
{
  "id": "82cb2ab3-ff43-4b05-955a-66fcde84c5f8",
  "rule": "FROM tag role = www TO tag role = db ALLOW tcp PORT 5432",
  "enabled": true
}

This rule allows *only* the web servers to connect to the database servers on the standard PostgreSQL port (5432). All other inbound traffic to the database servers is blocked.

Next, we want to allow HTTP and HTTPS traffic to the web servers from anywhere

on the Internet. We do so by creating this rule:

$ sdc-createfirewallrule --enabled --rule "FROM any TO tag role = www ALLOW tcp (PORT 80 AND PORT 443)"
{
  "id": "36548d03-0436-44d5-bf7b-383e693fd46e",
  "rule": "FROM any TO tag role = www ALLOW tcp (PORT 80 AND PORT 443)",
  "enabled": true
}

After you have created both of these rules, instances with the tag <tt>role</tt> set to <tt>db</tt> will have the following behavior:

Allow incoming TCP traffic on port 5432 from instances with tag <tt>role=www</tt>

Allow all outgoing traffic

Allow incoming ping requests

Block all other incoming traffic

And instances with the tag <tt>role</tt> set to <tt>www</tt> will have the following behavior:

Allow incoming TCP traffic on ports 80 and 443 from any IP address

Allow outgoing TCP traffic on port 5432 to instances with  <tt>tag role=www</tt>

Allow all outgoing traffic

Allow incoming ping requests

Block all other incoming traffic

Creating additional instances with the role tags listed above will automatically

apply these rules. For example, to apply the web server rules to a new server,

just give it tag <tt>role=www</tt>.

Bastion Host Setup

In this setup, we have the following requirements:

Instances are allowed access from the bastion host on all ports

Instances block all other connections

The bastion host accepts SSH connections from only certain IP addresses and no others.

Recall that the default policy is to block all incoming connecions, so

requirement 2 is taken care of. We then need two rules to handle the other

requirements.

The bastion host has the id 99a640b6-476f-ee0b-e2b0-b5146d6beb9f. To allow all traffic from the bastion host to all of the instances, you would create this rule:

$ sdc-createfirewallrule --enable \
                         --rule "FROM vm 99a640b6-476f-ee0b-e2b0-b5146d6beb9f TO all vms ALLOW tcp PORT all"
{
  "id": "23831805-bae6-41f0-8f04-bef1191443d4",
  "rule": "FROM vm 99a640b6-476f-ee0b-e2b0-b5146d6beb9f TO all vms ALLOW tcp PORT all",
  "enabled": true
}

The second requirement is that the bastion host should accept SSH connections only from certain IP addresses. To do that you use this rule:

$ sdc-createfirewallrule --enabled \
                         --rule "FROM (ip <IP_ADDRESS> OR ip <IP_ADDRESS>) to vm 99a640b6-476f-ee0b-e2b0-b5146d6beb9f ALLOW tcp PORT 22"
{
  "id": "5494849f-bbaa-41a9-b92e-21d1d61bf656",
  "rule": "FROM (ip <IP_ADDRESS> OR ip <IP_ADDRESS>) TO vm 99a640b6-476f-ee0b-e2b0-b5146d6beb9f ALLOW tcp PORT 22",
  "enabled": true
}

When you create new instances, they will have access from the bastion host.

repository: courtneyabernathy/github-practice

repo_name: courtneyabernathy/github-practice


text:
# Horizon
Horizon - a trustless harmony to ethereum bridge

## Key points

* A bridge with cross-chain light clients, relayers, and prover full nodes, all trustless, no additional trust assumptions beyond the two blockchains that the bridge is connected to.
* A gas-efficient Harmony light client on Ethereum (could be generalized to other chains) that only requires checkpoint blocks (1 block every x blocks, where 1 ≤ x ≤ 16384, 16384 is the #blocks per epoch) to verify any number of Harmony transaction proofs by the clients.
* A constant-size Harmony light client proof that any user needs to send cross-chain (e.g., Ethereum) to claim their Harmony transaction.

## Bridge Components
### Used in Ethereum to Harmony flow
* Bridge smart contract on Harmony
* Ethereum Light Client (ELC) smart contract on Harmony
* Ethereum Verifier (EVerifier) smart contract on Harmony
* Ethereum Prover (EProver) is an Ethereum full node or a client that has access to a full node
* Ethereum Relayer relays every Ethereum header information to ELC

### Used in Harmony to Ethereum flow
* Bridge smart contract on Ethereum
* Harmony Light Client (HLC) smart contract on Ethereum
* Harmony Verifier (HVerifier) smart contract on Ethereum
* Harmony Prover (HProver) is a Harmony full node or a client that has access to a full node
* Harmony Relayer relays every checkpoint block header information to HLC

## Ethereum to Harmony asset transfer
1. User locks ERC20 on Ethereum by transferring to bridge smart contract and obtains the hash of this transaction from blockchain
2. User sends the hash to EProver and receives proof-of-lock
3. User sends the proof-of-lock to bridge smart contract on Harmony
4. Bridge smart contract on Harmony invokes ELC and EVerifier to verify the proof-of-lock and mints HRC20 (equivalent amount)

## Harmony to Ethereum asset redeem
1. User burns HRC20 on Harmony using Bridge smart contract and obtains the hash of this transaction from blockchain
2. User sends the hash to HProver and receives proof-of-burn
3. User sends the proof-of-burn to bridge smart contract on Ethereum
4. Bridge smart contract on Ethereum invokes HLC and HVerifier to verify the proof-of-burn and unlocks ERC20 (equivalent amount)

## Setup and Run
## Easiest way is to use existing setup (already deployed) client and verifier, bridge contracts  on ethereum ropsten and harmony testnet,
1. Clone this repo (node_modules, configuration included)

2. cd horizon && ./index.js start-eth2hmy-relay
 //starts eth to hmy relay

3. ./index.js transfer-eth-erc20-to-harmony
 //sample script that does Ethereum to Harmony asset transfer described above

## For development, redeployment/setup of your own contracts.
1. Clone this repo

2. node_modules already included but if needed run 'npm install' in folders 'horizon, elc/ethClient, lib/src'

3. ./index.js --help shows detailed description of each command, run each command one by one in below order

4. ./index.js compile-all-contracts

5. ./index.js deploy-elc

6. ./index.js deploy-bridges-and-verifiers

7. ./index.js start-eth2hmy-relay

8. ./index.js transfer-eth-erc20-to-harmony

Note: after step 5 and before step 6, please paste the ethClientAddr in eth2hmy-relay/eth2hmy-relay.js(line no: 85) and lib/src/lib/HmyBridge.js (line no: 68)

Note: ./index.js is the cli and will be eventually replaced by a cool name like 'horizon-bridge', every single component has its own README.md. for eg: elc has its own README.md and scripts to deploy and even test, however its best to use cli(./index.js) as the cli commands are simplified and they can even execute a series of shell commands.

repository: harshabakku/horizon

repo_name: harshabakku/horizon


text:
# bpmn quiz

## About

This example showcases the usage of bpmn-questionnaire to embed a questionnaire into a website. It uses [three types of questions](https://github.com/bpmn-io/bpmn-questionnaire-example/tree/master/client/types).

```
var q = new BpmnQuestionnaire({
  container: 'container',
  questionnaireJson: questionnaireJson,
  types: {
    interactive: interactive,
    multiple:    multiple,
    single:      single
  }
});
```
It then hooks up for the 'results' event, to retrieve the results once the questionnaire is finished.

```
q.on('results', function(results) {
  console.log(results);
});
```

## Usage Summary

Install dependencies via npm

```
npm install
```

Build the application

```
grunt auto-build
```

Finally you have to fire up a server for example by using Python 3

```
python -m http.server 8000
```

Go to `localhost:8000/dist` to see the example in action.

## Licence

MIT

repository: camunda-internal/bpmn-quiz

repo_name: camunda-internal/bpmn-quiz


text:
## Running the development server

You need to set the API_HOST configuration in [src/environments/environment.ts](https://github.com/adobe/aem-sample-we-retail-journal/blob/master/angular-app/src/environments/environment.ts#L7) pointing to your AEM instance:

```API_HOST: "http://localhost:4502",```

Then:

```
npm run start
```
This will open the local dev server on port 4200. You can navigate then to http://localhost:4200/content/we-retail-journal/angular/en/home.html

### GOTCHA's - you should read this

#### Your requests to AEM are failing
Most probably this is due to CORS rejection, so you might want to either configure AEM to accept CORS or bypass it from the browser if you are doing local development.
Also assure that your request to the AEM instance is authorized.

#### Authorize your requests
* Instantiate a CustomModelClient such as [CustomModelClient.js](https://github.com/adobe/aem-sample-we-retail-journal/blob/master/angular-app/CustomModelClient.js)
when initializing the [ModelManager in src/app/app.component.ts](https://github.com/adobe/aem-sample-we-retail-journal/blob/master/angular-app/src/app/app.component.ts#L52)
* If necessary adapt the Authorization header in [CustomModelClient.js](https://github.com/adobe/aem-sample-we-retail-journal/blob/master/angular-app/CustomModelClient.js#L20)

#### Update the CORS configuration of the AEM instance
1. Navigate to the Configuration Manager on the AEM instance at http://localhost:4502/system/console/configMgr
2. Look for the configuration: Adobe Granite Cross-Origin Resource Sharing Policy
3. Create a new configuration with the following additional values:
    * Allowed Origins: http://localhost:4200
    * Supported Headers: Authorization
    * Allowed Methods: OPTIONS

#### Your images don't show up
Most probably the images are having relative paths, and because we are not on AEM they won't exist on this server.
Quick fix would be to force the AEM absolute path on the images from the image component

## Running the local NODE.js Server Side Rendering.
First, Set the API_HOST configuration in [src/environments/environment.ts](https://github.com/adobe/aem-sample-we-retail-journal/blob/master/angular-app/src/environments/environment.ts#L7) pointing to your AEM instance:

```API_HOST: "http://localhost:4502",```

Now, In order to get the server side rendering to work run the following commands
```
npm run build:ssr
```
then
```
npm run serve:ssr
```

This will open a server on port 4200 so you can navigate to http://localhost:4200/content/we-retail-journal/angular/en/home.html to see the running example

### SSR Setup

0. Modify the page component HTL template [a,b]
1. Start the local NODE.js server [c]
2. Request the page from your browser
3. Using a web browser, navigate to one of the pages of the app

a. Location of the page component HTL body template
```
../content/jcr_root/apps/we-retail-journal/angular/components/structure/page/body.html
```

b. Expected content of the page component HTL body template
```
<sly data-sly-resource="${resource @ resourceType='cq/spa/ssr'}" />
```

c. Command to start the local node server
```
npm run serve:ssr
```

### GOTCHA's - you should read this

For now we need to overcome some technical difficulties in order to get the server actually working.

#### Your client side code routing is failing
Most probably this is due to CORS rejection, so you might want to either configure AEM to accept CORS or bypass it from the browser if you are doing local development.

See [Authorize your requests](####authorize-your-requests )
and [Update the CORS configuration of the AEM instance](####update-the-cors-configuration-of-the-AEM-instance)

#### Your images don't show up
Most probably the images are having relative paths, and because we are not on AEM they won't exist on this server.
Quick fix would be to force the AEM absolute path on the images from the image component

repository: adobe/aem-sample-we-retail-journal

gha_language: CSS

repo_name: adobe/aem-sample-we-retail-journal


text:
Laravel Environments
================

[![License: MIT](https://img.shields.io/badge/License-MIT-brightgreen.svg?style=flat-square)](https://opensource.org/licenses/MIT)

Easy management of different environments in Laravel projects.

![Laravel-Environments by HighSolutions](https://raw.githubusercontent.com/highsolutions/laravel-environments/master/intro.jpg)

Installation
------------

This package can be installed through Composer:

```bash
composer require highsolutions/laravel-environments
```

Or by adding the following line to the `require` section of your Laravel webapp's `composer.json` file:

```javascript
    "require": {
        "HighSolutions/laravel-environments": "3.*"
    }
```

And run `composer update` to install the package.

Then, if you are using Laravel <= 5.4, update `config/app.php` by adding an entry for the service provider:

```php
'providers' => [
    // ...
    HighSolutions\LaravelEnvironments\EnvironmentServiceProvider::class,
];
```

Optionally, publish the configuration file if you want to change any defaults:

```bash
php artisan vendor:publish --provider="HighSolutions\LaravelEnvironments\EnvironmentServiceProvider"
```

This will create new file `config/environments.php` with few configuration options for package.

Configuration
------------

| Name                             | Description                                                                                | Default                                              |
|----------------------------------|--------------------------------------------------------------------------------------------|------------------------------------------------------|
| path                             | Path where environments will be stored                                                     | environments/                                        |
| files                            | Files that will be stored for each environment                                             | [   '.env',   'phpunit.xml',   'public/.htaccess', ] |
| clear_directory_when_overwriting | If set to true, overwriting environment will be cleared out before putting new files there | false                                                |
| keep_existing_file_when_missing  | If set to true, existing file in base directory will be not deleted when this file is missing in environment set to active | false                                                |

Usage
------------

Create a new environment
========================

To create a new environment, just use `create` method:

```bash
    php artisan env:create NAME_OF_ENVIRONMENT
```

In case that another environment exists with the same name, you can force to overwrite it with `--overwrite` option:

```bash
    php artisan env:create local --overwrite
```

You can use also predefined `make:env` method to be more consistent with other Laravel commands (`--overwrite` option is enabled here):

```bash
    php artisan make:env NAME_OF_ENVIRONMENT
```

Set environment as active
========================

To copy files to main codebase, just use `set` method:

```bash
    php artisan env:set NAME_OF_ENVIRONMENT
```

Copy an environment
========================

To make a duplicate of existing environment, just use `copy` method:

```bash
    php artisan env:copy NAME_OF_EXISTING_ENVIRONMENT NAME_OF_NEW_ENVIRONMENT
```

In case that another environment exists with the same name, you can force to overwrite it with `--overwrite` option:

```bash
    php artisan env:copy old new --overwrite
```

Remove an environment
========================

To remove an environment, just use `remove` method:

```bash
    php artisan env:remove NAME_OF_ENVIRONMENT
```

List all environments
========================

To see a list of all environments, just use `list` method:

```bash
    php artisan env:list
```

Testing
---------

Run the tests with:

``` bash
vendor/bin/phpunit
```

Changelog
---------

3.4.0
* Laravel 10.0 support

3.3.0
* Laravel 9.0 support

3.2.0
* Laravel 8.0 support

3.1.0
* Laravel 7.0 support

3.0.0
* Laravel 5.8 and 6.0 support

2.2.0
* Change name of config file from `config/laravel-environments.php` to `config/environments.php`

2.1.0
* Removing files that are exist in base folder but not exist in environment being set to active

2.0.0
* Support for all Laravel 5.* versions (to-date)

1.6.0
* Laravel 5.6 support

1.5.0
* Create, Copy, Remove, Set, List commands
* Unit tests
* Laravel 5.5 Support

Credits
-------

This package is developed by [HighSolutions](https://highsolutions.org), software house from Poland in love in Laravel.

repository: highsolutions/laravel-environments

gha_language: PHP

repo_name: highsolutions/laravel-environments


text:
# Soniferous #

Soniferous is a simple html music-player built on top of Django. It has a responsive interface and provides support for mp3 file and user access management.

## Dependencies ##

The following dependencies must be met at a minimum:

+ Python 3.4
+ Django 1.10
+ Mutagen 1.27

While Soniferous may work with previous versions of these software dependencies, they are not officially supported.

Install the prerequisites with `pip` use the following command:

    pip3 install mutagen django

## Setup ##

Download the latest build of Soniferous:

    git clone https://github.com/leechy9/Soniferous
    cd Soniferous/soniferous

Test to ensure the dependencies are met:

    python3 manage.py test

If the tests passed, then intialize the database (it may ask a few questions to create a superuser) and set up the rest of the application:

    python3 manage.py migrate --run-syncdb
    python3 manage.py createsuperuser
    python3 manage.py collectstatic --noinput

Soniferous should now be set up to run on any WSGI server.

## WSGI Servers ##

Soniferous should be compatible with any WSGI server. The application entry point is `soniferous.wsgi` , and the application working directory should be set to `Soniferous/soniferous`. It has been tested on Gunicorn, mod_wsgi, uWSGI, and Django's built-in server.

## Usage ##

### Adding Music ###

From the index page after logging in, click on the hamburger menu in the top right and select `Admin`. An administration page should open up. Selecting the `Add` option under _Songs_ will provide an interface to upload MP3 files to the server.

Note that any music uploaded will be available to all users. The only users able to modify and upload music are staff/superusers.

### Adding a user ###

From the index page after logging in, click on the hamburger menu in the top right and select `Admin`. An administration page should open up. Selecting the `Add` option under _Users_ will provide a form to create a new username and corresponding password. After pressing `Save`, the new user will be created.

Note that the following screen allows for finer control of user access and options, but is not necessary.

## License ##

This software is released under The MIT License. For more information consult the provided `LICENSE` file.