text:
# Introduction

An **Analytics Module** or short **AModule** is a wrapper around
analytics code, e.g. a machine learning model, that provides a
standardized but flexible API for running and testing a model.

Below a simplified example of a module implementation (located in `module.py`):

```python
class MyCatDetector(Module):

    def __init__(self, *args):
        self.my_model = create_my_model()

    def process(self, image):
        Module.checktype(self, 'process', 'input', image)
        classid = self.my_model.predict(image)
        Module.checktype(self, 'process', 'output', classid)
        return classid
```

The wrapper class `MyCatDetector` is derived from the base class `Module` and
provides a constructor method `__init__()` that creates a machine learning
model, and a `process()` method to call the model for some input data.
`Module.checktype()` verifies that model inputs and outputs for the method
`process` are of the correct type, which are defined in `specification.py`.

Every `module.py` is accompanied by a `specification.py` file, that describes
inputs, outputs and other properties of the module. Below a specification
for the `MyCatDetector` module:

```json
SPEC = \
    {
        "methods": {
            "process": {
                "input": [
                    {
                        "name": "image",
                        "description": "RGB image of shape (h,w,3)",
                        "type": "ndarray/unit8///3"
                    },
                ],
                "output": [
                    {
                        "name": "label",
                        "description": "Predicted class index",
                        "type": "numeric/int",
                    },
                ],
            },
        },
        "module": {
            "author": "Stefan Maetschke",
            "description": "Detects cats in images",
            "name": "My cat detector",
        }
    }
```

The repo `analytics-module-template` contains a template and example code
that can be used as a starting point when wrapping your analytics code.
Most of the actual functionality of analytics modules is implemented in the
base repo [analytics-module](https://github.quuux.com/aur/analytics-module),
which need to be installed but not modified.

Another requirement is [mma-common](https://github.com/maet3608/mma-common),
which, needs be installed but again requires no modification.

# File overview

Here a quick overview of the important files and folders in the **template**:

**Code**

- `module.py` : Implements the API by wrapping code in a class with
   specific methods, e.g. `process()`.
   `module.py` typically also contains a main method that provides a
   commandline interface and a pre-defined function `test_module()` for
   regression testing.
- `specification.py` : Describes inputs, outputs and other properties of
   the module.
- `rest_service.py` : Runs a [Flask](http://flask.pocoo.org/) server to provide
   a REST service with an API that is automatically derived from
   `specification.py`. Usually there is no need to touch this code.

**Data**

- `resources` : Contains resources such a machine learning models,
   configuration files, or other data files needed to run the module.
- `testdata` : Contains test data for regression testing of the module.
   This data is also used as examples in the GUI provided by the REST service.

**Packages**

- `amod_template` : Contains all code and data needed by the module.
   Note: Will be renamed when instantiating the template (see below).
- `analytics` : Subpackage under `amod_template` that contains your
   analytics code.

**Other**

These files you usually don't need to touch.

- `setup.py` : Installs the module as Python package under `site-packages`.
- `MANIFEST.in` : Defines which data files are part of the package.
- `.travis.yaml` : Configuration for *Continuous Integration* via Travis.
- `.gitignore` : Tells Git which files to ignore.
- `.gitattributes` Tells Git which files need LFS (large file system).
   Typically these are model weights files greater than 100MB.

# Preparation

Using and implementing an analytics module requires the installation of two
base libraries, `analytics-module` and `mmacommon`. Clone the following repos

```bash
git clone https://github.com/maet3608/mma-common
git clone https://github.quuux.com/aur/analytics-module
```

and then run `setup.py` to install them

```bash
cd mma-common
python setup.py develop

cd ../analytics-module
python setup.py develop
```

# Create an Analytics Module

The following list summarizes the steps required to create an Analytics Module.
More detailed information regarding the implementation of `module.py`
and the required `specification.py` will be provided in the following sections.

1. Create empty git repo for your module, e.g. `my-cat-detector`
2. Download `analytics-module-template` and copy its contents into your repo,
   e.g. download as zip file using this link:
   [analytics-module-template.zip](https://github.com/maet3608/analytics-module-template/archive/main.zip)
3. Run `python setup.py init`
   This will rename `amod_template` to `amod_<working directory>`
   omitting dashes or spaces, e.g. `amod_mycatdetector`
4. Run `python setup.py develop`
   This will "install" the package under `site-packages`
5. Add your code under `analytics` folder
6. Add weights files under `resources` and test data under `testdata`
7. Implement `process` method in `module.py`
8. Edit `specification.py`

## Folder structure

After Step 1 the folder structure should look like this:

```bash
my-cat-detector
    amod_template
       analytics
       resources
       testdata
       module.py
       specification.py
       ...
    setup.py
    ...
```

After Step 2 the folder structure should look like as follows:

```bash
my-cat-detector
    amod_mycatdetector
       analytics
       resources
       testdata
       module.py
       specification.py
       ...
    setup.py
    ...
```

Note that the package `amod_template` has been renamed to `amod_mycatdetector`.
If you prefer a package name not based on the name of your repo directory run
`python setup.py init --name <packagename>`

## Notes

- Download `analytics-module-template` and NOT `analytics-module`!
- Ensure that `.travis.yaml` and other files starting with a '.' are copied
  since they are 'hidden' files.
- Replace the comments in `module.py` with your own descriptions.
- Replace this `README.md` with a description of your code.
- Remove the example code `bright_pixel_segmentation` and the test images.
- If your repo contains large data > 100MB (e.g. model weights) ensure you have
  [Git LFS](https://help.github.com/articles/installing-git-large-file-storage/#platform-linux)
  installed and activated for your shell.

# Module implementation

All Analytics Modules have a file `module.py` that provides the standarized API
for running your analytics code. This is achieved by implementing a class
derived from `Module` with a `process()` method. A minimal example
is shown below that assumes your code is located under the
`amod_mycatdetector.analytics` and provides the functions
`create_my_model` and `load_my_imagedata`:

```python
import sys
import module
from amodule.base import Module
from amodule.util import create_analytics
from amod_mycatdetector.analytics import create_my_model, load_my_imagedata

class MyDetector(Module):

    def __init__(self, *args):
        self.my_model = create_my_model()

    def process(self, image):
        Module.checktype(self, 'process', 'input', image)
        probs = self.my_model.predict(image)
        Module.checktype(self, 'process', 'output', probs)
        return probs

def test_module():  # don't change
    name = sys.modules[__name__]
    analytics = create_analytics(name)
    analytics.test()

def main_module(*argv):
    filepath = argv[1]
    image = load_my_imagedata(filepath)
    detector = MyDetector()
    probs = detector.process(image)
    print(probs)

if __name__ == "__main__":
    main_module(sys.argv)
```

Typically you create and/or load your model in the `__init__()` method and
call the model (e.g. for prediction) in the `process()` method.

The `process()` method can take any number and type of parameters,
however, its arguments must match the description in `specification.py`.
For instance, here an excerpt of a matching specification

```json
"process": {
    "input": [
        {
            "name": "image",
            "description": "RGB image of shape (h,w,3)",
            "type": "ndarray/uint8///3"
        },
    ],
    "output": [
        {
            "name": "probabilities",
            "description": "Predicted softmax probailities",
            "type": "[numeric/float]",
            "category": {
                "name": "classification",
                "labels": [ "Cat", "Other" ],
            }
        },
    ],
```

In this example the input is single image provided as an Numpy array
(type is `ndarray/uint8///3`) and the output is a float vector
(type is a list of floats `[numeric/float]`), containing the
softmax probabilites.
Within the body of the method `Module.checktype` is called to verify the
correct types of inputs and outputs when `process` is called.

Note that you can add additional methods with arbitrary names to the class
(or rename `process()`). If there is a corresponding description in
`specification.py` these methods will be exposed via the Rest API.

The `test_module()` function `module.py` is executed when `pytest module.py`
is called and performs a regression test by comparing the outputs of the
`process()` method with the expected outputs given in `specification.py`
and the  `testdata` folder. Usually there is no need to modify this function.

Typically, `module.py` implements a main function (here `main_module()`) that
allows to run the module from the command line with some parameters. There are
no restriction on what the main function does and it does not need to exist
at all but is very handy for debugging and the creation of test data.

## Specification

Here we describe the required specification in `specification.py` in more
detail. The specification is a Python dictionary with key/value pairs
(similar to a JSON file) that is structured as follows

- methods
  - process
    - inputs
    - outputs
    - testdata
- module

The *methods* section describes all methods of the wrapper class, e.g. the
`process` method. For each method, descriptions of the *inputs* and *outputs*
are required. *testdata* are optional.
The *module* section contains information such as version number, author
and other meta-data about the module.

### `module` section

The `module` specification value consists of a list of key/value pairs that
describe the module.  The keys are as follows:

* `name` - name of the module
* `description` - short description of the module's function
* `version` - version number, e.g. 1.0.0
* `author` - name of author
* `auther_email` - email address of author
* `url` - url of Github repository
* `dependencies` - list of Python packages that the module depends on.

Here an example:

```json
"module": {
    "author": "Stefan Maetschke",
    "author_email"<EMAIL_ADDRESS>    "description": "Segments bright pixels.",
    "name": "Bright Pixel Segmenter",
    "url": "https://github.quuux.com/aur/analytics-module-template.git",
    "version": "1.0.0",
    "dependencies": [ "Keras >= 2.0.3", "nutsml >= 1.0.28"]
}
```

### `methods` section

The `methods` section contains the names of the methods in the wrapper class,
e.g. `foo` and `bar`, with descriptions of their inputs and outputs, and
an optional section with test cases:

```json
"foo": {
    "input": [ ],
    "output": [ ],
    "test_cases": [ ],

"bar": {
    "input": [ ],
    "output": [ ],
```

Any method that is listed in the description and has a corresponding
implementation in the wrapper class will be exposed as a REST service.
For instance, the definition above will generate the following entry points
when running the REST server locally:

```
http://localhost:5000/api/run/foo
http://localhost:5000/api/run/bar
```

#### `input` and `output` sections

The `input` and `output` specification are positional lists that define the
respective input and output arguments for the methods. These lists can be
empty for methods without inputs or outputs. Otherwise they contain the
argument's `name`, `description` and `type`. For example a method that
takes an input image as Numpy array and returns an integer for the
predicted class label would be described as follows:

```json
"input": [
    {
        "name": "image",
        "description": "RGB image of shape (h,w,3)",
        "type": "ndarray/uint8///3"
    },
],
"output": [
    {
        "name": "label",
        "description": "Predicted class index",
        "type": "numeric/int",
    },
]
```

The `output` section can have an additional `category` section that provides
semantic information useful for displaying results. For instance, if the
output is the result of a classification and returns the label index, the
`category` section will have the name `classification` and contains a
list of string labels corresponding to the class label indices
(or softmax probailities):

```json
"output": [
    {
        "name": "label",
        "description": "Predicted class index",
        "type": "numeric/int",
         "category": {
            "name": "classification",
            "labels": ["Cat", "Other"],
        }
    },
]
```

The following category specification are supported:

* `classification` - whole image/input classification
* `segmentation` - pixelwise image segmentation
* `detection` - object detection in image, e.g. bounding box
* `measurement` - some measurement, e.g. detected object diameter
* `transformation` - some data transformation, e.g. image normalization

These categories can have additional parameters. Examples are given below:

```json
 "category": {
    "name": "classification",
    "labels": ["label1", "label2", "..."],
}
```

```json
 "category": {
    "name": "segmentation",
    "labels": ["label1", "label2", "..."],
}
```

```json
 "category": {
    "name": "detection",
    "labels": ["label1", "label2", "..."],
}
```

```json
 "category": {
    "name": "measurement",
    "unit": "meter",
}
```

As for the input and output types: Technical details can be found in
`analytics-module/aurmodule/iotypes.py`. Here some common types:

```
'numeric' : any numeric value, e.g. 1, or 0.5 (int or float)
'numeric/int' : any integer value
'numeric/float' : any floating point value

'text/str' : any string

'ndarray/uint16//' : Numpy array used for gray scale images
'ndarray/uint16///3' : Numpy array used for RGB images
'ndarray/image' : Numpy array used for RGB, RGBA or grayscale images.
```

As you can see, IO types are defined by strings with a syntax similar to
mime types. The basic format of an IO type is:
```
'main-type/sub-type/params...'
```
where `sub-type` and `params` are optional. A simple example for an
integer type:
```
'numeric/int'
```
Similarly, there are types for floats, strings and booleans:
```
'numeric/float'
'text/str'
'boolean/bool'
```

Note that the subtype can be omitted:
```
'numeric'
'text'
'boolean'
```
where `'numeric'` permits floats or integers.

Numpy arrays can be specified in detail regarding dtype and shape,
using the following format:
```
'ndarray/dtype/#rows/#cols/...'
```

Here some examples:
```
'ndarray/uint8'      : ndarray with dtype uint8 but any shape
'ndarray/uint16//'   : ndarray with dtype uint16 and two dimensions
                       of arbitrary size
'ndarray/uint8/5/10' : ndarray with dtype uint8 and of shape (5,10)
'ndarray/uint8///3'  : ndarray with dtype uint8 and of shape (*,*,3)
'ndarray/image'      : ndarray with uint8 of shape (h,w) or (h,w,3)
                       or (h,w,4)
```
Note that shape parameters are separated by `/` but can be ommitted by leaving
the parameter value out. For instance, `'ndarray/uint8/5/10'` specifies a
Numpy array with shape `(5,10)`, while `'ndarray/uint8/5/'` specifies an
array with 5 rows but an arbitrary number of columns. Numpy representations of
RGB images that are of shape `(*,*,3)` are therefore specified as
`'ndarray/uint8///3'`

Finally there is the type 'annotation' (currently no subtype) that validates
the following data structures:

```
('point', ((x, y), ... ))
('circle', ((x, y, r), ...))
('ellipse', ((x, y, rx, ry, rot), ...))
('rect', ((x, y, w, h), ...))
('polyline', (((x, y), (x, y), ...), ...))
```

All the types listed above can be made list types, simply be wrapping them
in rectangular brackets (`[type]`). For instance,
`'[numeric/int]'` describes a list of integers and `'[ndarray/uint8//]'`
would be a list of 2-dimensional ndarrays with dtype uint8. Here some common
list types:

```
'[numeric/float]'      : list of floats, e.g. class probabilities.
'[test/str]'           : list of strings, e.g. class labels.
'[ndarray/uint16//]'   : list of gray scale images
'[ndarray/uint8///3]'  : list of RGB images
'[ndarray/image]'      : list of RGB, RBGA or grayscale images
```

#### `test_cases` section

Test cases describe input data and expected outputs for a method. These
test cases will be evaluated when building the module and can be run via

```bash
pytest module.py
```

The `test_cases` value is an array of a positional list of terms that
provide each of the input and expected output values for the method.
For input or output files, the value can be the filename relative to the
`testdata` directory in the module directory structure. In the following
an example for the bright pixel segmentation provided in the template:

```json
"methods": {
	"process": {
		"input": [
			{
				"name": "image",
				"description": "RGB image of shape (h,w,3)",
				"type": "ndarray/uint8///3"
			},
			{
				"name": "threshold",
				"description": "Threshold for bright pixels",
				"type": "numeric/int"
			},
		],
		"output": [
			{
				"name": "mask",
				"description": "Segmentation mask of shape (h,w)",
				"type": "ndarray/uint8//",
				"category": {
				    "name": "segmentation",
				    "labels": [ "background", "foreground" ],
				}
			},
			{
				"name": "#bright_pixels",
				"description": "Number of bright pixels",
				"type": "numeric/int",
				"category": {
				    "name": "measurement",
				    "unit": "count"
				}
			}
		],
		"test_cases": [
			["image.png", 130, "mask_130.png", 8865],
			["image.png", 150, "mask_150.png", 3593],
			["image.png", 0, "mask_0.png", 108204],
			["image.png", 255, "mask_255.png", 0],
		]
	},
},
```

Here input data are image files and thresholds and outputs are mask images
and numbers of segmented pixels.

## Installation

If you want to install your Analytics Module run either

```bash
python setup.py develop
```

or

```bash
python setup.py install
```

The former has the advantages that any changes to your code will be 'active'
immediately while the later requires you to rerun `setup.py install` if you
want the Python environment let know about the changes.

# REST API

Each analytics module supports a REST API and several web applications - one to
run a demo and another to execute the analytics module test cases.

To start the REST API and web application on localhost using the
default port (5000) run:

```bash
python rest_service.py
```

from the `amod_<module name>` directory

Once the analytics module is installed you can start the REST API by running:

```bash
python -m amod_<module name>.rest_service
```

For details of other command line options (host and port settings) run:

```bash
python rest_service.py --help
```

Once the REST API is running, open your browser and enter
`http://localhost:5000/api` to show the available REST calls. For instance,
the `analytics-module-template` exposes the following example REST API:

```JSON
{
    "name": "Bright Pixel Segmenter",
    "api_version": "1.2.0",
    "specification_url": "http://<IP_ADDRESS>:5000/api/spec",
    "run_url": "http://<IP_ADDRESS>:5000/api/run{/method}",
    "debug_url": "http://<IP_ADDRESS>:5000/api/debug",
    "test_url": "http://<IP_ADDRESS>:5000/api/test",
    "cache_url": "http://<IP_ADDRESS>:5000/api/cache"
}
```

- If you append `/spec` to the initial URL you will see the analytics
   specification which defines the REST API - method name, inputs and outputs.

- If you append `/test` to the initial URL you will access the test web application.
  This allows you to run and see the results of the analytics test cases.
  These tests are defined in the analytics package but they should give a view
  of the types of inputs and outputs from the analytics and their capabilities.

- If you append `/debug` to the initial URL you will access the
   debug web application.  This allows you to provide your own data to the
   analytics for processing. If you run within a docker container and
   would like to upload a file  you need to use the `docker cp` command
   to first copy data from disk into the container.  Note that such data is not
   persistent when the container  is shutdown and restarted.

- If you append `/run` to the initial URL you will see an example of how
  to call the analytics programmatically via the REST API, e.g.
  `"http://<IP_ADDRESS>:5000/api/run/process?image=ndarray/uint8///3&threshold=numeric/int"`

Per default, the REST API is single threaded and therefore handles only one
request at a time. Adding the `--threaded` argument allows you to run
the server multi-threaded:

```bash
python rest_service.py --threaded
```

Note that this is not sufficient for a production server. See
[Flask deployment](http://flask.pocoo.org/docs/0.12/deploying/#deployment)
on how to scale for production.

## Sending images and Numpy arrays

The Specification describes the IO types for the Python API of an Analytics
Module. Apart from primitive types such as strings or integers most types
cannot be transported directly via REST calls and need to be encoded or
converted - specifically Numpy arrays.

The Analytics Module therefore provides a range of converter functions that
map common Web data types such as image files, or data URLs to Numpy arrays. For
instance, if the REST API request the following Numpy array
 `/api/run/process?image=ndarray/uint8///3`, which describes an RGB image,
it can be provided as an HTTP URL, a file URL, or data URL. Here some examples:
```
/api/run/process?image=https://www.quuux.com/image.jpg
/api/run/process?image=file:///your/file/image.png
/api/run/process?image=data:image/gif;base64,/9j/4SXNR...
```

The format of the input image can be anything the Python PIL package
supports, which covers most common formats such as JPEG, PNG, TIFF and BMP,
but not DICOM images!

If the answer to a REST API call results in an image or a Numpy array,
it will be returned as a data URL.
Numpy arrays of shape (h,w), (h,w,3) and (h,w,4) with data type `uint8`
can be interpreted as images (grayscale, RGB, RBGA) and will be encoded
as PNG image in a data URL with the following header: `data:image/png;base64,...`

Input Numpy arrays that cannot be interpreted as images, e.g. vectors, 4D scans
or others can be send as files (`.npy` or `.npz`), URLs or data URLs.
In the case of data URLs they must be send as base64 encoded `.npy` or `.npz`
files with the appropriate header (`data:ndarray/npz;base64,`).
Some examples:

```
/api/run/process?oct=data:ndarray/npy;base64,/9j/4SXNR...
/api/run/process?oct=data:ndarray/npz;base64,JHIHUFD...
/api/run/process?oct=https://www.quuux.com/oct.npy
/api/run/process?oct=https://www.quuux.com/oct.npz
/api/run/process?oct=file:///your/file/oct.npy
/api/run/process?oct=file:///your/file/oct.npz
```

Finally, lists of all types described above are supported and are simply
send as comma separated values, e.g. a list of floating point values required
by `/api/run/process?probs=[numeric/float]`, would be provided as
```
/api/run/process?probs=0.2,0.7,0.1
```

This works the same for images or Numpy arrays, e.g. given the following
specification `/api/run/process?images=[ndarray/uint8//]` for a list of
grayscale images, the data could be provide as URLs
```
/api/run/process?images=https://www.quuux.com/image1.jpg,file:///folder/image2.png,...
```
or comma separated data URLs
```
/api/run/process?images=data:image/gif;base64,/9j/4SXNR,data:image/png;base64,/9j/4SXNR,...
```

## curl - examples

Here some example calls for the REST API using `curl`

### Example - specification

Request the Specification

GET:

`curl "http://<IP_ADDRESS>:5000/api/spec"`

### Example - method description

Request description of all methods that can be run.

GET:

`curl "http://<IP_ADDRESS>:5000/api/run"`

### Example - list of numbers

A list of numbers as integers and a single integer as threshold.

API:

`api/run/process?numbers=[numeric/int]&threshold=numeric/int`

GET:

`curl "http://<IP_ADDRESS>:5000/api/run/process?numbers=3,4,5&threshold=2"`

POST:

`curl --data "numbers=3,4,5&threshold=2"  http://<IP_ADDRESS>:5000/api/run/process`

POST JSON:

`curl --header "Content-Type: application/json" --request POST --data '{"numbers":[3,4],"threshold":2}' http://<IP_ADDRESS>:5000/api/run/process
`

NOTE: Windows requires double quotes around string and escaped quotes in string!

`curl --header "Content-Type: application/json" --request POST --data "{\"numbers\":[3,4],\"threshold\":2}" http://<IP_ADDRESS>:5000/api/run/process
`

### Example - single image

Single 2-dimensional numpy array with a data type `uint8` that can be
interpreted as an image.


text:
---

layout: pattern-detail
group: user-interface
subgroup: meta
permalink: /user-interface/meta/meta-logos

title: Logos
id: 00-meta-20-assets-logos
plid: meta-logos
description:
status:

meta:
- updated: April 2, 2019

---

## Getting Started

These are the official logos used by Emory Libraries

###### EXPORT VIA GRUNT

```
grunt export:meta-logos
```

### Description

Our logo library consists of the official university and unit brand marks used across library sites and applications. Use this logo library as a guide when building patterns that incorporate logos.

### Best Practices

To use our logos, refer to our [`tokens-logo`][tokens-logo] pattern.

## Schema

To use our logos, refer to our [`tokens-logo`][tokens-logo] pattern.

[tokens-logo]: /patterns/10-tokens-10-globals-logo/10-tokens-10-globals-logo.html

license: MIT

repository: emory-libraries/style-guide-guide

branch_name: refs/heads/master

extension: md

gha_language: HTML

gha_license_id: MIT

license_type: permissive

repo_name: emory-libraries/style-guide-guide


text:
# Machine Learning

CTP implements a number of machine learning algorithms that can be used in different ways.

## Getting Started

General procedure:
  - create a dataset or run an RL algorithm
  - fit a model
  - test

### Creating a Dataset

We need some data to work with. Let's start by making a small data set using both joint data and RGB images.

```
rosrun costar_bullet start --robot ur5 --task blocks --agent task \
  --features multi --save -i 10 --data_file small.npz --seed 1
```

When we want to create a bigger data set, we can do so easily with:
```
rosrun costar_bullet start --robot ur5 --task blocks --agent task \
  --features multi --save -i 100 --data_file big.npz --seed 1
```

This second one will include 100 trials of the robot picking and placing random blocks, as per the "blocks" task.

So, what do these arguments mean?
  - `save` tells us we should save a dataset
  - `--features multi` says we should use both camera input, arm joint state, and gripper state
  - `--robot ur5` says we should use the UR5 with 2-finger robotiq gripper
  - `--task blocks` says we are interested in performing the blocks task
  - `--agent task` says we want an "expert" task model to generate data rather than a human or RL algorithm
  - `-i 10` says we want to run for 10 iterations, i.e. on 10 different random environments
  - `--seed 1` tells us to initialize the `numpy` random number generator at each iteration, in order to generate a consistent set of examples. Randomizer is initialized to `(seed+iteration_num)` before environment setup.
  - `--no_ssm` disable spatial softmax algorithm in the model
      - the network performs similarly when enabling and disabling spatial softmax, with a very small quantitative difference on a pixel-to-pixel level and very little qualitative difference.

 Examples of preconfigured training commands can be found in [costar_plan/commands](https://github.com/cpaxton/costar_plan/tree/master/commands).

### Learning a Policy with Behavioral Cloning

The most straightforward approach we can take to getting a robot that will act on our environment is behavioral cloning. As long as we have a Task Agent that can generate decent policies, this is a reasonable starting point.

To fit such a model, run:
```
rosrun costar_bullet start --robot ur5 --agent null --features multi --load \
  --model ff_regression --si 5 -i 1000  --batch_size 64 --data_file big.npz
```

To try it out, run:
```
rosrun costar_bullet start --robot ur5 --task blocks --agent ff \
  --features multi -i 1000 --model ff_regression --gui
```

We need to separately define the specific architector (`ff_regression`) and the agent to execute (`ff`).

### Learning a Convolutional Autoencoder

This is a simple approach; we're going to directly fit an input to an output image.
```
rosrun costar_bullet start --robot ur5 --agent null --features multi --load \
  --model autoencoder --data_file small.npz --si 5 -i 1000  --batch_size 64
```

![Autoencoder Example](autoencoder_example.png)

Above is an example of what this might look like after about 300 iterations. That's not very long, but we can still clearly see the robot's shape, and the net is starting to learn about block color.

### Dev section

```
rosrun costar_bullet start --robot ur5 --agent null --features multi --load --model unsupervised --data_file big.npz --si 5 -i 1000  --batch_size 64
```

### Learning a Generative Adversarial Network

GANs are a popular approach these days, and luckily it's pretty easy to train one with CTP:
```
rosrun costar_bullet start --robot ur5 --agent null --features multi --load \
  --model gan --data_file small.npz --si 5 -i 1000  --batch_size 64 \
  --optimizer nadam --lr 0.001
```

This will load our small data set and run for 1000 iterationsm using the ADAM optimizer with Nesterov momentum. Go ahead and play with the settings.

## References

### Libraries Referenced

These are software libraries that might be worth a look.

**[For developers]** Libraries referenced, but not needed as prerequisites:
  - [Tensorflow-Reinforce](https://github.com/yukezhu/tensorflow-reinforce)
  - [Guided Policy Search](https://github.com/cbfinn/gps) - `traj_opt` directly included
  - [KeRLym](https://github.com/osh/kerlym) - referenced during `Trainer` implementation

### Papers

TODO


text:
This is a prototype gui mockup of an event sheet concept I made for
https://github.com/godotengine/godot/issues/17795
Please note that in no way is this usable at the moment-it just a quickly bashed together gui mockup for another thing that would hopefuly emerge from it - rewritten in c++.

So here it goes:

We currently have a visual scripting system similar to blueprints in Unreal - connecting nodes.
The proposal here is for a second visual scripting system, that is similar to event sheets in Construct 2 (proprietary), Multimedia fusion (proprietary) and Gdevelop (open source)
![11](https://user-images.githubusercontent.com/6495061/37964468-81886d54-31b9-11e8-9ba5-555123ad1fc7.jpg)

It is a very different approach from the one with blueprints and people learning to program are still requesting it on facebook and other godot community forums

What is an event sheet visual script in the other engines:
https://www.scirra.com/manual/44/event-sheet-view
The event sheet is pretty much a spreadsheet with two columns - a conditions column and an actions column. Both columns can be populated with logic blocks from nodes and their children that the sheet is attached to (node methods). On the left column the user can only attach conditional methods, on the right - only action methods. This clear divide makes for a very easy to learn way of setting game logic.
On top of that the user can use expressions in both columns - so potentially use gdscript for more specific instructions.

Rows can be nested under other rows (called sub-events), can be commented, disabled or re-enabled (just like commenting code)
https://www.scirra.com/manual/128/sub-events
![subeventexample](https://user-images.githubusercontent.com/6495061/37964565-da595506-31b9-11e8-8d9c-03f7f1944307.png)
Some actions/condition blocks can be negated

Functions that can take parameters can be used as well, by using a special function condition block and nesting conditions/actions under its row
![image28](https://user-images.githubusercontent.com/6495061/37964431-5b118958-31b9-11e8-9a81-2a56ac99c88a.png)
![modifiedcheckmatches](https://user-images.githubusercontent.com/6495061/37964409-4a2fafa2-31b9-11e8-8fee-ac374bb4996a.png)

So What are the advantages over our current visual script:
- It is an alternative style of visual scripting with a big following - a quick look at the number of users of construct 2 and the number of succesful 2d games made with clickteam fusion should be a good enough indicator. It has also been requested on Unity forums too
https://feedback.unity3d.com/suggestions/create-a-visual-scripting-for-begginer-like-construct-2-or-behavior-machine
https://feedback.unity3d.com/suggestions/visual-scripting-based-in-event-sheets-as-construct-2

- It is easier to learn and arguably clearer for non-programmers
- An event sheet can pack much more information of the game logic on one screen than blueprints - less scrolling and panning to get the information. Less wasted empty space between logic blocks. You can technically just take a screenshot of an event sheet and share it to show someone else how to do something.
![6708 image_2e2b4e43](https://user-images.githubusercontent.com/6495061/37964332-fc3ed1a6-31b8-11e8-82d8-835ea0c2ce00.png)

- It is easier to transition learning from event sheets to scripting - because it's more similar to scripting    than blueprints

- Why is it easier to learn than blueprints - the clear divide of condition and action and obvious order of execution. The user gets a filtered list of things to do on the two columns.

- Logic blocks are easy to quickly read/find because they have icons. Most nodes in godot also have icons - they can be reused for the event sheet implementation

- Less clicks needed to get things working - no need to connect nodes or move nodes on the blueprint table.  You just add or drop logic blocks in the cells. No need to pan at all- you only scroll and its much less.

In any case, I am writing this proposal not to say that one system is better than the other - but more with the hope of sparking interest in developing an alternative to our custom visual scripting approach - an alternative that is popular amongst people learning to code and that is a great transition to gdscript - as I found out from first hand experience

**Addon progress report 0**

Here is a crude mockup so far:
![capture](https://user-images.githubusercontent.com/6495061/38088809-13d17092-3355-11e8-89b3-563b2015686b.PNG)

Demos of event sheet style systems that you can try online(no log in required):
https://editor.gdevelop-app.com/
https://editor.construct.net/

Event Sheet System Possible Structure:
```
|_Event sheet established variables and connections tab
|_Event sheet script tab
  |_Function(built in or custom)
      |_event sheet row (can be parented to another event sheet row or an event sheet group)
          |_Actions column
               |_Action cell (richtex label) (click to open another window to edit)
          |_ Conditions Column
               |_Condition Cell (richtex label)(click to open another window to edit)
|_Action/Condition Cell Expression Editor
  |_Gdscript editor instance - to be used for expressions
  |_Easy Click interface to access the available subnodes - their nodepaths and methods- clicks bring up menu that populates the expression editor - similar to Clickteam Fusion's
```

Inner workflow:
Event sheet resource can be attached to node -->on runtime it generates a gdscript and that is used by the game

**Addon progress report 1**

I did some work on the addon's most important building block- the event sheet cell

![es-adding](https://user-images.githubusercontent.com/6495061/39065812-e6bc306a-44ca-11e8-9053-c64369d95aee.gif)

Some background in what it does - Basically the event sheet is made out of cells. A cell can contain either conditions (getters/expressions) or actions (setters that can be fed with getters/expressions).
On the GUI side, the event cell is created via a richtextlabel node and bbcode that is generated from gdscript. When you double click on it, the richtextlabel turns into an editbox node containing the actual gdscript expression.

So an event sheet cell has 2 modes:
- edit mode - textEdit node that can be typed into with gdscript.
The only difference is that the user does not need to type in If/else/while - that is context sensitive to the parent container as seen in the screenshot. Every line is a new condition, so if the user hasnt started the line with "or" or somethind else, the parser automatically knows that a new line has "and" pretext

When clicked away, switches to view mode.
- view mode - richtext label - When switching to view mode, a bbCode gets parsed from the gdscript that is in edit mode and presented via an interactive richtext label. Apart of being interactive and easy to change , the goal is to present the gdscript code in a clearer way. This means showing the node's name and icon only (not the entire path) and getting rid of some words, when its obvious (such as get_ and set_). Since every clickable part is actually a url tag, when hovering over a node name for example - the user can get some information, such as the full path of the node.

About the Add new condition/Action menu:
This is what creates a new gdscript line of code for a condition or an action. Whats great about it is that it lets you easily browse all of the nodes inside a scene and their methods - it sort of works in an inverted way to how autocompletion works in gdscript's editor. It shows all nodes and all of their setter, getter or both methods. You can then narrow down to what you want via a filter.
If callend from a condition cell, this menu shows only getters, if called from an actions cell, it shows both setter and getter methods.

Note that this is still full of bugs and not even half complete to share, but hopefully makes it clearer what I am proposing

**Progress report 2**
Made some planning on how it can work. Also looked into what needs to be refactored before presenting the concept addon

I made this flowchart to explain how it works at the moment
https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml
![eventsheetmockupplan](https://user-images.githubusercontent.com/6495061/40834668-5c1f4e58-6589-11e8-8e53-ee90d8c36e78.PNG)
Decided to refactor it to generate typed gdscript
 #19264
Its much easier to create bbcode links for further helper menus when its typed

repository: Norrox/Godot-eventSheetPrototype

repo_name: Norrox/Godot-eventSheetPrototype


text:
# Unissu Scraper
The project scrapes the details of PropTech companies listed in the Unissu(.com).

### About project

  - Thread and proxy management (100 proxies)
  - Used `requests` HTTP library
  - `json` response parsing

### Usage

The code uses 100 proxies. Create a Proxies.csv, copy and paste your proxies
in the form:

`http://username:password@proxy.yourorg.com:80`

Put your proxies into Proxies.csv file, also make changes in the code.

```python
    # "http://username:password@proxy.yourorg.com:80"
    proxies = {
        "http": f"http://username:password@{appointed_proxy}",
        "https": f"http://username:password@{appointed_proxy}"
    }
```

Also, you need to change `max_num_worker_threads` to number of proxies
you put in the `Proxies.csv` file.

The code writes data to csv file, to get the xls file I imported
the csv file into the MS Office Excel and saved as xls file.

`Data -> From Text/CSV -> Choose comma -> Save as .xls`

### Installation

Create your environment and run these commands:

```sh
$ .\venv\Scripts\activate
$ pip install requirements
$ python main.py
```

### Development

If you want to contribute to the project don't forget to add docstrings
and use `pip freeze > requirements.txt`

### License
This repository is licensed under the MIT License. Please see the
 [LICENSE](https://github.com/nurettinabaci/UnissuScraper/blob/master/LICENSE)
 file for more details.

repository: nurettn/UnissuScraper

repo_name: nurettn/UnissuScraper


text:
---
sidebar_position: 1
---

# Logging In

## Externally
For users outside the University Network, we access the clusters via the `krafla` front-facing node:

```bash
uglaUser="rog68"
ssh<EMAIL_ADDRESS># Now on the network
ssh elja.hi.is # or garpur or jotunn
```

Congratulations on getting to login node!

:::caution

**Do nothing** without reading the [common etiquette section](common/etiquette).

:::

branch_name: refs/heads/main


text:
## Changelog
### Version 2.0.0
#### Added
- Added PHP8.0 typed class,
- Added constructor to main `HunspellPHP` class where the `$dictionary`, `$encoding` and `$dictionary_path` cal be set/overridden during initialization.
- Added `$dictionary_path` as a new argument were the dictionary files path may be specified (system default search locations are used otherwise). Additional `get()` and `set()`methods added.
- Added functionality to `findCommand` method via new `(bool)$stem_mode` argument.
#### Removed
- Removed `findStemCommand` method.
- Removed unused exception classes.
- Removed `HunspellPHP\Exceptions` namespace.
- Removed composer.lock from repo.
#### Fixed
- Renamed `$language` more appropriately `$dictionary` since that is what that property is referencing.
- Moved HunspellMatchTypeException up one directory to \HunspellPHP namespace.
- Fixed an issue where not all `$match` values were returned from the command response resulting in PHP warnings.
- Fixed a missing type `-` extraction from the matcher regex which resulted in PHP warnings and bad responses.

repository: BelniakMedia/HunspellPHP

repo_name: BelniakMedia/HunspellPHP


text:
# Agoseris glauca var. laciniata (D.C.Eaton) Smiley VARIETY

#### Status
SYNONYM

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

#### Published in
Revis. gen. pl. 1:304. 1891

#### Original name
null

### Remarks
null

repository: mdoering/backbone

path: /life/Plantae/Magnoliophyta/Magnoliopsida/Asterales/Asteraceae/Agoseris/Agoseris parviflora/ Syn. Agoseris glauca laciniata/README.md

repo_name: mdoering/backbone


text:
Re-Rendering
============

In most cases the correct approach to update the UI from the client side with server side
data is to raise events, receive response data and then parse the data and perform
DOM manipulation. This is a very fast and efficient process as only a small amount of
JSON formatted data is being pushed over the XHR connection.

However in some cases this approach would lead to complete duplication of HTML creation
code in both server side PHP and client side Javascript. A pragmatic option is to
force a 're-render' of the View with the updated HTML being pushed from server
to client. It is slightly slower as a lot of redundant HTML characters are being
transmitted.

For example in the Basket of a shopping site there might be considerable work in
presenting the HTML. Updating the basket quantities may require many different
items to be updated in ways that would need codified in the Javascript if it were
just to receive data back from the update request. This is a good candidate for
using the re-rendering technique

## reRender()

All leaves have a reRender() method. When called during a normal non XHR request
it has no effect at all. During an XHR request (e.g. as a consequence of
`raiseServerEvent()`) however it causes that Leaf's view to be rendered into
HTML again and the output string to be sent to the client.

```php
class BasketView extends View
{
    protected function createSubLeaves()
    {
        $this->registerSubLeaf(
            new Button("updateBasket", function() {
                // Bubble the event up to the Leaf to do some heavy work.
                $this->updateBasketEvent->raise();
                // Now single a rerender so the basket is redrawn:
                $this->reRender();
            }, true );  // true to switch button event to XHR mode
        );
    }
}
```

## View Bridge reconnection

After a re-render the HTML of the view is replaced with the incoming HTML provided by the server.
This results in brand new DOM elements being created to replace the original ones. The View Bridge
base class handles reconnecting the View Bridge object to the new container DOM element (viewNode)
however it's important that all event wiring for the UI items in your View are reconfigured.

`attachEvents()` is ran on your View Bridge again after a re-render allowing you to reestablish
event handlers on UI elements.

> A common issue with re-render is event handlers being registered in `onReady` which is not fired
> after a re-render.

## Inappropriate Use

While it can seem like a universal and simple approach to handling XHR requests the re-rendering
of large bodies of complex HTML opens up a whole category of issues that are sometimes best
avoided. Generally it is simply lazy to re-render a whole page Leaf for example and fraught with
problems where state and event handlers may not restore themselves to exactly the same condition.

gha_language: PHP


text:
# DubinsJS
A Typescript/Javascript Translation of Andrew Walker's C Implementation of a Dubin's Curves Algorithm

## Recommended Reading (and viewing)
Please also check out [Andrew Walker's repo](https://github.com/AndrewWalker/Dubins-Curves) for the code I based this off of, as well [this python version](https://github.com/AndrewWalker/pydubins)

I also highly recomend checking out [this blog post that](https://gieseanw.wordpress.com/2012/10/21/a-comprehensive-step-by-step-tutorial-to-computing-dubins-paths/) explains and breaks down Dubins's algorithm. It also features a [really fun video](https://www.youtube.com/watch?v=fEImNJQ3hUM) that I think offers an excellent visual explanation

## Example
```
const newPoints: [number, number][] = []
const dubWorker = new Dubins()
dubWorker.shortestAndSample([
    // start x, y, and heading
    start.x,
    start.y,
    start.heading // in radians
  ], [
    // end x, y, and heading
    end.x,
    end.y,
    end.heading // in radians
  ],
  turning_radius,
  step_size,
  (q, _) => {
    // callback, you will need this in order to get your interpolated points
    newPoints.push([q[0], q[1]])
    return 0
  })
```

#### What if I want to use Lat/Long instead of X/Y?
Short answer, __don't do this__. I do it, but you shouldn't. If you *realllly* want to then you can do this:
```
// all units in degrees
const newPoints: [number, number][] = []
const turning_radius = 0.00001 // ~ 1 meter
const step_size = 0.000003 // ~ .3 meters

// last point of first segment, assuming array of latLng's
const start = firstSegment[firstSegment.length - 1]

// compute heading between second to last and last point
const startHeading = google.maps.geometry.spherical.computeHeading(firstSegment[firstSegment.length - 2], firstSegment[firstSegment.length - 1])

// first point of last segment, assuming array of latLng's
const end = lastSegment[0]
// compute heading between first and second point
const endHeading = google.maps.geometry.spherical.computeHeading(endHeading[0], endHeading[1])

const dubWorker = new Dubins()
dubWorker.shortestAndSample([
    // start x, y, and heading
    start.lat(),
    start.lng(),
    startHeading * (Math.PI / 180) // then convert to radians
  ], [
    // end x, y, and heading
    end.lat(),
    end.lng(),
    endHeading * (Math.PI / 180) // then convert to radians
  ], turning_radius, step_size, (q, _) => {
    // callback
    newPoints.push([q[0], q[1]])
    return 0
  })
```

repository: franklinharvey/DubinsJS

repo_name: franklinharvey/DubinsJS


text:
# React Application

## info

a complete react project with :

1. react, redux , redux sagas
2. eslint
3. customizable build config
4. jest and enzyme test framework
5. babel and eslint config to support es2017
6. react hot module replacement
7. code spliting
8. code organisation based on "Feature first approach"
9. webpack 4.

**this project requires**

1. `NodeJS`
2. `npm`.
3. `python 2.7` which may change in future

## How to set up? Install

this app is where all front end code will live. in most of the cases it will be a single page application
build with react,redux,sagas, and build by webpack.

- install node modules and run client applicarion
- hit `npm install`
- use `vs code` for best developer experience.
- download `EditorConfig for VS Code`
- download `EsLint` for vs code
- download `Prettier - code formatter` for vs code.
- you try other code editors also. as long as they support the above mentioned pluguns.

### start

after installing all modules hit `npm start`
this will run the applications in `watch` mode. meaning any file change will be reacted and updated`
in the browser. (Hot module replacement)

### build

to build for deployment/production.

- hit `npm run build`

doing this will copy build diles to dist folder in root `dist/public` folder in the application root which will contain a full stack build
`nodejs` application redy to deploy with its own `package.json` install node modules and run the app.

### Unit Testing

we are using jets and enzyme for unit testing javascript and react components. you can write unit test cases for
each javascript module (in ES6, commonJS a module is simply a javascript file .js ). to test any module just create
the same filename with .`spec.js` or `.spec.jsx` at the end. in the `__tests__` folder in the same directory, for example `api.service.js` => `__tests__/api.service.spec.js`
and `home.component.jsx` => `__tests__/home.component.spec.jsx`

tests can be run in 2 modes.

1. watch mode => where you can make changes to test files and on save all the jest tests will re run.
2. complete mode => where you start the tests and it runs to completion. no file changes are monitored in this mode.

**npm scripts**

- `npm run test:watch` runs the tests in watch mode. it provides some cli options which you can play with
- `npm run test` runs tests without watch mode. these are simplte run to completion tests.

**important**
to run the built application it needs following environment variables

1. `NODE_ENV`='production'
2. `NODE_ENV_PORT`='3000' or any available port

## npm scripts.

```
"scripts": {
    "start": "npm run start:dev",                                                                                # starts project  in dev mode
    "start:dev": "npm run dev-server --   --mode development --env.NODE_ENV=development --env.PROXY_ORIGIN=http://localhost:8000",          # starts project in dev with dev env vaiables and dev proxy origin
    "start:stage": "npm run dev-server --  --mode development --env.NODE_ENV=development --env.PROXY_ORIGIN=https://locahost:9001",         # starts project in dev and proxies to stage env
    "start:analyze-speed": "npm run start:dev -- --env.addons=speedmeasure",                                                                # starts project in dev with webpack speed analyzer plugin
    "build": "npm run test && webpack --optimize-minimize --mode production --env.NODE_ENV=production --env.PUBLIC_PATH=/",                 # build project for production
    "build:analyze-bundle": "npm run build -- --env.addons=bundleanalyzer",                                                                 # build project with webpack bundle analyzer plugin
    "build:analyze-buddy": "npm run build -- --env.addons=bundlebuddy",                                                                     # builds for production with webpack bundlebuddy plugin
    "dev-server": "webpack-dev-server --inline",                                                                                # starts webpack dev server to serve the app.
    "test:watch": "npm run test -- --watchAll",                                                                                # runs jest test runner in watch mode.
    "test": "export NODE_ENV=test&& jest",                                                                                # starts jest test runner
    "profile": "webpack --env.NODE_ENV=production --progress -c --profile --json  > stats.json"                                             # generates webpack build profile
  },
```

## under the hood

- [Node.js](https://nodejs.org/en/)
- [React](https://github.com/facebook/react)
- [Redux](https://github.com/reactjs/redux)
- [Sagas](https://redux-saga.js.org/docs/introduction/BeginnerTutorial.html)
- [React Router v4](https://github.com/reactjs/react-router)
- [Axios](https://github.com/axios/axios)
- [AntD with scss](https://ant.design/)
- [Webpack 4](https://github.com/webpack/webpack) with code splitting
- [React Hot Loader](https://github.com/gaearon/react-hot-loader)
- [Jest](https://jestjs.io/)
- [Enzyme](https://airbnb.io/enzyme/)
- [ESLint](https://eslint.org/)

## recommendations

its best to use vs code with the following plugins installed.

1. EditorConfig for VS Code
2. EsLint
3. Prettier - code formatter

## folder structure

**client folder**

```
.
├── /mocks/                    # This folder contains some mocks for jest like api,css modules etc
├── /build-config/             # webpack config divided into types of env is placed here
├── /coverage/                 # contains a small application wich shows coverage generated by jest
├── /node_module/              # contains all dependencies modules
├── /src/                      # contains the actual source code
├── /.babelrc                  # babel configuration and env specific plugins are kept here
├── /.editorconfig             # commom configuration to code editor
├── /.eslintignore             # some rules to ignore for eslint
├── /.eslintrc                 # eslint rules and configuration
├── /.gitignore                # ignore files to git
├── /.package.json             # dependencies for client app
├── /.package-lock.json        # dependencies lock
├── /.webpack.config.js        # root config for webpack which will import all other configurations.
├── /README.md                 # instructions and help
├── /LICENSE                   # license details
├── /CHANGELOG.md              # all changes mentioned
├── /jsconfig.js               # contains paths for vs code import resolve
```

**src folder**

```
.
├── /App/                     # App folder which contains all react components
├── /Assets/                  # Assets folder contain all images, logos, global styles, css etc which does not belong to react components
├── /Constants/               # Contains all app level constants for the app. like api endpoints etc.
├── /Services/                # All helper methods, functions modules that are used accross the application, shared code which should be reused everywhere
├── /Store                    # contains redux store and other redux utilities
├── /Styles/                  # styles for the app, libraries and common classes that should be re-used. also scss variables and antd theme variables are kept here.
├── /App.hot.js               # initializations for React HMR
├── /index.ejs                # index.html we are using ejs as templating engine so that we could inject variables into template
├── /index.jsx                # starting point of the app. which will initialises the react app.
```

**src/App folder**

```
.
├── /__tests__/               # Contains test files for App Component.
├── /Common/                  # Contains all Common Componenets which are to be shared accross the application.
├── /Elements/                # Elements are the Components taken from some library like Button, Accodion, Modal etc. these are wrappers over library components.
├── /Layout/                  # Layout component declares the application lyout. ex navbar,body, footer, side pan. which defines the app lyaout.
├── /Router/                  # Router component imports react router and declares the routing for the sub apps. all the routing should be registered here. and lyout will import router
├── /Modules                  # Modules are independent apps which in most of the cases is a PAGE or Router ex Home, Profile,Chat,Massenger etc.
├── /actionNames.js/          # Contains all App level action Names for the redux
├── /actions.js/              # Contains all redux actions on app level.
├── /action.spec.js           # Tests fir actions
├── /index.jsx                # App component definition is here.
├── /operations.js            # Contains all Sagas helper methods.
├── /reducer.js               # Contains reducer for app level actions.
├── /reducer.spec.js          # Tests for reducer.
├── /sagas.js                 # default export for app level sagas.
```

**src/Assets folder**

```
.
├── /Images/                  # Contains all images for the app.
```

**src/Constants folder**

```
.
├── /api/                    # Contains all constants for apis like endpoints, params etc
├── /app/                    # Contains all App level constants.
├── /elements/               # Contains Element level constants.
```

**src/Services folder**

```
.
├── /api/                    # Contains all api services like requests, request maker, authorizations etc.
├── /utility/                # Contains all utility functions like for objects,arrays, debounce, timers etc
```

**src/Store folder**

```
.
├── /combinedReducer.js      # All the reducers are combined here and given to the store.
├── /index.js                # Initializes the  redux store with all middlewares.
├── /logger.js               # A simple redux middleware which logs all the actions.
```

**src/Styles folder**

```
.
├── /display/                # All display classes like flex,margin,padding etc are here
├── /theme                   # Theme variables for app and antd
├── /variables               # Variables like colors and themes etc
├── /global.scss             # Global css.
```

## A simple Component structure.

here is a template for a component folder structure.
**src/Styles folder**

```
ComponentName
    ├── /__tests__/                        # contains all unit test cases files corrosponding to component, actions, reducer, operations, utility.
    ├── /Components                        # Child components that may be used by this component, which may be not be common.
    ├── /ComponentName.actionNames.js      # Action names for the component
    ├── /ComponentName.actions.js          # Action creators for the componentName
    ├── /ComponentName.component.jsx       # React component decleration
    ├── /ComponentName.reducer.js          # Reducer for the component
    ├── /ComponentName.operations.js       # operations for component
    ├── /ComponentName.styles.scss         # Styles for the component
    ├── /ComponentName.utility.js          # utility methods which do not belong to the component
```

if the component does not need redux actions and seperate store then

```
ComponentName
    ├── /__tests__/                        # contains all unit test cases files corrosponding to component, actions, reducer, operations, utility.
    ├── /Components                        # Child components that may be used by this component, which may be not be common.
    ├── /ComponentName.component.jsx       # React component decleration
    ├── /ComponentName.component.spec.js   # Test files component
    ├── /ComponentName.styles.scss         # Styles for the component
```

# Redux

redux is the most important part of the application because it handles the data.
we are only storing bussiness data in the redux store. which means data that is extenal or which has bussiness implication.
data with respect to UI and UI state or elements need not to be stored in the redux store as it can be handled by the component itself.
its a common misconception that we store every piece of data in the redux store. thats really not necessary. of you want to store the
`open` state of a accordion in the redux store then its wrong. the component using the accirdion should have that state

## Redux hierarchy

we have organished redux store as per our project structure. it makes it easy to maintain the store when u know what part of the application
requires what part of the store, there is no misconception or confusion when using the store in components.

also it should be noted that not each and every component needs not to be connected to the redux store. we should only connect top level components to the store
and pass around props to the child components. it makes data flow easy to understand in the component and you can visually understand that what props are passed to a component
without opening the component definition.

**redux hierarchy**

```
Store
  ├── App                    # contains app global data, can be a nested obect
  ├    ├──AppGlobals
  ├    ├──AppContext
  ├    ├──AppConfiguration
  ├    ├──AppVersion
  ├── User                   # User related data
  ├    ├──UserGlobals
  ├    ├──UserProfile
  ├    ├──UserConfiguration
  ├    ├──UserConrexr
  ├── Modules                # Seperate store for each sub application/routes
  ├    ├──Home
  ├    ├──Profile
  ├    ├──Todo
  ├    ├──About
  ├    ├──Error
```

maintaining the same hierarchy in redux store has many benifits. one of them is code organizastion.
each sub application has a `reducer`,`sagas` which are default exported and combined and given to the store.

## Handeling side effects with sagas

front end application is all about handling side effects. for us the most important side effects are the api calls.
apis give us external data and our react components should be able to handle them without making it complicated.

the best practice is to have react components onlt handle the view. no additional logic. that even includes making api calls.
react component should not be concerned about how the data is fetched from external source. it should only consider the data passed to it
as a props. thats why we are handling external data outside the component echosystem. and passing objects to the components as props.

### why sagas ?

there are other alternatives to manage side effects one them is [thunk](https://github.com/reduxjs/redux-thunk). thunks are good but the problem is
thunks are very painful to unit test.

sagas use `generator` functions to handle the async tasks which makes it unit testable.

## Saga Data structure for apis.

Every Api calls in most of the cases will have 3 states.

1. Loading
2. Success
3. Failure

at one instant of time there will be only one of these three states . and we can show accordiing Ux as per the state. ex

1. Loading state => show a loader/loading screen
2. Success state => show the actual data
3. Failure state => show error fallback/alert/toas etc.

storing all three states in store has good benifits. there will be no useless logic with respect to maintaing these states

it can be passed as props to the component, and thus component will re-render automatically when state changes, and our fallbacks will render
automatically.

there is less code in the component. component will focus on view layer only.

so we data point which needs to be stored in the redux store, must have these three states. ex.

`home reducer` stores `homeTiles` from an api. so our redcuer will have

```
 var home = {
   loading:false,
   data: null,
   error: null
 }
```

and for each state change a action has to be dispatched which `saga operation` will take care of.

```
import { put } from 'redux-saga/effects';

import {
  homeTiles,
} from 'Services/api/api.requests';

import {
  HomeFetchHomeTilesLoading,
  HomeFetchHomeTilesSuccess,
  HomeFetchHomeTilesFailure,
} from './actions';

export function* fetchHomeTilesSaga() {
  try {
    yield put(HomeFetchHomeTilesLoading()); // dispatched loading action which reducer will set loading state
    const profile = yield homeTiles(); // yeilds homeTiles when promise is success
    yield put(globalFetchHomeTilesSuccess(profile)); // dispatched data as success action
  } catch (e) {
    yield put(globalFetchHomeTilesFailure(e)); // dispatched error when api fails.
  }
}
```

**home reducer**

```
import homeActionNames from './actionNames';

const defaultState =  {
   loading:false,
   data: null,
   error: null
 }
const homeReducer = (state = defaultState, actions) => {
  switch (actions.type) {
    case homeActionNames.FETCH_HOME_TILES_LOADING:
      return {
        ...state,
        loading: true
      }
    case homeActionNames.FETCH_HOME_TILES_SUCCESS:
      return {
        ...state,
        loading: false,
        data: action.payload
      }
    case homeActionNames.FETCH_HOME_TILES_FAILURE:
      return {
        ...state,
        loading: false,
        error: action.payload
      }
    default:
      return state;
  }
};

export default homeReducer;
```

repository: hannadrehman/react-production

repo_name: hannadrehman/react-production


text:
# assemble-swig [![NPM version](https://badge.fury.io/js/assemble-swig.png)](http://badge.fury.io/js/assemble-swig)  [![Build Status](https://travis-ci.org/assemble/assemble-swig.png?branch=master)](https://travis-ci.org/assemble/assemble-swig)

> Assemble engine plugin for processing swig templates.

## Getting Started
This plugin requires Grunt `~0.4.1`

If you haven't used [Grunt](http://gruntjs.com/) before, be sure to check out the [Getting Started](http://gruntjs.com/getting-started) guide, as it explains how to create a [Gruntfile](http://gruntjs.com/sample-gruntfile) as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

```shell
npm install assemble-swig --save-dev
```

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

```js
grunt.loadNpmTasks('assemble-swig');
```

## The  Assemble  task
_Run this task with the `grunt swig` command._

### Overview
In your project's Gruntfile, add a section named `assemble` to the data object passed into `grunt.initConfig()`.

#### Usage Example

```js
grunt.initConfig({
  assemble: {
    options: {
      engine: 'swig'
    },
    site: {
      files: {
        '_gh_pages/': ['src/templates/**/*.swig']
      }
    }
  }
});
```
### Options

#### [options.engine](http://assemble.io/docs/options-engine.html)
Type: `String`

Specify the current engine for Assemble to use for processing templates.

```js
assemble: {
  options: {
    engine: 'swig'
  }
}
```

## Related projects
* [assemble/assemble](https://github.com/assemble/assemble)
* [assemble/dry](https://github.com/assemble/dry)
* [assemble/assemble-internal](https://github.com/assemble/assemble-internal)
* [assemble/assemble-less](https://github.com/assemble/assemble-less)
* [assemble/grunt-toc](https://github.com/assemble/grunt-toc)
* [assemble/handlebars-helpers](https://github.com/assemble/handlebars-helpers)
* [assemble/grunt-dry](https://github.com/assemble/grunt-dry)
* [assemble/boilerplates](https://github.com/assemble/boilerplates)
* [assemble/less-tests](https://github.com/assemble/less-tests)
* [assemble/boilerplate-site](https://github.com/assemble/boilerplate-site)
* [assemble/grunt-init-assemble](https://github.com/assemble/grunt-init-assemble)
* [assemble/generator-assemble](https://github.com/assemble/generator-assemble)
* [assemble/assemble-utils](https://github.com/assemble/assemble-utils)
* [assemble/task-manifest](https://github.com/assemble/task-manifest)
* [assemble/boilerplate-sitemap](https://github.com/assemble/boilerplate-sitemap)
* [assemble/assemble-package-manager](https://github.com/assemble/assemble-package-manager)
* [assemble/assemble-manifest](https://github.com/assemble/assemble-manifest)
* [assemble/assemble-handlebars](https://github.com/assemble/assemble-handlebars)
* [assemble/assemble-swig](https://github.com/assemble/assemble-swig)
* [assemble/boilerplate-book](https://github.com/assemble/boilerplate-book)
* [assemble/handlebars-helpers-examples](https://github.com/assemble/handlebars-helpers-examples)
* [assemble/glob-object](https://github.com/assemble/glob-object)
* [assemble/gruntjs.com](https://github.com/assemble/gruntjs.com)
* [assemble/grunt-assemble](https://github.com/assemble/grunt-assemble)
* [assemble/boilerplate-markdown](https://github.com/assemble/boilerplate-markdown)
* [assemble/assemble-docs](https://github.com/assemble/assemble-docs)
* [assemble/grunt-init-helper](https://github.com/assemble/grunt-init-helper)
* [assemble/lodash-mixins](https://github.com/assemble/lodash-mixins)
* [assemble/boilerplate-gist-blog](https://github.com/assemble/boilerplate-gist-blog)
* [assemble/grunt-convert](https://github.com/assemble/grunt-convert)

## Release History

 * 2013-08-07   v0.1.0   New Assemble engine plugin for swig templates.

***

Project authored by [Brian Woodward](https://github.com/doowb/).

_This file was generated on Wed Sep 11 2013 22:34:27._

repository: chrisjdavis/new-admin

repo_name: chrisjdavis/new-admin


text:
# ATTENTION. WORK IN PROGRESS.

Though the destructuring is done and works well.

# Super Duck

Destructuring, matching and multimethods.

## Getting Started
_(Coming soon)_

## Documentation
_(Coming soon)_

## Examples
_(Coming soon)_

## Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using [grunt](https://github.com/cowboy/grunt).

_Also, please don't edit files in the "dist" subdirectory as they are generated via grunt. You'll find source code in the "lib" subdirectory!_

## Release History
_(Nothing yet)_

## License
Copyright (c) 2012 Nek
Licensed under the MIT license.

repository: Nek/SuperDuck

repo_name: Nek/SuperDuck


text:
18% - Configuration
* Understanding Configmaps
* Understand SecurityContexts
* Define application resource requirements
* Create and consume secrets
* Understand service accounts
### Bookmark below

#### create a new service account named ckad in namespace ckadns
```bash
k create ns ckadns
k create sa ckad -n ckadns
```
#### create a nginx pod with serviceaccount as ckad and in namespace ckadns
```bash
k run mypod --image=nginx --restart=Never --serviceaccount=ckad -n=ckadns
```
#### try changing the service account of the above pod to default
```bash
k set serviceaccount po/mypod default -n ckadns
## **** NOTE: you wont be able to change serviceaccounts on pod as they are immutable but if you have a deployment it would work
```

#### Changing serviceaccount on deployment will work with k set serviceaccount
```bash
k run mydeploy --image=nginx --replicas=2 --serviceaccount=ckad -n ckadns
k get po -n ckadns
k get po <po_name> -n ckadns -o yaml  # notice the servcieaccount on pod spec level would be ckad
k set serviceaccount deploy/mydeploy default -n ckadns # changing service account on deployment level to ckad
k get po <new_Po_name> -n ckadns # notice the service account on pod spec level would be default
```


text:
To subset raw bam reads and use bwa to align them:
`bwa_to_bam.py -r reference.fasta -i input.txt -p 8`
where input.txt has a tab-delim list of `host	sample	path`

repository: wyim-pgl/phylogenomics

repo_name: wyim-pgl/phylogenomics


text:
---
title: MaixPy Featured Article
keywords: maixpy, k210, AIOT, edge computing
desc: maixpy  MaixPy Featured Articles
---

From the community **selected** articles, collect some good articles here to facilitate everyone to learn and communicate.

In addition, if you have experience and want to share, you are also welcome to participate. After writing the article, submit [issue](https://github.com/sipeed/MaixPy_DOC/issues) to add
Claim:
* Related to MaixPy
* Clear article directory hierarchy
* The logic of the article is clear, and the introduction, effect, operation process, and summary of the sharing need to be stated, with pictures and texts

You can also directly add experience sharing in the document according to [Participation in experience sharing/sharing template](../share/my_share/README.md). If it is well written, it will also be included on this page

-----------

The article links are all included in the following posts to facilitate updates:

[Selected Article Navigation](https://cn.bbs.sipeed.com/d/481) (Maybe Chienese article, you can use google translation to translate)

gha_language: JavaScript


text:
[link](../../index.md) / [com.tink.link.payments](../index.md) / [TransferStatus](./index.md)

# TransferStatus

`sealed class TransferStatus`

The status of a transfer.
Possible values are [Success](-success/index.md), [Loading](-loading/index.md), and [AwaitingAuthentication](-awaiting-authentication/index.md)

### Types

| Name | Summary |
|---|---|
| [AwaitingAuthentication](-awaiting-authentication/index.md) | There is an outstanding authentication waiting that needs to be completed by the user to proceed with the transfer.`class AwaitingAuthentication : `[`TransferStatus`](./index.md) |
| [Loading](-loading/index.md) | The transfer is being processed by Tink. There is currently no user action required.`data class Loading : `[`TransferStatus`](./index.md) |
| [Success](-success/index.md) | The status was successfully sent to the user's bank for processing.`data class Success : `[`TransferStatus`](./index.md) |

repository: jrodriguezva/tink-link-android

repo_name: jrodriguezva/tink-link-android


text:
# guinget Version 0.1 Alpha Changelog
Released on 7/7/2020 (MM/DD/YYYY).

One month after guinget's second pre-alpha version, the first real alpha version is now available! Although there are few overall changes in this version, the few changes that are there make a major difference in terms of usability, including one change that makes updating the package list much faster. Please be sure to read the Readme included with this version of guinget or [online](https://github.com/DrewNaylor/guinget/blob/master/docs/readmes/readme-v0.1-alpha.txt) as it has important info. Also refer to the [System Requirements](https://github.com/DrewNaylor/guinget/blob/master/docs/system-requirements.md).

As of July 17, 2020, there's an installer available as well.

If you are reading this in Notepad or another text editor, it displays best in Word Wrap view. Click on Format>Word Wrap on the top bar. Notepad++ users will find it under View>Word Wrap. Word Wrap is automatically done if viewing on GitHub or on the website.

## Hashes

MD5 checksums/hashes are not used for guinget as they are weaker than SHA-256. [More details](https://github.com/DrewNaylor/UXL-Launcher/issues/124), though they're not as relevant to guinget:

You can use Windows PowerShell to confirm the hash of the main guinget EXE file by running
`Get-FileHash .\guinget.exe -Algorithm SHA256` in the folder you extracted the archive to and comparing the output to my sums listed below. HowToGeek has a nice [article on this](https://www.howtogeek.com/67241/htg-explains-what-are-md5-sha-1-hashes-and-how-do-i-check-them/), but the Windows section is a bit further down on the page.

The PowerShell method can be used for all files listed below, though you'll have to switch out the filenames.

SHA-256 sum for "guinget_v0.1-alpha.exe", which is the installer attached to this release:
AFB4E6D91DA3BAA92655F70052D1E91667234D5EC7252181ECF182F26A6D5BA7

SHA-256 sum for "guinget.exe" in the archive:
41013DC21A36FF348AD9B2727059D2AFA10F3D7098042A154DE4D3E90A35F3C4

SHA-256 sum for "libguinget.dll" in the archive:
826B675C6666489B0F3D53D05502E3CD79B7E78AE04852E9808D9E473EEBC936

SHA-256 sum for "update-manifests.bat" in the archive:
AFA421669D4856FB9136656B97CD2098478B1FE67AD5CB2326DA5A8BDA4BD36A

SHA-256 sum for "YamlDotNet.dll" in the archive:
632E1C37E67E5BE46766FFC9ED7790C22D1FE75A5B83AAB9EC4C0678414E5B82

## Added

- `libguinget` is now in charge of updating the package list instead of `update-manifests.bat`. Benefits and implications:
  - Much faster package list zip file downloads and extractions (sadly the copying is a bit slower, but it doesn't matter much)
  - A pretty GUI to look at while it does its thing (unfortunately, with indeterminate progress bars for now since I don't know how to actually get the progress numbers to increment the progress bar)
  - Cancel buttons in the download and extract phases if you wish to stop the update and just load the package list from what's currently in the folder that's loaded into the package list data grid view
    - You can press the `Esc` key instead of clicking `Cancel` if that's easier or faster.
    - Please be aware that the cancel button is only available during the download and extract phases, and isn't available when copying. This is due to the package manifest folder being deleted before copying begins.
    - Additionally, canceling currently requires the current phase to complete before fully stopping the update.
    - Closing the progress windows doesn't cancel the task at the moment; clicking the cancel button is required.
  - `update-manifests.bat` is still available for now if you wish to use it, but it's deprecated and may be removed without warning. See [here](https://github.com/DrewNaylor/guinget/blob/master/docs/How-to-use.md#updating-with-update-manifestsbat) for instructions on re-enabling `update-manifests.bat`. This manual change will not persist guinget updates.

## Fixed

- Double-clicking on the column separators displays the package context menu. ([issue #16](https://github.com/DrewNaylor/guinget/issues/16))

## Changed

- When focusing the Search box with `Ctrl+F`, the text in it is now selected so it's easier to type something else.
- The `Apply changes` window no longer displays in the taskbar, and it also no longer has a minimize button.
- Controls that could interfere with the update process are blocked from being used, though some are still available such as `File>Exit`, `Help>About`, and the package details textbox (if people get bored and want to read something while it updates). This really only impacts the built-in update system provided by `libguinget`.
- `update-manifests.bat`'s message box now talks about how it's deprecated and that it's being used instead of the built-in updater.
- About window text updates:
  - Separators to make it a bit easier to visualize where text starts and stops for the license parts
  - `libguinget` is now mentioned here: "Apache License 2.0 summary as it applies to guinget **and libguinget**:" (new text in bold)
- Code for getting package details from winget has been commented out to save space in `libguinget.dll`'s `PackageTools` class. This code is for example purposes and is deprecated.
- `libguinget`'s assembly info now has "Package **and package list** tools for guinget and other programs that want to use them." (new text in bold)
- Documentation updates:
  - Project roadmap had some things moved around a bit.
  - System requirements are now a bit more detailed, especially with regards to minimum and recommended hardware requirements based on my testing.
  - Usage instructions now talk about how to use the new, built-in package list updater.

## Deprecated

- `update-manifests.bat` is deprecated as mentioned above. Its removal will be done in stages to slowly transition to a world that no longer relies on `update-manifests.bat` for any scenario:
  - For now it'll stay in the package, but be unused by default.  **<-- You Are Here**
  - Eventually the version in the package will be changed to be a simple script that tells you where to download the main script.
  - After a while it'll be fully removed from the package.
  - A while after that support for it will be fully removed from guinget. It's expected that support will be fully removed by the time guinget (and winget, but it may take longer for guinget to gain that feature) supports multiple sources, if not in the same version.
  - It may be possible that it'll go from being supported in a way that requires it to be enabled manually to being removed from the package, or having support be removed completely, all at once.
- Since the code to get details from winget is deprecated, it's been commented out as mentioned above. This code may continue to exist in this state as an example for how to get info from winget.


text:
# PrintLab
All you need to securely access your printer from the outside world, along with other useful utilities for 3d printing.

# Install instructions

First, setup port forwarding of UDP port 51820 to your pi's IP address. Giving your PI a static ip is recommended but not strictly necessary. However if your pi's ip ever changes you will need to redo this port forwarding.

## Easy mode install
If you have a fresh install on your Pi and want the minimal muss and fuss this is for you. This will download and install everything you need to get the PrintLab up and running.

1. Obtain and install Ubuntu 20.04+ from https://ubuntu.com/download/raspberry-pi
2. Be sure to update network-config on the boot root if you are using WiFi

*NOTE*
If this is a fresh Ubuntu install fire up your pi, wait 2 minutes, then power cycle it if using WiFi. WiFi doesn't work until the 2nd boot with Ubuntu.

*NOTE 2*
If this is a fresh install of ubuntu be sure to let it idle a about 15 minutes before starting the install. Ubuntu automatically updates and running this installer prior to it completing can cause weird behavior. You can check that it's done by running the following command:

````
ps -ef | grep apt
````

If all you see is something similar to this, you can continue:

````
ubuntu@ubuntu:~$ ps -ef | grep apt
ubuntu     45931    2142  0 03:47 pts/0    00:00:00 grep --color=auto apt
````

3. ssh into your pi via ssh ubuntu@piaddress default password is ubuntu. Follow the prompts and re-login.
4. run the following command:
````
curl https://raw.githubusercontent.com/pushc6/PrintLab/master/EasyMode/install.sh | bash
````
4. Profit.

After the script finishes everything should be installed and running. Point your browser to http://piaddress:8088 to get your WireGuard QRCode.

## Familiar with docker-compose install

If you are familiar with docker-compose you can clone this repo and run "docker-compose up -d" and it will do the same thing as the above. The script above assumes you have nothing pre-configured.

## Configuration
If you use the "easy-mode" install you probably don't need to configure anything, it should just work. If you *do* need to configure something most everything is located in the docker-compose.yml file, minus the nginx config which has it's own folder.

## What's installed?
PrintLab contains several images that help make installation\management easier. If you are a power user you don't need to install nginx or portainer if you don't want, you can just remove them from the docker-compose.yaml.

### Wireguard
This is the main reason for this repo. It allows for easy and secure access to your printer while at home via apps like Octopod.

### Nginx
This is used to provide easy access to the QR code necessary to configure the wireguard client. It is always online so you can quick reference it

### Portainer
If you want to make changes or view the status of your services this has been installed to make that easier for non-power users.

gha_language: Dockerfile


text:
# [Composum](https://www.composum.com/home.html)

yet another Apache Sling based Application Platform (asap)

## [Composum Platform](https://www.composum.com/home.html)

![Build Status](https://api.travis-ci.org/ist-dresden/composum-platform.svg?branch=develop) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

the central services to set up an Apache Sling based application platform

* [Composum Homepage](https://www.composum.com/home/pages.html)

### see also

#### [Composum Pages](https://github.com/ist-dresden/composum-pages)

* [Composum Pages Homepage](https://www.composum.com/home/pages.html)

#### [Composum Assets](https://github.com/ist-dresden/composum-assets)

* [Composum Homepage](https://www.composum.com/home.html)

#### [Composum Nodes](https://github.com/ist-dresden/composum)

* [Composum Nodes Homepage](https://www.composum.com/home/nodes.html)

repository: ist-dresden/composum-platform

branch_name: refs/heads/develop

gha_language: Java

repo_name: ist-dresden/composum-platform


text:
# ReactPHP WebDriver

This is a direct port of [RemoteWebDriver](https://github.com/php-webdriver/php-webdriver/blob/1.8.3/lib/Remote/RemoteWebDriver.php)
logic from the [php-webdriver/webdriver](https://github.com/php-webdriver/php-webdriver) package, which utilizes [ReactPHP](https://github.com/reactphp/reactphp)
event loop and promise API for browser interaction w/o execution flow blocking.

**Selenium WebDriver** is a software that is used to manipulate browsers from the code (primarily, for testing and web scraping).
You can find more here: [https://selenium.dev](https://selenium.dev).

This PHP client sends async HTTP requests to the [Grid](https://www.selenium.dev/documentation/en/grid). It is a central
endpoint for commands, a bridge between your code and browser instances. See
[SeleniumHQ/docker-selenium](https://github.com/SeleniumHQ/docker-selenium) to get your own remote browser (or a cluster).

Enjoy!

## Requirements

- **PHP 7.4** or higher.
- ReactPHP v1 (http **^1**, stream **^1**).
- Symfony conflicts: 5.1 (or newer) environments are preferred; the package uses (and will use) some components from
there, and their code / version constraints may need a review, to include a wider range of supported environments
(otherwise, you need to adjust your platform).

## Installation

With [composer](https://getcomposer.org/download):

```
$ composer require itnelo/reactphp-webdriver:^0.4
```

## How to use

Call a factory method to get your instance (recommended). The minimal configuration is:

```php
use React\EventLoop\Factory as LoopFactory;
use Itnelo\React\WebDriver\WebDriverFactory;

$loop = LoopFactory::create();

$webDriver = WebDriverFactory::create(
    $loop,
    [
        'hub' => [
            'host' => 'selenium-hub',
            'port' => 4444,
        ],
    ]
);
```

You can customize a set of parameters for the underlying [ReactPHP Browser](https://github.com/reactphp/http#browser)
and tune driver options:

```php
use React\EventLoop\Factory as LoopFactory;
use Itnelo\React\WebDriver\WebDriverFactory;

$loop = LoopFactory::create();

$webDriver = WebDriverFactory::create(
    $loop,
    [
        'browser' => [
            'tcp' => [
                'bindto' => '<IP_ADDRESS>:0',
            ],
            'tls' => [
                'verify_peer' => false,
                'verify_peer_name' => false,
            ],
        ],
        'hub' => [
            'host' => 'selenium-hub',
            'port' => 4444,
        ],
        'command' => [
            'timeout' => 30,
        ],
    ]
);
```

Manual configuration (if you prefer to configure each component as a separate service, e.g. compiling a DI container
and want to reuse existing service definitions):

```php
use React\EventLoop\Factory as LoopFactory;
use React\Socket\Connector as SocketConnector;
use React\Http\Browser;
use Itnelo\React\WebDriver\Client\W3CClient;
use Itnelo\React\WebDriver\Timeout\Interceptor as TimeoutInterceptor;
use Itnelo\React\WebDriver\SeleniumHubDriver;

$loop = LoopFactory::create();

$socketConnector = new SocketConnector(
    $loop,
    [
        'tcp' => [
            'bindto' => '<IP_ADDRESS>:0',
        ],
        'tls' => [
            'verify_peer' => false,
            'verify_peer_name' => false,
        ],
    ]
);
$browser = new Browser($loop, $socketConnector);
$browser = $browser->withRejectErrorResponse(false);

$hubClient = new W3CClient(
    $browser,
    [
        'server' => [
            'host' => 'selenium-hub',
            'port' => 4444,
        ],
    ]
);

$timeoutInterceptor = new TimeoutInterceptor($loop, 30);

$webDriver = new SeleniumHubDriver(
    $loop,
    $hubClient,
    $timeoutInterceptor
);
```

See a self-documented [WebDriverInterface.php](src/WebDriverInterface.php) (and [ClientInterface.php](src/ClientInterface.php))
for the API details. Not all methods and arguments are ported (only the most necessary), so feel free to open
an issue / make a pull request if you want more.

## See also

- [php-webdriver/webdriver](https://github.com/php-webdriver/php-webdriver) — the original, "blocking" implementation;
to get information how to use some advanced methods. For example, [WebDriverKeys](https://github.com/php-webdriver/php-webdriver/blob/main/lib/WebDriverKeys.php#L10)
helper describes Unicode strings for sending special inputs to page elements (e.g. `Ctrl`, `Alt` and other keys).

## Changelog

All notable changes to this project will be documented in [CHANGELOG.md](CHANGELOG.md).

repository: itnelo/reactphp-webdriver

repo_name: itnelo/reactphp-webdriver


text:
# [Dash](http://kapeli.com/dash) docset for [Rust](http://rust-lang.org)

## Installation

Download the latest release of the docset [from the releases page](https://github.com/indirect/dash-rust/releases). If you want to generate the docset yourself, follow the steps in "Usage" below.

## Usage

```bash
$ bundle install
$ rake
$ open Rust.docset
```

To download the documentation for the latest Rust nightly and build a
fresh docset from that:

```bash
$ bundle install
$ rake nightly
$ open Rust.docset
```

### License

MIT License, copyright 2014 by André Arko

repository: wycats/dash-rust

gha_language: Ruby

repo_name: wycats/dash-rust


text:
# Cloudhouse Guardian Content

Open source content available for use with [Guardian](https://cloudhouse.com/cloudhouse-guardian/).

## Code

* Working API usage examples provided in Python, PowerShell, Ruby, Perl and Bash
* Standard parameters that require updating include: `apikey`, `secretkey` and `hostname`
* See the [Using the API](https://help.cloudhouse.com/upguard/using-the-api) support article for further details

## Contibuting

* Issues, and Pull Requests are always welcome.
* Questions and feeback can be sent to [helpdesk<EMAIL_ADDRESS>

repository: marksheahan/content

repo_name: marksheahan/content


text:
# JSON

Any JSON-based message **MUST** conform to the following rules:

1. All JSON field names **MUST** follow the [Naming Conventions ](../rest-api-guidelines/evolution/naming-conventions.md)\(`camelCase`, American English, etc.\)
2. Field names **MUST** be ASCII alpha num characters, underscore \(`_`\) or dollar sign \(`$`\)
3. Boolean fields **MUST NOT** be of `null` value
4. Fields with `null` value **SHOULD** be omitted
5. Empty arrays and objects **SHOULD NOT**  be `null` \(use `[]` or `{}` instead\)
6. Array field names **SHOULD** be plural \(e.g. `"orders": []`\)

## Validation
All API designers **MUST** validate the definition of the payloads in requests/responses with the [JSON Schema](https://json-schema.org/) for the defined structure prior to the publication of the API Contract in SwaggerHub.

The publication of the JSON schema corresponding to the expected payloads in the bodies of requests and responses **SHOULD** be kept up to date according to the evolution of the API.

repository: srsudu/adidas-api-guidelines

repo_name: srsudu/adidas-api-guidelines


text:
# SearchAThing.UtilExt.EqualsTol method
## EqualsTol(double, double, double)
### Signature
```csharp
public static bool EqualsTol(double x, double tol, double y)
```

repository: fossabot/netcore-util

repo_name: fossabot/netcore-util


text:
---
title: Nodes
---

## List all nodes

```
GET {uri}/forum/nodes
```

Response:
```json
Status: 200 OK
[
    {
        "id": 1,
        "name": "Node 1",
        "description": null,
        "icon": null,
        "color": null,
        "counts": {
            "threads": 0,
            "followers": 0
        }
    }
]
```

## Get a single node

```
GET {uri}/forum/nodes/{id}
```

Response:
```json
Status: 200 OK
{
    "id": 1,
    "name": "Node 1",
    "description": null,
    "icon": null,
    "color": null,
    "counts": {
        "threads": 0,
        "followers": 0
    }
}
```

## Create on an node

```
POST {uri}/forum/nodes
```

Input:
| Name | Type | Description |
|----|----|----|
| `name` | `string` | **Required**, The name of the node. |
| `description` | `string` | The description of the node. |
| `color` | `string` | Set the node background color. |
| `icon` | `string` | The icon is image filename. |

Response:
```json
Status: 201 Created
{
    "id": 1,
    "name": "Node 1",
    "description": null,
    "icon": null,
    "color": null,
    "counts": {
        "threads": 0,
        "followers": 0
    }
}
```

## Edit a node

::: warning
Need jurisdiction:`forum:nodes-manage`.
:::

```
PUT|PATCH {uri}/forum/nodes/{id}
```

Input:
| Name | Type | Description |
|----|----|----|
| `name` | `string` | The name of the node. |
| `description` | `string` | The description of the node. |
| `color` | `string` | Set the node background color. |
| `icon` | `string` | The icon is image filename. |

Response:
```
Status: 204 No Content
```

## Delete a node

::: warning
Need jurisdiction:`forum:nodes-manage`.
:::

```
DELETE {uri}/forum/nodes/{id}
```

Input:
| Name | Type | Description |
|----|----|----|
| `node` | `integer` | The thread under the deleted node needs to be moved to the specified node. |

Response:
```
Status: 204 No Content
```


text:
# Changelog

## 4.0.0

* Changed namespace from `jyggen\Curl` to `Jyggen\Curl`.
* Moved `Curl` from `jyggen\Curl` to `Jyggen\Curl\Curl`.
* Requests added to the dispatcher are now split into stacks to avoid a lot of simultaneously requests.
* Stack size can be configured with `Dispatcher::setStackSize()`, default size is 42.
* Added `Dispatcher::getStackSize()` to retrieve the currently used stack size.
* `Dispatcher::execute()` now allows you to pass a closure to run each response through.
* Added `Dispatcher::all()` to retrieve all requests added to the dispatcher.
* `Request::__destruct()` will now close the cURL handle.
* Refactored `Curl` to not use `__callStatic()` which should make the public API more obvious.
* Calling `Dispatcher::get()` without a key is now deprecated. Use `Dispatcher::all()` instead.

## 3.0.1

* Improved Travis CI testing.
* Changed dependency of `symfony/http-foundation` to `~2.0`.
* Fixed broken test.
* Code cleanup.

## 3.0.0

* Renamed `Session` to `Request` (and `SessionInterface` to `RequestInterface`).
* `Curl` will now always return an array with instances of `Response`.
* Changed dependency of `symfony/http-foundation` to `~2.3`.

## 2.1

* Refactored Curl to be more testable.
* Added more tests to improve coverage.

## 2.0.2

* Fixed an issue with empty responses.

## 2.0.1

* Fixed many issues with `Response::forge()` by using `CURLINFO_HEADER_SIZE`.
* Changed dependency of `symfony/http-foundation` from `2.2.*` to `~2.2`.
* Removed unused excepetions.
* Improved documentation of the code.

## 2.0.0

Version 2.0 introduces a new library flow which changes the way `Dispatcher` and `Session` interacts with each other. If you've only used the static helper `Curl` in the past these changes shouldn't affect you that much. `Dispatcher` is stripped down to only be a wrapper around `curl_multi_init()` while `Session` continues to wrap around `curl_init()` but with more functionality previously located in `Dispatcher`.

repository: kelixlabs/curl

repo_name: kelixlabs/curl


text:
# [Basic Data Structures: Generate an Array of All Object Keys with Object.keys()](https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/basic-data-structures/generate-an-array-of-all-object-keys-with-object-keys)

We can also generate an array which contains all the keys stored in an object using the `Object.keys()` method and passing in an object as the argument. This will return an array with strings representing each property in the object. Again, there will be no specific order to the entries in the array.

---

Finish writing the `getArrayOfUsers` function so that it returns an array containing all the properties in the object it receives as an argument.

## Setup
```js
let users = {
  Alan: {
    age: 27,
    online: false
  },
  Jeff: {
    age: 32,
    online: true
  },
  Sarah: {
    age: 48,
    online: false
  },
  Ryan: {
    age: 19,
    online: true
  }
};

function getArrayOfUsers(obj) {
  // change code below this line
  // change code above this line
}

console.log(getArrayOfUsers(users));
```

## Solution
```js
let users = {
  Alan: {
    age: 27,
    online: false
  },
  Jeff: {
    age: 32,
    online: true
  },
  Sarah: {
    age: 48,
    online: false
  },
  Ryan: {
    age: 19,
    online: true
  }
};

function getArrayOfUsers(obj) {
  return Object.keys(obj);
}

console.log(getArrayOfUsers(users)); // (4) ["Alan", "Jeff", "Sarah", "Ryan"]
```

repository: johnfelipe/progress

repo_name: johnfelipe/progress


text:
# Testing

## Run test suite
Copy `test/_setup/config/credentials.example.js` to `test/_setup/config/credentials.js` and update parameters with yours.

In a terminal, `npm run test` or `npm run coverage`.

Tests needs to be performed serially to prevent flooding eWeLink servers, so if run jest manually, add `--runInBand` parameter.

> All devices needs to be connected before running test suite.

## Using nock
Running tests can take some time because there is many requests to eWeLink servers.

To speedup this process, you need to enable nock "record & play" feature by opening `test/_setup/setupTests.js` and change `nockAction` to `record` or `play`.

The first time you need to record all your requests then you can keep testing by "playing" recorded data.

Recorded data will be stored on `test/_setup/tapes` and you can delete folder content anytime.

Set `nockAction` to `false` to disable all nock functionality.

## ZeroConf cache
While testing ZeroConf functionalty, two temporary files will be created: `test/_setup/cache/arp-table.json` and `test/_setup/cache devices-cache.json`. These files can be safely deleted once tests finished.

repository: georgeaschiopu/JS-Ewelink

repo_name: georgeaschiopu/JS-Ewelink