text:
# CentralNodeWallet

Fully tested Node.JS library which implements a Ethereum wallet which supports multiple addresses, ETH and ERC20 tokens and which takes all required gas from one central Ethereum account.

To implement that the wallet's addresses do not get their balance reduced by transactions, the wallet's addresses are actually smart contracts. So, to transfer ETH or ERC20 tokens out of the wallet's addresses, the custom calls in the API specification below have to be called.

This project is based on https://github.com/Meshugah/ERC20-CommonGasWallet/ however adds a full Node.JS API and the ability to support ETH.

This project does not require Truffle.

## Gas statistics

Gas needed to deploy wallet: 1.292.339

Gas needed to add 20 addresses to wallet: 6.238.207

Transfering ETH/tokens is far cheaper. The above two transactions are so expensive because they require deploying smart contracts.

## API

### index.js
The actual wallet API

async function create(web3, privateKey, onlyEstimate)
Creates a new wallet without addresses. Private key of the central account is needed because the wallet is a smart contract which gets deployed. Returns the wallet's address. Note that the wallet's address cannot be paid, it is only to manage the wallet. If onlyEstimate is true, returns estimated gas cost without actually doing the transaction.

async function addAddresses(web3, privateKey, walletAddr, addrCount, onlyEstimate)
Adds the specific number of addresses to the wallet. Is a transaction with the wallet smart contract. If onlyEstimate is true, returns estimated gas cost without actually doing the transaction.

async function getAddresses(web3, walletAddr)
Returns the addresses of the wallet. These addresses can be paid via ETH or ERC20 tokens.

async function transfer(web3, privateKey, walletAddr, tokenAddr, address, to, amount)
Transfers amount ETH in Wei (set tokenAddr to null) or ERC20 tokens in fractions from the specifed wallet address to the Ethereum account specified at to.

async function transferBatch(web3, privateKey, walletAddr, tokenAddr, addresses, to, amounts)
Transfers ETH in Wei (set tokenAddr to null) or ERC20 tokens in fractions in the amounts specified from the wallet addresses specified to the Ethereum account specified at to. The addresses array length must math the amounts array length.

async function transferBatch2(web3, privateKey, walletAddr, tokenAddr, addresses, tos, amounts)
Transfers ETH in Wei (set tokenAddr to null) or ERC20 tokens in fractions in the amounts specified from the wallet addresses specified to the Ethereum accounts specified at tos. The addresses array length, the amounts array length and the tos array length must match.

### util.js
Some helper functions developed for the wallet and for the unit testing.

async function isNodeReady(web3)
Returns a bool specifying if the Ethereum node is done syncing and ready.

async function getDecimalFactor(web3, tokenAddr)
Returns the factor the ETH (in Wei) or ERC20 token amount has to be multiplied with to be in human readable units. Set tokenAddr for null for ETH.

async function getBalance(web3, tokenAddr, address, human)
Returns the balance of an Ethereum address in ETH (set tokenAddr to null) or ERC20 token. If human is true, the balance is in human readable units, otherwise it is a string in Wei / native token format.

async function getHistory(web3, tokenAddr, address, fromBlock, human)
Returns the history of transactions in ETH (if tokenAddr = null) or the given ERC20 token, starting with the block given at fromBlock. Returns a object

{
    nextBlock: await web3.eth.getBlockNumber() + 1,
    transfers: [...]
}

Transfers is a array of objects with the properties transaction, from, to, amount and timestamp (UNIX, not in milliseconds). transaction is the hash string which identifies the transaction. Either from or to will be equal to address. If human is true, the amounts are in human readable units, otherwise they are strings in Wei / native token format.

async function transfer(web3, privateKey, tokenAddr, to, amount)
Transfers ETH in Wei (if tokenAddr = null) or ERC20 tokens (in native unit) from own account to the account specified as to.

async function sendPrivateKey(web3, privateKey, query, to, onlyEstimate)
Sends the transaction specified in query to the address specified in to. If onlyEstimate is true, returns estimated gas cost without actually doing the transaction.

async function deployContract(web3, privateKey, contract, onlyEstimate, ...args)
Deploys the contract specified. The constructor of hte contract is called with the arguments specified. See the code of deploySimpleToken as an example on how to use. If onlyEstimate is true, returns estimated gas cost without actually doing the transaction.

async function deploySimpleToken(web3, privateKey, name, symbol, amount)
Deploys a simple ERC20 token with the name, symbol and the token amount specified, which is in native units and given to the contract creator. The decimals is set to 18.

## Testing

Testing was done with a private Ethereum network, based on the genesis block defined in test/CustomGenesis.json.

The code tested with is in test/test.js. This code has to be adapted for your own testing.

repository: neonious/CentralNodeWallet

repo_name: neonious/CentralNodeWallet


text:
# Dead easy rails permissions [![Gem Version](https://badge.fury.io/rb/granted.png)](http://badge.fury.io/rb/granted) [![Build Status](https://travis-ci.org/jayniz/granted.png?branch=master)](https://travis-ci.org/jayniz/granted) [![Coverage Status](https://coveralls.io/repos/jayniz/granted/badge.png)](https://coveralls.io/r/jayniz/granted)

Installation is as easy as 1,2,3:

1.
Add to Gemfile:
gem 'granted'

2.
Add to Rakefile:
require 'granted/tasks'

3.
Create grants migration:
rake granted:create_migration
rake db:migrate

This gem lets you define arbitrary permissions on a per object level (as opposed to roles).
They are implemented purely as active record associations and hence easy to understand.
Check out this readme on how to grant read/write permissions on individual documents to
individual users. This is a [moviepilot.com](http://moviepilot.com) project licensed
[MIT](LICENSE.txt). And now, code:

```ruby
# Let's grant a user access to a document
user.grant(:read).on(document)

# Let's revoke a user's write access to a document
user.revoke(:grant).from(document)

# We can also do it rails association style
document.read_users << user

# Let's count all documents a user has read access to
user.readable_documents.count

# Let's count all documents a user has any access to
user.all_documents.count

# List the rights a user has to a certain document
user.grants_for(document)
=> [:read, :write]

# Define the things we took for granted (scuse me) above
class Document
  include Granted::ForGranted

  # Creates associations and grant/revoke methods
  grantable :read, :write, :destroy, to: User
end
```

## How does it work

When creating the migration with `rake granted:create_migration`,
this gem will add a migration to your rails app that creates a
`grants` table when you run it. This is a polymorphic model sitting
between a `grantee` (e.g. `User` and a `subject` (e.g. `Document`).
It has only one attribute, and that is the `right` that it gives the
grantee to do with the subject.

### What does this code do?

```ruby
class Document < ActiveRecord::Base
  include Granted::ForGranted

  grantable :read, :write, to: User
end
```

### It does that:

```ruby
class Granted::WriteGrant < Granted::Grant; end
class Granted::ReadGrant < Granted::Grant; end

class Document < ActiveRecord::Base
  has_many :grants,       as: :subject, class_name: 'Granted::Grant', dependent: :destroy
  has_many :write_grants, as: :subject, class_name: 'Granted::WriteGrant'
  has_many :read_grants,  as: :subject, class_name: 'Granted::ReadGrant'

  has_many :write_users, source: :grantee, source_type: 'User', through: :write_grants
  has_many :read_users,  source: :grantee, source_type: 'User', through: :read_grants
  has_many :all_users,   source: :grantee, source_type: 'User', through: :grants, uniq: true

  attr_accessible :write_users_attributes, :read_users_attributes
  accepts_nested_attributes_for :write_users, :read_users
end

class User < ActiveRecord::Base
  has_many :grants,       as: :grantee, class_name: 'Granted::Grant', dependent: :destroy
  has_many :write_grants, as: :grantee, class_name: 'Granted::WriteGrant'
  has_many :read_grants,  as: :grantee, class_name: 'Granted::ReadGrant'

  has_many :writeable_documents, source: :subject, source_type: 'Document', through: :write_grants
  has_many :readable_documents,  source: :subject, source_type: 'Document', through: :read_grants
  has_many :all_documents,       source: :subject, source_type: 'Document', through: :grants, uniq: true

  # It does not do this yet, but hopefully soon :)
  # attr_accessible :writeable_documents_attributes, :readable_documents_attributes
  # accepts_nested_attributes_for :writeable_documents, :readable_documents
end
```

First it creates STI classes that inherit from `Granted::Grant`, one for
each right you defined as grantable (e.g. ReadGrant, WriteGrant).
It then creates the appropriate `has_many` relations to both `User` and
`Document`, so that they can be connected with a `Grant` instance.
So you have all the access control available via normal active record
associations (reading and writing).

PSA: You can only grant/revoke rights via the grantee side at the
moment, the other direction is not yet implemented:

```ruby
document.read_users << my_user         # Works
my_user.readable_documents << document # Doesn't work yet
```

## Granting/revoking rights

So now that you know how querying grants/rights work, you might wonder
how you give or revoke certain access rights to a user and a document.
Consider this familiar snippet of code:

```ruby
class Document < ActiveRecord::Base
  include Granted::ForGranted

  grantable :read, :write, to: User
end
```

It does not only create the associations, it also creates the `grant`
and `revoke` methods on `User` and `Document`. They return a convenient
little object ([Grant::Granter](lib/granted/granter.rb), if you're curious).
You can grant/revoke access rights using Users or Documents as a starting
point, it's all the same:

```ruby
# Both ways to grant are identical
my_user.grant(:read).on(my_document)
my_document.grant(:read).to(my_user)

# Both ways to revoke are identical
my_user.revoke(:read).on(my_document)
my_document.revoke(:read).from(my_user)

# Clever: even weird grammatic yields identic results
my_user.on(my_document).revoke(:read)
my_document.from(:my_user).revoke(:read)

# This is what the grant/revoke methods do:
Granted::Granter.new.grant(:read).on(my_document).to(my_user)
Granted::Granter.new.revoke(:read).on(my_document).from(my_user)
```

## Interedasting things

You can use arrays or single objects in `grantable` both as access rights
and grantees:

```ruby
class Document < ActiveRecord::Base
  include Granted::ForGranted

  grantable :read, to: [User, Editor]

  grantable :update, :destroy, to: [Editor]
end

my_document.grant(:read, :write).to(my_user)
```

That is all.

![](https://dl.dropboxusercontent.com/u/1953503/gifs/Zfb9Y.gif)

license: MIT

repository: jayniz/granted

branch_name: refs/heads/master

extension: markdown

license_type: permissive

repo_name: jayniz/granted


text:
# yahoo-visuals
# JSON Stock Price Scrapper using Yahoo-financials
*This code reads in data from the Yahoo finance api and then creates visualizations using this data*

## Usage
This code takes input from the user and returns data from the query. This data can be processed to draw a line plot, boxplot, and other visualizations.

## Contact Information
Name | email |
-----|------- |
Ruramaimunashe Mutefura|<EMAIL_ADDRESS>## License
[MIT](yahoo-visuals/licence.txt)

![](https://img.shields.io/static/v1?label=LICENSE&message=MIT&color=<COLOR>)

[![Check Style](https://github.com/Rura-M/yahoo-visuals/actions/workflows/style-test.yaml/badge.svg)](https://github.com/Rura-M/yahoo-visuals/actions/workflows/style-test.yaml)

[![Unit Tests](https://github.com/Rura-M/yahoo-visuals/actions/workflows/test.yaml/badge.svg)](https://github.com/Rura-M/yahoo-visuals/actions/workflows/test.yaml)

[![Coverage](https://github.com/Rura-M/yahoo-visuals/actions/workflows/coverage.yaml/badge.svg)](https://github.com/Rura-M/yahoo-visuals/actions/workflows/coverage.yaml)

repository: Rura-M/yahoo-visuals

extension: md

repo_name: Rura-M/yahoo-visuals


text:
# 28/4/2018

## Gradual Session Types revisited

Which in each pair is a subtype of the other?

* `&{a:b}` or `&{a:b,c:d}`
* `+{a:b}` or `+{a:b,c:d}`

It is somewhat tempting to say the smaller one is always more general, it has fewer properties, and so that larger one is the subtype. However, the application of subtypes in session types is that if two session types `A` and `B` are compatible, and `A` and `B` are subtypes of `A'` and `B'` respectively, then `A'` and `B'` should be compatible.

This is reflected in http://homepages.inf.ed.ac.uk/wadler/papers/gradsess/gradsess.pdf, where on page 38:9 it is stated that `+{a:b,c:d}` would be the subtype of `+{a:b}`, and `&{a:b}` is the subtype of `&{a:b,c:d}`.

repository: MatrixAI/Architect

repo_name: MatrixAI/Architect


text:
---
title: "Coding Conventions"
description: "I've published my coding conventions for Objective-C / Cocoa."
date: "2012-07-01"
tags: ["Objecive-C", "Cocoa"]
aliases: [ "/2012/07/01/coding-conventions/" ]
---

I've just published my
[Cocoa Coding Conventions](/cocoa-coding-conventions).

Not so that it can be followed, but to provide an idea of what can be done so
that others can write their own, just as I've based mine on published
conventions.

The idea isn't to create a rod for your back when writing code, but to put some
thought into the choices that are made when writing code so that it is consistent.

repository: Abizern/hblog

repo_name: Abizern/hblog


text:
# Phrase CLI Docker Image

> Lightweight Docker image based on node:14-alpine with basic [useful tools](https://github.com/COEXCZ/node-alpine#node-alpine-docker-image-with-basic-useful-tools) and [Phrase CLI](https://phrase.com/cli/)

## Docker hub

Can be pulled from Docker Hub: [coexcz/node-alpine-phrase](https://hub.docker.com/r/coexcz/node-alpine-phrase/tags)

```docker
docker pull coexcz/node-alpine-phrase
```

## Examples

### Bitbucket Pipelines CI

- Create `bitbucket-pipelines.yml`

```yml
image: coexcz/node-alpine-phrase

pipelines:
  branches:
    master:
      - step:
          script:
            - phrase --help
```

More examples on [Phrase CLI readme](https://github.com/phrase/phrase-cli/blob/master/README.md)

## Development

### Release

#### Automatically

```shell
yarn release:patch
# yarn release:minor
# yarn release:major
```

New version will be released, tagged and pushed into Docker hub with current tag + `latest` tag

#### Manually

```docker
docker build --no-cache --progress plain --pull -t node-alpine-phrase:v2.x.x .
docker tag node-alpine-phrase:v2.x.x coexcz/node-alpine-phrase:v2.x.x
docker push coexcz/node-alpine-phrase:v2.x.x
```

repository: COEXCZ/node-alpine-phrase

repo_name: COEXCZ/node-alpine-phrase


text:
# ansible-role-nsd

Configure NSD

## Notes for CentOS

Custom SELinux policy will be installed to workaround a bug ([Bug 1311299 -
Cannot start nsd with selinux
enabled](https://bugzilla.redhat.com/show_bug.cgi?id=1311299)). The policy is
created to support CentOS for the completeness. The author is not an expert of
SELinux at all.

# Requirements

Requires `reallyenglish.redhat-repo` for CentOS. Although the role depends on
it, other platforms do not require it.

# Role Variables

| Variable | Description | Default |
|----------|-------------|---------|
| `nsd_user` | `nsd` user | `{{ __nsd_user }}` |
| `nsd_group` | `nsd` group | `{{ __nsd_group }}` |
| `nsd_db_dir` | path to data base directory | `{{ __nsd_db_dir }}` |
| `nsd_run_dir` | path to run directory | `{{ __nsd_run_dir }}` |
| `nsd_state_dir` | path to state directory | `{{ __nsd_state_dir }}` |
| `nsd_service` | service name of `nsd` | `nsd` |
| `nsd_conf_dir` | path to config directory | `{{ __nsd_conf_dir }}` |
| `nsd_conf` | path to `nsd.conf` | `{{ nsd_conf_dir }}/nsd.conf` |
| `nsd_config_server` | list of configuration in `server` directive (see below) | `[]` |
| `nsd_config_remote_control` | list of configuration in `remote-control` directive (see below) | `[]` |
| `nsd_flags` | (not implemented) | `""` |
| `nsd_remote_setup` | run `nsd-control-setup` to create self-signed keys. when false, you need to provide certificates and keys (use `reallyenglish.x509-certificate` and see an example in `tests/serverspec/remote_control_with_variables.yml` | `false` |
| `nsd_zones` | dict of zones (see below) | `{}` |
| `nsd_include_role_x509_certificate` | include and execute `reallyenglish.x509-certificate` during the play if `yes` (see below) | `no` |

## `nsd_config_server`

This variable is a list of dict or string for `server` directive in
`nsd.conf(5)`.

When an element of `nsd_config_server` is a dict, it must have a mandatory key,
`name`. It also must have either `values` or `value` as key. The value of
`values` is a list of string. Use `values` for options that are allowed to
appear multiple times in `nsd.conf(5)`. The value of `value` is a string and
used as the value for the option.

When an element of `nsd_config_server` is a string, it is appended to `server`
sections as-is.

An example:

```yaml
    nsd_config_server:
      - "server-count: 1"
      - name: ip-address
        values: "{{ ansible_all_ipv4_addresses }} + {{ ['<IP_ADDRESS>'] }}"
      - name: do-ip4
        value: "yes"
      - name: do-ip6
        value: "no"
      - name: verbosity
        value: 0
      - name: username
        value: "{{ nsd_user }}"
      - name: zonesdir
        value: '"{{ nsd_conf_dir }}"'
      - name: database
        value: '"{{ nsd_db_dir }}/nsd.db"'
      - name: pidfile
        value: '"{{ nsd_run_dir }}/nsd.pid"'
      - name: xfrdfile
        value: '"{{ nsd_state_dir }}/xfrd.state"'
      - name: hide-version
        value: "yes"
```

## `nsd_config_remote_control`

This variable is a list of dict or string for `remote-control` directive in
`nsd.conf(5)`.

The same rules describe in `nsd_config_server` apply.

## `nsd_zones`

This variable is a dict of zones. Keys are domain name of zones. Each key must
have a dict as a value, and explained below.

| Key | Value | Mandatory? |
|-----|-------|------------|
| `zonefile` | relative path to the zone file from `nsd_conf_dir` | no |
| `zone` | the zone definition | no |
| `config` | list of configurations of the zone (see below) | no |

`config` is a list of configurations for the zone. An element can be a dict or
a string.

When an element of `config` is a dict, the dict must have a mandatory key,
`name`, which is one of zone options described in `nsd.conf(5)`. The dict must
have either `values` or `value` as a key. `values` is a list of string values
for the option. Use `values` for options that are allowed to appear multiple
times.  `value` is a string for the option.

When an element of `config` is a string, the string is simply added to the zone
configuration.

An example:

```yaml
nsd_zones:
  example.com:
    zonefile: example.com.zone
    zone: |
      example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com.<PHONE_NUMBER> 10800 3600<PHONE_NUMBER>
      example.com. 86400 IN NS ns1.example.com.
      example.com. 120 IN A <IP_ADDRESS>
      ns1.example.com. 120 IN A <IP_ADDRESS>
      mail.example.com. 120 IN A <IP_ADDRESS>
      example.com. 120 IN MX 25 mail.example.com.
    config:
      - name: provide-xfr
        values:
          - <IP_ADDRESS> my_tsig_key
          - <IP_ADDRESS> NOKEY
      - name: allow-notify
        value: <IP_ADDRESS> NOKEY
      - name: request-xfr
        values:
          - <IP_ADDRESS> NOKEY
      - name: outgoing-interface
        values:
          - <IP_ADDRESS>
      - 'allow-axfr-fallback: yes'
```

## `nsd_include_role_x509_certificate`

When `yes`, this variable includes and execute
[`reallyenglish.x509`](https://github.com/reallyenglish/ansible-role-x509-certificate)
during the play, which makes it possible to manage certificates without ugly
hacks. This is only supported in `ansible` version _at least_ 2.2 and later
(but see also issue #34 for possible bugs).

Confirmed to work:

| platform | `ansible version` |
|----------|-------------------|
| CentOS   | <IP_ADDRESS>           |

See an example in
[tests/serverspec/x509.yml](https://github.com/reallyenglish/ansible-role-nsd/tree/master/tests/serverspec/x509.yml).

If `ansible` version requirement cannot be met or your `ansible` version does
not work with `nsd_include_role_x509_certificate`, you need some hacks. See an
example in
[tests/serverspec/remote_control_with_variables.yml](https://github.com/reallyenglish/ansible-role-nsd/tree/master/tests/serverspec/remote_control_with_variables.yml).

## Debian

| Variable | Default |
|----------|---------|
| `__nsd_user` | `nsd` |
| `__nsd_group` | `nsd` |
| `__nsd_db_dir` | `/var/lib/nsd` |
| `__nsd_conf_dir` | `/etc/nsd` |
| `__nsd_run_dir` | `/var/run/nsd` |
| `__nsd_state_dir` | `{{ nsd_db_dir }}` |

## FreeBSD

| Variable | Default |
|----------|---------|
| `__nsd_user` | `nsd` |
| `__nsd_group` | `nsd` |
| `__nsd_db_dir` | `/var/db/nsd` |
| `__nsd_conf_dir` | `/usr/local/etc/nsd` |
| `__nsd_run_dir` | `/var/run/nsd` |
| `__nsd_state_dir` | `{{ nsd_db_dir }}` |

## OpenBSD

| Variable | Default |
|----------|---------|
| `__nsd_user` | `_nsd` |
| `__nsd_group` | `_nsd` |
| `__nsd_db_dir` | `/var/nsd/db` |
| `__nsd_conf_dir` | `/var/nsd/etc` |
| `__nsd_run_dir` | `/var/nsd/run` |
| `__nsd_state_dir` | `{{ nsd_run_dir }}` |

## RedHat

| Variable | Default |
|----------|---------|
| `__nsd_user` | `nsd` |
| `__nsd_group` | `nsd` |
| `__nsd_db_dir` | `/var/lib/nsd` |
| `__nsd_conf_dir` | `/etc/nsd` |
| `__nsd_run_dir` | `/var/run/nsd` |
| `__nsd_state_dir` | `{{ nsd_db_dir }}` |

# Dependencies

None

# Example Playbook

```yaml
- hosts: localhost
  roles:
    - ansible-role-nsd
  vars:
    nsd_config_server:
      - "server-count: 1"
      - name: ip-address
        values: "{{ ansible_all_ipv4_addresses }} + {{ ['<IP_ADDRESS>'] }}"
      - name: do-ip4
        value: "yes"
      - name: do-ip6
        value: "no"
      - name: verbosity
        value: 0
      - name: username
        value: "{{ nsd_user }}"
      - name: zonesdir
        value: '"{{ nsd_conf_dir }}"'
      - name: database
        value: '"{{ nsd_db_dir }}/nsd.db"'
      - name: pidfile
        value: '"{{ nsd_run_dir }}/nsd.pid"'
      - name: xfrdfile
        value: '"{{ nsd_state_dir }}/xfrd.state"'
      - name: hide-version
        value: "yes"
    nsd_remote_enable: "{% if ansible_os_family == 'FreeBSD' %}False{% else %}true{% endif %}"
    nsd_remote_setup: "{% if ansible_os_family == 'FreeBSD' %}False{% else %}true{% endif %}"
    nsd_config_remote_control:
      - "control-enable: {% if ansible_os_family == 'FreeBSD' %}no{% else %}yes{% endif %}"
    nsd_keys:
      my_tsig_key:
        secret: Qes2X7V8Fjg+EMlqng1qlCvErGFxXWa4Gxfy1uDWKvQ=
        algorithm: hmac-sha256
    nsd_zones:
      example.com:
        zonefile: example.com.zone
        zone: |
          example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com.<PHONE_NUMBER> 10800 3600<PHONE_NUMBER>
          example.com. 86400 IN NS ns1.example.com.
          example.com. 120 IN A <IP_ADDRESS>
          ns1.example.com. 120 IN A <IP_ADDRESS>
          mail.example.com. 120 IN A <IP_ADDRESS>
          example.com. 120 IN MX 25 mail.example.com.
        config:
          - name: provide-xfr
            values:
              - <IP_ADDRESS> my_tsig_key
              - <IP_ADDRESS> NOKEY
          - name: allow-notify
            value: <IP_ADDRESS> NOKEY
          - name: request-xfr
            values:
              - <IP_ADDRESS> NOKEY
          - name: outgoing-interface
            values:
              - <IP_ADDRESS>
          - 'allow-axfr-fallback: yes'
      example.net:
        zonefile: example.net.zone
        zone: |
          example.net. 86400 IN SOA ns1.example.net. hostmaster.example.net.<PHONE_NUMBER> 10800 3600<PHONE_NUMBER>
          example.net. 86400 IN NS ns1.example.net.
          example.net. 120 IN A <IP_ADDRESS>
          ns1.example.net. 120 IN A <IP_ADDRESS>
          mail.example.net. 120 IN A <IP_ADDRESS>
          example.net. 120 IN MX 25 mail.example.net.
        config: []

    redhat_repo_extra_packages:
      - epel-release
    redhat_repo:
      epel:
        mirrorlist: "http://mirrors.fedoraproject.org/mirrorlist?repo=epel-{{ ansible_distribution_major_version | default(7) }}&arch={{ ansible_architecture }}"
        gpgcheck: yes
        enabled: yes
```

Master-slave example can be found at
[tests/integration/example](https://github.com/reallyenglish/ansible-role-nsd/tree/master/tests/integration/example).

# License

```
Copyright (c) 2016 Tomoyuki Sakurai<EMAIL_ADDRESS>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

 IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
```

# Author Information

Tomoyuki Sakurai<EMAIL_ADDRESS>

license: ISC

repository: reallyenglish/ansible-role-nsd

gha_language: Ruby

gha_license_id: ISC

repo_name: reallyenglish/ansible-role-nsd


text:
# Shopify app

The Shopify app allows editors to select products from their Shopify account and reference them inside of Contentful entries.

## Usage

### Step 1: Install

This app can be installed for fields of type `Short text` or `List of short text`.

To install this app you have to:

- Sign up with Shopify and [create an API client]() to acquire the necessary credentials.
- Fill in all data pertaining to your Shopify account in the installation screen.
- Select all fields for which you'd like to install the Shopify app from the list of available fields.
- Click on `Install`

This will modify the fields in the selected content types and change their appearance to use the Shopify app.

### Step 2: Navigate to entries and start adding products

After a successful installation you can directly navigate to the content entries where the Shopify app is set up.

You will be able to link plain `Short text` fields to a single product in your Shopify account.

Lists of `Short text` fields can be linked to a selection of many products.

license: ISC,MIT

repository: joedooley/extensions

detected_licenses: ISC MIT

repo_name: joedooley/extensions


text:
---
name: "Bug Report"
about: "Is something not working as expected?"
---

## Expected behavior

<!--
  What is it you expected to happen? This should be a description of how the
  functionality you tried to use is supposed to work.
-->

## Steps to reproduce the behavior

<!--
  Describe the steps you took for this problem to exist. Such as: you installed
  the theme, customized _config.yml, added your own posts, and started up a
  Jekyll server locally.

  If an error occurred on GitHub Pages when pushing, please test a local version
  following these setup instructions:
  https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/

  Then provide a complete log by running `bundle exec jekyll build --trace --verbose`
  and include this output in the filed issue.

  Screenshots can also be included if they help illustrate a behavior.
-->

repository: VOKW/Sandbox

gha_language: CSS

gha_license_id: MIT

repo_name: VOKW/Sandbox


text:
# Style guide for john

A quick style guide for john. If you plan on submitting a pull request, please
follow these guidelines.

  - As much commenting as possible
    - Every line commented
    - Include links to techniques you have used
  - No single letter variables

repository: wridgers/john

repo_name: wridgers/john


text:
# @descriptive/web-scripts

[![NPM version](https://img.shields.io/npm/v/@descriptive/web-scripts.svg)](https://www.npmjs.com/package/@descriptive/web-scripts)

See [react-scripts](https://www.npmjs.com/package/react-scripts/v/5.0.0) ([repository](https://github.com/facebook/create-react-app/tree/v5.0.0/packages/react-scripts)).

## Install

```sh
npm install @descriptive/web-scripts
```

## Changes

New files:

```
CHANGELOG.md
```

Removed files and folders:

```
fixtures/
template/
template-typescript/
.npmignore
LICENSE
```

Remove the files and folders:

```sh
rm -rf fixtures/ \
       template/ \
       template-typescript/ \
       .npmignore \
       LICENSE
```

Updated files:

```
config/jest/babelTransform.js
config/jest/fileTransform.js
config/env.js
config/paths.js
config/webpack.config.js
scripts/utils/createJestConfig.js
scripts/utils/verifyTypeScriptSetup.js
scripts/eject.js
scripts/init.js
scripts/start.js
package.json
README.md
```

`package.json` diff:

```diff
 "dependencies": {
   "@babel/core": "^7.16.0",
+  "@descriptive/babel-preset-web-app": "1.1.0",
+  "@descriptive/eslint-config-web-app": "2.1.0",
-  "@pmmmwh/react-refresh-webpack-plugin": "^0.5.3",
   "@svgr/webpack": "^5.5.0",
   "babel-jest": "^27.4.2",
   "babel-loader": "^8.2.3",
   "babel-plugin-named-asset-import": "^0.3.8",
-  "babel-preset-react-app": "^10.0.1",
   "bfj": "^7.0.2",
   "browserslist": "^4.18.1",
   "camelcase": "^6.2.1",
   "case-sensitive-paths-webpack-plugin": "^2.4.0",
   "css-loader": "^6.5.1",
   "css-minimizer-webpack-plugin": "^3.2.0",
   "dotenv": "^10.0.0",
   "dotenv-expand": "^5.1.0",
   "eslint": "^8.3.0",
-  "eslint-config-react-app": "^7.0.0",
   "eslint-webpack-plugin": "^3.1.1",
   "file-loader": "^6.2.0",
   "fs-extra": "^10.0.0",
   "html-webpack-plugin": "^5.5.0",
   "identity-obj-proxy": "^3.0.0",
   "jest": "^27.4.3",
   "jest-resolve": "^27.4.2",
   "jest-watch-typeahead": "^1.0.0",
   "mini-css-extract-plugin": "^2.4.5",
   "postcss": "^8.4.4",
   "postcss-flexbugs-fixes": "^5.0.2",
   "postcss-loader": "^6.2.1",
   "postcss-normalize": "^10.0.1",
   "postcss-preset-env": "^7.0.1",
   "prompts": "^2.4.2",
-  "react-app-polyfill": "^3.0.0",
   "react-dev-utils": "^12.0.0",
-  "react-refresh": "^0.11.0",
   "resolve": "^1.20.0",
   "resolve-url-loader": "^4.0.0",
   "sass-loader": "^12.3.0",
   "semver": "^7.3.5",
   "source-map-loader": "^3.0.0",
   "style-loader": "^3.3.1",
   "tailwindcss": "^3.0.2",
   "terser-webpack-plugin": "^5.2.5",
   "webpack": "^5.64.4",
   "webpack-dev-server": "^4.6.0",
   "webpack-manifest-plugin": "^4.0.2",
   "workbox-webpack-plugin": "^6.4.1"
 },
-"devDependencies": {
-  "react": "^17.0.2",
-  "react-dom": "^17.0.2"
-},
 "optionalDependencies": {
   "fsevents": "^2.3.2"
 },
 "peerDependencies": {
-  "react": ">= 16",
   "typescript": "^3.2.1 || ^4"
 },
```

Remove the dependencies:

```sh
npm rm -S @pmmmwh/react-refresh-webpack-plugin \
          babel-preset-react-app \
          eslint-config-react-app \
          react-app-polyfill \
          react-refresh
```

Remove the devDependencies:

```sh
npm rm -D react \
          react-dom
```

Save the dependencies:

```sh
npm i -S @descriptive/babel-preset-web-app \
         @descriptive/eslint-config-web-app
```

## Migration

To migrate [web-app-template](https://github.com/remarkablemark/web-app-template) to [@descriptive/web-scripts](https://www.npmjs.com/package/@descriptive/web-scripts):

```sh
npx web-scripts-migration
```

See [web-scripts-migration](https://github.com/remarkablemark/descriptive/tree/master/packages/web-scripts-migration).

## License

[MIT](https://github.com/facebook/create-react-app/blob/v5.0.0/packages/react-scripts/LICENSE)

repository: remarkablemark/descriptive

gha_language: JavaScript

repo_name: remarkablemark/descriptive


text:
# Presentation Deck preparation

## What is this?

Convenient methods for deck preparation.

## Requirements

The following software needed.

- peco

## Current features

- Copy template file from assigned directory.

## How to use?

```Examples
$ setupdeck Path_to_tempaltefile
```

## TODO

- Nothing.

## Authors

- [@makotow](https://github.com/makotow)

## License

MIT

repository: makotow/dailyutils

repo_name: makotow/dailyutils


text:
Storing megolm keys serverside
==============================

Background
----------

A user who uses end-to-end encryption will usually have many inbound group session
keys.  Users who log into new devices and want to read old messages will need a
convenient way to transfer the session keys from one device to another.  While
users can currently export their keys from one device and import them to
another, this is involves several steps and may be cumbersome for many users.
Users can also share keys from one device to another, but this has several
limitations, such as the fact that key shares only share one key at a time, and
require another logged-in device to be active.

To help resolve this, we *optionally* let clients store an encrypted copy of
their megolm inbound session keys on the homeserver.  Clients can keep the
backup up to date, so that users will always have the keys needed to decrypt
their conversations.  The backup could be used not just for new logins, but
also to support clients with limited local storage for keys (clients can store
old keys to the backup, and remove their local copy, retrieving the key from
the backup when needed).

To recover keys from the backup, a user will need to enter a recovery key to
decrypt the backup.  The backup will be encrypted using public key
cryptography, so that any of a user's devices can back up keys without needing
the user to enter the recovery key until they need to read from the backup.

See also:

* https://github.com/matrix-org/matrix-doc/issues/1219
* https://github.com/vector-im/riot-web/issues/3661
* https://github.com/vector-im/riot-web/issues/5675
* https://docs.google.com/document/d/1MOoIA9qEKIhUQ3UmKZG-loqA8e0BzgWKKlKRUGMynVc/edit#
  (old version of proposal)

Proposal
--------

This proposal creates new APIs to allow clients to back up room decryption keys
on the server.  Room decryption keys are encrypted (using public key crypto)
before being sent to the server along with some unencrypted metadata to allow
the server to manage the backups.  If a key for a new megolm session is
uploaded, it is added to the current backup.  If a key is uploaded for a megolm
session is that is already present in the backup, the server will use the
metadata to determine which version of the key is "better".  The way in which
the server determines which key is "better" is described in the [Storing
Keys](#storing-keys) section.  The user is given a private recovery key in
order to recover the keys from the backup in the future.

Clients can create new key backups (sometimes also referred to in the API as
backup versions) to replace the current backup.  Aside from the initial backup
creation, a client might start a new a backup when, for example, a user loses a
device and wants to ensure that that device does not get any new decryption
keys.  In this case, the client will then create a new backup using a new key
that the device does not have access to.

Once one client has created a backup, other clients can fetch the public part
of the recovery key from the server and add keys to the backup, if they trust
that the backup was not created by a malicious device.

### Possible UX for interactive clients

This section gives an example of how a client might handle key backups.  Clients
may behave differently.

On receipt of encryption keys (1st time):

1. client checks if there is an existing backup: `GET /room_keys/version`
   1. if not, ask if the user wants to back up keys
      1. if yes:
         1. generate new curve25519 key pair, which will be the recovery key
         2. create new backup: `POST /room_keys/version`
         3. display private key for user to save (see below for the
            [format of the recovery key](#recovery-key))
      2. if no, exit and remember decision (user can change their mind later)
      3. while prompting, continue to poll `GET /room_keys/versions`, as
         another device may have created a backup.  If so, go to 1.2.
   2. if yes, either get the public part of the recovery key and check that it
      is signed by the master cross-signing key, or prompt user to enter the
      private part of the recovery key (which can derive the public part).
      1. User can also decide to create a new backup, in which case, go to 1.1.
2. send key to backup: `PUT /room_keys/keys/${roomId}/${sessionId}?version=$v`
3. continue backing up keys as we receive them (may receive a
   `M_WRONG_ROOM_KEYS_VERSION` error if a new backup has been created:
   see below)

On `M_WRONG_ROOM_KEYS_VERSION` error when trying to `PUT` keys:

1. get the current version
2. notify the user that there is a new backup, and display relevant information
3. confirm with user that they want to use the backup (user may want use the
   backup, to stop backing up keys, or to create a new backup)
4. ensure the public part of the recovery key is signed by the user's master
   key, or prompt the user to enter the private part of the recovery key

On receipt of undecryptable message:

1. ask user if they want to restore backup (ask whether to get individual key,
   room keys, or all keys).  (This can be done in the same place as asking if
   the user wants to request keys from other devices.)
2. if yes, prompt for private key, and get keys: `GET /room_keys/keys`

Users can also set up, disable, or rotate backups, or restore from backup via user
settings.

### Recovery key

The recovery key can be saved by the user directly, stored encrypted on the
server (using the method proposed in
[MSC1946](https://github.com/matrix-org/matrix-doc/issues/1946)), or both.  If
the key is saved directly by the user, then the code is constructed as follows:

1. The 256-bit curve25519 private key is prepended by the bytes `0x8B` and
   `0x01`
2. All the bytes in the string above, including the two header bytes, are XORed together to form a parity
   byte. This parity byte is appended to the byte string.
3. The byte string is encoded using base58, using the same mapping as is used
   for Bitcoin addresses.

This 58-character string is presented to the user to save.  Implementations may
add whitespace to the recovery key; adding a space every 4th character is
recommended.

When reading in a recovery key, clients must disregard whitespace.  Clients
must base58-decode the code, ensure that the first two bytes of the decoded
string are `0x8B` and `0x01`, ensure that XOR-ing all the bytes together
results in 0, and ensure that the total length of the decoded string
is 35 bytes.  Clients must then remove the first two bytes and the last byte,
and use the resulting string as the private key to decrypt backups.

#### Encoding the recovery key for server-side storage via MSC1946

If MSC1946 is used to store the key on the server, it must be stored using the
`account_data` type `m.megolm_backup.v1`.

As a special case, if the recovery key is the same as the curve25519 key used
for storing the key, then the contents of the `m.megolm_backup.v1`
`account_data` for that key will be an object with a `passthrough` property
whose value is `true`.  For example, if `m.megolm_backup.v1` is set to:

```json
{
  "encrypted": {
    "key_id": {
      "passthrough": true
    }
  }
}
```

means that the recovery key for the backup is the same as the private key for
the key with ID `key_id`. (This is mostly intended to provide a migration path
for for backups that were created using an earlier draft that stored the
recovery information in the `auth_data`.)

### API

#### Backup versions

##### `POST /room_keys/version`

Create a new backup version.

Body parameters:

- `algorithm` (string): Required. The algorithm used for storing backups.
  Currently, only `m.megolm_backup.v1.curve25519-aes-sha2` is defined.
- `auth_data` (object): Required. algorithm-dependent data.  For
  `m.megolm_backup.v1.curve25519-aes-sha2`, see below for the [definition of
  this property](#auth_data-backup-versions).

Example:

```javascript
{
  "algorithm": "m.megolm_backup.v1.curve25519-aes-sha2",
  "auth_data": {
    "public_key": "abcdefg",
    "signatures": {
      "something": {
        "ed25519:something": "hijklmnop"
      }
    }
  }
}
```

On success, returns a JSON object with keys:

- `version` (string): the backup version

##### `GET /room_keys/version/{version}`

Get information about the given version, or the current version if `/{version}`
is omitted.

On success, returns a JSON object with keys:

- `algorithm` (string): Required. Same as in the body parameters for `POST
  /room_keys/version`.
- `auth_data` (object): Required. Same as in the body parameters for
  `POST /room_keys/version`.
- `version` (string): Required. The backup version.
- `etag` (string): Required. The etag value which is an opaque string
  representing stored keys in the backup. Clients can compare it with the
  `etag` value they received in the response of their last key storage request.
  If not equal, another client has pushed new keys to the backup.
- `count` (number): Required. The number of keys stored in the backup.

Error codes:

- `M_NOT_FOUND`: No backup version has been created. (with HTTP status code 404)

##### `PUT /room_keys/version/{version}`

Update information about the given version. Only `auth_data` can be updated.

Body parameters:

- `algorithm` (string): Required. Must be the same as in the body parameters for `GET
  /room_keys/version`.
- `auth_data` (object): Required. algorithm-dependent data.  For
  `m.megolm_backup.v1.curve25519-aes-sha2`, see below for the [definition of
  this property](#auth_data-backup-versions).
- `version` (string): Optional. The backup version. If present, must be the same as the path parameter.

Example:

```javascript
{
  "algorithm": "m.megolm_backup.v1.curve25519-aes-sha2",
  "auth_data": {
    "public_key": "abcdefg",
    "signatures": {
      "something": {
        "ed25519:something": "hijklmnop"
        "ed25519:anotherthing": "abcdef"
      }
    }
  },
  "version": "42"
}
```

On success, returns the empty JSON object.

Error codes:

- `M_NOT_FOUND`: This backup version was not found. (with HTTP status code 404)

#### Storing keys

##### `PUT /room_keys/keys/${roomId}/${sessionId}?version=$v`

Store the key for the given session in the given room, using the given backup
version.

If the server already has a backup in the backup version for the given session
and room, then it will keep the "better" one.  To determine which one is
"better", keys are compared:

- first by the `is_verified` flag (`true` is better than `false`),
- then, if `is_verified` is equal, by the `first_message_index` (a lower number is better),
- and finally, is `is_verified` and `first_message_index` are equal, by
  `forwarded_count` (a lower number is better).

If neither key is better than the other (that is, if all three fields are
equal), then the server should keep the existing key.

Body parameters:

- `first_message_index` (integer): Required. The index of the first message
  in the session that the key can decrypt.
- `forwarded_count` (integer): Required. The number of times this key has been
  forwarded.
- `is_verified` (boolean): Required. Whether the device backing up the key has
  verified the device that the key is from.
- `session_data` (object): Required. Algorithm-dependent data.  For
  `m.megolm_backup.v1.curve25519-aes-sha2`, see below for the [definition of
  this property](#auth_data-backup-versions).

On success, returns a JSON object with keys:

- `etag` (string): Required. The new etag value representing stored keys. See
  `GET /room_keys/version/{version}` for more details.
- `count` (number): Required. The new count of keys stored in the backup.

Error codes:

- `M_WRONG_ROOM_KEYS_VERSION`: the version specified does not match the current
  backup version (with HTTP status code 403).  The current backup version will
  be included in the `current_version` field of the HTTP result.

Example:

`PUT /room_keys/keys/!room_id:example.com/sessionid?version=1`

```javascript
{
  "first_message_index": 1,
  "forwarded_count": 0,
  "is_verified": true,
  "session_data": {
    "ephemeral": "base64+ephemeral+key",
    "ciphertext": "base64+ciphertext+of+JSON+data",
    "mac": "base64+mac+of+ciphertext"
  }
}
```

Result:

```javascript
{
  "etag": "abcdefghi",
  "count": 10
}
```

##### `PUT /room_keys/keys/${roomId}?version=$v`

Store several keys for the given room, using the given backup version.

Behaves the same way as if the keys were added individually using `PUT
/room_keys/keys/${roomId}/${sessionId}?version=$v`.

Body parameters:
- `sessions` (object): an object where the keys are the session IDs, and the
  values are objects of the same form as the body in `PUT
  /room_keys/keys/${roomId}/${sessionId}?version=$v`.

Returns the same as `PUT
/room_keys/keys/${roomId}/${sessionId}?version=$v`.

Example:

`PUT /room_keys/keys/!room_id:example.com?version=1`

```javascript
{
  "sessions": {
    "sessionid": {
      "first_message_index": 1,
      "forwarded_count": 0,
      "is_verified": true,
      "session_data": {
        "ephemeral": "base64+ephemeral+key",
        "ciphertext": "base64+ciphertext+of+JSON+data",
        "mac": "base64+mac+of+ciphertext"
      }
    }
  }
}
```

Result:

```javascript
{
  "etag": "abcdefghi",
  "count": 10
}
```

##### `PUT /room_keys/keys?version=$v`

Store several keys, using the given backup version.

Behaves the same way as if the keys were added individually using `PUT
/room_keys/keys/${roomId}/${sessionId}?version=$v`.

Body parameters:
- `rooms` (object): an object where the keys are the room IDs, and the values
  are objects of the same form as the body in `PUT
  /room_keys/keys/${roomId}/?version=$v`.

Returns the same as `PUT
/room_keys/keys/${roomId}/${sessionId}?version=$v`

Example:

`PUT /room_keys/keys/!room_id:example.com?version=1`

```javascript
{
  "rooms": {
    "!room_id:example.com": {
      "sessions": {
        "sessionid": {
          "first_message_index": 1,
          "forwarded_count": 0,
          "is_verified": true,
          "session_data": {
            "ephemeral": "base64+ephemeral+key",
            "ciphertext": "base64+ciphertext+of+JSON+data",
            "mac": "base64+mac+of+ciphertext"
          }
        }
      }
    }
  }
}
```

Result:

```javascript
{
  "etag": "abcdefghi",
  "count": 10
}
```

#### Retrieving keys

When retrieving keys, the `version` parameter is optional, and defaults to
retrieving keys from the latest backup version.

##### `GET /room_keys/keys/${roomId}/${sessionId}?version=$v`

Retrieve the key for the given session in the given room from the backup.

On success, returns a JSON object in the same form as the request body of `PUT
/room_keys/keys/${roomId}/${sessionId}?version=$v`.

Error codes:

- M_NOT_FOUND: The session is not present in the backup, or the requested
  backup version does not exist. (with HTTP status code 404)

##### `GET /room_keys/keys/${roomId}?version=$v`

Retrieve the all the keys for the given room from the backup.

On success, returns a JSON object in the same form as the request body of `PUT
/room_keys/keys/${roomId}?version=$v`.

If the backup version exists but no keys are found, then this endpoint returns
a successful response with body:

```
{
  "sessions": {}
}
```

Error codes:

- `M_NOT_FOUND`: The requested backup version does not exist. (with HTTP status code 404)

##### `GET /room_keys/keys?version=$v`

Retrieve all the keys from the backup.

On success, returns a JSON object in the same form as the request body of `PUT
/room_keys/keys?version=$v`.

If the backup version exists but no keys are found, then this endpoint returns
a successful response with body:

```
{
  "rooms": {}
}
```

Error codes:

- `M_NOT_FOUND`: The requested backup version does not exist. (with HTTP status code 404)

#### Deleting keys

##### `DELETE /room_keys/keys/${roomId}/${sessionId}?version=$v`
##### `DELETE /room_keys/keys/${roomId}?version=$v`
##### `DELETE /room_keys/keys/?version=$v`

Deletes keys from the backup.

Returns the same as `PUT
/room_keys/keys/${roomId}/${sessionId}?version=$v`.

#### `m.megolm_backup.v1.curve25519-aes-sha2` definitions

##### `auth_data` for backup versions

The `auth_data` property for the backup versions endpoints for
`m.megolm_backup.v1.curve25519-aes-sha2` is a [signed
json](https://matrix.org/docs/spec/appendices#signing-json) object with the
following keys:

- `public_key` (string): the curve25519 public key used to encrypt the backups
- `signatures` (object): signatures of the `auth_data`.

The `auth_data` should be signed by the user's [master cross-signing
key](https://github.com/matrix-org/matrix-doc/pull/1756), and may also be
signed by the user's device key.  This allows clients to ensure that the public
key is valid, and prevents an attacker from being able to change the backup to
use a public key that they have the private key for.

##### `session_data` for key backups

The `session_data` field in the backups is constructed as follows:

1. Encode the session key to be backed up as a JSON object with the properties:
   - `algorithm` (string): `m.megolm.v1.aes-sha2`
   - `sender_key` (string): base64-encoded device curve25519 key
   - `sender_claimed_keys` (object): object containing the identity keys for the
     sending device
   - `forwarding_curve25519_key_chain` (array): zero or more curve25519 keys
     for devices who forwarded the session key
   - `session_key` (string): base64-encoded (unpadded) session key in
     [session-sharing
     format](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#session-sharing-format)
2. Generate an ephemeral curve25519 key, and perform an ECDH with the ephemeral
   key and the backup's public key to generate a shared secret.  The public
   half of the ephemeral key, encoded using base64, becomes the `ephemeral`
   property of the `session_data`.
3. Using the shared secret, generate 80 bytes by performing an HKDF using
   SHA-256 as the hash, with a salt of 32 bytes of 0, and with the empty string
   as the info.  The first 32 bytes are used as the AES key, the next 32 bytes
   are used as the MAC key, and the last 16 bytes are used as the AES
   initialization vector.
4. Stringify the JSON object, and encrypt it using AES-CBC-256 with PKCS#7
   padding.  This encrypted data, encoded using base64, becomes the
   `ciphertext` property of the `session_data`.
5. Pass the raw encrypted data (prior to base64 encoding) through HMAC-SHA-256
   using the MAC key generated above.  The first 8 bytes of the resulting MAC
   are base64-encoded, and become the `mac` property of the `session_data`.

(The key HKDF, AES, and HMAC steps are the same as what are used for encryption
in olm and megolm.)

Security Considerations
-----------------------

An attacker who gains access to a user's account can delete or corrupt their
key backup.  This proposal does not attempt to protect against that.

An attacker who gains access to a user's account can create a new backup
version using a key that they control.  For this reason, clients SHOULD confirm
with users before sending keys to a new backup version or verify that it was
created by a trusted device by checking the signature.  Alternatively, if the
signature cannot be verified, the backup can be validated by prompting the user
to enter the recovery key, and confirming that the backup's public key
corresponds to the recovery key.

Other Issues
------------

Since many clients will receive encryption keys at around the same time, they
will all want to back up their copies of the keys at around the same time,
which may increase load on the server if this happens in a big room.  (TODO:
how much of an issue is this?)  For this reason, clients should offset their
backup requests randomly.

Conclusion
----------

This proposal allows users to securely and conveniently back up and restore
their decryption keys so that users logging into a new device can decrypt old
messages.

repository: matrix-org/matrix-spec-proposals

branch_name: refs/heads/main

repo_name: matrix-org/matrix-spec-proposals


text:
# Button

Core button component.

## Usage

This component is registered globally as `<z-button>`.

```html
 <z-button>Button text</z-button>
```

Default color variant is `primary`. Other variants ( `secondary`, `tertiary`, `inline`, `icon` ) can be passed by Boolean prop:

```html
 <z-button secondary>Secondary button text</z-button>
```

repository: apathetic/zigzag-ui

repo_name: apathetic/zigzag-ui


text:
---
layout: page
title: Privacy Policy
include_in_header: false
---

# Contact
Alexander Steiner

Druffeler Str. 181
 33397 Rietberg

Germany

<EMAIL_ADDRESS>
# English
The app 'AdSense++' does generelly not collect any private information. All data is only stored on the device.

## Google Login
To access the displayed data in the app, the app needs permission to your Google accounts AdSense and AdMob data. This is done via the OAuth2 protocol. No access data leaves your devices. Except if you have the iCloud keychain enabled. Then authentication tokens are shared with your devices. No user data is ever transfered to a third party by the app.

## Analytics
For product improvement and optimization purposes of the app, the version number of the app is used for statistical evaluation of user access. It is sent to a server in Frankfurt (Germany). During the transfer, your IP address will be anonymized by shortening. The transmission takes place via an SSL-encrypted connection. If you have any further questions about your data, please contact me.

Last changes: 28. April 2020


text:
# Contributing

## Testing
`make test` will build the docker image and run the tests

## Upgrading Checkstyle Version
1. `make upgrade` => will adjust `bin/install-checkstyle.sh` with the URL to the latest version
1. `make test`
1. If all looks good, commit the change and open a PR :)

repository: vipuldarkknight/codeclimate-checkstyle

repo_name: vipuldarkknight/codeclimate-checkstyle


text:
Eggdrop Giphy
=========

A script for Eggdrop IRC bot to fetch random gifs from Giphy (with optional tag)

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

Just copy giphy.tcl to your eggdrop scripts directory, add to your Eggdrop configuration file, and edit the script the set config parameters. Set +giphy on any channels you want the command to be active.

repository: teeli/eggdrop-giphy

repo_name: teeli/eggdrop-giphy


text:
---
title: Detail Views
description: Kiali provides list and detail views for your mesh components.
---

Kiali provides filtered list views of all your service mesh definitions. Each view provides health, details, YAML definitions and links to help you visualize your mesh. There are list and detail views for:

* Applications
* Istio Configuration
* Services
* Workloads

![Detail list apps](/images/documentation/features/detail-list-app.png)
![Detail list service](/images/documentation/features/detail-list-service.png)
![Detail list workload](/images/documentation/features/detail-list-workload.png)
![Detail list Istio config](/images/documentation/features/detail-list-config.png)

Selecting an object from the list will bring you to its detail page.  For Istio Config, Kiali will present its YAML, along with contextual validation information. Other mesh components present a variety of Tabs.

## Overview Tab

Overview is the default Tab for any detail page.  The overview tab provides detailed information, including health status, and a detailed mini-graph of the current traffic involving the component.  The full set of tabs, as well as the detailed information, varies based on the component type.

Each Overview provides:

* links to related components and linked Istio configuration.
* health status.
* validation information.
* an Action menu for actions that can be taken on the component.
  * several [Wizards]({{< relref "wizards" >}}) are available.

And also type-specfic information.  For example:

* Service detail includes Network information.
* Workload detail provides backing Pod information.

![Detail overview app](/images/documentation/features/detail-overview-app.png)
![Detail overview service](/images/documentation/features/detail-overview-service.png)
![Detail overview workload](/images/documentation/features/detail-overview-workload.png)

Both Workload and Service detail can be customized to some extent, by adding additional details supplied as annotations. This is done through the `additional_display_details` field in [the Kiali CR](/docs/configuration/kialis.kiali.io/#.spec.additional_display_details).

![Detail overview additional details](/images/documentation/features/detail-overview-additional-details.png)

## Traffic

The Traffic Tab presents a service, app, or workload's Inbound and Outbound traffic in a table-oriented way:

![Detail traffic](/images/documentation/features/detail-traffic.png)

## Logs

Workload detail offers a special Logs tab.  Kiali offers a special _unified_ logs view that lets users correlate app and proxy logs.  It can also add-in trace span information to help identify important traces based on associated logging. More powerful features include substring or regex Show/Hide, full-screen, and the ability to set proxy log level without a pod restart.

![Detail logs](/images/documentation/features/detail-logs.png)

## Metrics

Each detail view provides _Inbound Metrics_ and/or _Outbound Metrics_ tabs, offering predefined metric dashboards. The dashboards provided are tailored to the relevant application, workload or service level. Application and workload detail views show request and response metrics such as volume, duration, size, or tcp traffic.  The service detail view shows request and response metrics for inbound traffic only.

Kiali allows the user to customize the charts by choosing the charted dimensions.  It can also present metrics reported by either source or destination proxy metrics.  And for troublshooting it can overlay trace spans.

![Detail metric inbound](/images/documentation/features/detail-metrics-in.png)
![Detail metrics outbound](/images/documentation/features/detail-metrics-out.png)

## Traces

Each detail view provides a _Traces_ tab with a native integration with Jaeger.  For more, see [Tracing]({{< relref "./tracing" >}}).

## Dashboards

Kiali will display additional tabs for each applicable [Built-In Dashboard](#built-in-dash) or  [Custom Dashboard](#custom-dash).

### Built-in dashboards {#built-in-dash}

Kiali comes with built-in dashboards for several runtimes, including Envoy, Go, Node.js, and others.

#### Envoy

The most important built-in dashboard is for Envoy.  Kiali offers the _Envoy_ tab for many workloads.  The Envoy tab is actually a [Built-In Dashboard](#built-in-dash), but it is very common as it applies to any workload injected with, or that is itself, an Envoy proxy.  Being able to inspect the Envoy proxy is invaluable when troublshooting your mesh.  The Envoy tab itself offers five subtabs, exposing a wealth of information.

![Detail Envoy](/images/documentation/features/detail-envoy.png)

Istio's Envoy sidecars supply [some internal metrics](https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats), that can be viewed in Kiali. They are different than the metrics reported by Istio Telemetry, which Kiali uses extensively. Some of Envoy's metrics may be redundant.

Note that the enabled Envoy metrics can be tuned, as explained in the [Istio documentation](https://istio.io/docs/ops/telemetry/envoy-stats/): it's possible to get more metrics using the `statsInclusionPrefixes` annotation. Make sure you include `cluster_manager` and `listener_manager` as they are required.

For example, `sidecar.istio.io/statsInclusionPrefixes: cluster_manager,listener_manager,listener` will add `listener` metrics for more inbound traffic information. You can then customize the Envoy dashboard of Kiali according to the collected metrics.

#### Go

Contains metrics such as the number of threads, goroutines, and heap usage. The expected metrics are provided by the [Prometheus Go client](https://prometheus.io/docs/guides/go-application/).

Example to expose built-in Go metrics:

```go
        http.Handle("/metrics", promhttp.Handler())
        http.ListenAndServe(":2112", nil)
```

As an example and for self-monitoring purpose Kiali itself [exposes Go metrics](https://github.com/kiali/kiali/blob/055b593e52ebf8a0eb00372bca71fbef94230f0f/server/metrics_server.go).

The pod annotation for Kiali is: `kiali.io/dashboards: go`

#### Kiali

Kiali has its own built-in dashboard that helps you observe performance of the Kiali server itself. To view this dashboard, navigate to either the application or workload view of the Kiali server and select the `Kiali Internal Metrics` tab to see Kiali's own internal metrics:

![Kiali Metrics (app view)](/images/documentation/features/kiali-dashboard-app-metrics.png)
![Kiali Metrics (workload view)](/images/documentation/features/kiali-dashboard-workload-metrics.png)

#### Node.js

Contains metrics such as active handles, event loop lag, and heap usage. The expected metrics are provided by [prom-client](https://www.npmjs.com/package/prom-client).

Example of Node.js metrics for Prometheus:

```javascript
const client = require('prom-client');
client.collectDefaultMetrics();
// ...
app.get('/metrics', (request, response) => {
  response.set('Content-Type', client.register.contentType);
  response.send(client.register.metrics());
});
```

Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/ratings

The pod annotation for Kiali is: `kiali.io/dashboards: nodejs`

#### Quarkus

Contains JVM-related, GC usage metrics. The expected metrics can be provided by [SmallRye Metrics](https://smallrye.io/), a MicroProfile Metrics implementation. Example with maven:

```xml
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-metrics</artifactId>
    </dependency>
```

The pod annotation for Kiali is: `kiali.io/dashboards: quarkus`

#### Spring Boot

Three dashboards are provided: one for JVM memory / threads, another for JVM buffer pools and the last one for Tomcat metrics. The expected metrics come from
[Spring Boot Actuator for Prometheus](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.metrics.export.prometheus). Example with maven:

```xml
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
      <groupId>io.micrometer</groupId>
      <artifactId>micrometer-core</artifactId>
    </dependency>
    <dependency>
      <groupId>io.micrometer</groupId>
      <artifactId>micrometer-registry-prometheus</artifactId>
    </dependency>
```

Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/details

The pod annotation for Kiali with the full list of dashboards is: `kiali.io/dashboards: springboot-jvm,springboot-jvm-pool,springboot-tomcat`

By default, the metrics are exposed on path _/actuator/prometheus_, so it must be specified in the corresponding annotation: `prometheus.io/path: "/actuator/prometheus"`

#### Thorntail

Contains mostly JVM-related metrics such as loaded classes count, memory usage, etc. The expected metrics are provided by the MicroProfile Metrics module. Example with maven:

```xml
    <dependency>
      <groupId>io.thorntail</groupId>
      <artifactId>microprofile-metrics</artifactId>
    </dependency>
```

Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/productpage

The pod annotation for Kiali is: `kiali.io/dashboards: thorntail`

#### Vert.x

Several dashboards are provided, related to different components in Vert.x: HTTP client/server metrics, Net client/server metrics, Pools usage, Eventbus metrics and JVM. The expected metrics are provided by the
[vertx-micrometer-metrics](https://vertx.io/docs/vertx-micrometer-metrics/java/) module. Example with maven:

```xml
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-micrometer-metrics</artifactId>
    </dependency>
    <dependency>
      <groupId>io.micrometer</groupId>
      <artifactId>micrometer-registry-prometheus</artifactId>
    </dependency>
```

Init example of Vert.x metrics, starting a dedicated server (other options are possible):

```java
      VertxOptions opts = new VertxOptions().setMetricsOptions(new MicrometerMetricsOptions()
          .setPrometheusOptions(new VertxPrometheusOptions()
              .setStartEmbeddedServer(true)
              .setEmbeddedServerOptions(new HttpServerOptions().setPort(9090))
              .setPublishQuantiles(true)
              .setEnabled(true))
          .setEnabled(true));
```

Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/reviews

The pod annotation for Kiali with the full list of dashboards is: `kiali.io/dashboards: vertx-client,vertx-server,vertx-eventbus,vertx-pool,vertx-jvm`

### Custom Dashboards {#custom-dash}

When the built-in dashboards don't offer what you need, it's possible to create your own.  See [Custom Dashboard Configuration]({{< ref "/docs/configuration/custom-dashboard" >}}) for more information.

branch_name: refs/heads/staging


text:
# PN5_60972

<PageHeader />

## Description

**PH-STATUS** facelift

### Previous Release Behavior

The **PH-STATUS** command's user interface was extremely limited.

### Current Release Behavior

\* The output is now sorted: **BY STATUS-ALPHA BY-DSND START-DATE BY-DSND START-TIME BY LINE**

\* The output can be restricted by specifying one or more valid status codes as options. For example, to display only Active tasks:

```
ph-status (a
```

\* The command-line options are case insensitive

\* A select-list can be passed to it

\* A check is done to ensure that a task marked as Active is still active; if it isn't then the status is changed to **X**. This could happen if the port was logged off or the task was killed in an abnormal manner.

\* Added help page which can be envoked with -h or -?

\* The **PH-HISTORY** file is now created as a Dynamic File

Back to [5.7.6 Release Notes](../jbase-5.7.6-release-notes/README.md)

<PageFooter />

repository: josepheshaw/docs

repo_name: josepheshaw/docs


text:
---
summary: >-
  The first in a series of posts about the perfect Bash history setup, focusing
  on never losing anything
---

# The perfect Bash history setup: infinite history

This is the first in a series of posts about Bash history configuration.

Bash can keep a history of the commands you've issued and make them available
via multiple methods, including [Readline history commands][rlhistcmds] and
[history expansion][histexp].

An example of a Readline history command is
[`reverse-search-history`][revhist], which is usually bound to `C-r`
(Ctrl+R), and incrementally searches the history
backwards.

An example for history expansion is `!!`, an [event designator][evdesig] for
the previous command.

Having your history around is very useful, but the default settings leave a few
things on the table:

- History entries seem to disappear
- History contains duplicates and useless junk like `ls`, which you're not very
  likely ever to feel like retrieving
- Multi-line entries are folded into a single line, or split into multiple
  separate entries, or even seem to change how they're stored
- Parallel shell sessions overwrite each other's history

In these posts, I explain my Bash history setup, which addresses all of these
points. "Perfect" is of course in jest---I don't think I've seen many topics
where people are as opinionated as when it comes to customizing a command-line
setup. So, "perfect for me", probably.

Note that I'm *not* going to talk about settings that change the behaviour of
history expansion, but only how history is stored.

[rlhistcmds]: <https://www.gnu.org/software/bash/manual/bash.html#Commands-For-History>
[histexp]: <https://www.gnu.org/software/bash/manual/bash.html#History-Interaction>
[revhist]: <https://www.gnu.org/software/bash/manual/bash.html#index-reverse_002dsearch_002dhistory-_0028C_002dr_0029>
[evdesig]: <https://www.gnu.org/software/bash/manual/bash.html#Event-Designators>

## Enabling history

Bash can be compiled without history support (`--enable-history` option for
`configure`), but it's enabled by default unless not supported by the operating
system.

Given history support, interactive shells have history turned on by default,
but this can also be controlled using the `history` shell option:

```bash
set -o history
```

to enable, and

```bash
set +o history
```

to disable. If enabled, the [`SHELLOPTS`][shopts] variable contains `history`,
and the status is also reported by `set -o`.

[shopts]: <https://www.gnu.org/software/bash/manual/bash.html#index-SHELLOPTS>

## Infinite history

The first nice-to-have is history that goes back all the way.

To understand how this works, we have to know a bit about how Bash stores
history. Command history is stored in multiple places: each session has an
in-memory history, which is initialized from a history file; when the session
is finished, the in-memory history is written back to the history file.

Configuring this in a way so multiple parallel sessions don't wipe out each
other's histories will be subject of a separate post; for now, we're just
thinking about a single session.

The history file by default lives at `~/.bash_history`; to put it elsewhere,
set the [`HISTFILE`][histfile] variable. I like my home directory uncluttered,
and I try to follow the [XDG Base Directory Specification][xdg], so I have this
in my `.bashrc`:

```bash
HISTFILE="$HOME/.local/share/bash/history"
```

where `~/.local/share` is the default value of `$XDG_DATA_HOME`.

When the session history gets written to the history file, the file is either
overwritten, or the history is appended. This is controlled with the
[`histappend` shell option][histapp]:

```bash
shopt -s histappend
```

to append, and

```bash
shopt -u histappend
```

to overwrite the history file.

Since we only care about an individual shell session so far, we don't need to
append; we can overwrite the history file at the end of each session without
losing anything.

The size of the history is controlled with the [`HISTSIZE`][histsize] variable
(defaults to 500), and the size of the history file with
[`HISTFILESIZE`][histfilesize]. Common advice is to just set these to large
numbers; however, since Bash 4.3, they can be set to a negative value for
unlimited history. (Watch out, setting to 0 disables history and truncates the
history file, respectively!)

So, for an infinite history (and so far ignoring implications of parallel shell
session), we'd want something like this in our `.bashrc`:

```bash
# No clutter in the home directory
HISTFILE="$HOME/.local/share/bash/history"

# Overwrite when storing
shopt -u histappend

# Infinite session history
HISTSIZE=-1

# Infinite history file
HISTFILESIZE=-1
```

In the next post, we'll look at controlling what exactly goes into the history.

[histfile]: <https://www.gnu.org/software/bash/manual/bash.html#index-HISTFILE>
[xdg]: <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>
[histapp]: <https://www.gnu.org/software/bash/manual/bash.html#The-Shopt-Builtin>
[histsize]: <https://www.gnu.org/software/bash/manual/bash.html#index-HISTSIZE>
[histfilesize]: <https://www.gnu.org/software/bash/manual/bash.html#index-HISTFILESIZE>


text:
# Greedy Decoding Optimality

This repository contains the code and datasets discussed in our paper "[How Optimal is Greedy Decoding for Extractive Question Answering?](https://arxiv.org/abs/2108.05857)".

The fine-tuning is based on PyTorch (1.8.1) and Transformers (4.6.1), with a traininig\testing script based on Pytorch-Lightning (1.2.10), according to the requirements files [environment.yml](environment.yml).

## Data
The few shot data is available in [data](data).

## Paper Correction - Table 3
There are some inaccuracies in Table 3 in the paper.
SearchQA: Greedy (no RSS): should be 24.0 (45) instead of 17.8 (26).
HotpotQA and BioASQ numbers for Greedy (no rss) were swapped.
Some incorrect numbers rounding were introduced in table 3 as well.
The correct table is as follows:
![correct table 3](fixed_table3.png)

## Exact-Extract code
The code for exact-extract algorithm can be found in [src/decoding/exact_extract.py](src/decoding/exact_extract.py).
It is written mainly for T5 as some assumptions are taken, such as the existence of ```<extra_id_0>``` and ```<extra_id_1>``` to be prepended and appended to each span. Most of the algorithm is implemented in ```mlspan_calc``` function, where the three functions mentioned in the paper - ```L```, ```l``` and ```e``` are realized as matrices.
\
If you wish to adapt it to some other encoder-decoder model (or even a decoder-only model) feel free to send an email (or.castel@cs.tau.ac.il).
Note that in its current implementation, and due to memory requirement of the algorithm, it is not batched across samples and as such it is slower than greedy decoding (but faster than a naive implementation).

### Useful parameters
dataset: ```HotpotQA```, ```NaturalQuestions```, ```NewsQA```, ```SQuAD``` ```SearchQA```, ```TriviaQA```, ```BioASQ```, ```TextBookQA```.
\
train_samples: ```16```, ```32```, ```64```, ```128```, ```256```, ```512```, ```1024``` and ```-1``` (for full training set)
\
seeds:  0-4
\
model_name/tokenizer: you can use anything that is T5 based, as current implementation assumes encoder-decoder and available ```<extra_id_0>``` and ```<extra_id_1>```.

To use the rss-pretrained model mentioned in the paper that achieves 71.4 F1 on zero-shot SQuAD, you can use the following:

## RSS zero shot

In the paper we discuss a model finetuned on RSS dataset for enhancing its tendency towards extracting spans from the context (encoder input). It is now avaialble via HuggingFace models hub, with the name ```tau\t5-v1_1-large-rss```.
You can pass its name as a paramters.  The pattern is only introduced in the MRQA datasets finetuning and inference phases. This means that if you choose to use this model, you don't need to assume it was
trained with some pattern.
## Citation

If you find this work helpful, please cite us:
```
@misc{castel2021optimal,
      title={How Optimal is Greedy Decoding for Extractive Question Answering?},
      author={Or Castel and Ori Ram and Avia Efrat and Omer Levy},
      year={2021},
      eprint={2108.05857},
      archivePrefix={arXiv},
      primaryClass={cs.CL}
}
```

If you are using the RSS model or referring to it's pretraining scheme, please also cite the paper that introduced it:
```
@inproceedings{ram-etal-2021-shot,
    title = "Few-Shot Question Answering by Pretraining Span Selection",
    author = "Ram, Ori  and
      Kirstain, Yuval  and
      Berant, Jonathan  and
      Globerson, Amir  and
      Levy, Omer",
    booktitle = "Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers)",
    month = aug,
    year = "2021",
    address = "Online",
    publisher = "Association for Computational Linguistics",
    url = "https://aclanthology.org/2021.acl-long.239",
    pages = "3066--3079",
}
```

repository: ocastel/exact-extract

repo_name: ocastel/exact-extract


text:
###Features

----------

Platform Social is a Platform extension used to add social authentication via Sentry Social (included) to the application.  Out of the box it comes with several popular services you can authenticate through, such as Facebook, Twitter, Google and more along with a widget for easy implementation. Here is a list of providers currently supported.

####OAuth
- Dropbox
- Flickr
- LinkedIn
- Tumblr
- Twitter
- Vimeo

####OAuth2
- Blooie
- Facebook
- Foursquare
- Github
- Google
- Instagram
- Paypal
- Soundcloud
- Windowslive

repository: treestones/manuals

repo_name: treestones/manuals


text:
---
date: 2019-05-16
year: 2019
title: Banana
category: Identity
thumbnail: "/uploads/mike-dorner-173502-unsplash.jpg"
categories:
- photography
- pink
project_bg_color: ''
project_fg_color: ''

---
The **banana** fruits grow from a **banana** blossom in hanging clusters, also called a bunch or **banana** stem. The fruits grow in rows called tiers or hands. There can be as many as twenty fruits to a hand, and as many as twenty tiers in a bunch. A bunch usually weighs between 30 and 50 kilograms (65 to 110 pounds).

![](/uploads/mike-dorner-173502-unsplash.jpg)

repository: itsnwa/gridsome-forestry-starter

gha_language: Vue

repo_name: itsnwa/gridsome-forestry-starter


text:
# 21. plugin config

Date: 2021-02-18

## Status

2021-02-18 proposed

2021-02-24 done

## Context

Context here...

## Decision

 - ~~use CLI to generate `plugins.yml` to list plugins config~~
    - ~~in default, we use all plugins~~
 - use `coco.yml` to read plugins

## Consequences

Consequences here...

repository: chalme/coco

gha_language: Rust

repo_name: chalme/coco


text:
# Omnibar

![Swift 5.7](https://img.shields.io/badge/Swift-5.7-blue.svg?style=flat)
![Version](https://img.shields.io/github/tag/CleanCocoa/Omnibar.svg?style=flat)
![License](https://img.shields.io/github/license/CleanCocoa/Omnibar.svg?style=flat)
![Platform](https://img.shields.io/badge/platform-macOS-lightgrey.svg?style=flat)
[![Carthage compatible](https://img.shields.io/badge/Carthage-compatible-4BC51D.svg?style=flat)](https://github.com/Carthage/Carthage)

A search field with support for auto-completion of typed strings and reactive extensions (RxSwift).

## Overview

Made to satisfy these needs:

1. Quickly filter search results;
2. Change result selection through use of the arrow keys from within the Omnibar;
3. Offer auto-completion of the search term inside the text field itself.

So if you type "aard", the Omnibar will suggest the term "aardvark" in the example app:

## Delegate-based Approach

### Displaying Values

Call `display(content: OmnibarContent)` to change the content of the Omnibar and affect the selection. You can also use the `stringValue` property to change the text and put the insertion point at the end like regular `NSTextField`s do.

```swift
public enum OmnibarContent {

    /// Empties the Omnibar.
    case empty

    /// Display `text` inside the Omnibar and select it all (like ⌘A) for
    /// quick overwriting.
    case selection(text: String)

    /// Display `text` inside the Omnibar and put the insertion point
    /// at the end.
    case prefix(text: String)

    /// Display `text`, followed by `appendix`, putting the insertion point
    /// before `appendix` and selecting it so it can be overwritten.
    case suggestion(text: String, appendix: String)
}
```

### Reacting to Events

Set `delegate` to be notified of changes. The `OmnibarDelegate` protocol offers these function signatures:

- Optional: `omnibarSelectNext(_ omnibar: Omnibar)` and `omnibarSelectPrevious(_ omnibar: Omnibar)` to change the selected result without unfocusing the Omnibar.
- Required: `omnibar(_ omnibar: Omnibar, contentChange: OmnibarContentChange, method: ChangeMethod)`, notifying the delegate about the last user interaction and typing change.

`ChangeMethod` can be `.deletion`, `.insertion`, or `.appending` to convey what the user did so you can react to all cases differently.

`OmnibarContentChange` is either a `.replacement` of the old stuff, or a `.continuation` of the last suggestion, if there was any; `.continuation` is just like a self-suggested `OmnibarContent.suggestion` waiting for approval.

```swift
enum OmnibarContentChange {
    case replacement(text: String)
    case continuation(text: String, remainingAppendix: String)
}
```

## Reactive Extension

Implementing delegates is nice and all, but with RxSwift, reacting to search term changes with filtering the results and offering a suggestion from the results back to the Omnibar is even simpler thanks to the declarative nature of observable sequences.

Once you have a reference to `omnibar: Omnibar`, the reactive extension `.rx` offers this:

- `omnibar.rx.text` which behaves just like `NSTextField().rx.text` and sends the whole contents while the user is typing -- it's like a stream of `stringValue` property changes;
- `omnibar.rx.contentChange` emits the changed content, either a `.replacement` or `.continuation`;
- `omnibar.rx.moveSelection` emits either `.previous` (up arrow key) or `.next` (down arrow key);
- `omnibar.rx.content` takes in any `OmnibarContent` value to change the text being displayed.

# Attributions and Contributions

## English Open Word List (EOWL) v1.1.2

The sample app uses a list of 12000+ english words to display and filter.

> The “English Open Word List” (EOWL) was developed by Ken Loge, but is almost entirely derived from the “UK Advanced Cryptics Dictionary” (UKACD) Version 1.6, by J Ross Beresford.

- [English Open Word List](http://dreamsteep.com/projects/the-english-open-word-list.html)
- "UK Advanded Cryptics Dictionary" was formerly available at <http://cfaj.freeshell.org/wordfinder/UKACD17.shtml> but is now down

## License

Copyright (c) 2017-2022 Christian Tietze. Distributed under the MIT License.

repository: CleanCocoa/Omnibar

repo_name: CleanCocoa/Omnibar


text:
# Rz_smp

## Introduction
Rz_smp stands for simple module protocol. It is used for covering common protocol between MCU and modules.

## Dependancy
* Rz_rbuf
* standard library

## How to use
1. set configuration in rz_smp.h
2. Create descriptor array based on protocol
3. Implement callback function phy_tx()
4. initial a variable struct smp_s
5. regist (1), (3)
6. use API phy_rx() to push data
7. use API do_packet() to analyse data anytime
8. check smp->packet_flag,
   if 1, means packet is valid and payload is ready to be read
10. use get_payload() to get data

### about descriptor
Descriptor is used for desciption each part of packet

```
struct smp_descriptor {
    char *name;
    char type;
    int size;
    int value;
};
```
#### name
rz_smp use "name" to recognize some specific parts in packet. So there are some reserved name for rz_smp use. Except them, Users can create their own name

Reserved name
* HEAD (header)
* LENG (length)
* VDAT (data with vary length)
* CHEC (checksum)

### type
type is a bit field controlled parameter. rz_smp will process data according to type
* DESC_TYPE_PAYLOAD
Indicate the part is included in payload and will be send to upper layer
* DESC_TYPE_IN_LEN
Indicate the part size is counted in LENG part
* DESC_TYPE_IN_CS
Indicate the part in included in calculating checksum
* DESC_CSTYPE_CS
CS type = checksum
* DESC_CSTYPE_CRC8
CS type = CRC8

### size
length of this part in packet (bytes)

### value
Magic numbe
e.g. HEADER, END, 1's compliment etc.

### example1

| HEADER | LENGTH     | PAYLOAD     | CS    |
| ------ | ---------- | ----------- | ----- |
| 1byte  | 1 byte     | cmd +arg    | 1byte |
| 0xAA   |  L + P + C | cmd +arg    | P + L |

            |----------------- length -----------------|
            |---------- CS ----------|

packet = 0xAA 0x04 0x01 0x03 0x08
HEADER= 0xAA
LENGTH = 1 + 2 + 1 = 4
CS = L + P = 0x04 + (0x01+0x03) = 0x08

Declare descriptor
```
{
    .name = "HEAD",
    .type = 0,
    .size = 1,
    .value = 0xAA
}
{
    .name = "LENG",
    .type = DESC_TYPE_IN_LEN | DESC_TYPE_IN_CS,
    .size = 1,
    .value = 0,
}
{
    .name = "VDAT",
    .type = DESC_TYPE_IN_LEN | DESC_TYPE_IN_CS,
    .size = 0,  //VDAT size has to be 0
    .value = 0,
}
{
    .name = "CHEC",
    .type = DESC_TYPE_IN_LEN,
    .size = 1,
    .value = 0,
}
```

### example 2
fixed length

| START | DIR | SERIAL | PAYLOAD | CRC | END |
| ----- | --- | ------ | ------- | --- | --  |
| 1B    | 1B  | 4B     | 64B     | 2B  | 1B  |
| 0x5A  | 0/1 | int    |         | crc | 0xA5|    |

                              |--- CS ---|

```
{
    .name = "HEAD",
    .type = DESC_TYPE_FIXED_VALUE,
    .size = 1,
    .value = 0x5A
}
{
    .name = "DIR",
    .type = 0,
    .size = 1,
    .value = 0,
}
{
    .name = "SERIAL",
    .type = 0,
    .size = 4,
    .value = 0,
}
{
    .name = "PAYL",
    .type = DESC_TYPE_IN_LEN,
    .size = 64,
    .value = 0,
}
{
    .name = "CHEC",
    .type = 0,
    .size = 2,
    .value = 0,
}
{
    .name = "END",
    .type = DESC_TYPE_FIXED_VALUE,
    .size = 1,
    .value = 0xA5,
}
```

## Configurations
* CONFIG_SMP_CALLBACK
  value: boolin
  if packet is ready, call payload_ypper_tx() automatically

* CONFIG_SMP_AUTO_DO_PACKET
  value: boolin
  auto run do_packet() everytime phy_rx() is called

* CONFIG_SMP_FIXED_PACKET_LENGTH
  value: boolin
  packet length is fixed, size in VDAT descriptor must be set

* CONFIG_SMP_TX_BUF_SIZE
  value: int range

## Todo
* add direction feature
* add doxygen style comment
* add ending feature
* add asynchronous feature
* 64bit debug
* add RTOS supporting
* add zero copy, not zero copy config
* add endian support (only little endian now)
* add other checksum method
* test.c
* seperate tx rx, make reentry work
* add malloc config (especially for tx)


text:
twitterScraper.js
=================

Script bundle to build a text corpus based on tweet IDs.

Given a corpus of tweet IDs in XML (following the format provided by the
[SEPLN TASS](http://www.daedalus.es/TASS/about.php) competition), the
twitterScraper.js extracts the tagged IDs and queries Twitter in order to
obtain the body of the text.

For any comment or suggestion of any kind, please contact
[Alexandre Trilla](mailto:alex@atrilla.net).

Install
-------

Some dependencies are needed for Node.js: jQuery and xml2js, available
through npm.

The main procedure is found in run.js. It outputs the textual body of the
tweets on the console.

Hacking
-------

* run.js: main procedure.
* stereo.js: tweet ID iterator.
* tweeter.js: interface to query Twitter.
* woofer.js: interface to the XML corpus.

Credits
-------

* Node.js: Joyent, Inc. http://nodejs.org/
* jQuery: jQuery Foundation and other contributors. http://jquery.com/
* xml2js: Leonidas-from-XIV. https://github.com/Leonidas-from-XIV/node-xml2js/

Copying
-------

Copyright (c) 2012 Alexandre Trilla

Distributed under the MIT/X11 License.


text:
# Parallel Programming With Python by Jan Palach - Chap 1: Contextualizing, Parallel, Concurrent, and Distributed Programming

<!-- toc orderedList:0 -->

- [Parallel Programming With Python by Jan Palach - Chap 1: Contextualizing, Parallel, Concurrent, and Distributed Programming](#parallel-programming-with-python-by-jan-palach-chap-1-contextualizing-parallel-concurrent-and-distributed-programming)
	- [Resources](#resources)
	- [Why use parallel programming?](#why-use-parallel-programming)
	- [Exploring common forms of parallelization](#exploring-common-forms-of-parallelization)
	- [Communicating in parallel programming](#communicating-in-parallel-programming)
		- [Shared state](#shared-state)
		- [Message passing](#message-passing)
	- [Identifying parallel programming problems](#identifying-parallel-programming-problems)
		- [Deadlock](#deadlock)
		- [Starvation](#starvation)
		- [Race conditions](#race-conditions)
	- [Discovering Python's external parallel programming tools](#discovering-pythons-external-parallel-programming-tools)
		- [`parallel` module](#parallel-modulehttpparallelpythoncom)
		- [`celery` – a distributed task queue](#celery-a-distributed-task-queuehttpceleryprojectorg)

<!-- tocstop -->

 ## Resources

The Little Book of Semaphores by David Beazley

## Why use parallel programming?

Speed.

## Exploring common forms of parallelization

- _Concurrent programming_ is an abstraction from parallel programming.
- _Parallel systems_ run tasks simultaneously.
- _Distributed systems_ run tasks within physically-separated nodes.

Distributed programming is becoming more and more popular for many reasons:

- **Fault-tolerance**: As the system is decentralized, we can distribute the processing to different machines in a network, and thus perform individual maintenance of specific machines without affecting the functioning of the system as a whole.
- **Horizontal scalability**: We can increase the capacity of processing in distributed systems in general. We can link new equipment with no need to abort applications being executed. We can say that it is cheaper and simpler compared to vertical scalability.
- **Cloud computing**: With the reduction in hardware costs, we need the growth of this type of business where we can obtaining huge machine parks acting in a cooperative way and running programs in a transparent way for their users.

## Communicating in parallel programming

Two forms of communication in parallel programming: shared state & message passing.

### Shared state

has many pitfalls:

- an invalid operation made to the shared resource by one of the processes will affect all of the others, thereby producing bad results.
- impossible for the program to be distributed between multiple machines.

### Message passing

- When we aim to avoid data access control and synchronizing problems originating from shared state.
- Once data is copied at each message exchange, it is impossible that problems occur in terms of concurrence of access.
- Higher memory use than in shared memory state.
- Advantages:

  - Absence of data access concurrence
  - Messages can be exchange locally (various processes) or in distributed environments
  - This makes it less likely that scalability issues occur and enables interoperability of different systems
  - In general, it is easy to maintain according to programmers

> Two events are concurrent if we cannot tell by looking at the program which will happen first.

## Identifying parallel programming problems

### Deadlock

- a situation in which 2 or more workers keep _indefinitely_ waiting for the freeing of a resource,
- which is blocked by a worker of the same group for some reason.

> Deadlock is a phenomenon in which processes wait for a condition to free their tasks, but this condition will never occur.

### Starvation

> Starvation is caused by badly adjusted policies of process ranking.

### Race conditions

- Occur when the result of a process depends on a sequence of facts, and this sequence is broken due to the lack of synchronizing mechanisms
- extremely difficult to filter in larger systems.
- parallel programming is _non-determinism_.

> Non-determinism, if combined with lack of synchronization mechanisms, may lead to race condition issues.

## Discovering Python's external parallel programming tools

### [`parallel` module](http://parallelpython.com)

- Automatic detection of the optimal configuration
- The fact that a number of worker processes can be changed during runtime
- Dynamic load balance
- Fault tolerance
- Auto-discovery of computational resources

### [`celery` – a distributed task queue](http://celeryproject.org)

repository: beenorgone-notebook/python-notebook

gha_language: Python

repo_name: beenorgone-notebook/python-notebook


text:
# Phyllachora uppalii K. Ramakr. & Subram., 1956 SPECIES

#### Status
ACCEPTED

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Journal of Madras Univ. , B 26: 364 (1956)

#### Original name
Phyllachora indica Theiss. & Syd., 1915

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
# Contributors Style Guide (feature/improvement)

Currently we are following a set of style rules and a basic test suite for maintaining a clean and organized code base. It is very important for to follow these style guide before you push your feature or enhancements to the master branch .

## Our linting tools

- `Eslint` : For linting and style related errors checks.
- `Prettier` : For linting fix and formatting.

## Our Testing tools

- `Chai and Mocha` : For the basic unit testing
- `Supertest` : for unit test with `http` assertions.

## Steps :

### Setting up the local environment

```
npm install

```

1. To install all the needed dependencies.

```
npm start
```

2. To start the development server . And thats it.It should be up and running in `localhost:3000`.
3. We are using reload module so any change you make will be immediately shown in the browser.

### Linting -

- For checking errors :

```
npm run lint
```

- For fixing all possible errors

```
npm run lint:fix
```

### Unit Test

```
npm run test
```

##### > Make sure to test your code with the above script before making a pull request

##### > Happy Coding :)


text:
# Setup

    npm install -g @graphprotocol/graph-cli
    npm run codegen

# Adding an entity

- subgraph.yaml
- schema.graphql
- src/mapping.ts

# Example Subgraph

An example to help you get started with The Graph. For more information see the docs on https://thegraph.com/docs/.

##
Active user count

  mintCount: Int!
  burnCount: Int!

  nonZeroBalanceCount: Int!

gha_language: TypeScript