text:
# CC1101_arduino
A clone of the ELECHOUSE_CC1101 http://www.elechouse.com library updated for Arduino 1.0 plus.

I made the following changes to the original library.
* Changed imports of WProgram.h to Arduino.h in line with Arduino 1.0+
* Changed the init method so that you have to set the carrier frequency

# Connecting an Arduino to a CC1101
These instructions are for an Arduino Uno.

|Arduino|CC1101|Notes|
|-------|------|-----|
|GND    |GND| |
|3.3V|VCC||
|10|CSN/SS|Must be level shifted to 3.3V|
|11|SI/MOSI|Must be level shifted to 3.3V|
|12|SO/MISO||
|13|SCK|Must be level shifted to 3.3V|
|2|GD0|Signals buffer ready to read|

![alt text](https://github.com/simonmonk/CC1101_arduino/blob/master/F19_10.png?raw=true_ "Connections")

# Installing the Library

To install the library into your IDE:
* click on the Clone or Download button on this Github page and select Download ZIP.
* Start the Arduino IDE and from the Sketch menu do Sketch->Include Library->Add ZIP Library and select the ZIP you just downloaded.

#API Reference

This is a very easy library to use. You may just wish to try out the examples, that send a text message from one Arduino to another using the Serial Monitor. But for completeness, here it is:

## Include File

```
#include <ELECHOUSE_CC1101.h>
```

## Initialisation

Put this in your setup function.

```
ELECHOUSE_cc1101.Init(F_433); // set frequency - F_433, F_868, F_965 MHz
```

## Send/Receive Mode

Put this in your setup function and call again, any time after you have processed a received message.

When a new message arives GD0 on the CC1101 (Arduino pin 2) will be set LOW. You can hook this up to an interrupt or just watch for it in your loop function.

```
 ELECHOUSE_cc1101.SetReceive();
```

## Receiving Data

The maximum data size is 64 bits.

ReceiveData requires a buffer of type byte[] and returns the number of bytes contained in the message.

```
int len = ELECHOUSE_cc1101.ReceiveData(buffer);
```

## Sending Data

The maximum data size is 64 bits.

SendData requires a buffer of type byte[] and the number of bytes contained in the message.

```
ELECHOUSE_cc1101.SendData(buffer, len);
```

#Legal

	This library was originally copyright of Michael at elechouse.com but permision was
    granted by Wilson Shen on 2016-10-23 for me (Simon Monk) to uodate the code for Arduino 1.0+
    and release the code on github under the MIT license.

Wilson Shen<EMAIL_ADDRESS>23 October 2016 at 02:08
To: Simon Monk
Thanks for your email.
You are free to put it in github and to do and change.

On Oct 22, 2016 10:07 PM, "Simon Monk"<EMAIL_ADDRESS>wrote:
	Hi,

	I'm Simon Monk, I'm currently writing the Electronics Cookbook for O'Reilly. I use your
	ELECHOUSE_CC1101 library in a 'recipe'. Your library is by far the easiest to use of
	the libraries for this device, but the .h and .cpp file both reference WProgram.h which
	as replaced by Arduino.h in Arduino 1.0.

	Rather than have to talk my readers through applying a fix to your library, I'd like
	your permission to put the modified lib into Github and add an example from the book.
	I would of course provide a link to your website in the book and mention that you can buy
	the modules there. If its ok, I'd give the code an MIT OS license, to clarify its use.

	Thanks for a great library,

	Kind Regards,

	Simon Monk.


text:
## `StateManager`

### `_putPendingBlock(struct BlockLib.BlockInput input)` (internal)

Puts a block in the array of pending blocks.
First ensures that the block has the expected number for the next block,
then converts the block to a commitment block header, which contains a
hash of the transactions data and the current block number.

\_putPendingBlock

### `_confirmBlock(struct BlockLib.BlockHeader header)` (internal)

Updates the lastConfirmedBlock value.
Checks:

- block is pending
- block has passed challenge period
- block number is one higher than last confirmed block number

\_confirmBlock

license: MIT

branch_name: refs/heads/master

extension: md

gha_license_id: MIT

license_type: permissive


text:
# This image belongs to a larger project called Bioinformatics Docker Images Project (http://pegi3s.github.io/dockerfiles)
## (Please note that the original software licenses still apply)

This image facilitates the usage of [GBIF](https://www.gbif.org/) (Global Biodiversity Information Facility - an international network and research infrastructure funded by the world’s governments and aimed at providing anyone, anywhere, open access to data about all types of life on Earth) data to predict species distributions.

# Using the GBIF image in Linux

You should adapt and run the following command: `docker run --rm -v /your/data/dir:/data pegi3s/gbif_gis bash -c "/opt/run <species_name>"`

In this command, you should replace:
- `/your/data/dir` to point to the directory that contains the input files you want to analyze.
- `<species_name>` to the actual name of the species.

For instance, if the selected species is `Solanum acaule*`, you should run: `docker run --rm -v /your/data/dir:/data pegi3s/gbif_gis bash -c "/opt/run Solanum acaule*"`

### *Note 1*
The previous command generates three files:
- `data.csv`:  a coordinates file showing the geographic coordinates of where the species was recorded.
- `statistics`: a results file containing some statistics on the species presence points.
- `Rplots-crop.pdf`:  a PDF file showing the presence and predicted distribution of the species (probabilities are given as color codes). The prediction model used is the [Bioclim](https://support.bccvl.org.au/support/solutions/articles/6000083201-bioclim) model.

### *Note 2*
A folder named `wc2-5` containing data on 19 abiotic variables from [WorldClim](https://www.worldclim.org/) will be created, if not present.

# Using the GBIF image in Windows

Please note that data must be under the same drive than the Docker Toolbox installation (usually `C:`) and in a folder with write permissions (e.g. `C:/Users/User_name/`).

You should adapt and run the following command: `docker run --rm -v "/c/Users/User_name/dir/":/data pegi3s/gbif_gis bash -c "/opt/run <species_name>"`

gha_language: Dockerfile


text:
🍿 Sprint #3 Front-end Prototyping 🍿

CISC 327  -  Fall 2021

## 💺 Customer Requirement

Continuing our requirements from the last sprint, now you have the backend models up running.
In this sprint, we will prototype frontends for the customers to try.
The purpose of this sprint is to build a front-end prototype that is directly connected with your tested backend.
The demo prototype should contain:

- user login page
- user registration page
- user profile update page
- user home page (with links to the pages below)
  - product creation page
  - product update page

The customer does not have additional requirements at the moment.
Detailed specifications with constraints will be provided in the next sprint after the customer tried out the prototype.

**Therefore, there is no need for extensive frontend testing or backend testing. 🔥**

The team is only required to provide a runnable demo (aka manual smoke test - run it and put out fires if any 🚒 )

**Again, each team member should read thoroughly the instruction and the provided template.**

### 🍱 Step 1 - Frontend Options

For this project, you have the following two options for frontend prototyping:

- [We Interface](https://github.com/CISC-CMPE-327/Python-CI-2021/tree/option_web) (later tested with selenium)
  -  MVC design - Testing will be done by auto-clicking the webpage and checking the presence of elements/text.
  - [Summary of files changes](https://github.com/CISC-CMPE-327/Python-CI-2021/pull/1/files)
- [CLI interface](https://github.com/CISC-CMPE-327/Python-CI-2021/tree/option_cli) (later tested with standard IO)
  - Command-line interface (e.g. enter 1,2,3 for navigations). Testing will be done by manually creating command-line inputs and checking all the terminal outputs (e.g. check if the terminal prints `welcome`, then `Logging in the system`, then `enter your email:` etc.)
  - [Summary of files changes](https://github.com/CISC-CMPE-327/Python-CI-2021/pull/2/files)

The team should vote and pick the option that is more applicable for the members' skill set.
Example template can be found by clicking the links above this paragraph.
Please note that the first option may require you to learn additional knowledge outside this course.
Specifically, template-based MVC web services and Selenium-based web testing.
These techniques, especially selenium, itself is not covered in any other courses, since it is a tool rather than a framework.
It will be worth it to pick them up by doing this course.
Many of the last year's students found that these tools/knowledge are very helpful for landing/doing their internship.
But again, there is no grading preference for either of them.
It is up to the team to discuss what is the best option.

### ✈ Step 2 - Planning

This sprint is then kicked off by a planning meeting, where the scrum master and the team members sit down,
- Create a new scrum board.
- Create columns (the detailed version but not the simple version).
- Put cards on the backlog. There should be at least four cards for the team.
- Assign members and reviewers to the cards.
- Assignees move the cards to the todo column.

### 🎨 Step 3 - Design

Once the assignee starts working on this assignment, move the corresponding card to the design column.
The team member designs the HTTP routes interface and the HTML file names (empty files), following our frontend template.
If it is the CLI option, then design the screens.

### 🚀 Step 4 - Daily-Scrum (MVC Dev)

With the given tested backend interface (Model), the team members start implementing the front-end pages (View) and HTTP routes (Controller)
Each team member should develop and test their frontend before making a PR.

### ✅ Step 5 - Review/Approve
Once a card is done with the implementation and local testing (on your workstation/laptop), you can proceed to PR, request review, and seek approval for merge.

### 📝 Step 6 - Review & Retrospect
Review your changes, and record a walkthrough demo video for your client (on Youtube).

## 💺 Rules

All the assignments, starting from this point, will follow these rules:

- No file changes/uploads through the web interface. We can tell.
- No direct change to the master/main branch of your repository.
- All the changes to the repository have to go through Pull Request (PR).
- All the PRs require reviews and approval before merging.
- Each PR requires at least 2 reviewers, and each member has to do at least two reviews.
- All the reviews must provide at least one comment (constructive & specific) for improvement.
- All the team members must have at least a PR for each assignment (sprint).
- All the project activities have to be planned through the scrum board before coding and testing.
- All the cards for each sprint have to go through each column of your team's scrum board (cannot just directly jump from todo to done).
- All the PRs should be associated with at least one card in your scrum board (by mentioning the PR number using `#` in the card)
- All the PRs should follow the agreed PR template.
- All the documentation has to follow the [markdown format](https://guides.github.com/features/mastering-markdown/).
- All the merged code must follow the selected coding style guide.
- Each of the PR's titles should have emojis.

Additional rules for this assignment:
- Your main branch's badge has to be build-passing at the time of assignment submission.
- The demo video shows that all the frontend pages are runnable.

Violation of any of the above rules (except the one about emoji) will result in a grade penalty.
All the team members, through the principle of collective ownership, must ensure other team members' PR/code does not violate any of the rules above.
For any violations that can be tracked down, a penalty will apply for both the reviewers and the related contributors.
**For any teamwork issue, penalties will only apply to the member that causing the issue. If there are any teamwork issues for the last/current sprint, please come to my office during the office hour**

## 💺 Grading:

- Scrum practices (max 1 for the deduction, .25 for each violation)
- PR and git practices, including code review (max 1 for the deduction)
- Code style compliance (max 1 for the deduction, .1 for each style error)
- Documentation and comments - each file/class/method/attribute should have comments !!!! (max 3 for deduction, **.2** for each violation)
- Completeness of the features for front-end (max 4 for the deduction, 1 for each missing/incompleted frontend, no partial grades)

branch_name: refs/heads/main


text:
# RayTraceBlocks
PocketMine-MP plugin demonstrating a fast block ray-tracing algorithm

## Usage
When the player right-clicks (or click-hold on mobile) the plugin will perform a ray-trace along the line the player is looking along.
It will change the first block it hits to glass, with a nice explosion sound and particle.
The range is limited to 50 blocks - anything outside of a 50-block radius will report "out of bounds".

## Caveats
The vanilla Minecraft Bedrock client only sends rotation changes above a certain threshold. This means that in some cases the server may
target a different block (slightly off-target) than you're aiming at under your crosshair, because the server does not know that you've moved.

## Future usages
This plugin is a test for the demonstrated algorithm. Once the algorithm has been fine-tuned, it may be used in PocketMine-MP for projectiles.

repository: dktapps-pm-pl/RayTraceBlocks

repo_name: dktapps-pm-pl/RayTraceBlocks


text:
# NBIC's identification key widget
###### Concepts and data format

## About the key
There are several types of digital identification keys. In the pathway type a user is presented one question at a time in a fixed order, until one arrives at a single result. At the other end of the spectrum, the random access variant allows the user to filter the list of possible outcomes by selecting properties, so that one may be left with only one result in the end.

NBIC's key solution is of the third, hybrid type. Based on what is known about the taxon, the user is presented with one or more questions. This makes it possible to represent all preexisting keys, whether they are purely dichotomous, matrix-based, or anything in between. It also allows for easily expanding key data sets later with more information, more species and/or additional properties.

The key's content is stored as a spreadsheet. It is possible to represent a wide array of various parameters and conditions, but only very few are required. This documents discusses all possibilities, but its length and complexity is no need to worry: most keys will not use all fields. If you have an existing key, or a start of a concept, we'll be happy to help convert it into our format.

## Data model and concepts
In addition to some information on the key itself, the key consists of taxa (species or any higher/lower taxonomic level), properties, and relationships between species and properties. An overview of the types of information key can contain (only parameters with a :exclamation: are required):

### Information about the key
:exclamation:**Name**: Title of the key, e.g. “Deer”.
**Geographic range**: The area for which the key is valid, e.g. “Spitsbergen”.
**Intro**: Short text about the key (html allowed).
**Description**: ID of an article describing the key on NBIC's site.
**Language**: the language of the key, e.g. "En-us”.

### Taxa
**Name**: Name of the taxon. This field is used only for temporary display while the species name is fetched from the NBIC taxonomic backbone. Useful for increased readability of the spreadsheet too however.
:exclamation:**Taxon**: ID of the taxon in the NBIC taxonomic backbone. NBIC can assist in converting a list of scientific names into a list of ID-numbers.
**Media element**: ID or url of a picture depicting the taxon.
**Description**: ID of an article describing the taxon on NBIC's site.
**Subset**: it is possible to define subsets of taxa: one or several sublevels of a taxon with different sets of properties, that one wishes to let the user identify separately. For example male/female of the same species (the user will then be presented questions to distinguish between the two, also when the species has already been identified.)
**Morph**: it is possible to define morphs of taxa: one or several sublevels of a taxon with different sets of properties, that one does not wish to let the user identify separately. For example regular/melanistic individuals of the same species (the user will then not be presented questions to distinguish between the two, it suffices that the species has been identified.)
**Sort order**: a sort order in which the list of taxa is to be shown. When the sort index is unique for all taxa it will override the sorting completely. Taxa without an index, or sharing the same index, will be sorted (descending) in order of number of hits in the NBIC Species Map Service.
**Follow-up**: a link to a follow-up key, allowing the user to further identify the result to a lower taxon level.

### Properties
:exclamation:**Question**: the property, e.g. “What is the color of the wings?” or just “Wing color”.
:exclamation:**Answer**: one of the possible answers belonging to a question, e.g. “Yellow”.
**Question type**: whether or not the question can have several valid answers within an individual, for example when "black" and "red" both are to be checked to indicate an individual is red with black dots.
**Question requirement**: a logical requirement defining when the question may be asked. For example to only display a question on wing color when it is known that the result is both an insect and that it has wings.
**Question description**: ID of an article describing the property (question) on NBIC's site.
**Sort order**: a sort order in which the questions are to be shown. When the sort index is unique for all questions it will override the sorting completely. Questions without an index, or sharing the same index (for example to distinguish between field versus lab versus microscopic properties), will be sorted (descending) by the  standard deviation from the 'perfect' question (with the highest average chance of excluding as many results as possible).
**Media element**: ID or url of a picture depicting the current answer alternative.

Answers to different questions but with identical values for all taxa will be displayed as one grouped alternative. So "Has six legs" versus "Has four legs" and "Is an insect" versus "Is a mammal" will be shown as "Has six legs, is an insect" versus "Has four legs, is a mammal". This way questions pertaining to several properties at once can be split up in the data-format, whilst still being presented in context of the other relevant properties.

### Taxon-property links
Properties (answers) and taxa can have several types of links. These are denoted with numerical values:

| Value | Interpretation |
| --- | --- |
| 1 | individuals belonging to this taxon always have this property |
| 0 | individuals belonging to this taxon never have this property |
| 0.xx | individuals belonging to this taxon have this property in xx % of the cases |
|  | it is irrelevant/unspecified whether or not individuals belonging to this taxon have this property |

## The data format
The key's content is saved as a spreadsheet. Bold text in the examples below are keywords, that have to be spelled thus for correct parameter interpretation by the module. Those that are not used within a data set may be omitted.

A minimal key, with only required fields can look like this:

|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **Key name** | Example | **Taxon** | 4515 | 83770 |
| **Character** | **State**   |       | | |
| Has feathers/fur | Feathers | | 1 | 0 |
| | Fur | | 0 | 1 |
| Color | White | | 1 | 0.5 |
| | Brown | | 0 | 0.5 |

This gives a working key that distinguishes between the snowy owl (with taxon ID 4515) and the arctic fox (837700). It would be sufficient to specify whether the animal has feathers or fur, but for the sake of this example color is included too here. Not all arctic foxes are white, so white and brown both have a value between 0 and 1.

### Information about the key
Information about the key is listed in the top left corner of the spreadsheet. In its most complete form, the fields look as follows:

|  | |
| --- | --- |
| **Key name** | Example |
| **Geographic range** | Mainland Norway |
| **Language** | No-nb |
| **Key intro** | This is an example key describing some of the species found on Norway's mainland. |
| **Key description** | 180944 |

**Key name** is the name of the key.
**Geographic range** is the area the key is valid for.
**Language** is the language used in the key data.
**Key intro** is a short description of the key.
**Key description** ID of an article describing the key on NBIC's site.

### Properties
Parameters linked to properties, aka questions and answers (characters og states) get a column each, below the information about the key and the last row with a parameters concerning taxa. In its most complete form, the fields look as follows:

| Character      | State     | Multistate character | Character requirement | Description | State id | State media             | Sort |
| -------------- | --------- | -------------------- | --------------------- | ----------- | -------- | ----------------------- | ---- |
| Number of legs | 6         |                      |                       | 63445       | 6legs    | 2342                    | 1    |
|                | 2         |                      |                       |             | 2legs    | 6774                    |      |
| Wings          | Has wings |                      |                       | 6345533     | wings    | 3466                    | 1    |
| Wing color     | Red       | TRUE                 | {wings} && {6legs}    | 3343435     |          | http://www.blablabla.no | 2    |
|                | Black     |                      |                       |             |          | 23552                   |      |
|                | Blue      |                      |                       |             |          |                         |      |

**Character** and **state** are the question and its possible answers. Any number of alternatives from one to many is supported. The wing question in the example has only one alternative, and the user will be able to answer positively or negatively. It is also possible to include two alternatives: has wings versus does not have wings, that the user then can choose from.
**Multi-state character** denotes whether or not multiple answers can be true simultaneously, for example when wings are red with black dots. If nothing is specified it is assumed not to be the case: individuals either have 6 or 2 legs.
**Character requirement** provides the opportunity to specify a logical rule that must be fulfilled before a question may be displayed. Answers can be referred to via **State id**,
between {}, as in the example above. It accepts javascript notation: "!" for 'not', "&&" for 'and', and "||" for 'or', and as many parentheses "()" as you want. This way complicated rules can be defined: (A || B) && ((!C && !D) || (E && !F)): A or B, while not C and not D, and/or E and not F.
**Description** is the ID of an article describing the character and its possible states on NBIC's site.
**State media** is an ID or url of a picture depicting the current answer alternative on NBIC's or an external site.
**Sort** is the sorting index. Sort primarily takes into account this index, and after that the standard deviation from the 'perfect' question (with the highest average chance of eliminating as many results as possible).

### Taxa
Parameters linked to the keys possible results (taxa) get a row each, right of the general information about the key and the last column with a parameter describing characters and states. In its most complete form, the fields look as follows:

| | | | | | |
| --- | --- | --- | --- | --- | --- |
|**Name** | Arctic fox male | Arctic fox female | Golden-belted bumblebee (normal) | Golden-belted bumblebee (melanistic) | Cod |
|**Taxon** | 83770 | 83770 | 634534 | 634534 | 466437 |
|**Subset** | ♂ | ♀ | | |  |
|**Morph** | | | | Melanistic |  |
|**Media** | 4534 | 7445 | 23423 | 12245 | 7456 |
|**Description** | 346773 | 346773 | 345744 | 345744 | 967343 |
|**Followup** | | | | | /Files/13512&taxa=84373 |

**Name** is a parameter that is displayed while the taxon name is fetched from the NBIC taxonomic backbone. It also makes the spreadsheet more readable.
**Taxon** is the ID of the taxon in the NBIC taxonomic backbone.
**Subset** defines a sub-level of the taxon by having several columns with the same taxon ID, each with a different subset name. Such individuals have a unique set of properties, and one wants to allow the user to identify the right subset. In this example the sex of the Arctic fox (the user will be presented questions to determine the sex of the individual, also when it is already known that it is an Arctic fox).
**Morphs** define a sub-level of the taxon by having several columns with the same taxon ID and subset, with or without a morph name. Such individuals have a unique set of properties, but one does not want to allow the user to identify the exact morph. In this example the normal/melanistic variant of the Golden-belted bumblebee (the user will not be presented questions to determine the type of individual, it is sufficient to determine that it is a Golden-belted bumblebee). If a morph with a specified name happens to be known in the end it will be shown.
**Media** is an ID or url of a picture depicting the taxon on NBIC's or an external site.
**Description** is the ID of an article describing the taxon on NBIC's site.
**Followup** is a url to a follow-up key, that the user can choose to go to in order to identify the individual to an even lower level. By specifying a comma-separated list of taxon IDs in the url as *&taxa=x,y* one can specify that only subtaxa of taxa x and y are relevant. It is usually a good idea to specify the current result ID when referring to another key, as that key may include a larger group of taxa.

### More examples
A realistic example containing a relatively straightforward key:

| | | | | | | |
| --- |  --- | --- | --- | --- | --- | --- |
| **Key name** | Example | | | **Name** | Snowy owl | Arctic fox |
| **Key intro** | Test key intro text | | | **Taxon** | 4515 | 83770 |
| **Key description** | 664564 | | | **Media** | 67345 | 57564 |
| | | | | **Description** | 774566 | 632346 |
| **Character** | **State** | **Description** | **State media** | | | |
| Has feathers/fur | Feathers | 456353 | 65655 | | 1 | 0 |
|  | Fur | | 87684 | | 0 | 1 |
| Color | White | 745626 | 73455 | | 1 | 0.5 |
| | Brown | | 78435 | | 0 | 0.25 |
| | Gray | | 65454 | | 0 | 0.25 |

path: /Data format (en).md

filename: Data format (en).md

gha_language: JavaScript


text:
## Usage

Here's a demo stack that uses the downloaded `vendor/modules/s3` module.

app/stack/demo/main.tf

```terraform
resource "random_pet" "this" {
  length = 2
}

module "bucket" {
  source     = "../../modules/s3" # looks up either app/modules/s3 or vendor/modules/s3
  bucket     = "bucket-${random_pet.this.id}"
  acl        = var.acl
}
```

A module downloaded to `vendor/modules/s3` is sourced same way as if they were defined in `app/modules/s3`. This is because Terraspace considers multiple lookup paths. Docs: [Lookup Paths]({% link _docs/lookups.md %})

Here's an example repo based on these docs: [boltops-tools/terraspace-demo-terrafile](https://github.com/boltops-tools/terraspace-demo-terrafile)

{% include terrafile/lockfile.md %}

repository: Grummfy/terraspace-docs

repo_name: Grummfy/terraspace-docs


text:
# `exceptions` package - Alta Standard Library
This package contains a base class that should be used for all exceptions and a few common exceptions.

All documentation for standard library packages list classes that inherit from the base exception class (called `Exception`) in a section called "Exceptions", including this one.

Classes
---
## `Exception`
**Has copy constructor**: Yes (default)\
**Has destructor**: Yes (default)

**Summary**: A basic exception class

**Notes**

All Alta exceptions should inherit from this class. While it's not required to do so, it's a nice way of providing some basic information about the exception to anyone who might encounter it.

Note that since Alta is still highly unstable, this class currently contains no useful members or methods. In fact, the entire exception system might be eliminated since different options for exception handling are being investigated.

Exceptions
---
## `NullPointerAccess`
**Summary**: Indicates that there was an attempt to access a null pointer

**Notes**

This is thrown by checks performed by the recipient of the null pointer. An attempt to access a null pointer will **not** automatically throw this error (at the moment), it will perform the same action it would in C: undefined behavior.

## `InvalidArgument`
**Summary**: Indicates that an invalid argument was provided

## `IndexOutOfBounds`
**Summary**: Indicates that there was an attempt to access an index outside the permitted bounds

**Notes**

This is usually thrown when trying to access an element that doesn't exist in a container.

## `UnsupportedPlatform`
**Summary**: Indicates that an operation that was trying to be performed is not supported on the current platform

## `Impossible`
**Summary**: Indicates that something has occurred that never should have been possible

**Notes**

This indicates that there has been a violation of the expections of the program and should be carefully investigated.

repository: alta-lang/alta

repo_name: alta-lang/alta


text:
---
layout: article
title: Rust Learning Note - Rust Data Types
modified: 2018-06-13T16:51:58-07:00
categories: blogs
excerpt:
tags: [Rust, Compilation]
image:
feature:
teaser:
thumb:
date: 2018-06-13T15:09:56-07:00
toc: true
---

Rust is a strongly-typed, statically-typed programming language.

# I. Scalar Types

There are four primary scalar types in Rust programming language.

## 1) Integers

Integers in Rust are either **signed** or **unsigned**.

| Length | Signed | Unsigned |
| :----: | :----: | :------: |
| 8-bit  | i8     | u8       |
| 16-bit | i16    | u16      |
| 32-bit | i32    | u32      |
| 64-bit | i64    | u64      |
| arch   | isize  | usize    |

Let n = length of binary representation of any integer:

    * in ranges from -(2^(n-1)) to 2^(n-1) - 1 inclusive
    * un ranges from 0 to 2^n - 1

`arch` integers are represented with either 32 bits or 64 bits, depending on the machine architecture.

## 2) Floating-point numbers

Floating-point numbers in Rust follow [IEEE 754](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4610935 "IEEE 754") standard.

| Length | Type   | Precision |
| :----: | :----: | :-------: |
| 32-bit | f32 | single-precision |
| 64-bit | f64 | double-precision |

## 3) Booleans

{% highlight rust %}
    let b : bool = false;
{% endhighlight %}

## 4) Characters

Each character in Rust is actually a Unicode scalar value ranging from `U+0000` to `U+D7FF` and `U+E000` to `U+10FFFF` inclusive.

# II. Compound Types

Rust has two primitive compound types : tuples and arrays

## 1) Tuples

A list of values of various data types in parentheses. The values in a tuple don't have to be of the same type.

Two ways of declaring a tuple:

###### Explicit type:

{% highlight rust %}
let tup: (i32, f64, u8) = (-1, 56.2, 32);
{% endhighlight %}

###### Implicit Type:

{% highlight rust %}
let tup = (-1, 56.2, 32);
{% endhighlight %}

###### Destruct a tup into multiple variables:

{% highlight rust %}
let (x, y, z) = tup;
{% endhighlight %}

###### Accessing tuple element:

{% highlight rust %}
let x = tup.0; // 0 is the index of first element in this tuple.
let y = tup.1;
let z = tup.2;
{% endhighlight %}

## 2) Arrays

A fixed-length list of values of the same type in square brackets.

{% highlight rust %}
let arr = [1, 2, 3, 4, 5];
{% endhighlight %}

An array is fixed-length and hence cannot grow or shrink. Use Vector in standard library for similar functionality of "ArrayList" in Java or Vector in C++;

Array in Rust is on stack rather than on heap.

Access array element: (same with C/C++/Java)

{% highlight rust %}
    let a = arr[0];
{% endhighlight %}


text:
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).

## [Unreleased]
## [0.3.1] - 2021-10-26

- `with_cryo` can now take `&[mut] (impl ?Sized)` (a reference to a dynamically-sized object)

## [0.3.0] - 2021-10-25

- Breaking (**soundness fix**):
    - `Cryo<T, _>: Send` requires `T: Sync` instead of `T: Send`.
    - `CryoMut<T, _>: Send` now requires `T: Sync` in addition to `T: Send`.
    - `CryoMutReadGuard<T, _>: Send` requires `T: Sync` instead of `T: Send`.
- Breaking: The `Send`/`Sync`-ness of `Lock` is now taken into account in trait bounds.
- `Cryo<T, _>: Sync` no longer requires `T: Send`.
- `CryoMutReadGuard<T, _>: Sync` no longer requires `T: Send`.
- `CryoMutWriteGuard<T, _>: Sync` if `T: Sync`.
- Breaking (**soundness fix**): Remove `cryo!`

## [0.2.7] - 2021-10-25

- Deprecate 0.2.x because of numerous soundness bugs that require breaking fixes

## [0.2.6] - 2021-09-11

- Update `README.md`

## [0.2.4] - 2021-09-11

- Bring `with_cryo` back with an overloaded interface (one function can produce both `Cryo` and `CryoMut` depending on a given type).
- Deprecate (**soundness fix**): `cryo!`

## [0.2.3] - 2021-09-02

- Breaking (**soundness fix**): `{Cryo, CryoMut}::new` is now `unsafe fn`.

## [0.2.2] - 2021-05-08

- `cryo` no longer enables the default features of `stable_deref_trait`, fixing builds on `core`-only targets.

## [0.2.1] - 2021-04-19

- Added `AtomicLock`

## [0.2.0] - 2021-04-18

- Breaking: `Cryo` is now generalized over lock implementations. Two implementations are provided: `LocalLock` (single-threaded) and `SyncLock` (borrows can be sent to other threads). You need to specify in `cryo!` to use the latter.
- Breaking: `parking-lot` feature was removed.
- Breaking: `Cryo` now utilizes `std::pin::Pin` (instead of making the constructor `unsafe fn`) for pinning. Most methods now take `self: Pin<&Cryo<_, _>>` as the receiver.
- Breaking: `with_cryo[_mut]` was superseded by `cryo!`.
- Breaking: `std` feature was added.

## [0.1.6] - 20xx-xx-xx
## [0.1.5] - 20xx-xx-xx
## [0.1.4] - 20xx-xx-xx
## [0.1.3] - 20xx-xx-xx
## [0.1.2] - 20xx-xx-xx
## [0.1.1] - 20xx-xx-xx
## 0.1.0 - 20xx-xx-xx

- Initial release.

[Unreleased]: https://github.com/yvt/cryo/compare/0.3.1...HEAD
[0.3.1]: https://github.com/yvt/cryo/compare/0.3.0...0.3.1
[0.3.0]: https://github.com/yvt/cryo/compare/0.2.6...0.3.0
[0.2.7]: https://github.com/yvt/cryo/compare/0.2.6...0.2.7
[0.2.6]: https://github.com/yvt/cryo/compare/0.2.4...0.2.6
[0.2.4]: https://github.com/yvt/cryo/compare/0.2.3...0.2.4
[0.2.3]: https://github.com/yvt/cryo/compare/0.2.2...0.2.3
[0.2.2]: https://github.com/yvt/cryo/compare/0.2.1...0.2.2
[0.2.1]: https://github.com/yvt/cryo/compare/0.2.0...0.2.1
[0.2.0]: https://github.com/yvt/cryo/compare/0.1.6...0.2.0
[0.1.6]: https://github.com/yvt/cryo/compare/0.1.5...0.1.6
[0.1.5]: https://github.com/yvt/cryo/compare/0.1.4...0.1.5
[0.1.4]: https://github.com/yvt/cryo/compare/0.1.3...0.1.4
[0.1.3]: https://github.com/yvt/cryo/compare/0.1.2...0.1.3
[0.1.2]: https://github.com/yvt/cryo/compare/0.1.1...0.1.2
[0.1.1]: https://github.com/yvt/cryo/compare/0.1.0...0.1.1

repository: yvt/cryo

repo_name: yvt/cryo


text:
# Next Steps for ndx-icephys-meta Extension for NWB:N

## Creating Your Extension

1. In a terminal, change directory into the new ndx-icephys-meta directory.

2. Add any packages required by your extension to `requirements.txt` and `setup.py`.

3. Run `python -m pip install -r requirements.txt` to install the `pynwb` package
and any other packages required by your extension.

4. Modify `src/create_extension_spec.py` to define your extension.

    - If you want to create any custom classes for interacting with the extension,
      add them to the `src/pynwb`.
      - If present, the `src/pynwb` folder MUST contain the following:
        - `ndx-icephys-meta` - Folder with the sources of the NWB extension
        - `ndx-icephys-meta/__init__.py` - Python file that may be empty
        - `requirements.txt` - Text file listing the Python package requirements for the extension
        - `README.md` - Markdown file describing the NWB extension
      - If present, the `src/pynwb` folder MAY contain the following files/folders:
        - `test` - Folder for unit tests for the extensions
        - `jupyter-widgets` - Optional package with custom widgets for use with Jupyter

5. Run `python src/spec/create_extension_spec.py` to generate the
`spec/ndx-icephys-meta.namespace.yaml` and
`spec/ndx-icephys-meta.extensions.yaml` files.

6. You may need to modify `setup.py` and re-run `python setup.py install` if you
use any dependencies.

## Documenting and Publishing Your Extension to the Community

1. Clone the latest nwb-docutils repository https://github.com/nwb-extensions-test/ndx-template.git
or install the latest release:
`python -m pip install nwb-docutils`
    - If you cloned the latest version, run `python setup.py install` to install nwb-docutils locally.

2. Start a git repository for your extension directory ndx-icephys-meta
 and push it to GitHub. You will need a GitHub account.
    - Follow these directions:
  https://help.github.com/en/articles/adding-an-existing-project-to-github-using-the-command-line

3. Change directory into `docs`.

4. Run `make html` to generate documentation for your extension based on the YAML files.

5. Read `docs/README.md` for instructions on how to customize documentation for
your extension.

6. Modify `README.md` to describe this extension for interested developers.

7. Add a license file. Permissive licenses should be used if possible. **A [BSD license](https://opensource.org/licenses/BSD-3-Clause) is recommended.**

8. Make a release for the extension on GitHub with the version number specified. e.g. if version is 0.1.0, then this page should exist: https://github.com/oruebel/ndx-icephys-meta/releases/tag/0.1.0

9. Publish your updated extension on PyPi.
    - Follow these directions: https://packaging.python.org/tutorials/packaging-projects/
    - You may need to modify `setup.py`
    - If your extension version is 0.1.0, then this page should exist: https://pypi.org/project/ndx-icephys-meta/0.1.0

    Once your GitHub release and ``setup.py`` are ready, publishing on PyPi:
    ```bash
    python setup.py sdist bdist_wheel
    twine upload dist/*
    ```

10. Go to https://github.com/nwb-extensions/staged-extensions and fork the
repository.

11. Clone the fork onto your local filesystem.

12. Copy the directory `staged-extensions/example` to a new directory
`staged-extensions/ndx-icephys-meta`:

    ```bash
    cp -r staged-extensions/example staged-extensions/ndx-icephys-meta
    ```

13. Edit `staged-extensions/ndx-icephys-meta/ndx-meta.yaml`
with information on where to find your NWB extension.
    - The YAML file MUST contain a dict with the following keys:
      - name: extension namespace name
      - version: extension version
      - src: URL for the main page of the public repository (e.g. on GitHub, BitBucket, GitLab) that contains the sources of the extension
      - pip: URL for the main page of the extension on PyPI
      - license: name of the license of the extension
      - maintainers: list of GitHub
      usernames of those who will reliably maintain the extension
    -

  You may copy and modify the following YAML that was auto-generated:
```yaml
name: ndx-icephys-meta
version: 0.1.0
src: https://github.com/oruebel/ndx-icephys-meta
pip: https://pypi.org/project/ndx-icephys-meta/
license: BSD 3-Clause
maintainers:
  - oruebel
```

14. Edit `staged-extensions/ndx-icephys-meta/README.md`
to add information about your extension. You may copy it from
`ndx-icephys-meta/README.md`.

  ```bash
cp ndx-icephys-meta/README.md staged-extensions/ndx-icephys-meta/README.md
```

15. Git commit and push your changes to GitHub.

16. Open a pull request. Building of your extension will be tested on Windows,
Mac, and Linux. The technical team will review your extension shortly after
and provide feedback and request changes, if any.

17. When your pull request is merged, a new repository, called
ndx-icephys-meta-feedstock will be created in the nwb-extensions
GitHub organization and you will be added as a maintainer for that repository.

## Updating Your Published Extension

1. Update your ndx-icephys-meta GitHub repository.

2. Publish your updated extension on PyPi.

3. Fork the ndx-icephys-meta-feedstock repository on GitHub.

4. Open a pull request to test the changes automatically. The technical team
will review your changes shortly after and provide feedback and request changes,
 if any.

5. Your updated extension is approved.

repository: oruebel/ndx-icephys-meta

gha_language: Jupyter Notebook

gha_license_id: NOASSERTION

repo_name: oruebel/ndx-icephys-meta


text:
= Errbit RabbitMQ Handler

Errbit notifier extension for handling notices using RabbitMQ

Use this library to grab errbit notices off of a RabbitMQ queue.

This extension is used in conjunction with the errbit_rabbitmq_notifier gem. Use that gem to asynchronously push notices to Errbit. This extension will pick those notices off of the queue and process them. No more relying on Errbit to be fast and/or up 100% of the time.

== Installation

Install RabbitMQ Server (http://www.rabbitmq.com/download.html)

Get Errbit https://github.com/errbit/errbit

Install the gem:

  gem install errbit_rabbitmq_handler

== Usage

Configure the RabbitMQ handler by defining it's address in <tt>config/initializers/errbit_rabbit_handler.rb</tt>:

  ErrbitRabbitMQHandler.configure do |config|
    # Address to bind to listen exception notifications
    config.rabbit_host = "<IP_ADDRESS>"
    # optional config variables
    # config.rabbit_port          = 5672
    # config.rabbit_routing_key   = :routing_key
    # config.rabbit_queue         = :a_queue
    # config.rabbit_exchange      = :some_exchange
  end

Starting handler daemon:
  APP_ROOT=/path/to/app/root RAILS_ENV=production errbit_rabbitmq_handler start

Stop handler daemon:
  APP_ROOT=/path/to/app/root RAILS_ENV=production errbit_rabbitmq_handler stop

Restart handler daemon:
  APP_ROOT=/path/to/app/root RAILS_ENV=production errbit_rabbitmq_handler restart

--
For a more detailed look at how to configure RabbitMQ, look at these guides:
http://rdoc.info/github/ruby-amqp/amqp/master/file/docs/DocumentationGuidesIndex.textile

== License

HoptoadRabbitMQNotifier: Copyright © 2011 Tracey Eubanks. It is free software, and may be redistributed under the terms specified in the MIT-LICENSE file.


text:
---
period: "Flow 4b"
title: "GraphQL and Apollo"
date: "14-05-2019"
pageintro: |

    Client Side GraphQL with React and Apollo
---

### Before this lesson you should:
<!--readings_begin-->
- :book: [introduction (15 min.)](https://www.apollographql.com/docs/react/) to the Apollo client, the library we are going to use for GraphQL Client Side interaction
- :book: [Getting Started (20 min.)](https://www.apollographql.com/docs/react/essentials/get-started.html) section of the Apollo Boost examples. This, and the sections Queries and Mutations is the starting point for the exercises for this lecture
<!--readings_end-->

### Exercises
<!--exercises_begin-->
- [Apollo/React-exercises](https://docs.google.com/document/d/1IIFoYyl3CMuSQ8oGHyGZBWh3-SroFyoaQWn-LPI9qVc/edit?usp=sharing)
- [Mini Project, part4 (client)](https://docs.google.com/document/d/11i1RJAfjQMgU-6RTLjcJNYyXRtAQzZOJFI-j4Kf2LVA/edit?usp=sharing)
<!--exercises_end-->

#### Slides
[Short intro to Client-side GraphQL with React](https://docs.google.com/presentation/d/1BxWP1GbLU5yET7wTWyoBPwoX6uN-bxRla47Vg2cWTsY/edit?usp=sharing)


text:
<!--
This is a template for TiDB's change proposal process, documented [here](./README.md).
-->

# Proposal: Support Common Table Expression

- Author(s): [@guo-shaoge](https://github.com/guo-shaoge), [@wjhuang2016](https://github.com/wjhuang2016)
- Discussion PR: https://github.com/pingcap/tidb/pull/24147
- Tracking Issue: https://github.com/pingcap/tidb/issues/17472

## Table of Contents

* [Introduction](#introduction)
* [Motivation or Background](#motivation-or-background)
* [Detailed Design](#detailed-design)
* [Test Design](#test-design)
    * [Functional Tests](#functional-tests)
    * [Scenario Tests](#scenario-tests)
    * [Compatibility Tests](#compatibility-tests)
    * [Benchmark Tests](#benchmark-tests)
* [Impacts & Risks](#impacts--risks)
* [Investigation & Alternatives](#investigation--alternatives)
* [Unresolved Questions](#unresolved-questions)
* [Future Work](#future-work)

## Introduction

This proposal describes the basic implementation of Common Table Expression(CTE) using the `Materialization` method.
`Merge` is another way to implement CTE and will be supported later.

## Motivation or Background

CTE was introduced in SQL:1999. It's a temporary result set which exists within a statement. You can reference it later in the statement.
It's similar to derived tables in some way. But CTE has extra advantages over derived tables.

1. CTE can be referenced multiple times.
2. CTE is easier to read.
3. You can use CTE to do hierarchical queries.

There are two kinds of CTE:
1. non-recursive CTE.

    ```SQL
    WITH
        cte1 AS (SELECT c1 FROM t1)
        cte2 AS (SELECT c2 FROM t2)
    SELECT cte1.c1, cte2.c2 FROM cte1, cte2 WHERE cte1.c1 = cte2.c2 AND cte1.c1 = 100;
    ```
2. recursive CTE, which can be used to do hierarchical queries. Recursive CTE normally consists of the seed part and the recursive part.
   Seed part will generate the origin data, the remaining computation will be done by the recursive part.

    ```SQL
    WITH RECURSIVE cte1 AS (
        SELECT part, sub_part FROM t WHERE part = 'human'
        UNION ALL
        SELECT t.part, t.sub_part FROM t, cte1 WHERE cte1.sub_part = t.part
    )
    SELECT * FROM cte1;
    ```

## Detailed Design
### Overview
There are two ways to implement CTE:
1. Merge: just like view, CTE is expanded on where it's used.
2. Materialization: use temporary storage to store the result of CTE, and read the temporary storage when using CTE.

`Merge` is normally a better way to implement CTE, because optimizer can pushdown predicates from outer query to inner query.
But when CTE is referenced multiple times, `Materialization` will be better. And recursive CTE can only be implemented by `Materialization`.

For simplicity, this design doc only uses `Materialization` to implement both non-recursive and recursive CTE.
So there is no need to consider how to choose between these two methods, so as to reduce the chance of bugs.
And in the near future, `Merge` will be definitely supported to implement non-recursive CTE.

`RowContainer` will be used to store the materialized result.
The result will first reside in memory, and when the memory usage exceeds `tidb_mem_quota_query`, intermediate results will be spilled to disk.

For recursive CTE, the optimizer has no way to accurately know the number of iterations. So we use the seed part's cost as CTE's cost.
Also we will add a system variable `cte_max_recursion_depth` to control the max iteration number.
If the maximum iteration number is reached, an error will be returned.

A major advantage of `Materialization` is that data will only be materialized once even if there are many references to the same CTE.
So we will add a map to record all CTE's subplan, these subplans will only be optimized and executed once.

### New Data Structures
#### Logical Operator
```Go
type LogicalCTE struct {
	logicalSchemaProducer

	cte       *CTEClass
	cteAsName model.CIStr
}

type CTEClass struct {
	IsDistinct bool
	seedPartLogicalPlan      LogicalPlan
	recursivePartLogicalPlan LogicalPlan
	IDForStorage int
	LimitBeg uint64
	LimitEnd uint64
}
```

`LogicalCTE` is the logical operator for CTE. `cte` is a member of `CTEClass` type.
The content of `CTEClass` will be the same if different CTE references point to the same CTE.

The meanings of main members in CTEClass are as follows:
1. `IsDistinct`: True if UNION [DISTINCT] and false if UNION ALL.
2. `seedPartLogicalPlan`: Logical Plan of seed part.
3. `recursivePartLogicalPlan`: Logical Plan of recursive part. It will be nil if CTE is non-recursive.
4. `IDForStorage`: ID of intermediate storage.
5. `LimitBeg` and `LimitEnd`: Useful when limit is used in recursive CTE.

```Go
type LogicalCTETable struct {
    logicalSchemaProducer

    name         string
    idForStorage int
}
```
`LogicalCTETable` will read the temporary result set of CTE. `idForStorage` points to the intermediate storage.

#### Physical Operator
`PhysicalCTE` and `PhysicalCTETable` will be added corresponding to `LogicalCTE` and `LogicalCTETable`.

#### Executor

```Go
type CTEExec struct {
	exec.BaseExecutor

	seedExec      Executor
	recursiveExec Executor

	resTbl     cteutil.Storage
	iterInTbl  cteutil.Storage
	iterOutTbl cteutil.Storage

	hashTbl baseHashTable
}
```

`CTEExec` will handle the main execution. Detailed execution process will be explained later.
1. `seedExec` and `recursiveExec`: Executors of seed part and recursive part.
2. `resTbl`: The final output is stored in this storage.
3. `iterInTbl`: Input data of each iteration.
4. `iterOutTbl`: Output data of each iteration.
5. `hashTbl`: Data will be deduplicated if UNION [DISTINCT] is used.

```Go
type CTETableReaderExec struct {
	exec.BaseExecutor

	iterInTbl cteutil.Storage
	chkIdx    int
	curIter   int
}
```

`CTETableReaderExec` is used in recursive CTE. It will read `iterInTbl` and the output chunk will be processed in `CTEExec`.

#### Storage
```Go
type Storage interface {
    OpenAndRef() bool
    DerefAndClose() error
    Add(chk *chunk.Chunk) error
    GetChunk(chkdIdx int) (*chunk.Chunk, error)
    Lock()
    Unlock()
}
```

`Storage` is used to store the intermediate data of CTE. Check the `resTbl`, `iterInTbl` and `iterOutTbl` in `CTEExec`.

Since there will be multiple executors using one `Storage`, we use a ref count to record how many users currently there are.
When the last user calls Close(), the `Storage` will really be closed.

1. `OpenAndRef()`: Open this `Storage`, if already opened, add ref count by one.
2. `DerefAndClose()`: Deref and check if ref count is zero, if true, the underlying storage will be truly closed.
3. `Add()`: Add chunk into storage.
4. `GetChunk()`: Get chunk by chunk id.
5. `Lock()` and `Unlock`: `Storage` may be used concurrently. So we need to add a lock.

### Life of a CTE
#### Parsing
In parsing phase, definition of CTE will be parsed as a subtree of the outermost select stmt.

#### Logical Plan
The parsing phase will generate an AST, which will be used to generate `LogicalCTE`. This stage will complete the following steps:
1. Distinguish between seed part and recursive part of the definition of CTE. And build logical plans for them.
2. Do some validation checks.

    1. Mutual recursive(cte1 -> cte2 -> cte1) is not supported.

    2. Column number of the seed part and the recursive part must be same.

    3. All seed parts should follow recursive parts.

    4. recursive parts cannot include: `ORDER BY`, `Aggregate Function`, `Window Function`, `DISTINCT`.

3. Recognize the same CTE. If there are multiple references to the same CTE.

We use the following SQL to illustrate:
```SQL
WITH RECURSIVE cte1 AS (SELECT c1 FROM t1 UNION ALL SELECT c1 FROM cte1 WHERE cte1.c1 < 10) SELECT * FROM t2 JOIN cte1;
```

The logical plan of above SQL will be like:

![logical_plan](./imgs/logical_plan.png)

#### Physical Plan
In this stage, the `LogicalCTE` will be converted to `PhysicalCTE`. We just convert logical plans of the seed part and the recursive part to its physical plan.
Also `LogicalCTETable` will be converted to `PhysicalCTETable`.

The Physical Plan will be like:

![physical_plan](./imgs/physical_plan.png)

#### Build Executor
Three structures will be constructed:
1. `CTEExec`: Evaluate seed part and recursive part iteratively.
2. `CTETableReaderExec`: Read result of previous iteration and return result to parent operator.
3. `Storage`: This is where the materialized results are stored. `CTEExec` will write it and `CTETableReaderExec` will read it.

The executor tree will be like:

![executors](./imgs/executors.png)

#### Execution
The following pseudo code describes the execution of `CTEExec`:

```Go
func (e *CTEExec) Next(req *Chunk) {
    // 1. The first executed CTEExec will be responsible for filling storage.
    e.storage.Lock()
    defer e.storage.Unlock()
    if !e.storage.Done() {
        // 1.1 Compute seed part and store data into e.iterInTbl.
        for {
            // 1.2 Compute recursive part iteratively and break if reaches termination conditions.
        }
        e.storage.SetDone()
    }
    // 2. Return chunk in e.resTbl.
}
```

Only the first `CTEExec` will fill the storage. Others will be waiting until the filling process is done.
So we use `Done()` to check at the beginning of execution.
If the filling process is already done, we just read the chunk from storage.

The filling of `Storage` is done by `CTEExec` and `CTETableReaderExec` together. The following figure describes the process.

![cte_computation](./imgs/cte_computation.png)

1. Compute the `SeedExec`(step 1) and all output chunks will be stored into `iterInTbl`(step 2), which will be the input data of next iteration.
2. Compute the `RecursiveExec` iteratively. `iterInTbl` will be read by `CTETableReaderExec`(step 3) and its output will be processed by executors in `RecursiveExec`(step 4,5). And finally the data will be put into `iterOutTbl`(step 5).
3. At the end of each iteration, we copy all data from `iterOutTbl` to `iterInTbl` and `resTbl`(step 7). So the output of the previous iteration will be the input of the next iteration.
4. Iteration will be terminated if:

    1. No data is generated in this iteration or
    2. Iteration number reaches `@@cte_max_recursion_depth` or
    3. Execution time reaches `@@max_execution_time`.

Data in storage will be spilled to disk if memory usage reaches `@@tidb_mem_quota_query`. `MemTracker` and `RowContainer` will handle all the spilling process.

Also we use a hash table to de-duplicate data in `resTbl`. Before copying data from `iterOutTbl` to `resTbl`, we use this hash table to check if there are duplications.

We also support use LIMIT in recursive CTE. By using LIMIT, users don’t have to worry about infinite recursion.
Because if the number of output rows reaches the LIMIT requirement, the iteration will be terminated early.

## Test Design

### Functional Tests

1. Basic usage of non-recursive and recursive CTE.
2. Define a new CTE within a CTE.
3. Use CTE in subquery.
4. Use CTE in UPDATE/DELETE/INSERT statements.
5. CTE name conflicts with other table names.
6. Join CTE with other tables/CTE.
7. Use expressions with CTE.

### Scenario Tests

We should test CTE used together with other features:
1. Use CTE with PREPARE/EXECUTE/PlanCache.
2. Use CTE with a partition table.
3. Stale read.
4. Clustered index.
5. SPM/Hint/Binding.

### Compatibility Tests

None

### Benchmark Tests

A basic performance test should be given in a specific scenario.
The memory usage, disk usage and QPS should be reported.

## Impacts & Risks

CTE is a new feature and it will not affect the overall performance.
But for now we only use `Materialization` to implement non-recursive CTE.
In some scenarios, the performance may not be as good as implementations which use `Merge`.

## Investigation & Alternatives

### Choose between Merge and Materialization
Most mainstream DBMS use `Merge` and `Materialization` to implement non-recursive cte, while recursive cte can only be implemented with `Materialization`.
`Merge` is preferred when there are no side effects, such as random()/cur_timestamp() is used in subquery.
But when CTE is referenced multiple times, `Materialization` may be better.
Also users can control which method to use explicitly by using hints.

### Materialization
For `Materialization`, most DBMS use some kind of container to store materialized result,
which will be spilled to disk if the size is too large. The computation steps for recursive CTE are all similar.

But different system use different ways to try to optimize:
1. Try to postpone materialization.
3. Pushdown predicates to reduce the size of the temporary table.

## Unresolved Questions

None

## Future Work
1. Support `Merge` and related hints(merge/no_merge).
2. Optimize `Materialization`, pushdown predicates to the materialized table.
2. MPP support. `CTEExec` will be implemented in TiFlash later. But SQL used in CTE definition still can be pushed to TiFlash.

repository: pingcap/tidb

gha_language: Go

repo_name: pingcap/tidb


text:
## MTRSVCP
## [Minecraft Transit Railway Snapshot Versions Chineseization Project] - MTR Snapshot Versions Chineseization Project
## What was this project created for?
### The snapshot version of the MinecraftTransitRailway module has lost all language translations except English since version 3.0.0-beta8-UnofficialSnapshot3 because it does not support Crowdin translation.
### It has caused inconvenience for many module players, including a language barrier.
### This project was created to facilitate Chinese players.
### It will help Chinese players to play MTR more easily.
### Key members involved
### At the moment it's just Cmbself (the owner of this repository)!
### If you are interested, you can join in too!
### Suggestions for bugs?
### At the moment you can send an email to
<EMAIL_ADDRESS>### You can also add the author's QQ to give feedback!

repository: Cmbself/MTRSVCP

path: /English README.MD

filename: English README.MD

repo_name: Cmbself/MTRSVCP


text:
# kiss-ssg

Kiss Static Site Generator, is an open-source MVC html website builder (for node), that leverages handlebar templates to make quick, simple and blisteringly fast websites.

- Create a .hbs view
- Specify a data source (JSON object, JSON file on file system, or URL)
- Optionally map data from the model to the page options in the controller (option mapper)

In addition you can use reusable [handlebar partials](https://handlebarsjs.com/guide/partials.html#partials) (components) and [handlebar-layouts](https://www.npmjs.com/package/handlebars-layouts) (themes) to

Install with `npm install kiss-ssg`, or just drop [kiss-ssg.js](https://github.com/cprobert/kiss-ssg/blob/main/kiss-ssg.js) somewhere.

## Usage

kiss-ssg has 3 methods

- .page()
- .pages()
- .scan()

The simplest usage is to use .scan() to scan your 'pages directory' for \*.hbs files and outputs them to the 'build folder'.

```js
const Kiss = require('kiss-ssg')
const kiss = new Kiss() // accept default folder locations
kiss.scan()
```

Note: kiss will generate the default folders for you wnen you first run the script.

You can overwrite the folder locations bay passing a config to the kiss constructor. The config options are:

```js
{
  folders: {
    src: './src',
    assets: './src/assets',
    layouts: './src/layouts',
    pages: './src/pages',
    components: './src/components',
    models: './src/models',
    build: './public',
  }
}
```

### Assets

Any statif files you have in the assets directory will be copied to the build directory

### .page()

Instead (in in conjunction) of using the .scan() method you can pass a model to the view using the .page() method. This allows you to name the view and pass a model to that view. The model is then available in the handlebar template under the model property, e.g. {{model.name}}

```js
const Kiss = require('kiss-ssg')
const kiss = new Kiss({ dev: true }) // export model with .html
kiss.page({
  view: 'index.hbs',
  title: 'My Page Title',
  model: {
    name: 'Courtenay Probert',
  },
})
```

The config options that you can pass to .page() & pages() are:

```js
  {
    view: 'index.hbs',
    title: 'Page Title',
    path: '/',
    slug: 'index',
    model: {}
  }
```

These options are both used internally by kiss and are available in view.

- view = the name of the handlebars file relative to the pages folder
- title = The page title
- path = the folder path to the page
- slug = the name of the file without the extension
- model = a json object, the name of the json file relative to the models folder or a URL for an API endpoint

page and path create the url, i.e. /{path}/{slug}.html

_Note:_ If you don't pass a path or a slug they will be inferred from the view

### .pages()

In addition to passing page options you can also pass a option mapper to act as a controllers to the .page() and .pages() methods:

```js
const Kiss = require('kiss-ssg')

const kiss = new Kiss()
kiss.page(
  {
    title: 'My Team Page',
    view: 'about/index.hbs',
    model: 'departments.json',
  },
  ({ model }) => {
    return {
      model: model.sort(
        (a, b) => parseInt(a.sort_order) - parseInt(b.sort_order)
      ),
    }
  }
)
```

### Controller

The option mapper is really useful for mapping a slug from the model. This is great for dynamic slugs and a necessity when passing an array of models to the .pages() method to generate a series of pages.

```js
const Kiss = require('kiss-ssg')
const kiss = new Kiss({ test: '123' })

kiss
  .page({
    title: 'Page Title',
    view: 'index.hbs',
    },
  })
  .pages(
    {
      path: 'courses',
      view: 'course.hbs',
      model: 'https://{my-cool-api}/courses',
    },
    ({ model }) => {
      return {
        slug: model.slug,
      }
    }
  )
```

### Markdown

You can also parse markdown like this:

```handlebars
<div>
{{#markdown}}
# Heading

> this is markdown

foo bar baz
{{/markdown}}
</div>
```

If you want to take a peek at whats properties you have available to to in a handlebars file you can use this helper:

```handlebars
{{{stringify this}}}
```


text:
# Zedonk API

Simple wrapper to read a zedonk repository through its api.

You'll need to set your credentials before using it :
`ZedonkAPI\ZedonkAPI::setCredentials($url, $key, $user, $password)`

Each call will return an array of `\ZedonkAPI\ZedonkEntity` which has basic getters/setters

Filters must have the following form
```
[
    ['price > 100', 'and'],
    ["vat = 'true'", 'or'] //Note the extra quotes here
]
```

Change the default season name with `ZedonkAPI::setSeason($season)`

Available calls :
- `ZedonkAPI\ZedonkAPI::getProducts($filters = [])`
- `ZedonkAPI\ZedonkAPI::getCustomers($filters = [])`
- `ZedonkAPI\ZedonkAPI::getOrders($filters = [])`
- `ZedonkAPI\ZedonkAPI::getInventory($filters = [])`

Or you could call any report by its name :
`ZedonkAPI\ZedonkAPI::call('MyCustomReport', $filters = [])`

repository: ryssbowh/zedonk-api-php

repo_name: ryssbowh/zedonk-api-php


text:
## ML models predicting molecular properties
* Machine Learning methods to predict physicochemical properties of molecules, i.e., melting points and levels of permeabilities of chemical compounds through Caco 2 Cell line during initial ADME profiling.

* `QSAR/QSPR datasets` used for the predictions.
What is [QSAR/QSPR ?](https://en.wikipedia.org/wiki/Quantitative_structure%E2%80%93activity_relationship)

* ML algorithms used for general melting point predictions include Multiple Linear Regression, Lasso, cross-validated Lasso, Ridge, Ridge with Kernel, Classification and Regression Tree(CART), Random Forests, Stochastic Gradient Descent with different loss functions, Support Vector Machines and Artificial Neural Networks.

* ML algorithms used for classification problem comprises Classification and Regression Tree(CART), Random Forest Classifier, Support Vector Machines, i.e, Support Vector Classifier.

### Contents
* extra-o-matic: extract .tsv files from QSARdata R package (http://qsardata.r-forge.r-project.org/QSARdata/QSARdata_Package.html)

repository: BeckResearchLab/MPexplo

repo_name: BeckResearchLab/MPexplo


text:
---
title: Swallow
playwright: Stef Smith
period: Spring
season: In House
season_sort: 190
date_start: 2018-02-28
date_end: 2018-03-03
venue: New Theatre

cast:
- role: Anna
  name: Lucy Chandler
- role: Rebecca
  name: Emily Wightman
- role: Sam
  name: Charlotte Sanders

crew:
- role: Director
  name: Ted Marriott
- role: Producer
  name: Rosa Morgan
- role: Technical Director
  name: Laura Wolczyk
- role: Lighting Designer
  name: Ian Webster
- role: Sound Designer
  name: Adam Frankland
- role: Shadow Director
  name: Esther Butterworth
- role: Production Assistant
  name: Olivia Morel
- role: Poster Designer/Publicity Manager
  name: Sam Morris
- role: Set Designer
  name: Beth Wilson
- role: Video Designer
  name: Louis Djalili
- role: Technical Operator
  name: Ben Woodford
- role: Technical Operator
  name: Nathan
- role: Technical Operator
  name: Zoe Smith
- role: Technical Operator
  name: Miguel Barrulas
- role: Technical Operator
  name: Andrew Houghton
- role: Make-up Assistant
  name: Sandra Jareno Ripoll
- role: Stash Designer
  name: Jase Neal
- role: Extras
  name: David Levey
  note: Christopher
- role: Photographer
  name: Zoe Smith

assets:
  - type: poster
    image: X9rgrmM
  - type: poster
    image: C7QjcF4
  - type: poster
    image: 2DPSVR4
  - type: poster
    image: 7dWMfd6
  - type: trailer
    video: CGRCrZg
    title: Trailer
  - type: backstage
    video: MLJ6Nt2
    title: Behind The Scenes

prod_shots: Vt5gtd

links:
  - type: Review
    href: https://impactnottingham.com/2018/03/swallow-nnt/
    snapshot: 5q8xz
    publisher: Impact Nottingham
    author: Sophie Hunt
    title: "Swallow @ NNT"
    date: 2018-03-01
    rating: 8/10
    quote: "Swallow has a poignant and very relevant message about how we view mental health as a society and, as reflected in the title, how we tend to bottle up or ‘swallow’ our emotions rather than communicating them. For that reason, it is definitely worth seeing."
  - type: Review
    href: http://kevcastletheatrereviews.blogspot.co.uk/2018/03/swallow-by-stef-smith-new-theatre.html
    snapshot: OMuJ5
    publisher: Kev Castle Reviews
    title: "\"Swallow\" by Stef Smith"
    date: 2018-03-03
    quote: "It's a brilliant start to the new season, and from past experience over the last few years, I know that the rest of the season is going to be just as strong as their opening gambit, and I am so looking forward to it."

---

“Who said smashing things up was a bad thing? It’s actually quite liberating.” Three strangers’ lives are on the edge of self-destruction. Anna hasn’t left her flat for two years, refuses to eat solid food and is tearing up her apartment piece by piece. Rebecca has spiralled into a cycle of rage, despair, sadness and anger she cannot control in the wake of ending a long-term relationship. Sam is discovering his new identity in a world of violence and discrimination, that is preventing him from becoming his true authentic self. When these three strangers come into contact with each other, their lives are changed forever. Passionate, complex, furious and funny, Swallow promises to be an emotional and visceral experience. One that explores the difficulties of surviving in the modern world, exposes us to the darkest corners of our minds, but reinforces the power we have to overcome even our darkest and most vulnerable moments.

repository: newtheatre/history-project

gha_language: HTML

repo_name: newtheatre/history-project


text:
---
id: '2'
date: '2020-04-16'
title: 'Design Pattern Fundamentals'
category: 'Programming'
tags: ['design-patterns', 'Javascript']
banner: '/images/bg/design-patterns-fundamentals.jpg'
lang: 'en'
---

# Design Pattern Fundamentals

## What is a software design pattern?

Is a general, reusable solution to a commonly occurring problem within a given context. Also this solution mustn't be obvious and it has to be based on a proven concept. They are formalized best practices that a programmer can use to resolve common problems when is designing aplications or systems, also they have to consider that the solution in a design pattern must be independent of the programming language, meaning that a design pattern represents an idea, not a particular implementation. As they are good programming practices they allow us to create more flexible, reusable and maintainable code.

## Classification

There are three main types of design patterns:

---

### Creationals

They provide mechanisms to create objects based on a required criteria and in a controlled way.

#### Prototype

It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

This pattern is used to:

- avoid subclasses of an object creator.
- avoid the inherent cost of creating a new object in the standard way (e.g., using the `new` keyword) when it is prohibitively expensive for a given application.

> Prototype - Is an encapsulation of properties/methods that an object links to.

##### Example

Each new copy/instance of `Developer` object is pointing to the prototype that is only one object and is not going to be duplicated.

```javascript
const Developer = function(name) {
  this.name = name;
  this.skills = [];
};

Developer.prototype.addSkill = function(skill) {
  console.log(`adding skill: ${skill}`);
  this.skills.push(skill);
};

Developer.prototype.save = function() {
  console.log(`Saving developer info: ${this.name}`);
};

const developerOne = new Developer('Jon');
const developerTwo = new Developer('Doe');

developerOne.addSkill('design patterns');
developerOne.save();
developerTwo.save();

// console output
// adding skill: design patterns
// Saving developer info: Jon
// Saving developer info: Doe
```

#### Factory

Is used to simplify object creation, sometimes this could be complicated, either because of configuration or other factors, and this pattern is used to simplify that and hide a lot of this from the frontend. In other words, is used to create objects without exposing the creation logic to the client and the client use the same common interface to create a new type of object.

##### Example

The `projectRepository` is going to be very similar to `developerRepository`. This is an example in node.js where we create differents `repositories` objects using a `facotry` function.

```javascript
// developerRepository.js
const developerRepository = function() {
  function get(id) {
    console.log(`getting developer from DB, ${id}`);
    return {
      name: `developer from DB ${id}`,
    };
  }

  function save(developer) {
    console.log(`saving developer to DB ${developer.name}`);
  }

  return {
    get: get,
    save: save,
  };
};

module.exports = developerRepository();
```

```javascript
// repoFactory.js
const repoFactory = function() {
  let repos = this;
  const repoList = [
    { name: 'developer', source: './developerRepository' },
    { name: 'project', source: './projectRepository' },
  ];

  repoList.forEach(({ name, source }) => {
    repos[name] = require(source);
  });
};

module.exports = new repoFactory();
```

```javascript
//main.js
const repoFactory = require('./repoFactory');

const developerOne = repoFactory.developer.get(1));
const project = repoFactory.project.get(1);

developerOne.project = project;
console.log(developerOne);
```

#### Singleton

It restricts the instantiation of a class to one "single" instance. Used to restrict an object to one instance of that object across the application. This design pattern is based on remembering the instance and sending back that same instance every time you need it.

In node.js, modules are cached the first time they are loaded. [modules-caching](https://nodejs.org/api/modules.html#modules_caching). And so if you look at the `developerRepository` on the factory design pattern, what we are doing here is a singleton because we are calling the function and exporting the object returned from it.

```javascript
// developerRepository.js
const developerRepository = function() {
  ...

  return {
    get: get,
    save: save,
  };
};

module.exports = developerRepository();
// or
//module.exports = new developerRepository;
```

Therefore every time we require this module `const developerRepo = require('./developerRepository')` we are going to get the same object instance.

> To have a module execute code multiple times, export a function, and call that function.

If we don't want to have a singleton we should do something like the following

```javascript
//developerRepository.js
module.exports = developerRepository;

//main.js
const developerRepo = require('./developerRepository');
const myRepo = developerRepo();
```

---

### Structural

Concerned with how objects are made up and simplify relationships between objects. They deal with the relationship of objects in two ways, extending or simplifying functionality.

#### Decorator

Add behavior to an individual object, dynamically, without affecting the behavior of other objects from the same class. This design pattern is often useful for adhering to the -Single Responsability Principle-, as it allows functionality to be divided between classes with unique areas of concern.

> Used to add new functionality to an existing object, without being obtrusive.

##### Example

`FrontendDeveloper` is extending or adding new features over the `Developer` object, the good part of this is that `Developer` object is not being modified

```javascript
const Developer = function(name) {
  this.name = name;
  this.skills = [];
};

Developer.prototype.addSkill = function(skill) {
  console.log(`adding skill: ${skill}`);
  this.skills.push(skill);
};

Developer.prototype.save = function() {
  console.log(`Saving developer info: ${this.name}`);
};

// create new object extending developer object
const FrontendDeveloper = function(name) {
  Developer.call(this, name);
};

FrontendDeveloper.prototype = Object.create(Developer.prototype);
FrontendDeveloper.prototype.createUserInterface = function() {
  console.log(`${this.name} is creating a new user interface`);
};
FrontendDeveloper.prototype.save = function() {
  console.log(`Saving Frontend developer info: ${this.name}`);
};

const developer = new Developer('Jon');
const frontendDeveloper = new FrontendDeveloper('Doe');

developer.save();
frontendDeveloper.createUserInterface();
frontendDeveloper.save();

// console output
// Saving developer info: Jon
// Doe is creating a new user interface
// Saving Frontend developer info: Doe
```

#### Facade

Used to provide a simplified interface to a complicated system. Facade defines a higher-level interface that makes the subsystem easier to use, and also hides subsystem chaos from us.

> Think about the front of a builing

JQuery is probably the most well-known implementation of a Facade pattern. At its core, all JQuery does is sit on top of the DOM and give you a simple, clean interface to interacting with the DOM, instead of having to do all the nasting Javascript you have to do to change the name of a button or the class of something. So JQuery gives as a nice,clean, simple interface to deal with the DOM when we are trying to manipulate our web page.

### Behavioral

Concerned with the assignment of responsibilities between objects and how they communicate.

#### Observer pattern

The Observer Pattern defines a one to many dependency between objects so that one object changes state, all of its dependents are notified and updated automatically.

- One to many dependency is between Subject(One) and Observer(Many).
- There is dependency as Observers themselves don’t have access to data. They are dependent on Subject to provide them data.

> Allows a collection of objects(observers) to watch an object(subject) and be notified of changes

Advantages:
Provides a loosely coupled design between objects that interact. Loosely coupled objects are flexible with changing requirements. Here loose coupling means that the interacting objects should have less information about each other.

Observer pattern provides this loose coupling as:

- Subject only knows that observer implement Observer interface.Nothing more.
- There is no need to modify Subject to add or remove observers.
- We can reuse subject and observer classes independently of each other.

Disadvantages:

- Memory leaks caused by Lapsed listener problem because of explicit register and unregistering of observers.

> Consider using this pattern in your application when **multiple** objects are dependent on the state of **one** object as it provides a neat and well tested design for it.

## References

- [Wikipedia](https://en.wikipedia.org/wiki/Software_design_pattern)
- [Practical design patterns in JS - Pluralsight](https://app.pluralsight.com/library/courses/javascript-practical-design-patterns/table-of-contents)

repository: danicc/dae-blog

gha_language: TypeScript

repo_name: danicc/dae-blog


text:
# GitHub Trending (2022-02-04)

![](https://img.shields.io/badge/C%23-New%20171-green?style=flat-square&logo=appveyor)
- [microsoft/PowerToys](https://github.com/microsoft/PowerToys): Windows system utilities to maximize productivity

![](https://img.shields.io/badge/Clojure-New%2068-green?style=flat-square&logo=appveyor)
- [logseq/logseq](https://github.com/logseq/logseq): A privacy-first, open-source platform for knowledge management and collaboration. Desktop app download link: https://github.com/logseq/logseq/releases, roadmap: https://trello.com/b/8txSM12G/roadmap

![](https://img.shields.io/badge/Elixir-New%2079-green?style=flat-square&logo=appveyor)
- [fly-apps/live_beats](https://github.com/fly-apps/live_beats):

![](https://img.shields.io/badge/TypeScript-New%2060-green?style=flat-square&logo=appveyor)
- [certusone/wormhole](https://github.com/certusone/wormhole): Certus One's reference implementation for the Wormhole blockchain interoperability protocol.

![](https://img.shields.io/badge/none-New%20129-green?style=flat-square&logo=appveyor)
- [Universidade-Livre/ciencia-da-computacao](https://github.com/Universidade-Livre/ciencia-da-computacao): 🎓 Um caminho para a educação autodidata em Ciência da Computação!

![](https://img.shields.io/badge/C-New%2022-green?style=flat-square&logo=appveyor)
- [thefLink/RecycledGate](https://github.com/thefLink/RecycledGate): Hellsgate + Halosgate/Tartarosgate. Ensures that all systemcalls go through ntdll.dll

![](https://img.shields.io/badge/C%23-New%209-green?style=flat-square&logo=appveyor)
- [dotnet/csharplang](https://github.com/dotnet/csharplang): The official repo for the design of the C# programming language

![](https://img.shields.io/badge/Rust-New%20456-green?style=flat-square&logo=appveyor)
- [Kindelia/HVM](https://github.com/Kindelia/HVM): A massively parallel, optimal functional runtime in Rust

![](https://img.shields.io/badge/Shell-New%2017-green?style=flat-square&logo=appveyor)
- [cosmic-horizon/testnets](https://github.com/cosmic-horizon/testnets):

![](https://img.shields.io/badge/none-New%20263-green?style=flat-square&logo=appveyor)
- [jwasham/coding-interview-university](https://github.com/jwasham/coding-interview-university): A complete computer science study plan to become a software engineer.

![](https://img.shields.io/badge/none-New%2030-green?style=flat-square&logo=appveyor)
- [alex/what-happens-when](https://github.com/alex/what-happens-when): An attempt to answer the age old interview question "What happens when you type google.com into your browser and press enter?"

![](https://img.shields.io/badge/Java-New%20135-green?style=flat-square&logo=appveyor)
- [TeamNewPipe/NewPipe](https://github.com/TeamNewPipe/NewPipe): A libre lightweight streaming front-end for Android.

![](https://img.shields.io/badge/JavaScript-New%20232-green?style=flat-square&logo=appveyor)
- [Budibase/budibase](https://github.com/Budibase/budibase): Budibase is an open-source low-code platform for creating internal apps in minutes. Supports PostgreSQL, MySQL, MSSQL, MongoDB, Rest API, Docker, K8s 🚀

![](https://img.shields.io/badge/Rust-New%2033-green?style=flat-square&logo=appveyor)
- [AdRoll/rustenstein](https://github.com/AdRoll/rustenstein): Rustenstein 3D: Game programming like it's 1992

![](https://img.shields.io/badge/TypeScript-New%2072-green?style=flat-square&logo=appveyor)
- [BuilderIO/partytown](https://github.com/BuilderIO/partytown): Relocate resource intensive third-party scripts off of the main thread and into a web worker. 🎉

![](https://img.shields.io/badge/HTML-New%20111-green?style=flat-square&logo=appveyor)
- [leaningtech/webvm](https://github.com/leaningtech/webvm): Source code for the page webvm.io

![](https://img.shields.io/badge/Python-New%20309-green?style=flat-square&logo=appveyor)
- [ThioJoe/YT-Spammer-Purge](https://github.com/ThioJoe/YT-Spammer-Purge): Allows you easily scan for and delete scam comments using several methods.

![](https://img.shields.io/badge/Dart-New%2070-green?style=flat-square&logo=appveyor)
- [flutter/flutter](https://github.com/flutter/flutter): Flutter makes it easy and fast to build beautiful apps for mobile and beyond

![](https://img.shields.io/badge/Go-New%205-green?style=flat-square&logo=appveyor)
- [google/go-github](https://github.com/google/go-github): Go library for accessing the GitHub API

![](https://img.shields.io/badge/Python-New%2080-green?style=flat-square&logo=appveyor)
- [Chia-Network/chia-blockchain](https://github.com/Chia-Network/chia-blockchain): Chia blockchain python implementation (full node, farmer, harvester, timelord, and wallet)

![](https://img.shields.io/badge/TypeScript-New%20112-green?style=flat-square&logo=appveyor)
- [solana-labs/solana-pay](https://github.com/solana-labs/solana-pay): A new standard for decentralized payments.

![](https://img.shields.io/badge/TypeScript-New%2055-green?style=flat-square&logo=appveyor)
- [serverless-stack/serverless-stack](https://github.com/serverless-stack/serverless-stack): 💥 SST makes it easy to build serverless apps. Set breakpoints and test your functions locally. https://serverless-stack.com

![](https://img.shields.io/badge/none-New%207-green?style=flat-square&logo=appveyor)
- [NaturalSelectionLabs/RSS3-Protocol](https://github.com/NaturalSelectionLabs/RSS3-Protocol): RSS3 is a next-generation feed standard that aims to support efficient and decentralized information distribution.

![](https://img.shields.io/badge/C%2B%2B-New%2011-green?style=flat-square&logo=appveyor)
- [pybind/pybind11](https://github.com/pybind/pybind11): Seamless operability between C++11 and Python

![](https://img.shields.io/badge/Go-New%2011-green?style=flat-square&logo=appveyor)
- [hashicorp/vault](https://github.com/hashicorp/vault): A tool for secrets management, encryption as a service, and privileged access management

repository: Hsins/Daily-GitHub-Trending

repo_name: Hsins/Daily-GitHub-Trending


text:
# Field Mapping

## Document To Do

- [ ] Add images of old designs with markup referencing endpoints - @jas0nmjames
- [ ] Add images of new designs with endpoints mapped - @jas0nmjames

## Existing Application Design

### Dispatching

#### Container-Trip Card

- [ ] I couldn't find matching kanban and full cards in dev.  Will need to look at production. - @jas0nmjames

Navigate to https://dev-mercuriotransport.azurewebsites.net/DispatchingRoute/Driver or https://mscargoexpress.azurewebsites.net/DispatchingRoute/Driver

##### Kanban Card

Note: On 01/16/2020 Sergio enabled on DEV for us to see hidden locations (legs) in the trip card.

![kanban-card]

![kanban-card-2]

##### Full Card

Select a driver to view the full card:

![full-card]

#### Card Stops Shown

![card-stops-shown]

#### Card Stops Hidden

![card-stops-hidden]

## New Application Design

<!--- Image Links Reference -->

[kanban-card]: ./assets/dev-dispatching-kanban-card.png
[kanban-card-2]: ./assets/dev-dispatching-kanban-card-2.png
[full-card]: ./assets/dev-dispatching-full-card.png
[card-stops-shown]: ./assets/dev-dispatching-card-stops-shown.png
[card-stops-hidden]: ./assets/dev-dispatching-card-stops-hidden.png

repository: cross-team/draying-front-end

repo_name: cross-team/draying-front-end


text:
# Golang storage server
## API Endpoints
### Upload
Store file into service.
* URL `http://hostname:8080/upload`
* Content type `multipart/form-data`
* Method `POST`
* Data Params `files[]`
* Success Response `application/json`
    * Code: 201
    * Content:
    ````
    {
        "files": [
            {
                "fileName": "photo-1541727687969-ce40493cd847.jpeg",
                "uuid": "e9509777-3811-442c-9c7a-51c9f04f63eb"
            }
        ],
        "status": "ok"
    }
  ````
---
### Delete
Delete stored file
* URL `http://hostname:8080/:uuid`
* Method `DELETE`
* URL Params

  Required:

        uuid=[string]

* Success Response `application/json`
    * Code: 200
    * Content:
    ````
    {
      "status": "ok",
      "data": "e9509777-3811-442c-9c7a-51c9f04f63eb"
    }
    ````
---
### Get stored file
* URL `http://hostname:8080/:uuid`
* Method `GET`
* URL Params

  Required:

        uuid=[string]

* Success Response: `binary-data`
---
### Get resized Image
* URL `http://hostname:8080/:uuid/:profile`
* Method `GET`
* URL Params

  Required:

        uuid=[string]
        profile=[string]

* Available options of `profile`

        - small [500x500 px]
        - medium [1024x768 px]
        - thumbnail [164x164 px]

* Success Response: `binary-data`
___

repository: JoneDoe/media-server

repo_name: JoneDoe/media-server


text:
# Algebraic data type

https://en.wikipedia.org/wiki/Algebraic_data_type

In FP and type theory, an algebraic data type (ADT) is a compound type, formed by using type operations. These are analogous to the operations found in algebra (arithmetic) like addition, multiplication and exponentiation.

Two of the most common kinds of algebraic types are *products*, which correspond to multiplication, and *sums*, which correspond to addition (hence their names).

In Haskell, the `Pair` type is the canonical product type, while the canonical sum type is `Either`. Note that Haskell allows using the same name for the type ctor (`Pair`) and the data ctor (`Pair`) as they live in separate namespaces.

```hs
-- Pair type, A ⨉ B
data Pair a b = Pair a b

-- Either type, A + B
data Either a b = Left a | Right b
```

Both products and sums have a single type ctor with a unique name (in the type namespace), but their differ in the lhs of their declarations in that products always have a single data ctor, while sums may have any number of data ctors; that is, any number larger than 2 (because, mutatis mutandis, a sum with only one data ctor would be the same as a product).

```hs
-- concrete Pair type, Int ⨉ Bool
p1 :: Pair Int Bool
p1 = Pair 42 true

-- concrete Either type, Int + Bool
s1 :: Either Int Bool
s1 = Left Int

s2 :: Either Int Bool
s2 = Right Bool
```

Note: a single example value is sufficient to represent a product type such as the `Pair Int Bool`. To construct a new value of a product type, all the constituent types (that is, a value of each constituent type) must be supplied, and they must be supplied all at once.

both values, `s1` and `s2`, have identical types

*Product types* are more specific, they consists of a single data ctor that, optionally, groups together several constituent types, called the fields, under its name. For example, the `Pair` data type above has a single data ctor, also named `Pair`, which groups exactly two types together, represented by the type variables `a` and `b`. An example of a concrete product type is `Pair Int Bool`.

*Sum types* are more general, in fact, we say that **algebraic data types are, possibly recursive, sums of products**. Sums are also compound types that group together types under a single type (ctor), but not under a single data ctor. Unlike products which only have a single data ctor, sum types must have two data ctors minimum, while the maximum number is unbound.

Sum types are also called tagged disjoint unions.

that is, sum types have several (at least two) subgroups called *variants*, and each variant is actually a product type. Hence, a sum type itself is also a possibly recursive, sum of products.

A value of a variant type is usually created with a quasi-functional entity called a data (or value) constructor.
Each variant has its own constructor, which takes a specified number of arguments with specified types.
The set of all possible values of a sum type is the set-theoretic sum, i.e., the disjoint union, of the sets of all possible values of its variants.
Enumerated types are a special case of sum types in which the constructors take no arguments, as exactly one value is defined for each constructor.

Values of algebraic data types are scrutinized (analyzed, destructured, eliminated, consumed) using the technic of *pattern matching*.

which identifies a value by its constructor or field names and extracts the data it contains.

Algebraic data types were introduced in Hope, a small functional programming language developed in the 1970s at the University of Edinburgh.

license: Unlicense


text:
## Preparation
Typically, you should have the following items in an SMS project:

![SMS project](../../assets/mesh-sms-proj.png)

For a complex meshing project, it is imperative to keep different features in seperate maps.
Merging individual maps should be done as the last step.

The purpose of each SMS project component is as follows:

- Scatter Data:

    - station: Mark locations where mesh quality is important; at least make sure none of the observational stations is in land cells.

    - watershed resolution: Used for setting "scalar density paving" on some polygons, see details [here]().

- Map Data:

    - select\*: A map containing a polygon that intersects with all polygons where the "scalar density paving" attribute is needed, see details [here]().
                This is useful when the number of watershed polygons is too large to select manually.
                The polygon can be made in Qgis by first extracting the grid boundary then simplifying its geometry (otherwise the polygon is too complex for efficient selection of intersecting features).

    - lbnd: land boundary roughly along the 10-m contour, see [caveats of making the land boundary]().

    - \*levee\*: Levees from National Levee Database.

    - auto\*arcs: Automatically generated river arcs, which have been cleaned in Qgis (see details in [cleaning river arcs]()) .

    - coast: This map includes all manually made polygons (including quad patches) and the coastline.

    - ocean: This map includes everything beyond the coastline and in the ocean.

    - divide: A few manually drawn arcs that divide the coastal regions into subregions.
              This makes the mesh generation of complex maps more robust in SMS.
              This is also useful for locating SMS issues because you can mesh different subregions in seperate SMS sessions simultaneously, which speeds up the diagnosis of SMS exceptions (crashing or hanging) that may occur for a complex map, see details [below](#find-and-fix-sms-issues).

    - merge coverge: Merged map of all individual maps above.

- Gis Data:

    - World imagery and NWM segments: These provide a guidance on watershed and river topography, which helps avoid meshing errors during the desgin phase (e.g., when editing the [land boundary]())

!!! Attention
    Never edit the merged map directly, unless you are willing to take the time to exactly reproduce the changes in all individual maps (which is more time consuming in most cases, so don't do it).
    Unsyncing the merged map with the individual maps make it practically impossible for any significant changes in the future.
    The only case in which editing the merged map may be beneficial is when you work on a huge map (with tens of thousands of arcs) and cleaning the merged map takes much time (e.g. hours).
    In this case, make sure the changes are also reproduced in individual maps.

## Clean the merged map

Clean the merged map twice with the following parameters:

![Clean SMS map](../../assets/mesh-clean-map.png)

Two cleans are needed because the second clean will snap some of the newly created points during the first clean.

## Build polygons

![Build polygons](../../assets/mesh-build-polygons.png)

## Set watershed resolution
To avoid over-refinement, most watershed polygons should have a specified mesh resolution, which can be set via the "scalar paving density" option in each polygon's attributes.

Selecting the watershed polygons may involve much labor because many small polygons are generated after the river arcs are merged into the final map.
Instead of manual selection, use the ["select\*" map coverage](#select) to select all polygons more efficiently.

Activate the "select\*" coverage:

![Activate\_select](../../assets/mesh-activate-select.png)

Select the big polygon, right click on it, and click "Select intersecting objects":

![Intersect\_polygons](../../assets/mesh-intersect-polygons.png)

Intersect it with "merge coverage" with the following parameters:

![Intersect-parameters](../../assets/mesh-intersect-parameters.png)

It will take about 10 minutes to do the selection for the STOFS3D domain.
Right click on the selected polygons and set "mesh type" in "polygon attributes" to scalar paving density:

![Scalar paving](../../assets/mesh-scalar-paving.png)

Set scalar options using the [watershed_resolution](#watershed_resolution) scatter dataset from the [preparation](#preparation) step:

![Scalar options](../../assets/mesh-scalar-options.png)

In addition, set the polygon attribute of the "island" between Chesapeake Bay and Delaware Bay as "None":

![Polygon None](../../assets/mesh-none.png)

## Known SMS issues
There are some known issues in SMS that may hang or crash SMS:

- SMS may hang while generating mesh for a complex polygon.
Breaking the large polygon into smaller and simpler polygons can help fix the issue.

![intersect joints](../../assets/mesh-sms-hang.png)

- "Void in breakline" in some polygons. Slightly moving some vertices may fix the problem.

![intersect joints](../../assets/mesh-breakline-issue.png)

If SMS hangs, copy down the polygon ID (found in the lower-left corner) and restart the session.
 Note that occasionally the real problematic polygon may be the next one from 'ID'.

##Find and avoid SMS issues
We have reported the above issues to the SMS team.
Before these issues are officially fixed, you can use the following methods to find and avoid them before the final meshing.

Using STOFS3D Atlantic as an example, launch about 5 - 6 SMS sessions to mesh in sub-regions simultaneously.

Here you have two options.

### Option 1. More manual work but takes less time
Break the merged map into sub-maps along the [division lines](#divide).
Make sure there are no overlaps among the sub-maps except for the interface line:

![sub-map](../../assets/mesh-sub-map.png)

Mesh each sub-map in a seperate SMS session and fix issues when they occur using the methods discussed earlier.

Combine the sub-meshes using the following script in [SCHISM Git]():
```
/sciclone/data10/feiye/SCHISM_REPOSITORY/schism/src/Utility/Grid_Scripts/mergegrid5.f90
```

### Option 2. Less manual work but takes more time

In each session, select the polygons within a sub-domain and try to generate a sub-domain mesh.
Normally, there won't be any "hanging" issues, but there can be 5 - 8 "breakline" issues in total and SMS will prompt for the IDs of the problematic polygons.

Open another SMS session and fix all issues in the merged map.
Here, editing the merged map is unavoidable because the issues originates from the merging step.

Finally, generate the mesh for the full domain.
This takes about 3-5 hours, depending on how fast your desktop is.

## Relax crowded elements (at river intersections)
The automatic river map generation tool may lead to over-crowded points at river intersections if the thalwegs themselves are not cleanly seperated there.
This doesn't affect the stableness of the simulation, but it is recommended to remedy it by a "relax" operation in SMS.

![mesh-thalweg-relax-with-without](../../assets/mesh-thalweg-relax-with-without.png)

Import and activate the ["intersection joints"](generate-river-map.md#products) map coverage (which is one of the products from the [previous step](generate-river-map.md)):

![intersect joints](../../assets/mesh-intersection-joints.png)

Make a copy of the generated mesh and select the copy:

![mesh copy](../../assets/mesh-copy.png)

Press the select element button:

![](../../assets/mesh-select-element.png)

Select the elements within a specified distance of the intersecting coverage:

![](../../assets/mesh-select-by-coverage.png)

![](../../assets/mesh-select-coverage-tolerance.png)

Set relax options:

![](../../assets/mesh-relax-options.png)

![](../../assets/mesh-relax-options1.png)

Relax the selected elements:

![](../../assets/mesh-relax.png)

## Finalize the mesh
Delete the disjoint nodes:

![disjoint nodes](../../assets/mesh-disjoint-nodes.png)

Renumber nodes:

![renumber nodes](../../assets/mesh-renumber-nodes.png)

Save the mesh as \*.2dm:

![renumber nodes](../../assets/mesh-save.png)

Quality check using a script:
```bash
STOFS3D_scripts/Pre_processing/Grid/proc_hgrid.py
```
from the [STOFS3D scripts](https://github.com/feiye-vims/STOFS3D-scripts) repository
, which identifies small elements, skew elements, and bad quads,
then generate hgrid.\* in different projections.