text:
---
eip: 2718
title: Typed Transaction Envelope
author: Micah Zoltu (@MicahZoltu)
discussions-to: https://ethereum-magicians.org/t/eip-2718-typed-transaction-envelope/4355
status: Draft
type: Standards Track
category: Core
created: 2020-06-13
requires: 155
---

## Simple Summary
Defines a new transaction type that is an envelope for future transaction types.

## Abstract
`TransactionType || TransactionPayload` will become a valid transaction and `TransactionType || TransactionPayload` will become a valid transaction receipt identifying the format of the transaction and `*Payload` is the transaction/receipt contents, which are defined in future EIPs.

The first two new transaction types will be a wrapped legacy transactions with the formats:
* `0x00 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data)`
* `0x01 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)`

The first new receipt will be a wrapped legacy receipt with the format `0 || ssz(status, cumulativeGasUsed, logsBloom, logs)`.

## Motivation
In the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types.
This was seen in [EIP-155](./eip-155.md) where the new value was bit-packed into one of the encoded fields.
There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides `msg.sender` to pay for gas, and proposals related to layer 0 multi-sig transactions.
These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.

By introducing an envolope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between `TransactionType`s.

## Specification
### Definitions
* `||` is the byte/byte-array concatenation operator.
* `yParity` is the parity (0 for even, 1 for odd) of the `y` value of the curve point for which `r` is the `x` value in the secp256k1 signing process.

### Transactions
As of `FORK_BLOCK_NUMBER`, `rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` (legacy transaction) will no longer be a valid Ethereum transaction over the devp2p protocol or in a block.

As of `FORK_BLOCK_NUMBER`, all transactions sent over devp2p **MUST** be of the form `TransactionType || TransactionPayload` where `TransactionType` is a positive unsigned number between `0` and `0x7f` that represents the type of the transcation and `TransactionPayload` is an opaque byte array whose interpretation is dependent on the `TransactionType`.
New `TransactionType`s **SHOULD** include the `TransactionType` as the first byte in any signatures they include to minimize the chance of unintentional replay attacks between different transaction types.
The transaction hash of all transactions **MUST** be `keccak256(TransactionType || TransactionPayload)`

As of `FORK_BLOCK_NUMBER`, the transaction root in the block header **MUST** be the root hash of `patriciaTrie(transactionIndexInBlock => TransactionType || TransactionPayload)` where `transactionIndexInBlock` is encoded as a big endian 16-bit number.

As of `FORK_BLOCK_NUMBER`, `0x00 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data)` will be a valid transaction where the RLP encoded transaction portion is signed/processed/handled exactly the same as legacy transactions were signed/processed/handled, with the exception of the final encoding.

As of `FORK_BLOCK_NUMBER`, `0x01 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)` will be a valid transaction where the RLP encoded transaction portion is signed/processed/handled exactly the same as legacy transactions were signed/processed/handled, with the exception of the final encoding.

### Receipts
As of `FORK_BLOCK_NUMBER`, `rlp([status, cumulativeGasUsed, logsBloom, logs])` (legacy receipt) will no longer be a valid Ethereum transaction receipt over the devp2p protocol or as part of a block.

As of `FORK_BLOCK_NUMBER`, all receipts sent over devp2p **MUST** be of the form `TransactionType || ReceiptPayload` where `TransactionType` is a number between `0` and `0x7f` that represents the type of the transaction and `ReceiptPayload` is an opaque byte array whose interpretation is dependent on the `TransactionType`.

As of `FORK_BLOCK_NUMBER`, the receipt root in the block header **MUST** be the root hash of `patriciaTrie(transactionIndexInBlock => TransactionType || ReceiptPayload)` where `transactionIndexInBlock` is encoded as a big endian 16-bit number.

As of `FORK_BLOCK_NUMBER`, `0 || ssz(status, cumulativeGasUsed, logsBloom, logs)` will be a valid receipt where the `ReceiptPayload` will be generated/processed/handled exactly the same as legacy receipts were processed/handled with the exception of its encoding.

As of `FORK_BLOCK_NUMBER`, `1 || ssz(status, cumulativeGasUsed, logsBloom, logs)` will be a valid receipt where the `ReceiptPayload` will be generated/processed/handled exactly the same as legacy receipts were processed/handled with the exception of its encoding.

### Fork Block Transition
Between `FORK_BLOCK_NUMBER - 1` and `FORK_BLOCK_NUMBER` clients **SHOULD** convert all transactions in their local pending pool into type 0 transactions.
Clients **MAY** choose to flush their pending pool instead, if it is not possible to do the wrapping in time for the next block, though this is discouraged.

As of `FORK_BLOCK_NUMBER`, clients **SHOULD** accept incoming transactions over user/application facing APIs such as JSON-RPC in both the new wrapped format and the legacy format.
If a legacy format transaction is received, the client **MUST** wrap it in a type 0 envelope before sending it over devp2p or including it in a block.

As of `FORK_BLOCK_NUMBER`, clients **SHOULD** return type 0 receipts over user/application facing APIs such as JSON-RPC in the **legacy** format.
Clients **SHOULD** devise a long term strategy for deprecating the legacy format over APIs in favor of the typed receipt envelope format.

## Rationale
### Not including the type in type 6 signatures
While this EIP recommends that the envelope be included in any signatures, it also specifies that for Transaction Type 0 the envelope is not included in the signature.
This EIP disobayes its own recommendation because we don't want all signing tools to break on the fork block and require updates to start working again.
### TransactionType only goes up to 0x7f
For the forseable future, 0x7f is plenty and it leaves open a number of options for extending the range such as using the high bit as a continuation bit.  This also prevents us from colliding with legacy transaction types, which always start with a byte `>= 0xc0`.
### TransactionType selection algorithm
There was discussion about defining the `TransactionType` identifier assignment/selection algorithm in this standard.
While it would be nice to have a standardized mechanism for assignment, at the time of writing of this standard there is not a strong need for it so it was deemed out of scope.
A future EIP may introduce a standard for TransactionType identifier assignment if it is deemed necessary.
### Opaque byte array rather than an RLP array
By having the second byte on be opaque bytes, rather than an RLP (or other encoding) list, we can support different encoding formats for the transaction payload in the future such as SSZ, LEB128, or a fixed width format.
### ORIGIN and CALLER
There was discussion about having ORIGIN and CALLER opcodes be dependent on the transaction type, so that each transaction type could define what those opcodes returned.
However, there is a desire to make transaction type opaque to the contracts to discourage contracts treating different different types of transactions differently and there also were concerns over backward compatibility with existing contracts which make assumptions about ORIGIN and CALLER opcodes.
Going forward, we will assume that all transaction types will have an address that reasonably represents a `CALLER` of the first EVM frame and `ORIGIN` will be the same address in all cases.
If a transaction type needs to supply additional information to contracts, they will need a new opcode.
### Hashing the outer transaction
If you submit a transaction prior to the fork block and it is mined after the fork block, the transaction hash of the mined transaction will not match the the transaction hash of the transaction you originally submitted.
This is because the mined transaction will be a wrapped one, while the submitted transaction will be unwrapped.
Applications that use the transaction hash to lookup the transaction result will fail to ever find it or see it ever mined.
Clients can optionally choose to track type 6 transactions internally by both hashes for a period of time so that lookups of the old hash won't fail for the user, but this is not required for consensus.
### TransactionType 0 & 1 instead of just 0 that matches legacy
Legacy transactions were quite complicated due partially to EIP-155 and partially to the way they are encoded.
This change should reduce complexity in clients by making it easier to validate transactions, and it moves the complexities around EIP-155 and transaction encoding out near the JSON-RPC layer.
* Legacy transactions have to be RLP decoded first, the signature extracted, and then RLP encoded without the signature in order to validate them.
* Legacy transactions have to extract and process the `v` value before they can recreate the signed data for validation.

### TransactionType 0/1 0x65000000 element
`0x00 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data)` is the same as `ssz(0, yParity, r, s, rlp(nonce, gasPrice, gasLimit, to, value, data))`, which may prove convenient for some clients.  It costs us 4 extra bytes on the wire (mostly zeros), but the authors deem this a worthwhile trade to be SSZ encodable/decodable.

## Backwards Compatibility
Clients can differentiate between the legacy transactions and typed transactions by looking at the first byte.  If it starts with a value in the range `[0, 0x7f]` then it is a new transaction type, if it starts with a value in the range `[0xc0, 0xff]` then it is a legacy transaction type.

## Test Cases
TBD

## Implementation
TBD

## Security Considerations
TBD

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

repository: vulcanize/EIPs

gha_language: HTML

repo_name: vulcanize/EIPs


text:
# hello-gcp-cloudrun-flask
hello-gcp-cloudrun-flask

## How to run

### Assumptions
Define below environment variables for GCP specific environment
- HOSTNAME=gcr.io
- PROJECT=hello-cloudrun
- REGION=us-central1
- IMAGE_TAG=hello-gcp-cloudrun-flask

### Initialize
`source 0_init.sh`
`source z_dump_env.sh`

### Enable GCP services
`source 1_gcloud_enable_services.sh`

### Submit GCP build
`source 2_gcloud_submit_build.sh`

### Submit GCP run
`source 3_gcloud_run.sh`

### Cleanup
`source 4_gcloud_images_list.sh`
`source 5_gcloud_delete_image.sh`
- confirm images are deleted in GCP console
- (optionally) delete PROJECT

## References
- https://cloud.google.com/run/docs/quickstarts/build-and-deploy

license: MIT

repository: nalbarr/hello-gcp-cloudrun-flask

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: nalbarr/hello-gcp-cloudrun-flask


text:
# Land Acknowledgement

A compilation of resources for those looking to acknowledge land and place.

Forked from [Political Resources](https://valeriecodes.github.io/political-resources/) by [valeriecodes](https://github.com/valeriecodes).

[The site.](https://davidagross.github.io/land-acknowledgement/)

Have something to add?

* The easiest way is to make a pull request, if you are able. The pages are written in [Markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) and if you've never made a pull request you can learn how from [this page](https://help.github.com/articles/creating-a-pull-request/).
* If you'd rather not bother with a PR, open [an issue](https://github.com/davidagross/land-acknowledgement/) or [email me](mailto:david.alexander.gross@gmail.com).

Questions, comments? I'm [@dgroseph](https://twitter.com/dgroseph) on Twitter.

repository: davidagross/land-acknowledgement

repo_name: davidagross/land-acknowledgement


text:
Experimental lx branded zone for openSUSE Leap 42.2

Current status: **it works**

# SmartOS Requirements

* SmartOS: > 20170913T233706Z
* https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20170913T233706Z
* https://smartos.org/bugview/OS-6326

# Requirements

Install kiwi3 from the Virtualization:Appliances repository:

```
sudo zypper ar -f obs://Virtualization:Appliances/openSUSE_Leap_42.2 Virtualization:Appliances"
zypper in -f python3-kiwi
```

# Build instructions

Perform the following command inside of the git repository checkout:

```
sudo kiwi-ng system prepare --description . --root /tmp/lx-zone
```

This will build the root filesystem of the zone.

At the end of the process just run:

```
sudo tar czf opensuse-zone.tar.gz /tmp/lx-zone
```

### SmartOS lx-brand guest tools

This repository contains a small fork of the [upstream guest tools](https://github.com/joyent/sdc-vmtools-lx-brand).

Some changes have been made to make the installation script work with KIWI. This
is needed because KIWI `system prepare` will run the script straight from a chroot
session.

TODO: submit the changes upstream once the lx branded zone works.

# Image and manifest creation

Copy the `opensuse-lx-zone.tar.gz` file to a SmartOS host.

Checkout [this](https://github.com/joyent/debian-lx-brand-image-builder) repository
and then execute:

```
./create-lx-image -t /zones/opensuse-zone.tar.gz -k 3.13.0 -i lx-opensuse-leap-42-2 -d "openSUSE Leap 42.2 64-bit lx-brand image." -u http://opensuse.org -m 20150316T201553Z
```

This will produce the `.zfs` image and its manifest.

The can be imported via:

```
imgadm install -m lx-opensuse-leap-42-2-20170406.json -f lx-opensuse-leap-42-2-20170406.zfs.gz
```

The names of the image and of the manifest are going to change according to your
local time.

# Run the zone

Get the uuid of the image by doing: `imgadm list | grep opensuse`, then
create a `.json` file like this one:

```json
{
  "alias": "lxtest",
  "brand": "lx",
  "kernel_version": "4.3.0",
  "max_physical_memory": 2048,
  "quota": 10,
  "image_uuid": "82e018c4-1ada-11e7-9b00-17458a170ca3"
}
```

Replace `image_uuid` with the actual `uuid` of your image.

Then start the zone by doing:

```
vmadm create -f opensuse.json
```

repository: plitc/opensuse-lx-zone

repo_name: plitc/opensuse-lx-zone


text:
# shendi
## Character generator for Pathfinder Second Edition (2e)
###### Built in python

## About
Hi!, this is a project by AucaCoyan#9411. Contact me at Discord.

**I'm pretty new to programming, so expect a bunch of bugs and spaghetti code.**

The issues tab is layered in Alpha, Beta, Release 1.0, and Release 2. There is specified when is planned to do which feature.

repository: shendi-project/shendi

gha_language: Python

gha_license_id: MIT

repo_name: shendi-project/shendi


text:
Thanks so much for filing an issue or feature request! Please fill out the following (wherever relevant):

* cordova-plugin-code-push version:
* List of installed plugins:
* Cordova version:
* iOS/Android/Windows version:
* Does this reproduce on a debug build or release build?
* Does this reproduce on a simulator, or only on a physical device?
* Repro steps and/or stack trace:

(The more info the faster we will be able to address it!)

repository: zenput/cordova-plugin-code-push

repo_name: zenput/cordova-plugin-code-push


text:
# Tangram Refill Style

**Refill** provides a high contrast, black & white basemap useful for data visualization. Give [OpenStreetMap](http://www.openstreetmap.org/) data a refined basemap skin using the [Tangram](http://github.com/tangrams/tangram) graphics library and Mapzen's versatile [Vector Tiles](https://mapzen.com/projects/vector-tiles/).

Refill is a continuation of the [Toner](http://content.stamen.com/dotspotting_toner_cartography_available_for_download) style Geraldine started at [Stamen](http://stamen.com). With the GL capabilities of Tangram, detailed lines, patterns and building extrusions are further explored and elaborated upon from the previous Toner base-style. Toner was a style created at Stamen as part of their great [CityTracking](http://citytracking.org) project. Please use and adapt the open source scene file in your own projects!

**Looking for help?** There is a mini tutorial after the preview image below walking thru [Vector Tiles API key signup](https://github.com/tangrams/refill-style/blob/gh-pages/README.md#sign-up-for-a-mapzen-vector-tiles-api-key) and [building a Leaflet map](https://github.com/tangrams/refill-style/blob/gh-pages/README.md#building-a-leaflet-map-using-tangram) using Tangram and this repo's scene file.

### A family of styles with many flavours

Mapzen offers the Refill style in three flavors:

2. **Default** (this repo) - Some labels for streets, cities, water bodies, and some big parks with name only (no icons). No business labels. Good for data visualization overlays that need to provide some location context.
1. **[More labels](https://github.com/tangrams/refill-style-more-labels)** - Full set of labels, including high contrast icons highlighting OpenStreetMap business listing data.
3. **[No labels](https://github.com/tangrams/refill-style-no-labels)** - Just the lines and polygons, please.

**Looking for a different style?** We offer a range of styles including [Cinnabar](https://github.com/tangrams/cinnabar-style) (colorful classic cartography) and [Zinc](https://github.com/tangrams/zinc-style) (soft gray cartography).

**Live Refill demo:** http://tangrams.github.io/refill-style

![refill-preview](https://cloud.githubusercontent.com/assets/853051/11160181/87349950-8a1b-11e5-8559-5c6d95cb84d5.png)

## Developer resources

**So how do you actually use this stuff?** Tangram styles are called "scenes" and are written in YAML. The scene file (e.g.: [refill-style.yaml](https://github.com/tangrams/refill-style/blob/gh-pages/refill-style.yaml)) requires a vector tile source. To use Mapzen's vector tile service you must first obtain a free developer API key and update your scene file with that key.

 As such, there are generous limitations on requests to prevent individual users from degrading the overall system performance.

1. Go to https://mapzen.com/developers.
2. Sign in with your GitHub account. If you have not done this before, you need to agree to the terms first.
3. Create a new key for Vector Tiles, and optionally, give it a project name so you can remember the purpose of the key.
4. Keep the web page open so you can copy the key into your source code later.

### Building a Leaflet map using Tangram

Using Tangram and Mapzen's Vector tiles inside the popular [Leaflet](http://leafletjs.com) mapping framework is easy. We'll make it even easier soon to do this via a Leaflet [provider](https://github.com/leaflet-extras/leaflet-providers), but in the meantime...

1. Update your copy of the scene file on [line 428](https://github.com/tangrams/refill-style/blob/gh-pages/refill-style.yaml#L428) to reference the API key you created in Step 3 in the **Sign up** section above.
`url:  //vector.mapzen.com/osm/all/{z}/{x}/{y}.topojson?api_key=vector-tiles-{your-api-key-here}`
2. Reference the [index-demo.html](index-demo.html) file in any of the style repos for how to configure Leaflet with Tangram and the scene file (e.g.: [Refill](http://github.com/tangrams/refill-style)).
3. Looking for a more sophisticated implementation that includes basic search? The main [index.html](index.html) file has a more real world example.
4. Need help testing your map locally? See the README in each repo.
5. Wondering where to host your map? Make a public repo on Github (or fork ours!) and enjoy their [GitHub Pages](https://pages.github.com) to github.io magic dance.

### Tangram resources

1. [Procedural Cartography with Tangram](https://github.com/mapzen/presentations/tree/master/08-2015-JSGEO) Patricio's presentation notes from [JS.Geo](http://www.jsgeo.com).
2. [Walkthrough: Make a map with Tangram](https://mapzen.com/documentation/tangram/walkthrough/) by Rhonda on Mapzen's documentation team.

### To run locally

Want to modify the style to fit your needs? Clone or downloaded the repo locally. Then...

Start a web server in the repo's directory:

    python -m SimpleHTTPServer 8000

If that doesn't work, try:

    python -m http.server 8000

Then navigate to: [http://localhost:8000](http://localhost:8000), which loads the [index.html](index.html) file.

**You should be all set, happy mapping!** But please let us know at [hello@mapzen.com](mailto:hello@mapzen.com?subject=Help%20with%20style%20demo%3F) or via Twitter [@mapzen](http://twitter.com/mapzen) if you encounter any funk and we'll help you get up and running.

### See also:

* Blog post announcing this style...

repository: tangrams/refill-style

branch_name: refs/heads/gh-pages

repo_name: tangrams/refill-style


text:
# Evernote Sample Usage of API for Express

This is a sample application of Express with a library for accessing the Evernote API from node.

You can find a blog post on how to use it [here](https://medium.com/@heitorburger/2e7184b2a08b).

## Setup

- You need a sandbox account.  If you haven't had a Sandbox account yet, you can create one [here](https://sandbox.evernote.com/Registration.action).
- Create the .env file to set your environment variables:

```sh
$ cp .env.sample .env
```

- Fill your API Consumer Key and Consumer Secret in .env.

## Start application

### Run with Node.js

- Change the environment variables in .env to:

```
APP_URL=http://localhost
PORT=3000
```

You can start the express server with `npm start`.  Once the server starts, you can access `http://localhost:3000` and see the application. It will list the notebooks in your sandbox account after you authenticate. Edit express/routes/index.js to try other parts of the Evernote API.

### Run with azk

- Change the environment variables in .env to:

```
APP_URL=http://express.dev.azk.io
PORT=3000
```

Go to your terminal and run:

```sh
$ azk start
```

And open: http://express.dev.azk.io

## Deploy to Heroku

To deploy to Heroku, just run:

```sh
git subtree push --prefix sample/express heroku master

# or force push
$ git push heroku `git subtree split --prefix sample/express master`:master --force
```

repository: lydonchandra/evernote-sdk-js

repo_name: lydonchandra/evernote-sdk-js


text:
# Sentiment Anlaysis of lyrics of songs by popular artist.

# Exploration through markov chains.

_**[View web version here](https://arnavd96.github.io/songs-sentiment-analysis/).**_

_**[View pdf version of paper here](https://arnavd96.github.io/songs-sentiment-analysis/Project_Paper_notebook.pdf).**_

repository: gitvivekgupta/songs-sentiment-analysis

repo_name: gitvivekgupta/songs-sentiment-analysis


text:
---
title: Can Bee Stings Treat Lyme Disease?
author: PipisCrew
date: 2019-12-07
categories: [health]
toc: true
---

**Gschwind** asked. “One, two, three.” She held the bee’s butt about an inch to the left of **Avery’s** lower spine and waited for the tiny stinger to pierce the skin. Then she pulled away the bee, now missing its stinger, which was still drilling into **Avery’s** back.

This process would continue until the bottom portion of **Avery’s** spine looked like a clear highway running between two parallel rows of five inflamed bumps. Each protrusion was dotted with a stinger, moving like a pumpjack atop a tiny, rising hill, as it continued to gently, rhythmically, excrete venom. Twenty minutes later, when the barbs had done their job and stopped moving, **Gschwind** extracted them.

https://www.texasmonthly.com/articles/can-bee-stings-treat-lyme-disease/

![alt](https://i.imgur.com/TTW1qUh.jpg)

origin - https://www.pipiscrew.com/?p=16241 can-bee-stings-treat-lyme-disease


text:
# Cluster

## Overview

This folder contains files related to the configuration of the Prow production cluster that are used during the cluster provisioning.

### Project structure

<!-- Update the folder structure each time you modify it. -->

The structure of the folder looks as follows:

```
  ├── 00-deck-patch.yaml                # The patch file for the Deck Deployment used to enable HTTP to HTTPS redirection.
  ├── 01-cert-manager.yaml              # The definition of the Cert Manager and related resources, required to manage the SSL certificates that ensure the trusted website connection
  ├── 02-cluster-issuer.yaml            # The definition of the resource which creates new certificates
  ├── 03-tls-ing_ingress.yaml           # The definition of the encrypted Ingress that accesses the Prow cluster
  ├── 04-branchprotector_cronjob.yaml   # The definition of the Branch Protector CronJob that configures protection on branches
  ├── 05-tiller.yaml                    # The definition of the Tiller that is used for Helm integration
  ├── 06-pushgateway_deployment.yaml    # The definition of the Pushgateway that is used for monitoring
  ├── 07-kube-system_poddisruptionbudgets.yaml # The definition of Pod Disruption Budgets for Pods in the  `kube-system` Namespace, used to unblock the node autoscaler.
  ├── 08-prow-addons-ctrl-manager.yaml #  The definition of the prow addons controller manager resources, required i.a. to send Slack notification about ProwJob.
  ├── starter.yaml                      # The basic definition of Prow, including ConfigMaps, Deployments, and CustomResourceDefinitions
  └── required-secrets.yaml             # A default list of required Secrets that must be stored in a storage bucket
```

### Required secrets structure
The `required-secrets.yaml` file is read by `secretspopulator` and consists of required Secrets stored in a Google Cloud Storage (GCS) bucket.
You can define two kinds of Secrets:
- Service accounts
- Generic Secrets

`Secretspopulator` looks for a `{prefix}.encrypted` object in a bucket and creates a Kubernetes Secret with a `{prefix}` name.
For service accounts, the Secret key is `service-account.json`. For generic Secrets, you must provide a key.
For more details about the syntax of this file, see the `RequiredSecretsData` type in `development/tools/cmd/secretspopulator/secretspopulator`.

repository: jesusreal/test-infra

repo_name: jesusreal/test-infra


text:
# Leptosphaeria hamamelidis Fairm. SPECIES

#### Status
ACCEPTED

#### According to
Index Fungorum

#### Published in
Proc. Rochester Acad. Sci. 6: 127 (1922)

#### Original name
Leptosphaeria hamamelidis Fairm.

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
## Welcome to CricVis

Here, you can find a few visualizations, mostly pertaining to probably irrelevant statistics in cricket.
This page gets updated from time to time, with no particular schedule.

If you are interested in some visualization or seek help in doing something similar yourself, you can email at [cricvis@protonmail.com](mailto:cricvis@protonmail.com).

#### [Average variation](variation)

A basic look at the performance variation of players through a radar chart. Data has been scraped from the espncricinfo player profile pages, and is updated at the end of major series. Some basic thresholds were used to limit the players. Feedback welcome.

#### [Player separation](separation)

Inspired by [a post on r/cricket](https://www.reddit.com/r/Cricket/comments/cq1z2n/steve_smith_is_9_degrees_of_separation_from_the)
about degree of separation between Steven Smith from the Australian team that played its first test,
this is a visualization about who played with whom in tests, with an option to look for degree of separation
between any two players.

#### Work in progress

Some of the other ideas which will show up here are mentioned below. Since this is a hobby project, there's no timeline whatsoever.

1. Historical player (possibly teams as well) rankings.

Have an interesting idea? Please drop an email to [cricvis<EMAIL_ADDRESS>


text:
---
title: "Supported Browsers"
keywords: "FAQ, console, KubeSphere, Kubernetes"
description: "Use a supported web browser to access the console."
linkTitle: "Supported Browsers"
Weight: 16510
---

The KubeSphere web console supports major web browsers including **Chrome, Firefox, Safari, Opera, and Edge.** You only need to consider the supported versions of these browsers listed in the green box of the table below:

![console-browser](/images/docs/v3.3/faq/kubesphere-web-console/supported-browsers/console-browser.png)

repository: kubesphere/website

gha_language: SCSS

repo_name: kubesphere/website


text:
# nod-vid-skal
Node at Shell (nodejs, zsh)

This is an essay about using javascript in the command line via ``nodejs``.

Check it here [Node at Shell (essay)](https://github.com/ricoymx/nod-vid-skal/blob/main/_named-arguments-with-json_essay.md)

repository: ricoymx/nod-vid-skal

branch_name: refs/heads/main

repo_name: ricoymx/nod-vid-skal


text:
JPool

A simple job queue which provides control over a NodeJS worker_thread pool.

## What is it
Jobs taking seconds to complete over time is expensive in the long run. This library makes it possible to execute thousands of in under a minute! This is the final result.

## Installation
```
npm install jpool
```

## Features
The amount of threads is variable, and all states are deterministic. A job will either pass, fail, or halt. This allows the pool to gracefully shut down or quit abruptly without zombies or runaway processes.

## Usage
Clients need at least 2 files. The file that houses the main event loop, and the job file. Jobs are added to the queue by referencing the file name.

#### Basic example (Main.js)
```js
// create a new pool. Pass options to configure the initial state.
const pool = new Pool({threads: 8});

// add a job to the queue
pool.add(path.resolve(__dirname, 'jobs/findRandomNumber.js'));

// process all jobs in queue and listen for more.
pool.start()

// jobs can be added while pool is running
pool.add(path.resolve(__dirname, 'jobs/findRandomNumber.js'));

// stop the pool
pool.stop()
```

#### Basic example (Job.js)
```js
const {parentPort, workerData} = require("worker_threads");

// Run anything. Once the process terminates, then
// the pool will take another item from the queue.
// Calling parentPort.close(); is like resolving a promise
// but it is not required as long as the program terminates normally.

const interval = setInterval(() => {
    if (Math.random() > 0.8) {
        parentPort.postMessage("Found good number")
        clearInterval(interval) // very important!
        parentPort.close(); // optional
    }
}, 1000)

```

## See the difference
Each terminal window is processing the same set of jobs. From left to right, the programs use 1, 8, and 256 workers. Threads increase memory usage, but the benefits are worth it!
![imgur](https://imgur.com/PIZeeMU.gif)

## Contributions
Please use reasonable coding standards and write a test for everything you change. There should be a test for single-threaded, average-threaded (8 threads), and stress-threaded (256+ threads).

## License
MIT

repository: wadez/jpool

repo_name: wadez/jpool


text:
Yokai Versioning
================

[![Build Status](https://travis-ci.org/yokai-php/versioning.svg?branch=master)](https://travis-ci.org/yokai-php/versioning)

todo badges

Introduction
------------

This library aims to provide storage agnostic mechanics to add versioning capabilities to any PHP application.

Documentation
-------------

todo documentation

MIT License
-----------

License can be found [here](LICENSE).

Authors
-------

The library was originally created by [Yann Eugoné](https://github.com/yann-eugone).
See the list of [contributors](https://github.com/yokai-php/versioning/contributors).

---

Thank's to [Prestaconcept](https://github.com/prestaconcept) for supporting this library.

repository: yokai-php/versioning

gha_language: PHP

repo_name: yokai-php/versioning


text:
# Terminal.Gui - Terminal UI toolkit for .NET

A simple UI toolkit for .NET, .NET Core, and Mono that works on Windows, the Mac, and Linux/Unix.

*We are actively converging on a major update to Terminal.Gui. The most recent released Nuget package is version `0.81` which is way behind `master`. This README and the API Documentation refers to the latest build from `master`. If you want the latest and greatest functionality, clone and build locally. Otherwise `0.81` is quite stable, but the documentation may not match.*

* [Terminal.Gui Project on GitHub](https://github.com/migueldeicaza/gui.cs)

## Terminal.Gui API Documentation

* [API Reference](api/Terminal.Gui/Terminal.Gui.html)
* [Terminal.Gui API Overview](articles/overview.html)
* [Keyboard Event Processing](articles/keyboard.html)
* [Event Processing and the Application Main Loop](articles/mainloop.md)

## UI Catalog

UI Catalog is a comprehensive sample library for Terminal.Gui. It provides a simple UI for adding to the catalog of scenarios.

* [UI Catalog API Reference](api/UICatalog/UICatalog.html)
* [UI Catalog Source](https://github.com/migueldeicaza/gui.cs/tree/master/UICatalog)


text:
# simple-color-extract

# Installing

Assumes Python3 with pip and virtualenv

Install the requirements with pip:

```
pip3 install -r requirements.txt --ignore-installed
```

Note the `ignore-installed` flag as colorgram has on occasion not installed properly to a virtualenv without it for me.

# Running the app

Control and view extracted data in a Flask served application.

```
export FLASK_APP=app.py
export FLASK_ENV=development
flask run
```

As it is currently setup, the app looks for image files in the `static` directory. It will analyse every image it finds, every time someone visits either the home URL or `/api`.

Visit root local host to extract colours for all images and provide an HTML summary.

e.g. http://<IP_ADDRESS>:5000/

Visit `/api` for a data view.

e.g. http://<IP_ADDRESS>:5000/api

repository: fogonwater/simple-color-extract

repo_name: fogonwater/simple-color-extract


text:
# Conference tracks

SciPyLA 2017 is the 5th Latin American conference on the applications in science of the Python
programing language.

The SciPyLA conference encourages submissions of three types of papers:

- Research and position papers: We encourage papers that describe work-in-progress
  or recently completed work based on the themes and goals of the different tracks or
  related topics, report on experiences gained, question accepted wisdom,
  raise challenging open problems, or propose speculative new approaches.
  We will accept two types of papers: research papers up to 15 pages in length;
  and position papers up to 4 pages in length.

- Hypotheses papers: Hypotheses papers explicitly identify beliefs of the research
  community or mainstream industries about how a scientific technology and tools
  affect research practice. Hypotheses can be collected from mailing lists,
  blog posts, paper introductions, developer forums, or interviews.
  Papers should clearly document the source(s) of each hypothesis and discuss the
  importance, use, and relevance of the hypotheses on research or practice.
  Papers may also, but are not required to, review evidence for or against the
  hypotheses identified. Hypotheses papers can be up to 4 pages in length.

- Review articles: Review articles summarize the current state
  of understanding on a topic. A review article surveys and summarizes previously
  published studies, rather than reporting new facts or analysis. The conference
  encourages submission of industrial experience and tool demonstrations in this
  category. Review articles can be up to 10 pages in length.
  Review Articles teach about:
  * the main people working in a field
  * recent major advances and discoveries
  * significant gaps in the research
  * current debates
  * ideas of where research might go next

Research papers will be judged for technical novelty and scientific merit.
Any previous publication in any form must be explicitly identified and
cited on the first page of the submission. Papers in all other categories
will be judged on novelty, clarity, accessibility, and suitability for a
high quality presentation and discussion at the workshop.

Submissions may be accompanied by data papers and video papers complementing
the subjects discussed.

The activities scheduled in SciPyLA 2017 program are the following.

## Latin American Workshop on Python and Bio-informatics

SciPyLA 2017 will be the venue to explore innovation opportunities
in Latin America’s life science industry. Cuba excels with 893 sanitary
permits in more than 50 countries. Join researchers leveraging Python
tools and explaining how biotechnology finds its way in Latin America.

### Topics

Some particular areas of interest are:

- Biological Inspired Sensors. APIs
- Bio-printing
- Bioplastic
- Brain, Heart and Organ Simulations and Processing
- Brain reading and Neuroinformatics
- Brain-computer interfaces
- Cancer and Tumor Studies with Big Data
- Conductive polymers
- DNA Sequencing
- Health Informatics as a Service (HIaaS)
- Immunoassays
- In vitro meat
- Lab-on-a-chip and applications
- Nanomedicines and Nanosensors
- Oncolytic virus research
- Personalized treatments
- Plantibodies
- Stem cell treatments
- Synthetic Biology Open Language
- Tissue engineering

In general the program committee will accept paper submissions related to the following disciplines:

Analytical Chemistry, Astrobiology, Biochemistry, Bioinformatics, Biomaterials, Biomechatronics, Biophysics, Biotechnology,
Chemical Engineering, Chemical Biology, Cheminformatics, Computational Biology,
Computational Chemistry, Femtochemistry, Flow Chemistry, Genetics, Genomics, Healthcare Science,
Immunochemistry, Immunology, Mathematical Biology, Mathematical Chemistry,
Microbiology, Molecular Biology, Molecular Mechanics, Nanomaterials, Nanotechnology, Neuroscience,
Paleobiology, Polymer Chemistry and Engineering, Phytochemistry, Structural Biology,
Supramolecular Chemistry, Synthetic Biology, Synthetic Genomics Systematics, Tissue Engineering, Virology.

## Latin American Workshop on Python and Physics

The workshop is a meeting point to discuss the latest results of Latin American
research facilities. Participation of peers from poorer countries will
contribute to fight the regional disparities in education and research
as well as to reach more than 15,000 physicists.

### Topics

Some particular areas of interest are:

- Numerical methods for resolution of differential equations
- High-energy physics experiments
- Universe large-scale structure formation
- Galaxies evolution
- Dark matter simulations

In general the program committee will accept paper submissions related to the following disciplines:

Applied Physics, Astronomy, Astrophysics, Computational Physics, Cosmology, Elementary Particle Physics,
Experimental Physics, Fluid Dynamics, Mathematical Physics, Molecular Quantum Mechanics,
Nuclear Physics, Numerical Simulations, Physics of materials, Quantum Physics, Radiochemistry,
Semiconductors, Statistical Mechanics.

## Latin American Workshop on Python, Engineering and Process Automation

Researchers and entrepreneurs will meet in Havana to cover the potential of
smart-grid technologies, robotics, AI and similar technologies to implement
disruptive applications, emphasizing on explaining how Python helped them to
achieve a competitive advantage.

### Topics

Some particular areas of interest are:

- 3D printing
- 3D and holographic display solutions
- Adaptive Signal Processing and Control
- Agricultural robots
- Android, gynoid
- Autonomous vehicles
- Bionics
- Claytronics algorithms and programming
- Cloud robotics
- Collective Adaptive Systems
- Computer-based Manufacturing Technologies
- Computer-generated holography devices
- Digital scent technology
- Electric vehicles
- Energy-efficient networking and smart grid technologies
- Expert Systems for Industry
- Flying cars
- Future-generation sensor networks
- Hardware prototyping and simulation
- Human-robots Interfaces
- Intelligent Fault Detection and Identification
- Machine Learning in Control Applications
- MyHDL
- Petri Nets (System Design/Verification with Nets, Protocols and Networks)
- Powered exoskeleton
- Real-time systems
- Robot Design, Development and Control
- Robotic surgery
- Self-reconfiguring modular robots
- Self-organization, self-stabilization, & autonomic computing
- System-on-Chip design and simulation
- Software Agents for Intelligent Control Systems
- Vehicular communication systems
- Virtual prototyping and testing of cyber-physical systems
- Wearable devices

In general the program committee will accept paper submissions related to the following disciplines:

Aerospace Engineering, Artificial Intelligence, Control Systems and Theory, Electronics,
Electronic Design Automation, Electronic materials and Devices, Hardware Design,
High-Performance Computing, Magnetic Materials and Devices, Mechatronics,
Optical materials and devices, Robotics, Semiconductors.

## Latin American Workshop on Python, Economics and Management Science

The financial industry, digital payments, and ports across more than 200,000 km
of coasts have been presenting a number of mathematical and computational
challenges to researchers. Experts will explain how Python tools help small
businesses and companies to boost economic growth.

### Topics

Some particular areas of interest are:

- Airport simulation
- Business Intelligence
- Business Process as a Service (BPaaS)
- Business Process Modeling
- CRM, ERP and Decision Support Systems
- Cryptocurrency
- Forecasting
- E-Business, E-Entrepreneurship, E-Learning, and E-Logistics
- Economics of big data
- Enterprise and Strategic Information Systems
- Enterprise Service Bus, Workflows, Data and Tool Integration
- Financial Software as a Service (FSaaS)
- Integrated Production, Inventory and Distribution planning
- Lean Enterprise, Lean Startups
- Lot Sizing and Scheduling
- Merchandise port and Shipping transport simulation
- Mobile payment protocols, solutions, service systems, platforms and marketplaces
- Network economics
- Payment gateways
- Physical internet
- Process Mining and Process Reengineering
- Process simulation frameworks
- Public transport simulation
- Sharing economy
- Simulation for business planning
- Simulation and models in finance
- Simulation in warehouse operations
- Simulation to predict market behavior
- Simulation-based scheduling
- Social web economics and business
- Stochastic Processes
- Supply Chain Information Systems
- Virtual Enterprises and Interoperability

In general the program committee will accept paper submissions related to the following disciplines:

Advertising, Complexity Economics, Computational Economics, Computational Finance,
Combinatorial Optimization, E-Business, Econometrics, Experimental Economics,
Financial econometrics, Large Scale Optimization, Logistics, Marketing, Macroeconomics,
Mathematical Economics, Microeconomics, Operations management, Suply chain management.

## Latin American Workshop on Python and Emerging Computing Technologies

A number of research subjects are pushing the limits of current technologies and tools.
It is then convenient to explore the impact of Python to support the most prominent ongoing
developments, advances, and innovations in various fields of modern technology
which rely extensively on complex computing systems.
Submitted contributions are expected to portray how Python
constitutes an integral part of the technical innovations and the particular
role of the programming language in providing a competitive advantage.

Science and Python tools will provide answers to regional IT initiatives in
need of coping with more than 689 million mobile subscriptions, 50 million
active consumers, and an IoT market expected to double to $15.6 billion and
reach more than 800 million connected endpoints.

### Topics

Some particular areas of interest are:

- 4G and 5G cellular communications
- Agent-based systems and architectures
- Agent-to-Human service interactions
- Analytics as a Service (AaaS)
- Augmented reality
- Big Data
- Cloud Computing, IaaS, PaaS and SaaS
- Big Data as a Service (BDaaS)
- Biometrics
- Combinatorial optimization
- Computational Geometry
- Computer-generated imagery
- Computer vision
- Data Mining
- Data-parallel algorithms and SIMD architectures
- Data Science
- Distributed algorithms, operating systems, and database systems
- Domain Specific Languages
- Deep learning
- Evolutionary computation
- Graph Computation Models
- High-performance Computing
- Image processing
- Integration as a Service
- Internet of Things
- Large scale optimization
- Machine learning
- Machine to Machine Communications
- Mobile collaboration and e-learning
- Mobile database retrieval techniques, transaction models and caching techniques
- Network function virtualization and Mobile edge computing
- Scalable Model-Driven Engineering
- Pattern recognition
- Radio-frequency identification
- Software Defined (and Cognitive) Networks
- Software Defined Radio
- Speech recognition
- Virtual reality
- Virtualization and Containers
- Wearable solutions

In general the program committee will accept paper submissions related to the following disciplines:

Artificial Intelligence, Business Intelligence, Cryptgraphy, Data Science,
Datawarehousing, Digital Broadcasting Networks, Digital Signal Processing,
Mass media, Optical fiber networks, Quantum Computing, Telecommunications,
Wireless Technologies.

## Latin American Workshop on Python and Earth Sciences

Earth Sciences are the key to mitigate the impact of disasters and to prepare
for responsible prospection and sustainable explotation of resources. The
callenge consists in finding a balance between consumption of societies and
preservation of Latin American ecosystems.

### Topics

Some particular areas of interest are:

- Analysis of seismic records
- Atmospheric carbon dioxide removal
- Carbon neutral fuel
- Climate and weather-related simulations
- Closed ecological systems
- Computational analysis of effects of topography on prospection results
- Comptational magnetometry and applications in geological mapping
- Computational prospection methods based on dip-angle techniques
- Galvanic and magneto-telluric resistivity methods
- Interpretation of electromagnetic surveys
- Interpretation methods based on reflections and refractions of spherical waves
- Natural Science as a Service (NSaaS)
- Numerical calculations and direct interpretation of direct-current conduction methods
- Numerical analysis to determine ocurrence of flow (movement) of ground water
- Precision agriculture
- Propagation of elastic waves in randomly inhomogeneous media
- Reduction and interpretation of potential field data. Gravity and magnetic anomalies
- Seismic interpretation
- Simulation for disaster mitigation
- Vertical farming
- Weather Data Visualization
- Weather Forecasting

In general the program committee will accept paper submissions related to the following disciplines:

Astronomy, Astrophysics, Atmospheric Chemistry, Ecotechnology, Edaphology,
Gemology, Geochemistry, Geodesy,
Geography, Geology, Geomorphology, Geophysics, Glaciology, Hydrogeology, Hidrology,
Inorganic Chemistry, Marine Chemistry, Meteorology, Mineralogy, Oceanography,
Paleontology, Pedology, Petrochemistry, Seismics, Soil Science, Speleology.

## Latin American Workshop on Python, Architecture, Social Sciences and Humanities

The 670 Latin American ethnic groups conform the fastest growing Internet
population in the world. Join the experts to discuss regional trends in fields
like smart cities, sharing economy, multilingual content navigation, open data,
social networking and e-communities.

### Topics

Some particular areas of interest are:

- Adaptive/Personalized conversational media
- Ambient intelligent frameworks, platforms, and systems
- Arcology
- Autonomous building
- Bionic architecture
- Civic technology and Smart cities. Examples and Case Studies
- Computational intelligence for media adaptation and personalization
- Content creation, annotation and modelling for semantic and social web
- Context-aware multimedia applications
- Domed city
- e-Communities
- Education as a Service (EaaS)
- Historic preservation
- Machine translation
- Multilingual content navigation
- Online social models for social networking and consumption simulation
- Ontologies and reasoning applied to social media
- Open data: Issues, Services and Solutions
- Privacy/Security issues in Social and Personalized Media Applications
- Semantic context modelling and extraction
- Semantic web technologies
- Semantics-based recommender systems: theory and applications
- Semantics-driven indexing and retrieval of multimedia contents
- Sharing economy
- Simulation of building physics
- Simulation of urban mobility
- Social and semantic media collaboration platforms (e.g. semantic wikis)
- Social multimedia applications (livecasting, audio-video sharing)
- Social multimedia tagging and multimedia content communities
- Social network aggregation
- User modelling and dynamic profiling
- User-generated content mechanisms
- Video Search and Video Mining

In general the program committee will accept paper submissions related to the following disciplines:

Architecture, Bibliometrics, Citation analysis, Computational Linguistics, Computational Sociology,
Internet sociology, Journalism, Mass media, Natural language processing,
Sociocybernetics, Urban planning, Urban sociology.


text:
# Orchard.ParkingData
RESTful Web API for the City of Santa Monica's Parking Data, implemented as an Orchard module.

This module has a dependency on the [CSM.WebApi](https://github.com/CityofSantaMonica/Orchard.WebApi) module.

The theme for the site can be found here [CSM.ParkingData.Theme](https://github.com/CityofSantaMonica/Orchard.ParkingData.Theme).


text:
# M0518 BSP

This BSP folder

## .\Document\

- Revision History.pdf

	This document shows the revision history of BSP.

- NuMicro M0518 Series Driver Reference Guide.chm

	This document describes the usage of drivers in BSP.

## .\Library\

- CMSIS

	Cortex® Microcontroller Software Interface Standard (CMSIS) definitions by ARM® Corp.

- Device

	CMSIS compliant device header file.

- StdDriver

	All peripheral driver header and source files.

## .\Sample Code\

- Hard\_Fault\_Sample

	Show hard fault information when hard fault happened.

- ISP

	Sample codes for In-System-Programming.

- Semihost

	Show how to print and get character with IDE console window.

- RegBased

	The sample code able to access control registers directly

- StdDriver

	Demonstrate the usage of M0518 series MCU peripheral driver APIs.

- Template

	A project template for M0518 series MCU.

# Licesne

**SPDX-License-Identifier: Apache-2.0**

Copyright in some of the content available in this BSP belongs to third parties.
Third parties license is specified in a file header or license file.
M0518 BSP files are provided under the Apache-2.0 license.


text:
# Change log

JSON Feed follows the [Package Versioning Policy](https://pvp.haskell.org).
You can find release notes [on GitHub](https://github.com/tfausak/json-feed/releases).

repository: tfausak/json-feed

extension: markdown

gha_language: Haskell

repo_name: tfausak/json-feed


text:
# Lambda Cryptocurrency Fetcher
A simple script to fetch cryptocurrency rates from [messari.io](https://messari.io) API and store these into a MongoDB database
meant to be used on AWS Lambda.

![Go](https://img.shields.io/badge/go-%2300ADD8.svg?style=for-the-badge&logo=go&logoColor=white)
[![License](https://img.shields.io/github/license/Loupeznik/lambda-crypto-fetcher?style=for-the-badge)](./LICENSE)

## Build (for publishing to Lambda)

```bash
git clone https://github.com/Loupeznik/lambda-crypto-fetcher.git
cd lambda-crypto-fetcher
go get .
GOOS=linux GOARCH=amd64 go build -o main .
zip main.zip main
```

## License
This project is MIT licensed.

repository: Loupeznik/lambda-crypto-fetcher

repo_name: Loupeznik/lambda-crypto-fetcher


text:
# Concurrent Requests in Java
This example shows three different ways of handling concurrent request execution with Apache Cassandra™ using the
[Java DataStax Driver](https://docs.datastax.com/en/developer/java-driver/latest).

Contributors: [Olivier Michallat](https://github.com/olim7t), [Hsu-Kwang Hwang](https://github.com/hsuhwang), [Tomasz Lelek](https://github.com/tomekl007) - derived from
[here](https://github.com/datastax/java-driver/tree/4.x/examples/src/main/java/com/datastax/oss/driver/examples/concurrent)
## Objectives

* How to limit concurrent query executions with Cassandra in blocking and non-blocking ways.
* How to throttle Concurrent Requests.

## Project Layout
The following are the main Java files used by the application.

* [LimitConcurrencyCustom](/src/main/java/com/datastax/examples/LimitConcurrencyCustom.java) - This example shows executing concurrent queries in blocking ways.
The basic java concurrent mechanism such as SEMAPHORE, and Latch are used to control the flow.
* [LimitConcurrencyCustomAsync](/src/main/java/com/datastax/examples/LimitConcurrencyCustomAsync.java) - This example shows executing concurrent queries in
non-blocking ways. Java CompletableFuture is used to achieve non-blocking.
* [LimitConcurrencyRequestThrottler](/src/main/java/com/datastax/examples/LimitConcurrencyRequestThrottler.java) - Throttling allows you to limit how many
requests a session can execute concurrently. This is useful if you have multiple applications connecting to the same Cassandra cluster, and want to enforce some
kind of SLA to ensure fair resource allocation.

## Setup and Running

### Prerequisites

* Maven 3 installed on the machine running the examples
* JDK 14
* An Apache Cassandra(R) cluster is running and accessible through the contacts points and data center identified in [application.conf](/src/main/resources/application.conf)

### Running
#### Building
At the project root level

```mvn clean package```

This builds the JAR file located at `target/java-concurrent-execution-1.0.jar`

#### Configuration changes
The main configuration file is `src/main/resources/application.conf`
Change `basic.contact-points` = ["<IP_ADDRESS>:9042"] to the IP and cql port of your Cassandra cluster.
Change `basic.local-datacenter` = dc1 to the datacenter of the Cassandra cluster you want to connect to.

##### Throttling
For throttling the configurations are in the following block

```
advanced.throttler {
    class = ConcurrencyLimitingRequestThrottler
    max-concurrent-requests = 32
    max-queue-size = 10000
}
```

You are encouraged to experiment the configuration. For more details about throttling please check the
following [link](https://docs.datastax.com/en/developer/java-driver/4.3/manual/core/throttling/)

#### Run the program
* `java -cp target/java-concurrent-execution-1.0.jar com.datastax.examples.LimitConcurrencyCustom`
* `java -cp target/java-concurrent-execution-1.0.jar com.datastax.examples.LimitConcurrencyCustomAsync`
* `java -cp target/java-concurrent-execution-1.0.jar com.datastax.examples.LimitConcurrencyRequestThrottler`

gha_language: Java


text:
# docx to github-flavored-markdown converter

For quite a while I have been the maintainer/editor of the engineering blog [underthehood.meltwater.com][uth]. The authors wrote their drafts as Google Docs, and then eventually needed to convert the google doc to [github-flavored-markdown][gfm], as that is what the [jekyll](https://jekyllrb.com)-based blog uses.

This conversion step is tedious, boring, and some parts are error-prone.

With `docx2gfm.rb` you can do this conversion quickly, and have more time to write new blog posts ... or drink coffee :)

Technically `docx2gfm.rb` is a thin wrapper around [pandoc][pandoc]. Read more about the [motivation](./MOTIVATION.md) here.

## Example

docx2gfm is not flawless, but it turns [this docx file](./examples/sample.docx) into [this markdown](./examples/sample.md). (also see the original [google Doc][gDoc])

So while some post-processing of the markdown is still required, it already makes the conversation process much faster.

## Installation

- install [pandoc][pandoc]
- install ruby
- Done :)

## How to convert a gdoc

1. download your gdoc as a `.docx` file e.g. `my_post.docx` (File >> Download as >> Microsoft Word (.docx))
1. convert docx to github-flavored-markdown:

```
ruby docx2gfm.rb -f my_post.docx > my_post.md
```

To learn more about the available commandline options please refer to the built-in help.

```
ruby docx2gfm.rb -h

Usage: docx2gmf.rb [options]
-f, --file FILE                  (required) The .docx file to convert to markdown
-j, --[no-]jekyll                (optional) Prefix the markdown output with a jekyll frontmatter. Default: --jekyll
-r, --[no-]ref-style-links       (optional) Create reference style links at the end of the markdown. Default: --ref-style-links
-h, --help                       Display this help screen
```

## Finishing touches for your markdown

The markdown produced by docx2gfm is good, but it is not 100% polished. You still have to do some manual steps:

* Adapt the YAML Frontmatter (if you used the `--jekyll` option)
* Add the correct image links
* Add code blocks
* Add quotes
* Add tables

## How to contribute

docx2gfm is far from perfect. Help us make it better by filing an issue or sending a pull request.

## Alternatives to docx2gfm

* Word to Markdown Converter: [online](https://word-to-markdown.herokuapp.com/), [source](https://github.com/benbalter/word-to-markdown)
* [Writage](http://www.writage.com) - Markdown plugin for Microsoft Word

[uth]: https://underthehood.meltwater.com/
[gfm]: https://guides.github.com/features/mastering-markdown/
[gDoc]: https://docs.google.com/document/d/16Kww2ic-YgFKskfDxYJu6o_ooSF3IORJh8Ho7XbgngI/edit
[pandoc]: https://pandoc.org/installing.html


text:
GPU
===

`init()`
--------
- create window & buffer surface

`tick()`
--------
- update registers
- fire interrupts
- for each frame, call `draw_line()` 144 times and noop (vblank) 10 times
- we draw one line at a time because it's possible to update GPU settings
  multiple times per frame, eg adjusting x-offset for a parallax effect

`draw_line()`
-------------
- figure out what tiles are active on which layers (background, window,
  sprites) and call `paint_tile_line()` for each tile.

`paint_tile_line()`
-------------------
- copy a line of pixels from a tile into the buffer

repository: LaplaceKorea/rosettaboy

repo_name: LaplaceKorea/rosettaboy


text:
# Typegoose Automatic Increment

[![Build Status](https://github.com/typegoose/auto-increment/actions/workflows/tests.yml/badge.svg)](https://github.com/typegoose/auto-increment/actions/workflows/tests.yml)
[![codecov.io](https://codecov.io/github/typegoose/auto-increment/coverage.svg?branch=master)](https://codecov.io/github/typegoose/auto-increment?branch=master)
[![npm](https://img.shields.io/npm/dt/@typegoose/auto-increment.svg)](https://www.npmjs.com/package/@typegoose/auto-increment)

Automaticly Increment properties

## Basic Usage

### Simple

(mongoose)

```ts
const schema = new mongoose.Schema({
  somefield: Number
});
schema.plugin(AutoIncrementSimple, [{ field: 'somefield' }]);
const model = mongoose.model('SomeModel', schema);

const doc = await model.create({ somefield: 10 });

await doc.save(); // somefield will be 11
```

(typegoose)

```ts
@plugin(AutoIncrementSimple, [{ field: "someIncrementedField" }])
class SomeClass {
  @prop() // does not need to be empty
  public someIncrementedField: number;
}

const SomeModel = getModelForClass(SomeClass);

const doc = await SomeModel.create({ someIncrementedField: 10 });

await doc.save(); // someIncrementedField will be 11
```

### For Identification

(mongoose)

```ts
const schema = new mongoose.Schema({
  _id: Number,
  somefield: Number
});
schema.plugin(AutoIncrementID, {});
const model = mongoose.model('SomeModel', schema);

const doc = await model.create({ somefield: 10 }); // _id will be 1
```

(typegoose)

```ts
@plugin(AutoIncrementID, {})
class SomeClass {
  @prop()
  public _id: number;

  @prop() // does not need to be empty
  public someIncrementedField: number;
}

const SomeModel = getModelForClass(SomeClass);

const doc = await SomeModel.create({ someIncrementedField: 10 }); // _id will be 1
```

## Motivation

I started `@typegoose/auto-increment` because `mongoose-auto-increment` and `mongoose-auto-increment-reworked` are archived and didnt get any update for at least 2 years, and there were many issues about them in [typegoose](https://github.com/typegoose/typegoose) so i thought it will be easy to make an up-to-date automatic incrementing plugin.

## Requirements

- Node 14.17.0+
- TypeScript 4.9+ (older versions could work, but are not tested)
- mongoose 7.5.0+

## Install

`npm i -s @typegoose/auto-increment`

You also need to install `mongoose`, because this plugin is made for `mongoose`.

## Testing

`npm run test` / `npm run test:watch`

## Versioning

`Major.Minor.Fix` (or how npm expresses it `Major.Minor.Patch`)
(This Project should comply with [Semver](https://semver.org))

## Join Our Discord Server

To ask questions or just talk with us [join our Discord Server](https://discord.gg/BpGjTTD)

## Documentation

### AutoIncrementSimple - Options

The options can either be an object or an array of objects (single field / multiple fields).

Note: This function will only increment if the document is not new, this is to apply the default value.

#### field

`string`

This option is always required to get which field to increment.

#### incrementBy

`number` default `1`

This option is optional, default is to increment by `1`.

### AutoIncrementID - Options

The options can only be one single object.

This plugin variant uses a model and a collection to store tracking(/counter) infomation to keep track of the ID in case the latest one gets deleted.

Note: the model used to keep track of the counter, will use the connection that the assigned schema uses.
Note: when the model is completly new, the first document will be "1", [see here as on why](https://github.com/Automattic/mongoose/issues/3617).

if the hook should be skipped, use `AutoIncrementIDSkipSymbol`:

```ts
const doc = new Model();

doc[AutoIncrementIDSkipSymbol] = true;
await doc.save();

// the symbol can also be set on the connection
Model.db[AutoIncrementIDSkipSymbol] = true;
await Model.create({ _id: something });
// dont forget to unset it again
Model.db[AutoIncrementIDSkipSymbol] = true;
// or
delete Model.db[AutoIncrementIDSkipSymbol];
```

Note: `AutoIncrementIDSkipSymbol` can also be set inside hooks, but hooks might be called before others.
Note: `AutoIncrementIDSkipSymbol` cannot be used for `.create` (unless set via connection), because `AutoIncrementIDSkipSymbol` works on the current document and `.create({ [AutoIncrementIDSkipSymbol]: true })` will not transfer symbols to the document.
Note: if `AutoIncrementIDSkipSymbol` is set to `false` on either method, no modification will be done

#### incrementBy

`number` default `1`

This option is optional, default is to increment by `1`.

#### field

`string`

This option is optional, defaults to `_id`.

#### trackerCollection

`string`

Set the Collection the tracker-model should use to store tracking infomation (/ to store the tracking documents).

This option is optional, defaults to `identitycounters`.

#### trackerModelName

`string`

Set the tracker-model's name (sets the model-name of the tracker model like `mongoose.model(NameHere, ...)`).

This option is optional, defaults to `identitycounter`.

#### startAt

`number` default `0`

Set the starting number of the counter.
(the first document will be this number)

### overwriteModelName

`string` default's to the documents's model-name
`(modelName: string, model: Model) => string`

Overwrite the used value for the `modelName` property on the tracker-document, this can be used when wanting to use the same tracker document across different models.
If the value is falsy, then it will default to the `modelName`.
Can also be used as a function to generate a name to use based on `modelName` or the `model` itself, needs to return a non-empty string, when wanting to default back to default behavior just return the parameter `modelName`.

## Notes

* Please dont add comments with `+1` or something like that, use the Reactions
* `npm run doc` generates all documentation for all files that can be used as modules (is used for github-pages)
* `npm run doc:all` generates documentation even for internal modules

repository: typegoose/auto-increment

gha_language: TypeScript

repo_name: typegoose/auto-increment


text:
---
kernelspec:
  display_name: Python 3
  language: python
  name: python3
---

```{raw-cell}
:raw_mimetype: text/latex

$1+1$
```

```{raw-cell}
:raw_mimetype: text/restructuredtext

:math:`1+1`
```

```{raw-cell}
:raw_mimetype: text/html

<b>Bold text<b>
```

```{raw-cell}
:raw_mimetype: text/markdown

**Bold text**
```

```{raw-cell}
:raw_mimetype: text/x-python

1 + 1
```

```{raw-cell}
Not formatted
```

url: https://raw.githubusercontent.com/mwouts/jupytext/28cc7de53d403838caf24c3470df95e94a82d132/tests/notebooks/mirror/ipynb_to_myst/The flavors of raw cells.md

repository: mwouts/jupytext

filename: The flavors of raw cells.md

repo_name: mwouts/jupytext


text:
---
layout: post
title: How to create pull requests on Github
date: 2017-06-30 11:00
categories: [git, github]
slug: quick-github-pull-requests
---

Pull Requests are the web-based version of sending software patches via email to code maintainers.
They allow a person that has no access to a code repository to submit a code change to the repository administrator for review and 1-click merging.

## Preparation

* Create a free Github account at <https://github.com>
* Login on Github with your credentials
* Go to the homepage of the repository, for example <https://github.com/sdsc/sdsc-summer-institute-2017>

## Small changes via Github.com

For small changes, like create a folder and upload a few files, or a quick fix on a previous file, you don't even need to use the `git` command line client.

* If you need to **create a folder**
    * click on "Create new file"
    * in the "Name your file..." box, insert: "yourfolder/README.md"
    * in the README.md write a description of the content of the folder, you can use markdown syntax, (see [the Markdown Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) )
    * create a bullet list with description of the files you will be uploading next
    * Click on "Propose new file"
    * this will ask you to create a Pull Request, follow the prompts and make sure to confirm at the end that you want to create a Pull Request, you have to click twice on "Create Pull Request" buttons
* If you want to upload files in the folder you just created, you need an additional step, if you want to upload to a folder already existing in the original repo, skip this:
    * Go to the fork of the original repository that was created automatically under your account, for example: <https://github.com/YOURUSERNAME/sdsc-summer-institute-2017>
    * Click on the dropdown "Branch" menu and look for the branch named `patch-1`, or `patch-n` if you have more.
* Click on the "Upload files" button, select and upload all files, a few notes:
    * do not upload zip archives
    * do not upload large data files, Github is for code
    * if you are uploading binary files like images, downgrade them to a small size
    * this will ask you to create a Pull Request, follow the prompts and make sure to confirm at the end that you want to create a Pull Request, you have to click twice on "Create Pull Request" buttons
* Check that your pull request appeared in the Pull Requests area of the repository, for example <https://github.com/sdsc/sdsc-summer-institute-2017/pulls>

## Update a previously create Pull Request via Github.com

If the repository maintainer has some feedback on your Pull Request, you can update it to accomodate any requested change.

* Go to the fork of the original repository that was created automatically under your account, for example: <https://github.com/YOURUSERNAME/sdsc-summer-institute-2017>
* Click on the dropdown "Branch" menu and look for the branch named `patch-1`, or `patch-n` if you have more.
* Now make changes to files or upload new files, then confirm and write a commit message from the web interface
* Check that your changes appear as updates inside the Pull Request you created before, for example  <https://github.com/sdsc/sdsc-summer-institute-2017/pull/N> where N is the number assigned to your Pull Request

## Use the command line client

For more control and especially if you expect the repository maintainer to make changes to your Pull Request before merging it, better use `git`.

* Click on the "Fork" button on the top right of the repository
* Now you should be on the copy of the repository under your own account, for example <https://github.com/YOURUSERNAME/sdsc-summer-institute-2017>
* Now open your terminal, if you never used `git` before, set it up with:

        $ git config --global user.name "Your Name"
        $ git config --global user.email<EMAIL_ADDRESS>
* Now open your terminal and clone the repository with:

        git clone https://github.com/YOURUSERNAME/sdsc-summer-institute-2017

* Enter in the repository folder
* Create a branch to isolate your changes with:

        git checkout -b "add_XXXX_material"

* Now create folders, modify files, you can use any text editor
* Once you are done doing modifications, you can prepare them to be committed with, this adds everything inside the folder:

        git add my_folder

* Generally better instead to add each file to make sure you don't accidentally commit wrong files

        git add my_folder/aaa.txt my_folder/README.md

* Then write this changes to history with a commit

        git commit -m "Added material about XXXX"

* Push changes to Github

        git push -u origin add_XXXX_material

* Now go to the homepage of the original repository, for example <https://github.com/sdsc/sdsc-summer-institute-2017>
* There should be a yellow notice saying that it detected a recently pushed branch, click on "Compare and Pull Request"
* Add a description
* Confirm with the green "Create Pull Request" button

In case you want to update your Pull Request, repeat the steps of `git add`, `git commit` and `git push`, any changes will be reflected inside the pull request.

repository: zonca/zonca-blog

gha_language: Jupyter Notebook

repo_name: zonca/zonca-blog


text:
---
layout: default
---

# 1997-09-12 - Re: in defense of Lon Horiuchi

## Header Data

From: Zooko Journeyman<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: d07b8ed5cd009312f6ee30117d022758cff232462d44344625919eeeb90c0b53

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1997-09-12 08:57:27 UTC

Raw Date: Fri, 12 Sep 1997 16:57:27 +0800

## Raw message

```
{% raw  %}From: Zooko Journeyman<EMAIL_ADDRESS>Date: Fri, 12 Sep 1997 16:57:27 +0800
To<EMAIL_ADDRESS>Subject: Re: in defense of Lon Horiuchi
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

When I posted "in defense of Lon Horiuchi" I had intended not
to follow up on the thread, but the several responses I've
read (which were more reasoned and polite than I had expected--
thanks guys) indicate that I didn't explain myself clearly.

It was not my intention to argue that Lon Horiuchi is a good
guy, that he fulfilled his responsibilities with appropriate
care, that he's a good shot, that he worked in an honorable
profession, that he is blameless in the death of the child, or
such.  (I may or may not _believe_ some of these propositions,
but I'll spare you for you the full littany of my opinions.)
All I intended to assert was that Lon Horiuchi is almost
certainly not the malicious baby-killing murderer that
Anonymous portrayed.

There are many issues one could legitimately argue regarding
a policeman who accidentally kills a non-combatant bystander
during a fight.  But comparing such a policemen to a
terrorist who deliberately targets non-combatants with a bomb
is beyond the pale.  That, but for my interruption, this
comparison would have passed unremarked among the cypherpunks
crowd is damning.

Why I'm posting:

I don't expect that merely because of my contradiction the
more rabid cypherpunks will suddenly throw off their twin
blinders of ideology and hatred.  Neither do I desire that
they retreat into closed conversation where they can continue
their self-inflaming rants without fear of interruption.  My
motivation in posting critical articles like these is primarily
because there are a great number of silent readers of the
cpunks list, and some of these people, perhaps being young or
inexperienced, may consider such vile slanders to be
self-evident truths if they continually see them pass
unchallenged.

Regards,

Zooko

{% endraw %}
```

## Thread

+ Return to [September 1997](/archive/1997/09)

+ Return to "[Alec McCrackin <camcc@abraxis.com>](/authors/alec_mccrackin_camcc_at_abraxis_com_)"
+ Return to<EMAIL_ADDRESS>(Douglas L. Peterson)](/authors/fnorky_at_geocities_com_douglas_l_peterson_)"
+ Return to "["snow" <snow@smoke.suba.com>](/authors/snow_snow_at_smoke_suba_com_)"
+ Return to "[TruthMonger <tm@dev.null>](/authors/truthmonger_tm_at_dev_null_)"
+ Return to "[Zooko Journeyman <zooko@xs4all.nl>](/authors/zooko_journeyman_zooko_at_xs4all_nl_)"

+ 1997-09-12 (Fri, 12 Sep 1997 16:57:27 +0800) - Re: in defense of Lon Horiuchi - _Zooko Journeyman<EMAIL_ADDRESS>  + 1997-09-12 (Fri, 12 Sep 1997 17:28:15 +0800) - [Re: in defense of Lon Horiuchi](/archive/1997/09/dfe3124f02bead7e4a4eafdde905ba861683eec3bdadd6ebc6272c12c7018e19) - _TruthMonger<EMAIL_ADDRESS>  + 1997-09-12 (Fri, 12 Sep 1997 18:07:47 +0800) - [in defense of the baby-murderer](/archive/1997/09/1ff9cc8104f730dbda57d07b412f1e4efb27683e421540e0b72d69d5a95f03f6) - _Alec McCrackin<EMAIL_ADDRESS>  + 1997-09-15 (Mon, 15 Sep 1997 10:13:02 +0800) - [Re: in defense of Lon Horiuchi](/archive/1997/09/6d58cfefcbc28205cb2b8b70893a46c44277142b09c2d008a250f84851b384de) - _"snow"<EMAIL_ADDRESS>  + 1997-09-15 (Mon, 15 Sep 1997 12:48:38 +0800) - [Re: in defense of Lon Horiuchi](/archive/1997/09/53d604b19ea17ecb914da85889386a8b5c4bb4d72b19c0652cb2cf01b010af83) -<EMAIL_ADDRESS>(Douglas L. Peterson)_


text:
GraphQL Errors
--------------

The `graphql/error` module is responsible for creating and formating
GraphQL errors.

```js
import { ... } from 'graphql/error'; // ES6
var GraphQLError = require('graphql/error'); // CommonJS
```

repository: mike-marcacci/graphql-js

gha_language: JavaScript

repo_name: mike-marcacci/graphql-js


text:
# Fisher's Linear Discriminant

$$
\newcommand{\sumN}{\sum_{n = 1}^N}
\newcommand{\sumn}{\sum_n}
\newcommand{\prodN}{\prod_{n = 1}^N}
\newcommand{\by}{\mathbf{y}} \newcommand{\bX}{\mathbf{X}}
\newcommand{\bx}{\mathbf{x}}
\newcommand{\bbeta}{\boldsymbol{\beta}}
\newcommand{\btheta}{\boldsymbol{\theta}}
\newcommand{\bbetahat}{\boldsymbol{\hat{\beta}}}
\newcommand{\bthetahat}{\boldsymbol{\hat{\theta}}}
\newcommand{\bmu}{\boldsymbol{\mu}}
\newcommand{\bSigma}{\boldsymbol{\Sigma}}
\newcommand{\bT}{\mathbf{T}}
\newcommand{\dadb}[2]{\frac{\partial #1}{\partial #2}}
\newcommand{\iid}{\overset{\small{\text{i.i.d.}}}{\sim}}
$$

Intuitively, a good classifier is one that bunches together observations in the same class and separates observations between classes. *Fisher's linear discriminant* attempts to do this through dimensionality reduction. Specifically, it projects data points onto a single dimension and classifies them according to their location along this dimension. As we will see, its goal is to find the projection that that maximizes the ratio of between-class variation to within-class variation. Fisher's linear discriminant can be applied to multiclass tasks, but we'll only review the binary case here.

# Model Structure

As usual, suppose we have a vector of one or more predictors per observation, $\bx_n$. However we do *not* append a 1 to this vector. I.e., there is no bias term built into the vector of predictors. Then, we can project $\mathbf{x}_n$ to one dimension with

$$
f(\mathbf{x}_n) = \bbeta^\top \bx_n.
$$

Once we've chosen our $\bbeta$, we can classify observation $n$ according to whether $f(\bx_n)$ is greater than some cutoff value. For instance, consider the data on the left below. Given the vector $\bbeta ^\top= \begin{bmatrix} 1 &-1 \end{bmatrix}$ (shown in red), we could classify observations as dark blue if $\bbeta^\top \bx_n \geq 2$ and light blue otherwise. The image on the right shows the projections using $\bbeta$. Using the cutoff $\bbeta^\top \bx_n \geq 2$, we see that most cases are correctly classified though some are misclassified. We can improve the model in two ways: either changing $\bbeta$ or changing the cutoff.

![download-2](/content/c3/s1/img1.png)

In practice, the linear discriminant will tell us $\bbeta$ but won't tell us the cutoff value. Instead, the discriminant will rank the $f(\bx_n)$ so that the classes are separated as much as possible. It is up to us to choose the cutoff value.

## Fisher Criterion

The *Fisher criterion* quantifies how well a parameter vector $\bbeta$ classifies observations by rewarding between-class variation and penalizing within-class variation. The only variation it considers, however, is in the single dimension we project along. For each observation, we have

$$
f(\mathbf{x}_n) = \bbeta^\top \bx_n.
$$

Let $N_k$ be the number of observations and $\mathcal{S}_k$ be the set of observations in class $k$ for $k \in \{0, 1\}$. Then let

$$
\bmu_k = \frac{1}{N_k}\sum_{n \in \mathcal{S}_k} \bx_n
$$

be the mean vector (also known as the *centroid*) of the predictors in class $k$. This class-mean is also projected along our single dimension with

$$
\mu_k = \bbeta^\top \bmu_k.
$$

A simple way to measure how well $\bbeta$ separates classes is with the magnitude of the difference between $\mu_2$ and $\mu_1$. To assess similarity *within* a class, we use

$$
\sigma_k^2 = \sum_{n \in \mathcal{S}_k} \left(f(\bx_n) - \mu_k \right)^2,
$$

the within-class sum of squared differences between the projections of the observations and the projection of the class-mean. We are then ready to introduce the Fisher criterion:

$$
F(\bbeta) = \frac{(\mu_2 - \mu_1)^2}{\sigma_1^2 + \sigma_2^2}.
$$

Intuitively, an increase in $F(\bbeta)$ implies the between-class variation has increased relative to the within-class variation.

Let's write $F(\bbeta)$ as an explicit function of $\bbeta$. Starting with the numerator, we have

$$
\begin{align*}
(\mu_2 - \mu_1)^2 &=  \left(\bbeta^\top(\bmu_2 - \bmu_1)\right)^2
\\
&= \left(\bbeta^\top(\bmu_2 - \bmu_1)\right)\cdot \left(\bbeta^\top(\bmu_2 - \bmu_1)\right)
\\
&= \bbeta^\top(\bmu_2 - \bmu_1)(\bmu_2 - \bmu_1)^\top \bbeta
\\
&= \bbeta^\top \bSigma_b\bbeta,
\end{align*}
$$

where $\bSigma_b = (\bmu_2 - \bmu_1)(\bmu_2 - \bmu_1)^\top$ is the *between class* covariance matrix. Then for the denominator, we have

$$
\begin{align*}
\sigma_1^2 + \sigma_2^2 &= \sum_{n \in \mathcal{S}_1} \left(\bbeta^\top(\bx_n - \bmu_1) \right)^2 + \sum_{n \in \mathcal{S}_2} \left(\bbeta^\top(\bx_n - \bmu_2) \right)^2
\\
&= \sum_{n \in \mathcal{S}_1} \bbeta^\top(\bx_n - \bmu_1)(\bx_n - \bmu_1)^\top \bbeta + \sum_{n \in \mathcal{S}_2}  \bbeta^\top(\bx_n - \bmu_2)(\bx_n - \bmu_2)^\top \bbeta
\\
&= \bbeta^\top \left(\sum_{n \in \mathcal{S}_1}(\bx_n - \bmu_1)(\bx_n - \bmu_1)^\top +  \sum_{n \in \mathcal{S}_2}(\bx_n - \bmu_2)(\bx_n - \bmu_2)^\top\right)\bbeta
\\
&= \bbeta^\top \bSigma_w\bbeta,
\end{align*}
$$

where $\bSigma_w = \sum_{n \in \mathcal{S}_1}(\bx_n - \bmu_1)(\bx_n - \bmu_1)^\top +  \sum_{n \in \mathcal{S}_2}(\bx_n - \bmu_2)(\bx_n - \bmu_2)^\top$ is the *within class* covariance matrix.  In total, then, we have

$$
F(\bbeta) = \frac{\bbeta^\top \bSigma_b\bbeta}{\bbeta^\top \bSigma_w \bbeta}.
$$

## Parameter Estimation

Finally, we can find the $\bbeta$ to optimize $F(\bbeta)$. Importantly, note that the magnitude of $\bbeta$ is unimportant since we simply want to rank the $f(\bx_n) = \bbeta^\top \bx_n$ values and using a vector proportional to $\bbeta$ will not change this ranking.

```{admonition} Math Note
For a symmetric matrix $\mathbf{W}$ and a vector $\mathbf{s}$, we have

$$
\dadb{\mathbf{s}^\top \mathbf{W}\mathbf{s}}{\mathbf{s}} = 2 \mathbf{W}\mathbf{s}.
$$

Notice that $\bSigma_w$ is symmetric since its $(i, j)^\text{th}$ element is

$$
\sum_{n \in \mathcal{S}_1} (x_{ni} - \mu_{1i})(x_{nj} - \mu_{1j}) + \sum_{n \in \mathcal{S}_2} (x_{ni} - \mu_{2i})(x_{nj} - \mu_{2j}),
$$

which is equivalent to its $(j, i)^\text{th}$ element.
```

By the quotient rule and the math note above,

$$
\begin{align*}
\dadb{F(\bbeta)}{\bbeta} &= \frac{2\bSigma_b\bbeta\left(\bbeta^\top \bSigma_w \bbeta\right) - 2\bSigma_w\bbeta\left(\bbeta^\top \bSigma_b \bbeta\right)}{(\bbeta^\top \bSigma_w\bbeta)^2}.
\end{align*}
$$

We then set this equal to 0. Note that the denominator is just a scalar, so it goes away.

$$
\begin{align*}
\mathbf{0} &=\bSigma_b\bbeta\left(\bbeta^\top \bSigma_w \bbeta\right) - \bSigma_w\bbeta\left(\bbeta^\top \bSigma_b \bbeta\right) \\
\bSigma_w\bbeta\left(\bbeta^\top \bSigma_b \bbeta\right)  &= \bSigma_b\bbeta\left(\bbeta^\top \bSigma_w \bbeta\right).
\end{align*}
$$

Since we only care about the direction of $\bbeta$ and not its magnitude, we can make some simplifications. First, we can ignore $\bbeta^\top \bSigma_b \bbeta$ and $\bbeta^\top \bSigma_b \bbeta$ since they are just constants. Second, we can note that $\bSigma_b \bbeta$ is proportional to $\bmu_2 - \bmu_1$, as shown below:

$$
\bSigma_b \bbeta = (\bmu_2 - \bmu_1)(\bmu_2 - \bmu_1)^\top\bbeta = (\bmu_2 - \bmu_1)k\propto (\bmu_2 - \bmu_1),
$$

where $k$ is some constant. Therefore, our solution becomes

$$
\bbetahat \propto \bSigma_w^{-1}(\bmu_2 - \bmu_1).
$$

The image below on the left shows the $\bbetahat$ (in red) found by Fisher's linear discriminant. On the right, we again see the projections of these datapoints from $\bbetahat$. The cutoff is chosen to be around 0.05. Note that this discriminator, unlike the one above, successfully separates the two classes!

![](/content/c3/s1/img2.png)

repository: rajan-v/mlbook

filename: fisher_discriminant 2.md

repo_name: rajan-v/mlbook


text:
# Clinical coding of long COVID in English primary care: a federated analysis of 58 million patient records in situ using OpenSAFELY

This is the code and configuration for our paper.

* The published peer-reviewed paper is available in the [British Journal of General Practice](https://doi.org/10.3399/BJGP.2021.0301)
* Raw model outputs, including charts, crosstabs, etc, are in `released_outputs/`
* If you are interested in how we defined our variables, take a look at the [study definition](analysis/study_definition_cohort.py); this is written in `python`, but non-programmers should be able to understand what is going on there
* If you are interested in how we defined our code lists, look in the [codelists folder](./codelists/)
* Developers and epidemiologists interested in the framework should review [the OpenSAFELY documentation](https://docs.opensafely.org)
* The preprint version of the paper is [here](https://doi.org/10.1101/2<IP_ADDRESS>56755)

# About the OpenSAFELY framework

The OpenSAFELY framework is a secure analytics platform for
electronic health records research in the NHS.

Instead of requesting access for slices of patient data and
transporting them elsewhere for analysis, the framework supports
developing analytics against dummy data, and then running against the
real data *within the same infrastructure that the data is stored*.
Read more at [OpenSAFELY.org](https://opensafely.org).

repository: opensafely/long-covid

repo_name: opensafely/long-covid


text:
# tool-gallery-5.1
Materials for ACDH Tool Gallery 5.1

## Useful Links
* GitHub Desktop: https://desktop.github.com/
* GitHub Desktop Documentation: https://help.github.com/en/desktop/contributing-to-projects
* Software Carpentry Git Lessons: http://swcarpentry.github.io/git-novice/
* Further Git Lessons: https://github.com/acdh-oeaw/Teaching_CBS4DH/blob/master/lectures/git.md
* [Slides About Data Management by Martina](https://docs.google.com/presentation/d/1uj5XR0SdIj0GkcAaIe8Hfpg0bla_SrO4Rf2-F0ElfWc)


text:
# Contributing

Thank you very much for contributing to the Linkis project! Before participating in the contribution, please read the following guidelines carefully.

## 1. Contribution category

### 1.1 Bug feedback and repair

We suggest that whether it is bug feedback or repair, you should create an issue first to describe the status of the bug in detail, so as to help the community to find and review issues and codes through issue records. Bug feedback issues usually need to include a complete description
**Bug** information and reproducible scenarios, so that the community can quickly locate the cause of the bug and fix it. contain
The opened Issues of the #bug label all need to be fixed.

### 1.2 Functional communication, implementation and refactoring

In the communication process, a detailed description of the details, mechanisms and usage scenarios of the new function (or refactoring) can promote it better and faster.
If you plan to implement a major feature (or refactoring), be sure to communicate with the team through **Issue** or other methods, so that everyone can move forward in the most efficient way. An open Issue containing the #feature tag means that there are new functions need to be implemented. And open issues including #Enhancement tags always means that needs to be improved for refactoring.

### 1.3 Issue Q&A

Helping to answer the usage questions in the Issue is a very valuable way to contribute to the Linkis community; There will always be new users keeping coming in. While helping new users, you can also show your expertise.

### 1.4 Documentation improvements

Linkis User Manual Documents are maintained in the Linkis-Doc project of github, you can edit the markdown file in the project and improve the document by submit a pr.

## 2. Contribution process

### 2.1 Branch structure

The Linkis source code may produce some temporary branches, but there are only three branches as followed that are really meaningful:

```
master: The source code of the last stable release, and occasionally hotfix submissions;
branch-0.10.0: The latest stable version
dev-1.0.0: Main development branch;
```

### 2.2 Development Guidelines

Linkis front-end and back-end code share the same code base, but they are separated in development. Before embarking on development, please fork a copy of Linkis project to your own Github Repositories. When developing, please do it based on your own Github Repositories.

We recommend cloning the dev-1.0.0 branch for development, so there will be much less conflicts on merging when submitting a PR to the Linkis main project
Much smaller

```
git clone https://github.com/yourname/Linkis.git --branch dev-1.0.0
```

#### 2.2.1 Backend

The user configuration is under the project root directory /config/, the project startup script and the upgrade patch script are under the project root directory /bin/.
The back-end code and core configuration are in the server/ directory, and the log is in the project root directory /log/.
Note: All records referred to the directory of the project root item, refer to the directory configured by the environment variable LINKIS_HOME, and environment variables need to be configured on development using IDE.
For example, Idea regarding the priority of environment variable loading from  high to low: Environment configured in Run/Debug Configurations
variables —> System environment variables cached by the IDE.

**<IP_ADDRESS>** Directory structure

```
1. Script
```
```
├── assembly-package/bin # script directory
 ├── install.sh # One-click deployment script
 ├── checkEnv.sh # Environment check script
 └── common.sh # Common script function
```
```
├── sbin # script directory
 ├── linkis-daemon.sh # Single service start and stop, status detection script
 ├── linkis-start-all.sh # One-click start script
 ├── linkis-stop-all.sh # One-click stop script
 └── ext # Separate service script directory
    ├── linkis-xxx.sh # The startup script of a service
    ├── linkis-xxx.sh
    ├── ...
```

```
2. Configuration
```
```
├── assembly-package/config # User configuration directory
 ├── linkis-env.sh # Configuration variable settings for one-click deployment
 ├── db.sh # One-click deployment database configuration
```
```
3. Code directory structure
See Linkis code directory structure for details
4. Log directory
```
```
├── logs # log root directory
```
**<IP_ADDRESS>** Environment variables

```
Configure system environment variable or IDE environment variable LINKIS_HOME, it is recommended to use IDE environment variable first.
```
**<IP_ADDRESS>** Database

```
1. Create the Linkis system database by yourself;
2. Modify the corresponding information of the database in conf/db.sh and execute bin/install.sh or import directly on the database client
db/linkis_*.sql.
```

**<IP_ADDRESS>** Configuration file

Modify the application-linkis.yml file in the conf directory and the properties file corresponding to each microservice name to configure related properties.

**<IP_ADDRESS>** Packaging

```
1. To open the complete release package, you need to modify the version in /assembly/src/main/assembly/assembly.xml in the root directory, and then execute in the root directory: mvn clean package;
2. Open the package of each module and execute mvn clean package directly in the module directory.
```
### 2.3 Pull Request Guidelines

#### If you still don’t know how to initiate a PR to an open source project, please refer to this description

```
Whether it is bug fixes or new feature development, please submit a PR to the dev-1.0.0 branch.
PR and submission name follow the principle of <type>(<scope>): <subject>. For details, please refer to Ruan Yifeng's article [Commitmessage and Change log Compilation Guide](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html).
If the PR contains new features, the document update should be included in this PR.
If this PR is not ready to merge, please add the [WIP] prefix to the head of the name (WIP = work-in-progress).
All submissions to the dev-1.0.0 branch need to go through at least one review before they can be merged
```
### 2.4 Review Standard

Before contributing code, you can find out what kind of submissions are popular in Review. Simply put, if one item
Submission can bring as many gains as possible and as few side effects or risks as possible, the higher the probability of it being merged, Review’s
The speed will be faster. Submissions with high risk and low value are almost impossible to be merged, and may be rejected.
There is no chance for Review.

**2.4.1** Gain

```
Fix the main cause of the bug
Add or fix a feature or problem that a large number of users urgently need
Simple and effective
Easy to test, with test cases
Reduce complexity and amount of code
```

#### Issues that have been discussed by the community and identified for improvement

#### 2.4.2 Side effects and risks

```
Only fix the surface phenomenon of the bug
Introduce new features with high complexity
Add complexity to meet niche needs
Change stable existing API or semantics
Cause other functions to not operate normally
Add a lot of dependencies
Change the dependency version at will
Submit a large amount of code or changes at once
```
**2.4.3 Reviewer** Note

```
Please use a constructive tone to write comments
If you need to make changes by the submitter, please clearly state all the content that needs to be modified to complete the Pull Request
If a PR is found to have brought new problems after the merger, the Reviewer needs to contact the PR author and communicate to resolve the problem.
Question; if the PR author cannot be contacted, the Reviewer needs to restore the PR
```
## Three, advanced contribution

### 3.1 About Committers (Collaborators)

**3.1.1** How to become **Committer**

If you have had a valuable PR for the Linkis code and it has been merged, you can contact the core development team through the official WeChat group
Team applied to be the Committer of the Linkis project; the core development team and other Committers will vote together to decide whether or not allow you to join. If you get enough votes, you will become a Committer for the Linkis project.

**3.1.2 Committer** Rights

```
You can join the official developer WeChat group, participate in discussions and make development plans
Can manage Issues, including closing and adding tags
Can create and manage project branches, except for master and dev-1.0.0 branches
Can review the PR submitted to the dev-1.0.0 branch
Can apply to be a member of Committee
```
### 3.2 About Committee

**3.2.1** How to become a **Committee** member

If you are a Committer of the Linkis project, and all your contributions have been recognized by other Committee members
Yes, you can apply to be a member of the Linkis Committee, and other Committee members will vote together to decide whether to allow
You are allowed to join, and if unanimously approved, you will become a member of the Linkis Committee.

**3.2.2 Committee members' rights

```
You can merge PRs submitted by other Committers and contributors to the dev-1.0.0 branch
```

repository: yangzhiyue/Linkis-Doc

repo_name: yangzhiyue/Linkis-Doc


text:
# Contributing to TypeBetter

## Install development dependencies

TypeBetter's build process uses [npm](https://www.npmjs.com/) and [Node.js](http://nodejs.org/). If you're using a Mac, the easiest way to install npm and Node.js (and plenty of other great tools) is with [Homebrew](http://brew.sh/):

	brew install node

If you're using a different operating system, use a different package manager, or prefer not to use Homebrew, check out the [Node.js Downloads page](http://nodejs.org/download/).

## Get set up to contribute

Contributing to TypeBetter is pretty straightforward:

1. Fork the TypeBetter repo and clone your fork.
1. Install development dependencies by running `npm install` from the root of the project.
1. Create a feature branch for the issue or new feature you're looking to tackle: `git checkout -b your-descriptive-branch-name`.
1. _Write some code!_
1. Commit your changes: `git commit -am 'Add some new feature or fix some issue'`.
1. Push the branch to your fork of TypeBetter: `git push origin your-descriptive-branch-name`.
1. Create a new Pull Request and we'll give it a look!

## "But what files do I change?!?"

Excellent question. TypeBetter's source code is in the file `src/typebetter.js`. Make your changes here!

When you're done working (and before you push your code or issue a pull request), run `npm run build` from the root of the project to recreate the files in the `dist` folder. This task will generate compiled and compressed versions of the project.

**Do not directly edit the files in the `dist` folder!**

## Code Style

Code styles are like opinions: Everyone's got one and yours is better than mine. TypeBetter's coding styles are defined in the `.editorconfig` file which uses the [EditorConfig](http://editorconfig.org/) syntax. There are [a number of great plugins for a variety of editors](http://editorconfig.org/#download) that utilize the settings in the `.editorconfig` file.

Basically, follow along with the conventions present in the existing code as best you can.

repository: yurivictor/typebetter

repo_name: yurivictor/typebetter


text:
# PsCmdletHelpEditor
PowerShell Cmdlet Help Editor is the tool that helps you to create and edit XML-based help files for your PowerShell modules and PSSnap-Ins. This project is intended to replace existing project (since it is no longer developed and has breaking issues) created by Microsoft: [Cmdlet Help Editor](https://cmdlethelpeditor.codeplex.com/). I tried to resolve main issues with the existing editor, but failed.

This means that new editor is not a rewrited version of a previous tool, instead, PS Cmdlet Help Editor is written from scratch and uses brand new codebase.

Since I'm going to support this project (really??), you may expect bug fixes (if any) and new feature addition (if I have a time to implement them). Also, in the  Source Code tab you can explore and download project sources and rewrite as necessary. Editor usage is described in the Documentation tab.

Key features:
* import and export help content to a PowerShell-compatible format;
* edit multiple modules at a time;
* edit and review help content in an easy and convenient way;
* use BB-codes for HTML rendering;
* get XML, HTML source (raw) code or formatted HTML view;
* publish help online via MetaWeblog API.

System requirements:
PowerShell 3.0;
.NET Framework 4.5

[![](https://download-codeplex.sec.s-msft.com/Download?ProjectName=pscmdlethelpeditor&DownloadId=1381532)](https://download-codeplex.sec.s-msft.com/Download?ProjectName=pscmdlethelpeditor&DownloadId=1381531)

license: MS-PL

gha_language: C#

gha_license_id: MS-PL


text:
# Using the Camel API

The Camel connector is based on the [Reactive Streams
support](https://camel.apache.org/components/latest/reactive-streams-component.html)
from Camel. If you have an application already using the Camel API
(routes, `from`...), you can integrate it with Reactive Messaging.

## Getting the CamelReactiveStreamsService

Once you add the Camel connector to your application, you can retrieve
the
`org.apache.camel.component.reactive.streams.api.CamelReactiveStreamsService`
object:

``` java
{{ insert('camel/api/CamelApi.java', 'reactive') }}
```

This `CamelReactiveStreamsService` lets you create `Publisher` and
`Subscriber` instances from existing routes.

## Using Camel Route with @Outgoing

If you have an existing Camel route, you can transform it as a
`Publisher` using the `CamelReactiveStreamsService`. Then, you can
return this `Publisher` from a method annotated with `@Outgoing`:

``` java
{{ insert('camel/api/CamelApi.java', 'source') }}
```

You can also use `RouteBuilder`:

``` java
{{ insert('camel/api/CamelApi.java', 'source-route-builder') }}
```

# Using Camel Route with @Incoming

If you have an existing Camel route, you can transform it as a
`Subscriber` using the `CamelReactiveStreamsService`. Then, you can
return this `Subscriber` from a method annotated with `@Incoming`:

``` java
{{ insert('camel/api/CamelApi.java', 'sink') }}
```

You can also use a producer:

``` java
{{ insert('camel/api/CamelApi.java', 'producer') }}
```

repository: smallrye/smallrye-reactive-messaging

repo_name: smallrye/smallrye-reactive-messaging