text:
# Release Notes

This project adheres to [Semantic Versioning](https://semver.org/).

## 6.2.2

- Fixed missing handling of `Save Results...` in the `Unihan Radical-Strokes` utility.

## 6.2.1

- Allowed alt-click as an alternative to shift-click in the `CJK Font Variants` utility.
- Added a hidden "save DOT source" debug feature to the `Unihan Variants` utility.
- Updated instructions.

## 6.2.0

- Added the full list of radical-strokes combinations as tooltip to each Unihan character listed in the `Unihan Radical-Strokes` utility.
- Added the detailed list of code points with Unicode names as tooltip to each emoji listed in the `Emoji Data Finder` utility.

## 6.1.0

- Added a "Save as SVG" feature to the `Unihan Variants` utility.
- Updated instructions and screenshots accordingly.

## 6.0.0

- Added a new `Unihan Variants` utility.
- Updated screenshots, instructions and `README.md` file accordingly.
- Improved horizontal centering of Unihan characters in the `View by Grid` feature of the `Unihan Data Finder` utility.
- Enabled opening of external links in SVG graphs.
- Updated `Electron` to version `7.1.9`.
- Updated `Electron Packager` to version `14.2.0`.

## 5.16.5

- Fixed opening of invalid anchors.
- Updated `Electron` to version `7.1.8`.

## 5.16.4

- Fixed app timestamp date.
- Updated copyright years.
- Updated emoji version dates.
- Updated handling of default smart zoom setting.

## 5.16.3

- Improved display of data table in the **Match Character** feature of the **Unihan Data Finder** utility, by graying out rows of variant characters, if any.
- Increased font size of Unihan input field for better legibility.
- Updated screenshot.

## 5.16.2

- Improved layout of Unihan data tables, by refactoring styling code.
- Cleaned up variable and class names in Unihan data tables code.
- Added regex example.
- Updated screenshot.
- Updated `Electron` to version `7.1.7`.

## 5.16.1

- Used constant terminology for characters and code points.
- Fixed typo.
- Simplified code.
- Added regex example.
- Updated screenshots.

## 5.16.0

- Moved the **Radical/Strokes** feature out of the **Unihan Data Finder** utility to a new **Unihan Radical-Strokes** utility.
- Added a new **Match Character** feature to the **Unihan Data Finder** utility, including a `Match Variants` option.
- Updated instructions and screenshots accordingly.
- Updated `Electron` to version `7.1.6`.

## 5.15.3

- Improved compact layout of chart of the **Radical/Strokes** feature of the **Unihan Data Finder** utility.
- Improved unique names for surrogates and private use characters, making use of a pattern consistent with the Unicode name derivation rules.
- Fixed removal of menu bar in license window on Linux.
- Updated `Electron` to version `7.1.5`.

## 5.15.2

- Fixed unique names of CJK Unified Ideographs, making use of the Unicode name derivation rules.
- Updated screenshots accordingly.
- Added samples for unassigned characters to the **Unicode Inspector** utility.
- Updated `Electron` to version `7.1.4`.

## 5.15.1

- Fixed incorrect display of age information in specific cases.
- Fixed missing non-character information for plane 16 private use characters.
- Added regex example to the **Match Character** feature of the **Unicode Data Finder** utility, for the total of 137,929 Unicode characters defined in [Unicode 12.1](https://unicode.org/versions/Unicode12.1.0/).

## 5.15.0

- Added tooltips with age, script, script extensions and general category to the data table rows of the **Unicode Data Finder** utility.
- Added tooltips with age and status of Unihan characters (unified or compatibility ideograph) to the data table rows of the **Find by Tag Value** feature, and to the data table cells of the **View by Grid** feature of the **Unihan Data Finder** utility.
- Added status (unified or compatibility ideograph) to the basic Unihan information of the **Unihan Inspector** utility.
- Appended date (month & year) to the age information in all utilities.
- Fixed missing age information for plane 16 private use characters.
- Updated instructions and screenshots accordingly.

## 5.14.0

- Replaced deprecated HTML Imports with explicit reading of HTML files and dynamic templates.
- Updated `Electron` to version `7.1.3`.

## 5.13.2

- Renamed license HTML file to prevent licensing ambiguity on GitHub.
- Added appropriate `lang` attribute to CJK reference links.
- Replaced custom code with `padStart()` string function for cleaner code and better performance.
- Fixed UI init order issue and added tooltip to each option of the `Locale` drop-down menu in the **Unicode Foldings** utility.

## 5.13.1

- Used stronger contrasting colors for the diff color mode of the **CJK Font Variants** utility.
- Added new regex example for `kTotalStrokes` to the **Find by Tag Value** feature of the **Unihan Data Finder** utility.
- Updated `Electron Packager` to version `14.1.1`.

## 5.13.0

- Added diff color mode to the **CJK Font Variants** utility.
- Cleaned up table creation in the **Radical/Strokes** feature of the **Unihan Data Finder** utility.
- Updated various samples.
- Updated `Electron` to version `7.1.2`.

## 5.12.1

- Added new CJK samples.
- Improved support for `Emoji 12.1`.
- Added separator lines for non compact layout in the `Radical/Strokes` feature of the `Unihan Data Finder` utility.
- Updated `Electron` to version `7.1.1`.

## 5.12.0

- Improved layout of checkboxes.
- Added support for `Emoji 12.1`.
- Added `Display Emoji Size Statistics` sample script.
- Updated `Electron` to version `7.1.0`.

## 5.11.1

- Fixed issues in `<input type="search">` fields by reverting `Electron` to version `6.1.1`.

## 5.11.0

- Improved the **Unicode Foldings** utility: added a `Locale` drop-down menu and related sample strings.
- Added a new Unicode sample script `Test Special Case Foldings` to the **JavaScript Runner** utility.
- Added an optional `Case Foldings` info field to the **Unicode Inspector** utility.
- Added Bopomofo samples to the **CJK Font Variants** utility.
- Replaced deprecated `get` functions with equivalent properties.
- Displayed custom menu bar as early as possible.
- Improved styling of disabled drop-down menus.
- Updated instructions and screenshots.
- Updated `Electron` to version `7.0.0`.

## 5.10.0

- Added a new **Unicode Foldings** utility.
- Added/updated samples, reference links and regex examples.

## 5.9.3

- Updated various samples.
- Added Unihan reference links.
- Added priority and source(s) tooltip to the IICore set field in the **Unihan Inspector** utility.
- Updated `Electron` to version `6.0.12`.

## 5.9.2

- Added unusual CJK samples to the **Unicode Inspector** utility.
- Updated screenshot accordingly.
- Used distinct background color for user text selection.
- Updated `Electron` to version `6.0.11`.

## 5.9.1

- Improved horizontal centering of CJK characters in vertical mode in the **CJK Font Variants** utility.
- Added new CJK sample string: Hiragana Named Sequences.
- Disabled unintentional user selection of table headers.
- Updated screenshots.

## 5.9.0

- Improved the results of the **Find by Tag Value** feature of the **Unihan Data Finder**: display all values, with non-matching ones grayed out.
- Updated screenshot.
- Fixed incorrect build date in About dialog.
- Updated `Electron` to version `6.0.10`.
- Updated `Electron Packager` to version `14.0.6`.

## 5.8.3

- Improved the CJK typeface widget of the **Unihan Inspector** utility.
- Improved tooltips for Unihan characters and radicals.
- Improved the presentation of regex examples in the **Match Character** feature of the **Unicode Data Finder** utility.
- Updated screenshots.

## 5.8.2

- Updated minimum size of main window to more consistent values for width and height.
- Updated instructions of the **Unihan Inspector** utility, related to the lookup of radicals.
- Added Radical hint to the **Unihan Inspector** utility.
- Updated screenshots.

## 5.8.1

- Improved info layout and dynamic links of the **Unihan Inspector** utility.
- Refactored code of the **Unihan Inspector** utility.
- Increased font size of Unihan input fields consistently.
- Fixed syntax of `--asar` option of `electron-packager` in `package.json`.
- Updated screenshots.

## 5.8.0

- Improved dynamically generated links in the **Unihan Inspector** utility, matching combinations as well.
- Added basic radical info to the **Unihan Inspector** utility when looking up radicals.
- Fixed inconsistent font in the **Radical/Strokes** feature of the **Unihan Data Finder** utility.
- Increased font weight of emoji short names in the **Emoji Data Finder** utility.
- Added System Version to the system information copied to clipboard.
- Used promise-based versions of open/save file dialog functions.
- Combined `Array.from ()` with `map ()` where relevant.
- Updated `Electron` to version `6.0.7`.

## 5.7.0

- Improved the **Unihan Inspector** utility:
    - added dynamic links to Unihan characters and code points, making use of transitory buttons on hovering
    - allowed lookup of CJK and KangXi radicals in addition to Unihan characters
    - updated and reordered fields in the basic Unicode and Unihan information lists
    - allowed display of self-variants too
    - updated instructions
    - updated screenshot
- Updated `Electron` to version `6.0.5`.
- Updated `Electron Packager` to version `14.0.5`.

## 5.6.3

- Added alternate diff visualization feature (shift-click) in the **CJK Font Variants** utility.
- Updated instructions accordingly.
- Added new samples and regex examples.
- Updated `Electron` to version `6.0.4`.

## 5.6.2

- Fixed font loading issue and improved language tooltips in the **CJK Font Variants** utility.
- Prepared for a future Traditional Chinese (Macao) language font flavor.
- Added reference link to the CJK fonts repository.

## 5.6.1

- Improved CJK language names and tags for Traditional Chinese.
- Added samples (IVD sequence, Hiragana digraph, Hangul letters) to the **CJK Font Variants** utility.
- Added sample (confusables) to the **Unicode Inspector** utility.
- Updated screenshots.
- Updated documentation.

## 5.6.0

- Fixed issue when launching second instance of app on macOS.
- Updated `Electron` to version `6.0.0`, supporting Unicode 12.1 for normalization and regular expressions.
- Used `grapheme-splitter` module.
- Updated regex examples.
- Reorganized samples.
- Added font size tooltip to slider.
- Added radical code point and name as tooltip to radicals table.
- Added missing `--asar` option for `electron-packager`.

## 5.5.1

- Added code point as tooltip to each Unihan variant character in the **Unihan Inspector** utility.
- Refactored Unihan variants code.
- Updated reference links.
- Updated `Electron Packager` to version `14.0.1`.

## 5.5.0

- Added several classes of variant characters in the basic Unihan information panel of the **Unihan Inspector** utility.
- Updated instructions accordingly.
- Updated `Electron` to version `5.0.6`.

## 5.4.2

- Allowed all *enclosed ideographs* to be displayed in the **CJK Font Variants** utility, and added them as sample strings.
- Refactored code dealing with *offscreen canvas* in the **Emoji Picture Book** utility.
- Added new regex example in the **Match Sequence** feature of the **Emoji Data Finder** utility.

## 5.4.1

- Fixed layout of error message box for search input strings.
- Added new Unicode script: `Compare Whitespace Matches`.
- Added spaces sample.
- Updated `Electron` to version `5.0.5`.
- Updated `Electron Packager` to version `14.0.0`.

## 5.4.0

- Added new interactive feature to the **CJK Font Variants** utility: visual feedback on mouse click to spot differences in glyph variations.
- Fixed grapheme segmentation of input string and improved tooltips in the **CJK Font Variants** utility.
- Added line break property to the **Unicode Inspector** utility.
- Used standard bracketed comma-separated notation for sequences of code points.
- Added Unicode and ICU versions to the system information copied to clipboard.
- Fixed window icon in Linux.
- Updated samples.
- Updated screenshots.
- Updated `Electron` to version `5.0.3`.

## 5.3.0

- Added all name aliases to the **Unicode Inspector** utility, according to the *NameAliases.txt* data file.
- Used all name aliases for search and display in the **Unicode Data Finder** utility.
- Cleaned up code: used consistent string delimiters.
- Updated instructions.
- Updated screenshots.

## 5.2.0

- Replaced the `Filter` push-button with a three-action pop-up menu in the **Filter Text** feature of the **Emoji Data Finder** utility:
    - `Discard Non-Emoji`: strip out non-emoji characters
    - `Upgrade to RGI Emoji`: restore incomplete emoji to their **RGI** form
    - `Remove Duplicate Emoji`: delete emoji duplicates
- Removed systematic deletion of duplicates in emoji data list.
- Added ISO country code to the short name of emoji flags.
- Improved status tooltip in the emoji data lists.
- Updated emoji regex examples.
- Updated samples.
- Updated instructions.
- Updated `Electron` to version `5.0.2`.

## 5.1.1

- Truncated loaded file text longer than max length.
- Added tooltip to `Results` pop-up menu button.

## 5.1.0

- Replaced `Clear Results` button with `Results` pop-up menu used to perform basic actions: `Copy Results`, `Save Results...`, `Clear Results`.
- Improved pop-up menus: positioning, visual feedback.
- Added max length to text input and text area fields.
- Fixed use of proper current target in event listeners.
- Fixed layout visual glitches.
- Updated instructions.
- Updated samples.
- Cleaned up code.

## 5.0.1

- Moved duplicated Unicode regex building code to separate module function.
- Fixed potential bug in regex pattern when Whole Word option set.
- Doubled vertical root margin in IntersectionObserver instances.
- Fixed typo in sample name.
- Updated reference links.
- Updated instructions.

## 5.0.0

- Added support for **Unicode 12.1**.
- Updated the **CJK Font Variants** utility:
    - allowed more kinds of characters to get displayed,
    - added clone of language header as extra footer.
- Added the `Vertical Orientation` property to the **Unicode Inspector** utility.
- Improved the `Run Normalization Conformance Test` script.
- Updated samples and reference links.
- Refactored and cleaned up code.
- Updated all screenshots.
- Updated `Electron` to version `5.0.1`.

## 4.7.0

- Revamped the **CJK Font Variants** utility, adding a `Writing Mode` option: `Horizontal` or `Vertical`, together with a Japanese manuscript paper-like layout.
- Added `East Asian Width` and `Emoji` properties to the **Unicode Inspector** utility.
- Added preload of embedded fonts.
- Updated samples and reference links.
- Updated `Electron` to version `4.2.0`.
- Reorganized the Unicode-related data files.

## 4.6.0

- Added Compact Layout option to the **Radical/Strokes** feature of the **Unihan Data Finder** utility.
- Removed pointless codes info for lone surrogates in the **Unicode Inspector** utility.
- Renamed Developer category to Common.

## 4.5.5

- Improved layout and display of data in the **Unicode Inspector** and **Unihan Inspector** utilities.
- Used better names for planes 15 and 16.
- Cleaned up code.

## 4.5.0

- Renamed `Binary Properties` to `Extended Properties`.
- Used *Snake_Case* for all listed Unicode property names, consistent with their regex counterparts.
- Optimized the *Match Decomposition* search option of the **Match Character** feature of the **Unicode Data Finder** utility.
- Added Regex Examples for *Match Decomposition* toggled ON.
- Updated the Noto Sans CJK set of fonts to version 2.001.
- Updated CJK character samples of the **CJK Font Variants** utility.

## 4.4.0

- Extended the *Match Decomposition* search option of the **Match Character** feature of the **Unicode Data Finder** utility.
- Sorted in lexical order `Binary Properties`, `Core Properties` and `Script Extensions` in the **Unicode Inpector** utility.

## 4.3.0

- Added Unicode sample script: **Write Parsed Numeric Values Data to File**
- Added Unihan sample scripts: **Detect Misclassified Compatibility Ideographs** and **Write Unihan Compatibility Variants to File**
- Improved layout of emoji data table in the **Emoji Data Finder** utility
- Added numeric value field and CJK Numerals samples to the **Unicode Inspector** utility
- Reordered normalization forms in the **Unicode Normalizer** utility
- Added Unihan numeric value and compatibility variants infos to the **Unihan Inspector** utility
- Updated `Electron` to version `4.1.4`

## 4.2.0

- Enhanced the *Use Decomposition* search option of the **Match Character** feature of the **Unicode Data Finder** utility.

## 4.1.1

- Refactored code and added instructions for the *Use Decomposition* search option of the **Match Character** feature of the **Unicode Data Finder** utility.

## 4.1.0

- Added simple yet powerful *Use Decomposition* search option to the **Match Character** feature of the **Unicode Data Finder** utility.
- Added CJK font variant sample.
- Added normalization form samples.
- Updated emoji CLDR annotation file.
- Fixed vertical overflow of normalized strings.

## 4.0.0

- Added support for **Unicode 12.0**, including Unihan and emoji.
- Updated instructions accordingly.
- Updated **JavaScript Runner** sample scripts.
- Updated `Electron` to version `4.0.8`.
- Revamped display of MIT License.
- Cleaned up code.

## 3.1.0

- Added **Unicode Normalizer** utility.
- Added Unicode normalization-related reference links.

## 3.0.1

- Fixed `Electron Packager` high severity vulnerability warning on install.
- Filtered out non-Unihan characters in Yasuoka variants.
- Added new Unihan sample scripts.
- Reorganized reference links.
- Updated `README.md` file.
- Cleaned up code.

## 3.0.0

- Renamed application to **Unicopedia Plus**.
- Renamed two **Match Symbol** features to **Match Sequence** and **Match Character**, respectively.
- Added new command in Developer menu: `Copy System Info to Clipboard`.
- Added new sample scripts: `Run Normalization Conformance Test` and `Write Normalization Test Data to File`.
- Added Unicode age to each Unihan character tooltip in the **View by Grid** feature of the **Unihan Data Finder** utility.

repository: simoncozens/unicopedia-plus

repo_name: simoncozens/unicopedia-plus


text:
---
title: otype
---

**node type**

Types for text objects.
As text objects are represented by nodes in
[Text-Fabric](https://github.com/annotation/text-fabric),
we shall use both *object* and *node* without much consistency.

---|---|---
`letter`       |slot          |single letter, fills a *slot*; sometimes letters are followed by a space
`word`         |tree          |word
`verse`        |section       |numbered unit of a chapter
`chapter`      |section       |numbered unit of a book
`book`         |section       |named file in the corpus

All objects have a type, which is just a label.
Objects and their slots are represented in Text-Fabric as *nodes*.
The information which object occupies which slot is stored in the edge feature [oslots](oslots).

# Letter type

The letters in the dataset are the non-white characters.
The white space characters have been stripped away.
However, the position where they have been is remembered in the feature [trailer](trailer).

# Word type

The original words are still available as a separate type.

license: MIT

repository: dirkroorda/text-fabric-data

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: dirkroorda/text-fabric-data


text:
# Domains

1.  [Overview](#overview)
2.  [Creating Domains](#creating-domains)
3.  [Subscribing to different action states](#subscribing-to-different-action-states)
4.  [API](#api)

## Overview

Domains define the rules in which resolved actions are converted into
new state. They are added to a Microcosm instance using `addDomain`:

```javascript
// Mount a domain that operates on a specific key in repo state.
// Any operations the domain handles are recorded at `repo.state.key`:
repo.addDomain('key', Domain)

// Mount a domain that operates on all repo state, handlers will
// write directly to `repo.state` itself:
repo.addDomain(Domain)
```

Domains do not enforce any particular structure. However specific
methods can be defined on domains to configure behavior at key points
in a Microcosm's lifecycle.

## Creating Domains

There are two ways to create a domains: as a class, and as a plain object. The
usage is roughly the same for both versions, the class form can additionally
take advantage of having a `constructor`.

### Domains as classes

```javascript
class Domain {
  setup(repo, options) {
    // Run startup behavior
  }
  teardown(repo) {
    // Clean up any setup behavior
  }
  handleAction(state, payload) {
    // Old state in, new state out...
    let newState = { ...state, prop: payload.prop }

    return newState
  }
  register() {
    return {
      [action]: this.handleAction
    }
  }
}

repo.addDomain('key', Domain)
```

### Domains as plain objects

```javascript
const Domain = {
  setup(repo, options) {
    // Run startup behavior
  },
  teardown(repo) {
    // Clean up any setup behavior
  },
  handleAction(state, payload) {
    let newState = { ...state, prop: payload.prop }

    return newState
  },
  register() {
    return {
      [action]: this.handleAction
    }
  }
}

repo.addDomain('key', Domain)
```

Microcosm calls `Object.create` on the simple object form, preventing any
assignments within the Domain from polluting other instances. In this way, they
are somewhat similar to the class form.

## Subscribing to different action states

Domains can provide a `register` method to dictate what actions they
listen to:

```javascript
const Domain = {
  // ... Other domain methods

  register() {
    return {
      [action]: {
        open: this.setLoading,
        loading: this.setProgress,
        done: this.addRecord,
        error: this.setError,
        cancelled: this.setCancelled
      }
    }
  }
}
```

`action` referenced directly, like `[action]: callback`, refer to the
`done` state.

## API

### `getInitialState()`

Generate the starting value for the particular state this domain is
managing. This will be called by the Microcosm using this domain when
it is started.

```javascript
var Planets = {
  getInitialState() {
    return []
  }
}
```

### `setup(repo, options)`

Setup runs right after a domain is added to a Microcosm, but before it runs
getInitialState. This is useful for one-time setup instructions.

Options are passed from the second argument of
`repo.addDomain`. Additionally, `options.key` indicates the key where
the domain was mounted:

```javascript
let repo = new Microcosm()

class Planets {
  setup(repo, options) {
    console.log(options.key) // "planets"
  }
}

repo.addDomain('planets', Planets)
```

### `teardown(repo)`

Runs whenever a Microcosm is torn down. This usually happens when a
Presenter component unmounts. Useful for cleaning up work done in
`setup()`.

### `serialize(staged)`

Allows a domain to transform data before it leaves the system. It gives
the domain the opportunity to reduce non-primitive values into
JSON.

For example, if using
[ImmutableJS](https://github.com/facebook/immutable-js), this might
look like:

```javascript
const Planets = {
  getInitialState() {
    return Immutable.List()
  },
  serialize(planets) {
    return planets.toJSON()
  }
}
```

### `deserialize(state)`

Allows data to be transformed into a valid shape before it enters a
Microcosm. This is the reverse operation to `serialize`. Drawing from
the example in `serialize`:

```javascript
const Planets = {
  getInitialState() {
    return Immutable.List()
  },
  serialize(planets) {
    return planets.toJSON()
  },
  deserialize(raw) {
    return Immutable.List(raw)
  }
}
```

### `register()`

Returns an object mapping actions to methods on the domain. This is the
communication point between a domain and the rest of the system.

```javascript
import { addPlanet } from '../actions/planets'

const Planets = {
  //...
  register() {
    return {
      [addPlanet]: this.append
    }
  },
  append(planets, params) {
    return planets.concat(params)
  }
}

repo.push(Actions.add, { name: 'earth' }) // this will add Earth
```

#### Multiple handlers for the same action

You can assign multiple handlers to an action by passing an array:

```javascript
import { addPlanet } from '../actions/planets'
import { sortBy } from 'lodash'

const Planets = {
  //...
  register() {
    return {
      [addPlanet]: [this.append, this.sort]
    }
  },
  append(planets, params) {
    return planets.concat(params)
  },
  sort(planets) {
    return sortBy(planets, 'name')
  }
}

repo.push(Actions.add, { name: 'earth' }) // this will add Earth
```

These handlers are processed from left to right, receiving the result of the prior handler as the first argument.

### `Domain.defaults`

Specifies default options a Domain is instantiated with. This
provides a concise way to configure sensible defaults for setup
options:

```javascript
class Counter {
  static defaults = {
    start: 0
  }

  setup(repo, { start }) {
    console.log(start) // 0
  }
}

let repo = new Microcosm()

repo.addDomain('counter', Counter) // default start is 0
```

When instantiated, default options are determined in the following
order:

1.  Microcosm defaults
2.  Microcosm instantiation options
3.  Domain defaults
4.  Options passed to `repo.addDomain`.


text:
This file lists how the azure-chef-extension project is maintained. When making changes to the system, this file tells you who needs to review your patch - you need a simple majority of maintainers for the relevant subsystems to provide a :+1: on your pull request.

##Project Lead
* [Adam Edwards](https://github.com/adamedx)

##Maintainers
* [Siddheshwar More](https://github.com/siddheshwar-more)
* [Nimisha Sharad](https://github.com/NimishaS)

repository: nabeelamjad/azure-chef-extension

repo_name: nabeelamjad/azure-chef-extension


text:
# Hestia
**Project in active development! Please don't use it in production.**

A production management system for CGI/VFX productions.

![Hestia (Asset Browser - V0.0.4)](./Hestia_0.0.4.png)

## FEATURES
- [x] Mostly implemented Kitsu link.
- [x] Preferences system to store login credentials.
- [x] Maya integration with Asset import/reference system.
- [x] Maya scene setup.
- [x] Basic publish system.

## Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.

### Prerequisites

You can download stable versions in github release or clone the repository.

```
git clone https://github.com/PiloeGAO/Hestia.git
```

Download pre-build binaries for [FFMPEG](https://www.ffmpeg.org/) (Needed for playblast publishing - Only available for Windows).

## Installation

1. Create a virtual environment for Python2.7 or Python 3.8.

2. Use the package manager [pip](https://pip.pypa.io/en/stable/) to install libraries.

For Python 2.7 [**Deprecated**]:
```bash
pip install -r requirements2.txt
```

For Python 3.8:
```bash
pip install -r requirements3.txt
```

3. Create a folder "ffmpeg" inside of "./Hestia/core" and copy ffmpeg files inside.

## Usage

Start the standalone app with this command:
```bash
cd ./Hestia
python __init__.py
```

To open the browser inside of Maya please add the following lines to your Maya.env:
```bash
PYTHONPATH = ;%hestiaInstallPath%\Hestia;%hestiaInstallPath%\Hestia\Hestia\dccs\maya\scripts;%yourVirtualEnvPath%\Lib\site-packages;
```
Please change %hestiaInstallPath% with the correct install path.
For the %yourVirtualEnvPath%, please follow instructions from the Installation category.
## Roadmap

Trello Board (with releases notes): https://trello.com/b/90POyZZC/hestia-dev-board

- Links to projects managers:
    - [ ] Local Folders
    - [x] Kitsu (Only for the Asset Browser - Shot assembly is WIP)
- Assets Browser:
    - [x] Maya 2020+ [Currently in development]
    - [ ] Houdini
    - [ ] Blender 2.93+
    - [ ] Guerilla Render [Currently in development]
- Shot Assembly:
    - [x] Shot setup for Maya
    - [x] Designing the main system
    - [ ] Building the HSHOT file exporter
    - [ ] Building the HSHOT file importer
- Publish System:
    - [x] Basic publish system to Kitsu.
    - [x] Take screenshot/playblast directly inside of Maya.

## Contributing
Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

## Versioning

We use [SemVer](http://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/your/project/tags).

## Authors

* **Léo DEPOIX** - *Initial work* - [PiloeGAO](https://github.com/PiloeGAO)

See also the list of [contributors](https://github.com/your/project/contributors) who participated in this project.

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details

## Acknowledgments

* IZES Team for testing this tool in production, making constructive feedback and breaking it.
* [Pôle 3D](https://pole3d.com) teachers.

repository: PiloeGAO/Hestia

gha_language: Python

gha_license_id: MIT

repo_name: PiloeGAO/Hestia


text:
# v0.11.1 (Upcoming Release)

- Concrete types of X and y changed to AbstractMatrix{Float64} and AbstractVector{Float64}
- Change function signatures from ::Function to ::F where {F <: Function}

# v0.11.0

- Deepest Regression Estimator added.

# v0.10.2

- mahalanobisSquaredBetweenPairs() return Union{Nothing, Matrix} depending on the determinant of the covariance matrix
- mahalanobisSquaredMatrix() returns Union{Nothing, Matrix} depending on the determinant of the covariance matrix
- import in DataImages fixed.
- Array{Float64, 1} is replaced by Vector{Float64}.
- Array{Float64, 2} is replaced by Matrix{Float64}.
- Use of try/catch reduced, many tries were depending on singularities.

# v0.10.1

- Update compatibility with Clustering and StatsModels

# v0.10.0

- LMS returns betas rather than coefs
- PrecompileTools integration for faster loading of package
- Replace RGB{} to RGBX{} in plots

# v0.9.5

- Adopt to SnoopPrecompile for better first-time-use experiment

# v0.9.4

- Convergency check for hs93()
- Add earlystop option for inexact version of lta().
- Remove cga() and cga based experimental algorithm.
- Fix deadlock in bacon.

# v0.9.3

- ga() is now faster.
- Implement dfbetas().
- Separate implementations of dffit() and dffits()
- Implement diagnose()
- Replace GLPK with HiGHS. When n > 10000, HiGHS based lad() is now approximately 6x faster.
- asm2000(), imon2005(), ks89(), bacon(), and smr98() now return regression coefficients calculated using the clean set of observations.
- lts() has a new optional parameter called earlystop and it is true by default. If the objective function does not change in a predefined number of iterations, the search is stopped.
- py95() returns vector of estimated regression coefficients using the clean observations.

# v0.9.2

- Increase test coverage
- Add ols(setting) and wls(setting, weights = w) type method call where setting is a regression setting
- Implement cooksoutliers() method for determining potential regression outliers using a cutoff value.
- Update documentation
- Implement Theil-Sen estimator for multiple regression

# v0.9.1

- Fix bchplot dependencies
- Update README with new instructions
- Satman2015 now returns more verbose output

# v0.9.0

- Add exact argument for LAD. If exact is true then the linear programming based exact solution is found. Otherwise, a GA based search is performed to yield approximate solutions.
- Remove dependency of Plots.jl. If Plots.jl is installed and loaded manually, the functionality that uses Plot is autmatically loaded by Requires.jl. Affected functions are `dataimage`, `mveltsplot`, and `bchplot`.

# v0.8.19

- Update Satman(2013) algorithm

# v0.8.18

- Add docs for Satman's (modified) GA based LTS estimation (2012)

# v0.8.17

- Remove dependency of StatsBase

# v0.8.16

- Quantile Regression implemented

# v0.8.15

- Modularize dataimage()
- Grouped tests
- x === nothing style decisions replaces by isnothing(x)

# v0.8.14

- Update documentation
- Modularization

# v0.8.13

- Removed some unused variables
- Refactor code
- Update docs system

# v0.8.12

- Dependency entries updated in Project.toml

# v0.8.11

- asyncmap replaced with map in lta
- JuMP version increased

# v0.8.10

- Julia compatibality level is now 1.7
- Update JuMP and GLPK

# v0.8.9

- LAD (Least Absolute Deviations) is now exact and uses a linear programming based model
- Dependencies for JuMP and GLPK are added
- Dependency for Optim removed

repository: jbytecode/LinRegOutliers

gha_language: Julia

repo_name: jbytecode/LinRegOutliers


text:
# The Locker Riddle

This simple .NET Core code was written to solve the Locker Riddle as explained on the TED-Ed YouTube video called `Can you solve the locker riddle? - Lisa Winer`.

[![Can you solve the locker riddle? - Lisa Winer](https://img.youtube.com/vi/c18GjbnZXMw/0.jpg)](https://www.youtube.com/watch?v=c18GjbnZXMw)

Feel free to suggest improvements to the algorithm.

repository: seanfisher/locker-riddle

repo_name: seanfisher/locker-riddle


text:
---
uid: tutorial-2
title: Part 2. The Device Actor
---

# Part 2: The Device Actor

In part 1 we explained how to view actor systems _in the large_, i.e. how components should be represented, how
actors should be arranged in the hierarchy. In this part, we will look at actors _in the small_ by implementing an
actor with the most common conversational patterns.

In particular, leaving the components aside for a while, we will implement an actor that represents a device. The
tasks of this actor will be rather simple:

* Collect temperature measurements
* Report the last measured temperature if asked

When working with objects we usually design our API as _interfaces_, which are basically a collection of abstract
methods to be filled out by the actual implementation. In the world of actors, the counterpart of interfaces is
protocols. While it is not possible to formalize general protocols in the programming language, we can formalize
its most basic elements: The messages.

## The Query Protocol

Just because a device has been started it does not mean that it immediately has a temperature measurement. Hence, we
need to account in our protocol for the case in which a temperature is not present. This, fortunately, means that we
can test the query part of the actor without the write part present, as it can simply report an empty result.

The protocol for obtaining the current temperature from the device actor is rather simple:

 1. Wait for a request for the current temperature.
 2. Respond to the request with a reply containing the current temperature or an indication that it is not yet
    available.

We need two messages, one for the request, and one for the reply. A first attempt could look like this:

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/DeviceInProgress.cs?name=read-protocol-1)]

This is a fine approach, but it limits the flexibility of the protocol. To understand why we need to talk
about message ordering and message delivery guarantees in general.

## Message Ordering, Delivery Guarantees

In order to give some context to the discussion below, consider an application which spans multiple network hosts.
The basic mechanism for communication is the same whether sending to an actor on the local CLR or to a remote actor,
but of course, there will be observable differences in the latency of delivery (possibly also depending on the bandwidth
of the network link and the message size) and the reliability. In the case of a remote message send there are
more steps involved which means that more can go wrong. Another aspect is that a local send will just pass a
reference to the message inside the same CLR, without any restrictions on the underlying object which is sent,
whereas a remote transport will place a limit on the message size.

It is also important to keep in mind that while sending inside the same CLR is significantly more reliable, if an
actor fails due to a programmer error while processing the message, the effect is basically the same as if a remote,
network request fails due to the remote host crashing while processing the message. Even though in both cases the
service is recovered after a while (the actor is restarted by its supervisor, the host is restarted by an operator
or by a monitoring system) individual requests are lost during the crash. **Writing your actors such that every
message could possibly be lost is the safe, pessimistic bet.**

These are the rules in Akka.NET for message sends:

* At-most-once delivery, i.e. no guaranteed delivery.
* Message ordering is maintained per sender, receiver pair.

### What Does "At-Most-Once" Mean?

When it comes to describing the semantics of a delivery mechanism, there are three basic categories:

* **At-most-once delivery** means that for each message handed to the mechanism, that message is delivered zero or
   one time; in more casual terms it means that messages may be lost, but never duplicated.
* **At-least-once delivery** means that for each message handed to the mechanism potentially multiple attempts are made
   at delivering it, such that at least one succeeds; again, in more casual terms this means that messages may be duplicated but not lost.
* **Exactly-once delivery** means that for each message handed to the mechanism exactly one delivery is made to
   the recipient; the message can neither be lost nor duplicated.

The first one is the cheapest, highest performance, least implementation overhead because it can be done in a
fire-and-forget fashion without keeping the state at the sending end or in the transport mechanism.
The second one requires retries to counter transport losses, which means keeping the state at the sending end and
having an acknowledgment mechanism at the receiving end. The third is most expensive, and has consequently worst
performance: in addition to the second, it requires the state to be kept at the receiving end in order to filter out
duplicate deliveries.

### Why No Guaranteed Delivery?

At the core of the problem lies the question what exactly this guarantee shall mean, i.e. at which point is
the delivery considered to be guaranteed:

 1. When the message is sent out on the network?
 2. When the message is received by the other host?
 3. When the message is put into the target actor's mailbox?
 4. When the message is starting to be processed by the target actor?
 5. When the message is processed successfully by the target actor?

Most frameworks/protocols claiming guaranteed delivery actually provide something similar to point 4 and 5. While this
sounds fair, **is this actually useful?** To understand the implications, consider a simple, practical example:
A user attempts to place an order and we only want to claim that it has successfully processed once it is actually on
disk in the database containing orders.

If we rely on the guarantees of such system it will report success as soon as the order has been submitted to the
internal API that has the responsibility to validate it, process it and put it into the database. Unfortunately,
immediately after the API has been invoked the following may happen:

* The host can immediately crash.
* Deserialization can fail.
* Validation can fail.
* The database might be unavailable.
* A programming error might occur.

The problem is that the **guarantee of delivery** does not translate to the **domain level guarantee**. We only want to
report success once the order has been actually fully processed and persisted. **The only entity that can report
success is the application itself, since only it has any understanding of the domain guarantees required. No generalized
framework can figure out the specifics of a particular domain and what is considered a success in that domain**. In
this particular example, we only want to signal success after a successful database write, where the database acknowledged
that the order is now safely stored. **For these reasons Akka.NET lifts the responsibilities of guarantees to the application
itself, i.e. you have to implement them yourself. On the other hand, you are in full control of the guarantees that you want
to provide**.

### Message Ordering

The rule is that for a given pair of actors, messages sent directly from the first to the second will not be
received out-of-order. The word directly emphasizes that this guarantee only applies when sending with the tell
operator directly to the final destination, but not when employing mediators.

If:

* Actor `A1` sends messages `M1`, `M2`, `M3` to `A2`.
* Actor `A3` sends messages `M4`, `M5`, `M6` to `A2`.

This means that:

* If `M1` is delivered it must be delivered before `M2` and `M3`.
* If `M2` is delivered it must be delivered before `M3`.
* If `M4` is delivered it must be delivered before `M5` and `M6`.
* If `M5` is delivered it must be delivered before `M6`.
* `A2` can see messages from `A1` interleaved with messages from `A3`.
* Since there is no guaranteed delivery, any of the messages may be dropped, i.e. not arrive at `A2`.

For the full details on delivery guarantees please refer to the [reference page](xref:message-delivery-reliability).

### Revisiting the Query Protocol

There is nothing wrong with our first query protocol but it limits our flexibility. If we want to implement re-sends
in the actor that queries our device actor (because of timed out requests) or want to query multiple actors it
can be helpful to put an additional query ID field in the message which helps us correlate requests with responses.

Hence, we add one more field to our messages, so that an ID can be provided by the requester:

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/DeviceInProgress.cs?name=read-protocol-2)]

Our device actor has the responsibility to use the same ID for the response of a given query. Now we can sketch
our device actor:

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/DeviceInProgress.cs?name=device-with-read)]

We maintain the current temperature, initially set to `null`, and we simply report it back if queried. We also
added fields for the ID of the device and the group it belongs to, which we will use later.

We can already write a simple test for this functionality (we are using xUnit but any other test framework can be
used with the Akka.NET Testkit):

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/DeviceSpec.cs?name=device-read-test)]

## The Write Protocol

As a first attempt, we could model recording the current temperature in the device actor as a single message:

* When a temperature record request is received, update the `currentTemperature` property.

Such a message could possibly look like this:

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/DeviceInProgress.cs?name=write-protocol-1)]

The problem with this approach is that the sender of the record temperature message can never be sure if the message
was processed or not. We have seen that Akka.NET does not guarantee delivery of these messages and leaves it to the
application to provide success notifications. In our case, we would like to send an acknowledgment to the sender
once we have updated our last temperature recording, e.g. `TemperatureRecorded`.
Just like in the case of temperature queries and responses, it is a good idea to include an ID field to provide maximum flexibility.

Putting read and write protocol together, the device actor will look like this:

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/Device.cs?name=full-device)]

We are also responsible for writing a new test case now, exercising both the read/query and write/record functionality
together. Note, that your test class should implement Akka.TestKit.XUnit2.TestKit in order to access CreateTestProbe().

[!code-csharp[Main](../../../../src/core/Akka.Docs.Tutorials/Tutorial2/DeviceSpec.cs?name=device-write-read-test)]

## What Is Next?

So far, we have started designing our overall architecture, and we wrote our first actor directly corresponding to the
domain. We now have to create the component that is responsible for maintaining groups of devices and the device
actors themselves.

branch_name: refs/heads/dev

gha_language: C#

gha_license_id: NOASSERTION


text:
# Nginx(proxy) - Django - Vue - Postgresql

## Deploy Django using Nginx, Postgresql
1. Deploy Django, Gunicorn, NGINX, Postgresql using Docker
2. Serve Static Files by Nginx from Django using Docker
3. Docker: Use Celery in Django(Redis as Broker)
> % Postgresql would be used in production

### Basic Usage
1. First run `make build` inside root directory.
2. Then run `make build-vue` on root directory. (See command 15.)
3. At last run `make up` to start up the project for first time.

Checkout the [commands](#commands) section for more usage.

### Preview
A default Django project resides in `src` directory. So, when you start the project, you will see the following screen in `8000` port:

![Demo One](https://github.com/ruddra/blog-images/raw/master/Demo%201.png)

Also when you access the django container log via `make log-web`, you will see the following:

![Demo Two](https://github.com/ruddra/blog-images/raw/master/Demo%202.png)

### Commands
To use this project, run this commands:

1. `make up` to make containers and start on background
2. `make build` to build the project.
3. `make start` to start containers if project has been up already.
4. `make down` to stop containers.
5. `make shell-web` to shell access web container.
6. `make shell-db` to shell access db container.
7. `make shell-nginx` to shell access nginx container.
8. `make logs-web` to log access web container.
9. `make logs-db` to log access db container.
10. `make logs-nginx` to log access nginx container.
11. `make collectstatic` to put static files in static directory.
12. `make log-web` to log access web container.
13. `make log-db` to log access db container.
14. `make log-nginx` to log access nginx container.
15. `make build-vue` make build.js file and copy to js directory

repository: YanJa/docker-django-vue

repo_name: YanJa/docker-django-vue


text:
## relBack - Oracle Backup Report
The relBack system was developed from the need for the DBA team's verify the implementation of existing backup policies for each Oracle database serviced by the team's task was carried out previously manually accessing each base and referring to the information related to backup or through emails sent by scripts stored on each server.
The centralization of information provides a quick and efficient in verifying the execution of each backup policy scheduling and as more systems are serviced and monitored is decentralized verification is concerned more and more staff time, both in check as the maintenance of scripts.
The relBack query information stored by the RMAN catalog to be able to cross the information regarding existing policies and thereby confirm that the backup performed was completed successfully and can be used at a time of crisis a restore and recovery of a base is needed.
### Instalation
1. Prepare Apache + PHP server environment, for people who do not have a lot of experience in apache configuration as I do, I suggest create a user on OS and using the LAMP package (https://bitnami.com/stack/lamp), simple installation, fast, works very well.

     1.1. Install apache >= 2

     1.2. Install PHP >= 5.6

     1.3. Install OCI8 in PHP

4. Download project
5. Extract for path destination (relBackPath), if you used LAMP, move the project to the APPS folder and change the file conf / httpd-prefix.conf, updating the folder path.
6. Configure CRON for schedules of project, this line is for the project to execute the routines with cron.
     ex: * * * * * php /relBackPath/artisan schedule:run >> /dev/null 2>&1
7. Edit file of configurations ".env"
     Basically base connection settings and for sending mail.
       ex: /relBackPath/.env
8. Execute script to create schema relback, preferably with user with dba permission
   ex: /relBackPath/database/script_create_relback.sql
     This script do:
         Create tablespace for relback, is necessary alter location of datafile.
         Create User relback;
         Grant permissons to relback;
         Grant Select permision on RMAN views;
         Create Tables;
         Create Views;
         Create Procedure;

9. In this step, when you start and configure apache, you should already be able to open the project.
     9.1. If the project start page opened normally, okay pass on.
     9.2. Review the apache configuration from the previous steps.
10. Start by registering the necessary information, in this order Client> Host> Database> Backup Policies;
11. After adding some policies, it is necessary to update the schedule, which by default is set to update the hours 00h, 06h, 12h and 18h (format HH24).
To update the schedule manually execute a procedure on the base:
execute RELBACK.SP_CREATE_SCHEDULE (sysdate-7);
By default I chose to set up the calendar with information for the last 7 days.
12. Like any good manual, if everything works out you can access the report by crossing the information between the policy agenda and the executions you perform on the Report screen.

### License
The Laravel framework is open-sourced software licensed under the [MIT license](http://opensource.org/licenses/MIT)

repository: dba-kosova/relback

repo_name: dba-kosova/relback


text:
# medSynthesis with TensorFlow (we also provide an improved version in pytorch, you can access it at https://github.com/ginobilinie/medSynthesisV1. Since the pytorch version is recently updated, all the APIs are to the latest and the network is more advanced, I suggest your use the pytorch version.)

This project is for medical image synthesis with generative adversarial networks (GAN), such as, synthesize CT from MRI, 7T from 3T, high does PET from low dose PET.

Currently, we have uploaded a 2D/3D GAN in this repository (2D is in the root folder, and 3D version is in the folder of '3dversion'). Detailed information can be found in our paper:

Medical Image Synthesis with Context-Aware Generative Adversarial Networks

If it is helpful for you, please cite our paper:

@inproceedings{nie2017medical,
  title={Medical image synthesis with context-aware generative adversarial networks},
  author={Nie, Dong and Trullo, Roger and Lian, Jun and Petitjean, Caroline and Ruan, Su and Wang, Qian and Shen, Dinggang},
  booktitle={International Conference on Medical Image Computing and Computer-Assisted Intervention},
  pages={417--425},
  year={2017},
  organization={Springer}
}

# How to run the tensorflow code
The main entrance for the code is main.py

I suppose you have installed:

         tensorflow (>=0.12.1)

      simpleITK

      numpy

Steps to run the code (since the code is implemented as early as 2016, part of the codes are deprecated, you can refer to our pytorch version for new implementations):
1. use readMedImg4CaffeCropNie4SingleS.py to extract patches (as limited annotated data can be acquired in medical image fields, we usually use patch as the training unit), and save as hdf5 format.
2. modify the g_model.py if you want to do some changes to the architecture of the generator
3. modify the d_model.py if you want to do some changes to the architecture of the discriminator
4. check the loss function in the loss_functions.py.
5. set up the hyper-parameters in the main.py
6. run the code: python main.py

# Dataset
BTW, you can download a real medical image synthesis dataset for reconstructing standard-dose PET from low-dose PET via this link:  https://www.aapm.org/GrandChallenge/LowDoseCT/

Also, there are some MRI synthesis datasets available:
http://brain-development.org/ixi-dataset/

# Cite

@inproceedings{nie2017medical,
  title={Medical image synthesis with context-aware generative adversarial networks},
  author={Nie, Dong and Trullo, Roger and Lian, Jun and Petitjean, Caroline and Ruan, Su and Wang, Qian and Shen, Dinggang},
  booktitle={International Conference on Medical Image Computing and Computer-Assisted Intervention},
  pages={417--425},
  year={2017},
  organization={Springer}
}
@article{nie2018medical,
  title={Medical Image Synthesis with Deep Convolutional Adversarial Networks},
  author={Nie, Dong and Trullo, Roger and Lian, Jun and Wang, Li and Petitjean, Caroline and Ruan, Su and Wang, Qian and Shen, Dinggang},
  journal={IEEE Transactions on Biomedical Engineering},
  year={2018},
  publisher={IEEE}
}

# License
medSynthesis is released under the MIT License (refer to the LICENSE file for details).


text:
---
id: StrMap
title: Module StrMap
---

[← Back](.)

[Source](https://github.com/gcanti/fp-ts/blob/master/src/StrMap.ts)

## strmap

```ts
FunctorWithIndex1<URI, string> &
  Foldable2v1<URI> &
  TraversableWithIndex1<URI, string> &
  Compactable1<URI> &
  FilterableWithIndex1<URI, string> &
  Witherable1<URI> &
  FoldableWithIndex1<URI, string>
```

Added in v1.0.0 (instance)

# StrMap

```ts
constructor(readonly value: { [key: string]: A }) {}
```

Added in v1.0.0 (data)

## filter

```ts
(p: Predicate<A>): StrMap<A>
```

Added in v1.4.0 (method)

## filterMap

```ts
<B>(f: (a: A) => Option<B>): StrMap<B>
```

Added in v1.12.0 (method)

## filterMapWithIndex

```ts
<B>(f: (i: string, a: A) => Option<B>): StrMap<B>
```

Added in v1.12.0 (method)

## filterWithIndex

```ts
(p: (i: string, a: A) => boolean): StrMap<A>
```

Added in v1.12.0 (method)

## foldr

```ts
<B>(b: B, f: (a: A, b: B) => B): B
```

Added in v1.12.0 (method)

## foldrWithKey

```ts
<B>(b: B, f: (k: string, a: A, b: B) => B): B
```

Added in v1.12.0 (method)

## map

```ts
<B>(f: (a: A) => B): StrMap<B>
```

Added in v1.0.0 (method)

## mapWithKey

```ts
<B>(f: (k: string, a: A) => B): StrMap<B>
```

Added in v1.0.0 (method)

## partition

```ts
(p: Predicate<A>): Separated<StrMap<A>, StrMap<A>>
```

Added in v1.12.0 (method)

## partitionMap

```ts
<RL, RR>(f: (a: A) => Either<RL, RR>): Separated<StrMap<RL>, StrMap<RR>>
```

Added in v1.12.0 (method)

## partitionMapWithIndex

```ts
<RL, RR>(f: (i: string, a: A) => Either<RL, RR>): Separated<StrMap<RL>, StrMap<RR>>
```

Added in v1.12.0 (method)

## partitionWithIndex

```ts
(p: (i: string, a: A) => boolean): Separated<StrMap<A>, StrMap<A>>
```

Added in v1.12.0 (method)

## reduce

```ts
<B>(b: B, f: (b: B, a: A) => B): B
```

Added in v1.0.0 (method)

## reduceWithKey

```ts
<B>(b: B, f: (k: string, b: B, a: A) => B): B
```

Added in v1.12.0 (method)

## separate

```ts
<RL, RR>(this: StrMap<Either<RL, RR>>): Separated<StrMap<RL>, StrMap<RR>>
```

Added in v1.12.0 (method)

## empty

```ts
const empty: StrMap<never>
```

Added in v1.10.0 (constant)

## collect

```ts
<A, B>(d: StrMap<A>, f: (k: string, a: A) => B): Array<B>
```

Added in v1.0.0 (function)

## fromFoldable

```ts
fromFoldable<F>(
  F: Foldable<F>
): <A>(ta: HKT<F, [string, A]>, f: (existing: A, a: A) => A) => StrMap<A>
```

Added in v1.0.0 (function)

Create a dictionary from a foldable collection of key/value pairs, using the
specified function to combine values for duplicate keys.

## getMonoid

```ts
<A = never>(S: Semigroup<A> = getLastSemigroup()): Monoid<StrMap<A>>
```

Added in v1.0.0 (function)

## getSetoid

```ts
<A>(S: Setoid<A>): Setoid<StrMap<A>>
```

Added in v1.0.0 (function)

## insert

```ts
<A>(k: string, a: A, d: StrMap<A>): StrMap<A>
```

Added in v1.0.0 (function)

Insert or replace a key/value pair in a map

## isEmpty

```ts
<A>(d: StrMap<A>): boolean
```

Added in v1.0.0 (function)

Test whether a dictionary is empty

## isSubdictionary

```ts
<A>(S: Setoid<A>): ((d1: StrMap<A>, d2: StrMap<A>) => boolean)
```

Added in v1.0.0 (function)

Test whether one dictionary contains all of the keys and values contained in another dictionary

## lookup

```ts
<A>(k: string, d: StrMap<A>): Option<A>
```

Added in v1.0.0 (function)

Lookup the value for a key in a dictionary

## pop

```ts
<A>(k: string, d: StrMap<A>): Option<[A, StrMap<A>]>
```

Added in v1.0.0 (function)

Delete a key and value from a map, returning the value as well as the subsequent map

## remove

```ts
<A>(k: string, d: StrMap<A>): StrMap<A>
```

Added in v1.0.0 (function)

Delete a key and value from a map

## singleton

```ts
<A>(k: string, a: A): StrMap<A>
```

Added in v1.0.0 (function)

Create a dictionary with one key/value pair

## size

```ts
<A>(d: StrMap<A>): number
```

Added in v1.0.0 (function)

Calculate the number of key/value pairs in a dictionary

## toArray

```ts
<A>(d: StrMap<A>): Array<[string, A]>
```

Added in v1.0.0 (function)

## toUnfoldable

```ts
<F>(U: Unfoldable<F>): (<A>(d: StrMap<A>) => HKT<F, [string, A]>)
```

Added in v1.0.0 (function)

Unfolds a dictionary into a list of key/value pairs

## traverseWithKey

```ts
traverseWithKey<F>(
  F: Applicative<F>
): <A, B>(ta: StrMap<A>, f: (k: string, a: A) => HKT<F, B>) => HKT<F, StrMap<B>>
```

Added in v1.0.0 (function)


text:
# Additional Notes For Running on a Windows Machine

The support for running on Windows is experimental since we mainly tested on Linux machines. In additional to the [code setup instructions](code_setup.md), you also need to meet some hardware requirement and install some dependencies differently.

## Hardware requirement

While this code runs with any modern desktop GPU in Windows, latency measures might be off and do not reflect the full capability of the hardware. By default, GTX/RTX GPUs operate in WDDM mode (intended for graphics use) instead of TCC mode (intended for general-purpose computation). Latency is not optimized for computation tasks under WDDM and you might observe runtime much larger than what's reported in the paper. To avoid such issues, you need to operate in TCC mode. Measured runtime in TCC mode in Windows should match that in Linux. However, due to NVIDIA's restriction, only certain GPUs can be put into TCC mode in Windows. Commonly known models that allow TCC mode in Windows are TITAN RTX and all Tesla series including V100. In summary, if you want to obtain reasonable results for latency-sensitive parts of this codebase in Windows, you need one of the above GPUs.

## Installing dependencies

Since the old mmdetection doesn't support Windows, you will need to switch to a newer version and with a newer mmcv.

First, set up the conda environment in the same way as in the [code setup instructions](code_setup.md):
```
conda env create -f environment.yml
conda activate sap
```

Next, install mmcv:
```
pip install mmcv==0.2.15
```

Clone mmdetection and switch to a different version
```
git clone https://github.com/open-mmlab/mmdetection.git
cd mmdetection
git checkout e60d34af8b0ec8f6e6439a0f3fb687042e9dde82
```

The last step is the same (install within the `sap` environment):
```
pip install -e .
```

## Running the scripts
Instead of running the `*.sh` scripts, you run `*.cmd` counterparts in Windows.

repository: Major-Yuan/sAP

repo_name: Major-Yuan/sAP


text:
//[uistate-lib](../../index.md)/[com.app.uistatelib](index.md)/[onSuccess](on-success.md)

# onSuccess

[jvm]\
inline fun <[M](on-success.md), [E](on-success.md)> [UiState](-ui-state/index.md)<[M](on-success.md), [E](on-success.md)>.[onSuccess](on-success.md)(successBlock: ([M](on-success.md)) -> [Unit](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/index.html)): [UiState](-ui-state/index.md)<[M](on-success.md), [E](on-success.md)>

Performs the given [successBlock](on-success.md) on the encapsulated value if this instance represents [success](-ui-state/-success/index.md).

#### Return

the original UiState unchanged.

repository: atulgpt/LibTron

repo_name: atulgpt/LibTron


text:
---
date: 2005-04-04 02:30:27
author: Jay Cuthrell
tags:
   - essays
slug: consolidation
title: Consolidation
cover:<PHONE_NUMBER>.jpg

---

Photo: A 5 minute self installation of AT&T Xtreme DSL circa 2005-ish.

Consumers are playing the part of a monk watching the beer bubbles coalesce into larger bubbles. Only, today those bubbles are called telecommunications providers. I wonder if we’ll wake up one morning with a massive hangover?

I remember what Tom Selleck promised 11 years ago.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/TZb0avfQme8" frameborder="0" allow="accelerometer; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## You will? Well, I’m still waiting.

I suppose after MCI/Quest/SBC/AT&T/Verizon/BellSouth/etc… is done coming back together there is a chance. But as these companies slash and burn to _right size_, I can’t see where the heavy R&D will be coming from to make decade old promises come any closer to reality.

Sure, there are elements of the promises around today. One could argue they are even possible to some degree — but the promise was of the ubiquitous not the proof of concept.

I guess I’ll still be fighting with self check out at the grocery store for a few years more…  Oooh… nice innovation…. you get **the customer** to do the work of a grocery store clerk. That’s a much more personal way of saying your clerk job is obsolete than by having a RFID implementation that spans all major suppliers to the retail sector.

gha_language: HTML


text:
title: Why reinvent the wheel? (April Fools)
date: 2017-04-01 21:42
category: news
tags: blog
author: aramperes
email<EMAIL_ADDRESS>
Hello everyone! So we've heard your critism and concerns about no longer planning to support Sponge on our server platform. Well, turn that frown upside down, because we are now dumping Bukkit plugins in favor of Sponge plugins!

That's right, starting from today, Glowstone will permanently consist of patches to the SpongeVanilla server software. Why reinvent the wheel when we can base our work on a much more capable server and API? You can view the source for _GlowSpone_ [here](https://github.com/GlowstoneMC/GlowSpone)! (_dead link_)

Bukkit? Gross! Use GlowSpone now and never go back to Spigot or any of its nasty derivatives.

Thank you for your continuous support,
The GlowSpone team.

**Edit: this was our April Fools post for 2017, we are not planning to support Sponge or to drop Bukkit anytime soon. Read more [here](/news/about-sponge/).**

branch_name: refs/heads/main


text:
Cookout Social, Plus DIY Media Server

Our next meeting will be essentially social & food-related, at Arkhangel Productions studios in Mt. Juliet, run by Andy & Byron! Hawley will provide burgers and drinks, and and some point Byron will tell us all about the media server system he's designed and is in the process of implementing.

Monday November 6, 7pm

Address: 1502 Saddle View, Mt Juliet, Tn 37122


text:
# Typescript 3.7 presentation
Reveal presentation to show the most important features of the new typescript version (version 3.7)

**USAGE**

This presentation was made using [reveal.js](https://revealjs.com/#/), framework created by Hakim El Hattab and contributors.
In order to install the dependencies and deploy it using a local environment, you should execute this commands:
- `npm init`
- `npm start`

gha_language: JavaScript


text:
# DataPort-Examples
A collection of examples of how to use Pecan Street Inc. Data.

https://dataport.pecanstreet.org/

## Requirements
- Python 3
- A DataPort account

## Installation / Setup
### Python Modules
The requirements.txt file has the Python modules needed for these examples.
If you are using pip then issue the command:

`pip3 install -r requirements.txt`

### Database Credentials
If you have direct database access, you'll need to enter the connection parameters and authentication credentials
into the config/config.txt file. You can find the necessary info at https://dataport.pecanstreet.org/access .

### Flat File Download
If you are a university free account, the data can be found on this page:
https://dataport.pecanstreet.org/academic
In particular the flat_file/read_csv.py example uses the `Austin 15-min (22.4 MB)` download.

## Examples
The examples directory has subdirectories containing Python 3 scripts for reading the csv
flat files downloaded from the DataPort portal as well as loading data by connecting to the
DataPort Postgres database directly.

### examples/flat_file
The flat_file directory has an example that uses the flat csv files downloaded from the DataPort portal.
To run this example, download the 15 minute Austin bundle, then untar and unzip its contents into the flat_file
directory. You'll need the `metadata.csv` file and the `15minute_data_austin.csv` to be in the same directory as
the `read_csv.py` file.

At the top of the file there's a constant set to limit the size of the dataset that is read.

`LIMIT = 10000`

This is there because the dataset is quite large, and can take a long time to load, but this will limit
time covered to a few months. Change it to `LIMIT = None` to read the entire dataset.

To run the example execute from the `examples/flat_file` directory:

`python3 read_csv.py`

### examples/database
The database directory has an example of reading the metadata and data directly from the Postgres database.
The `eclipse.py` script reads and plots solar panel generation over a few days surrounding the August 17, 2017
solar eclipse.

Be sure you configured your database connection parameters and credentials as outlined above.

To run this example execute from the `examples/database` directory:

`python3 eclipse.py`

## Dataport CSV to HDF Conversion
The kind folks at the NILMTK [repo](https://github.com/nilmtk/nilmtk) have contributed a converter for our Dataport CSV data to HDF. You can find the converter
[here](https://github.com/nilmtk/nilmtk/tree/master/nilmtk/dataset_converters/dataport).

## Contribute:
We're happy to take contributions! Submit a pull request to this repo!

repository: Pecan-Street/DataPort-Examples

repo_name: Pecan-Street/DataPort-Examples


text:
## Docs
### Rules
* Every file should have the License and Copyright at the top.
* Every pkg should have a `doc.go` file that has the `copyright - blank line - package description - then package <blah>` only. Then every other file in the package will not have the package description.
* All func, type, interfaces, etc should have a comment.
* `LICENSE` file at top level (essetially the same as the license and copyright in each go file).
* `go vet, golint, gosimple` should be run on all code and the results should be "clean".
* ***Viable, usable godoc is the goal***.

## Tests
### Rules
* Every `X.go` should have a corresponding `X_test.go` file (if applicable)
* `X_test.go` should provide full code coverage if possible.
* Do NOT create a `X_test.go` just to silent the `[no test file]` warnings.  Only create `X_test.go` with actual tests internal and a `not implemented` failure or skip.

## Dependencies
### Rules
* Dependency Management tools for golang are in flux.  Hopeful future is `go dep`.
* For now, create and check in `./vendor` sub-ddirectory.
* Create the ./vendor dir via whatever means you like.  For exmple:
** Dependencies are managed with [Glide](https://github.com/Masterminds/glide).
** Add new golang package dependencies to `glide.yaml`.  Add package version information to `glide.lock`.
** NOTE: `glide.lock` has a timestamp that is updated whenever the dependencies are checked.  This should not cause a `git` checkin, however, editing the file should be checked in.  This is not automated.
** You should only have to rum `make dep` or `make dep-update`, and only if missing packages or they are out of date.  This is not automated.

## Development Helpers
### cobra
[cobra](https://github.com/spf13/cobra) pkg is used for the `main/cmd` packages.  New `cmd` files may be added by hand, or easier, with the `cobra add` command template add.

repository: alejandroEsc/jsonsvalidator

repo_name: alejandroEsc/jsonsvalidator


text:
# Contributing guide
Want to contribute to **pendect/action-syncer**? Awesome!
There are many ways you can contribute, see below.

## Opening issues
Open an issue to report bugs or to propose new features.

## Proposing pull requests
Pull requests are very welcome.
Note that if you are going to propose drastic changes, be sure to open an issue for discussion first,
to make sure that your PR will be accepted before you spend effort coding it.

repository: Pendect/action-rsyncer

gha_language: Shell

repo_name: Pendect/action-rsyncer


text:
---
title: "Chapter 1: Of Deliverables and Deliverance"
author: The Narrator
category: episodes
layout: post
---

## Episode Summaries ##

### Episode 1 ###

What secrets hide in the dreams of a dead city that has yet to note its own demise? What dread do we bury under layers of waking nightmares, beneath more tractable and familiar horrors? What misdeeds do we ignore in the sunlight while we live in the shade afforded by the profane landscapes of steel and glass that surrounds, embraces, and suffocates us? Today, we begin to lay all bare, for the die is cast. What is seen will not be unseen.

**Played:** 29 July 2019

**TODO: write summary**

### Episode 2 ###

**Voiceover**: Joining us today as we continue our celebration of [Removed due to ongoing IP complaint.] IPO is Valfreyja of Pandora Holdings. In a rare opportunity, Valfreyja has agreed to share a few words with us today.

*[Removed due to ongoing IP complaint.]*

**Interviewer**: Before we go, can you share a few words about the secret to your success?

**Valfreyja**: I choose my fate. The only secret is what fate I have chosen to succeed by.

**Interviewer**: What do you mean?

**Valfreyja**: I record my fate for each day, so that I may know which success will be mine. If I choose my fate to be 0x09f9, then my fate will be to succeed with thunderous innocence.

**Interviewer** _(stammering)_: That's all the time we have, thank you so much for joining us!
_Valfreyja removes mic and sits impassive as the video clip fades to black._

**Played:** 12 August 2019

**TODO: write summary**

### Epsiode 3 ###

There is an order to this world, a system. All rise in power in accordance with this system, and all fall in equal accord and in due time.
Kings, emperors, popes, presidents, ministers, CEOs, all fall from their lofty heights.
Brick by brick we rise, only to fall to the poisons of our respective days.
We are the new monarchs of this age, absolute in our sovereignty over this doomed world, and we will fail as surely as every in our lineage.
This is the way, the order, the system of the world, and we will not change it --- we will merely perish trying.

**Played**: 2 September 2019

This episode opens with some definitely _not_ planning a stake-out the next day of the newly located Obelisk headquarters (borealis building) by definitely _not_ Scruffy and Margo.
Chris was _not_ waiting to find out if Vincent or Taika left the building to follow them. Zoe _was_ planning on doing her actual job for once.

In the morning the stake-out commences and Vincent and Taika are seen entering the building by Scruffy in disguise "writing his novel" in a green notebook lent to him by Margo.
Margo took her exam that morning and ... probably should spend more time studying and not hanging our with some random and occasionally attractive strangers.
Scruffy after a few hours makes eye contact with someone briefly who then enters the building with Obelisk's offices, and for fear of being found he leaves to a more remote vantage point.
Margo moves in and while watching the building entrance, she sees someone leaving the building rapidly, but not from the actual building exit.

Separately, Zoe was doing her job that morning by looking into Taika's background (clean) and getting the cops to bring in and question Taika and Vincent.
However, a call just shortly after lunch communicated that was not going to be an option as Vincent and Taika were **MURDERED**.
This call from Detective Neil Paul (homicide) was productive and he asked her if she could come down to the scene to ID the bodies and see if there were any clues that would connect the two cases.
When there, Zoe catches Neil up on the details of her case and they go up into the building to see both people shot once in the head slumped in a meeting room while seated at the conference table.
Zoe, who should have went to cop school, notices some scuffed carpet near the victims and that the bodies had their pockets emptied.
After showing the cops this, a uniform finds vincent's wallet with nothing apparently missing in a trash bin outside.
Zoe then walked around the office looking for clues to her case, and found a safe embedded in Vincent's desk.
She then with her budding larceny skills manages to get it open and put the contents in her pocket before the unis notice and walk over.
She gets kudos for noticing a clue, and then is too much in the way so she is shown out of the building.

The squad then meets up again at at different bar they had agreed upon the previous night, Zoe shares the bad news.
Scruffy made a touching memorial speech about how the world was better off without them, and to get him to stop Zoe showed them something she found at the crime scene, a Magician tarot card.
Margo touches the card, and it became hers and she just then _knew_ how it worked.
Everyone else touched it to also learn the rules/understand what she was babbling about, but knew she was the "owner".
Margo accidentally invokes the spell and then everyone had fries at dinner, despite not actually originally ordering them.

To close out the night the crew decides to go get a tarot reading from Chris' friend Imani.
She did a past/present/future reading for the group which was: the fool/inverted moon/9 of pentacles.
She tells a compelling story with this reading that seemed pretty relevant to the group 💖

## Plot ##

### Prologue (before 25 Jan 2038) ###

Zoe started her day with a case on her desk about a worker (**Maya Byrne**) who had filed a complaint against her former employer for the health issues her job caused her.
After reviewing the files, Zoe gave her a call and found out Maya couldn't walk, the workplace was always super, super rushed, and her previous boss there was named **Vincent Hall**.

The startup was in stealth mode so mostly all there was publicly was a shim site with reasonably good typography.
Looking a bit deeper in goverment records Zoe found some missing files for some applications/permits which she could get them on but was super minor.
Finally managed to find a liquor licence permit for a holding related in a paper trail to Obelisk.
It was to be held at the Lunar room at the Eclipse Hotel at 4th and Columbia on the 84th floor.
Apparently there was a party on Jan 25 that she needed to crash.

Now given she didn't have an invite to the party, Zoe needed an in.
Given the venue was fancy AF she decided to go to the fanciest bar she knew and try to find someone with an invite.
After some very expensive cocktails, she manages to hear a woman **Catalina** who was a start-up founder and complaining she didn't have the appropriate "arm candy" to take to the party.
Catalina runs a company that makes brain bran, an individually customized cereal for brain function.
Zoe grabs drinks for Catalina and her friend and turns on the charm, offering some suggestions for cap hill boutiques that Catalina could use to find what she needed to wear (Zoe knew what she ment, but was going for cute).
After a very successful seduction, Zoe has a date and an invite to the party.

### 25 Jan 2038: At the Lunar Room ###

Zoe serves Catalina's purposes well, and they both look stunning in emerald and gold gowns respectively.
They get their fancy mezcals as well as a survey of other people at the party:

- Joyce Bennett (surveillence stuff?),
- Vincent Hill: Catalina said "he didn't know which way the wind was blowing",
- Jake Wood: 2nd time founder analytical fashion and boutiques, custom programmed pieces
- Valfreya: The funder of all of he projects here tonight CEO of Pandora Holdings, no one seems to talk to her.

Valfreya opens the talks section for the year 38 kickoff and has Sam (Margo's boss) to talk, and then Catalina went next.
Valfreya esp called out she was happy Vincent Hall of Obelisk could join.
After the speeches, Zoe tries to go talk to Vincent but he was talking to Valfreya and get slapped... hard.
Zoe overheard him telling her he is a magician and told her the inner inscription of a bracelet she was wearing.
Vincent was escorted out and then the party wound down.

After going outside, Zoe sees Margo following Vincent who was attacking Scruffy.
A long chase ensues, and completly winded Zoe is the last to catch up to Scruffy and Margo as Vincent and his assistant make away into the night.
Zoe called the cops but unclear if anyone came.
A moment later, Chris comes by on his way home and we all go to a bar Chris and Zoe know to process what in the hell just happened.

### 25--28 Jan 2038: Reflecting and Searching ###

**TODO**

repository: cgranade/the-final-telling

gha_language: CSS

repo_name: cgranade/the-final-telling


text:
---
layout: post
title: Unity 2017.2 Stereo
---

It appears that Unity has accidentally left out the “Stereo Non-Head Mounted” option in the Virtual Reality Supported settings in a Unity 2017.2 release. More info on how to work-around this here:

[https://stackoverflow.com/questions/47286544/stereo-display-non-head-mounted-option-in-unity-2017-2-is-not-available](https://stackoverflow.com/questions/47286544/stereo-display-non-head-mounted-option-in-unity-2017-2-is-not-available)

And it sounds like it will be re-added in a next release:

[http://developer.zspace.com/answers/2167/unity-2017-2of3-virtual-reality-sdks](http://developer.zspace.com/answers/2167/unity-2017-2of3-virtual-reality-sdks)

Let’s hope so!

repository: widVE/UniCAVE

repo_name: widVE/UniCAVE


text:
# Starbucks launches five new cup designs for the holidays

Published at: **2019-11-07T17:55:00+00:00**

Author: **Black Press Media Staff**

Original: [North Delta Reporter](https://www.northdeltareporter.com/trending-now/starbucks-launches-five-new-cup-designs-for-the-holidays/)

Do you smell the cheer in the air? Maybe it’s just the peppermint mochas from Starbucks you’re smelling, complete with the launch of new holiday cups from the coffee shops.
Four new designs for disposable cups launched in stores Thursday, along with a reusable red cup design.
Jen Quotson, vice president of Starbucks Creative, said they hoped the festive cups would be “mini moments of joy” for customers.
“We came up with this idea of wrapping the stores in holiday joy and wrapping the cups like a gift to our partners and customers,” Quotson said. “We wanted coming to Starbucks to be like uncovering a present.”
The cups included green polka dots on a red background, a “merry coffee” cup, a striped green cup with holiday wishes, and candy cane stripes with Starbucks lettering. There is also a reusable red cup with “merry coffee” lettering.

license: Unlicense

repository: dsadlollioygjmzvcxv/tdc-exported

repo_name: dsadlollioygjmzvcxv/tdc-exported


text:
---
layout: post
title: Paperless Post
---
<div class="showcase-header">
I worked as a full-stack developer for 5 years on the stationery customization tool and on the presentation of the customized stationery to recipients. Initially, most of the front-end work was in Flash but due to its decline was replaced with JavaScript. When adding front-end functionality, I often had to update the accompanying back-end which was written in Rails and Ruby with a Postgres database. Back-end changes included updating the API, the content management system (CMS), and relevant unit tests.
</div>

### Minimum Viable Product
I was the first full-time employee and was the primary developer working on tools to allow users to create their own custom stationery. I implemented much of the initial stationery customization functionality for the site launch including the photo panning and resizing functionality seen below.

![photo stationery](/images/paperlesspost/photo_stationery.gif)

### Stationery Sets
I wrote code that allowed for automated rendering of different arrangements of stationery sets. Cards and envelopes could be reordered, positioned and rotated in relation to each other, drop shadows could be customized, and sets could be rendered as flat or standing.

![stationery sets](/images/paperlesspost/multicard_layouts_row.jpg)

### Envelope Content Editing
I was responsible for all of the editable features of the envelope. The style of the text, the postmark, the stamp, envelope liner and envelope itself are all&nbscustomizable.

![envelope content editing](/images/paperlesspost/envelope_content_editing.gif)

### Envelope Opening Animation
The envelope opening animation uses a real-time 3D rendered envelope. I created the initial texture map template and animation tool for determining the timing for the animation.

![envelope opening animation](/images/paperlesspost/envelope_opening.gif)

### Envelope Interaction
After the initial card animation, one can interact with the envelope by viewing both sides and opening and closing the flap. I programmed all of the interaction including inertia physics.

![envelope interaction](/images/paperlesspost/envelope_interaction.gif)

### Back-end Work
#### Updating Data Models
Initially, each stationery card had only one side so the data model only allowed for a single text container. I refactored it to allow for multiple text containers and wrote a script to update all the stationery to use the new model.

#### Improving CMS Workflow
When designers created new stationery, text container dimensions had to be manually entered into the CMS. The designers would determine the dimensions in an image editor then copy over each value separately into the CMS. I created a tool that allowed them to select the text area directly on the image in the CMS, saving them many hours of work.

#### Rewriting Flash Functionality
The decline of Flash necessitated porting all of the Flash functionality to HTML so that existing stationery would render exactly the same as before. I did extensive work in parsing vector graphics and fonts in the Flash file format and extracting the formatting.


text:
# Envr

Run a command using environment variables

## Installation

Install with `yarn add -g @rkingon/envr`.

## Usage

    $ envr [your command here]

## Environment Config

We use dotenv-flow under the hood, please reference for docs: https://github.com/kerimdzhanov/dotenv-flow

license: ISC

repository: rkingon/envr

repo_name: rkingon/envr


text:
# Introduction

Until now, we have created new creeps directly in the console. It’s not a good idea to do it constantly since the very idea of Screeps is making your colony control itself. You will do well if you teach your spawn to produce creeps in the room on its own.

This is a rather complicated topic and many players spend months perfecting and refining their auto-spawning code. But let’s try at least something simple and master some basic principles to start with.

# Auto-spawning creeps

You will have to create new creeps when old ones die from age or some other reasons. Since there are no events in the game to report death of a particular creep, the easiest way is to just count the number of required creeps, and if it becomes less than a defined value, to start spawning.

There are several ways to count the number of creeps of the required type. One of them is filtering `Game.creeps` with the help of the `_.filter` function and using the role in their memory. Let’s try to do that and bring the number of creeps into the console.

Add the output of the number of creeps with the role `harvester` into the console.

Documentation:

* [Game.creeps](http://docs.screeps.com/api/#Game.creeps)
* [lodash.filter](https://lodash.com/docs#filter)

## Code

```js
var roleHarvester = require('role.harvester');
var roleUpgrader = require('role.upgrader');

module.exports.loop = function () {

    var harvesters = _.filter(Game.creeps, (creep) => creep.memory.role == 'harvester');
    console.log('Harvesters: ' + harvesters.length);

    for(var name in Game.creeps) {
        var creep = Game.creeps[name];
        if(creep.memory.role == 'harvester') {
            roleHarvester.run(creep);
        }
        if(creep.memory.role == 'upgrader') {
            roleUpgrader.run(creep);
        }
    }
}
```

# Working with two harversters

Let’s say we want to have at least two harvesters at any time. The easiest way to achieve this is to run `StructureSpawn.spawnCreep` each time we discover it’s less than this number. You may not define its name (it will be given automatically in this case), but don’t forget to define the needed role.

We may also add some new `RoomVisual` call in order to visualize what creep is being spawned.

Add the logic for `StructureSpawn.spawnCreep` in your main module.

Documentation:

* [StructureSpawn.spawnCreep](http://docs.screeps.com/api/#StructureSpawn.spawnCreep)
* [RoomVisual](http://docs.screeps.com/api/#RoomVisual)

## Code

```js
var roleHarvester = require('role.harvester');
var roleUpgrader = require('role.upgrader');

module.exports.loop = function () {

    var harvesters = _.filter(Game.creeps, (creep) => creep.memory.role == 'harvester');
    console.log('Harvesters: ' + harvesters.length);

    if(harvesters.length < 2) {
        var newName = 'Harvester' + Game.time;
        console.log('Spawning new harvester: ' + newName);
        Game.spawns['Spawn1'].spawnCreep([WORK,CARRY,MOVE], newName,
            {memory: {role: 'harvester'}});
    }

    if(Game.spawns['Spawn1'].spawning) {
        var spawningCreep = Game.creeps[Game.spawns['Spawn1'].spawning.name];
        Game.spawns['Spawn1'].room.visual.text(
            '🛠' + spawningCreep.memory.role,
            Game.spawns['Spawn1'].pos.x + 1,
            Game.spawns['Spawn1'].pos.y,
            {align: 'left', opacity: 0.8});
    }

    for(var name in Game.creeps) {
        var creep = Game.creeps[name];
        if(creep.memory.role == 'harvester') {
            roleHarvester.run(creep);
        }
        if(creep.memory.role == 'upgrader') {
            roleUpgrader.run(creep);
        }
    }
}
```

# Killing a creep

Now let’s try to emulate a situation when one of our harvesters dies. You can now give the command `suicide` to the creep via the console or its properties panel on the right.

Make one of the harvesters suicide.

Documentation:

* [Creep.suicide](http://docs.screeps.com/api/#Creep.suicide)

## Code

```js
Game.creeps['Harvester1'].suicide()
```

As you can see from the console, after we lacked one harvester, the spawn instantly started building a new one with a new name.

# Releasing memory

An important point here is that the memory of dead creeps is not erased but kept for later reuse. If you create creeps with random names each time it may lead to memory overflow, so you should clear it in the beginning of each tick (prior to the creep creation code).

Add code to clear the memory.

## Code

```js
var roleHarvester = require('role.harvester');
var roleUpgrader = require('role.upgrader');

module.exports.loop = function () {

    for(var name in Memory.creeps) {
        if(!Game.creeps[name]) {
            delete Memory.creeps[name];
            console.log('Clearing non-existing creep memory:', name);
        }
    }

    var harvesters = _.filter(Game.creeps, (creep) => creep.memory.role == 'harvester');
    console.log('Harvesters: ' + harvesters.length);

    if(harvesters.length < 2) {
        var newName = 'Harvester' + Game.time;
        console.log('Spawning new harvester: ' + newName);
        Game.spawns['Spawn1'].spawnCreep([WORK,CARRY,MOVE], newName,
            {memory: {role: 'harvester'}});
    }

    if(Game.spawns['Spawn1'].spawning) {
        var spawningCreep = Game.creeps[Game.spawns['Spawn1'].spawning.name];
        Game.spawns['Spawn1'].room.visual.text(
            '🛠' + spawningCreep.memory.role,
            Game.spawns['Spawn1'].pos.x + 1,
            Game.spawns['Spawn1'].pos.y,
            {align: 'left', opacity: 0.8});
    }

    for(var name in Game.creeps) {
        var creep = Game.creeps[name];
        if(creep.memory.role == 'harvester') {
            roleHarvester.run(creep);
        }
        if(creep.memory.role == 'upgrader') {
            roleUpgrader.run(creep);
        }
    }
}
```

# Renewing creeps

Now the memory of the deceased is relegated to oblivion which saves us resources.

Apart from creating new creeps after the death of old ones, there is another way to maintain the needed number of creeps: the method `StructureSpawn.renewCreep`. Creep aging is disabled in the Tutorial, so we recommend that you familiarize yourself with it on your own.

Documentation:

* [StructureSpawn.renewCreep](http://docs.screeps.com/api/#StructureSpawn.renewCreep)

repository: arlm/creeps

repo_name: arlm/creeps


text:
# Indiana Jumps
It is a project made by CITM (Centre de la Imatge i la Tecnologia Multimedia) students of the TTC (Talent Tech Center) in Barcelona. We are Pol Casaú and Xavi Marin and we hope you enjoy the game.

Indiana Jumps is a platformer game where you put yourself in the shoes of an adventurer, with the objective of arriving to the end of each level avoiding all the obstacles and impediments that you will find across the map.

You won't complete the levels if you bump into cactus or if you fall into the water; there are also enemies which you can kill by sliding at them, but they will follow you, so be careful while jumping through the map!

## Information

### Website
If you want to know more about the game and about us:
- Visit our [Website](https://bullseye14.github.io/IndianaJumps/)

### Controls
- Move: LEFT/RIGHT
- Jump: SPACE
- Slide: DOWN
- Double Jump: SPACE x2

### Debug Functions
- F1: Start from the very first level
- F2: Start from the beginning of the current level
- F5: Save the current state
- F6: Load the previous state
- F9: View colliders logic
- F10: Activate / Deactivate God Mode
- F11: Activate / Deactivate frame cap

## Authors
* Pol Casaú
  - Github: [Bullseye14](https://github.com/Bullseye14)

* Xavi Marín
  - Github [Xavimarin35](https://github.com/xavimarin35)

* Group's Github link
  - [Indiana Jumps](https://github.com/Bullseye14/Development-Pol-Xavi)

## Accomplishments
### Pol:
- Map updates: Parallax and adapt it to enemies' movement
- Enemies' spritesheet
- Sliding
- Zombie entity
- Brofiler
- UML file

### Xavi:
- Timer: Frame cap and timer modules
- Sliding
- Entity system
- Pathfinding
- Bird entity

## License

Licensed under the [MIT License](LICENSE)

repository: marcgreig/IndianaJumps

repo_name: marcgreig/IndianaJumps


text:
# Installation
> `npm install --save @types/exceljs`

# Summary
This package contains type definitions for exceljs ( https://github.com/exceljs/exceljs ).

# Details
Files were exported from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/exceljs

Additional Details
 * Last updated: Wed, 13 Feb 2019 18:42:05 GMT
 * Dependencies: @types/node
 * Global values: none

# Credits
These definitions were written by Rogier Schouten <https://github.com/rogierschouten>, Ali Taheri Moghaddar <https://github.com/alitaheri>.

gha_language: TypeScript


text:
### [CVE-2005-3488](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3488)
![](https://img.shields.io/static/v1?label=Product&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

Scorched 3D 39.1 (bf) and earlier allows remote attackers to cause a denial of service (long loop and server hang) via a negative numplayers value that bypasses a signed check in ServerConnectHandler.cpp.

### POC

#### Reference
- http://aluigi.altervista.org/adv/scorchbugs-adv.txt
- http://marc.info/?l=full-disclosure&m=113095941031946&w=2

#### Github
No PoCs found on GitHub currently.

repository: trickest/cve

repo_name: trickest/cve


text:
# cdpgen

The cdpgen tool is used to generate the Golang API for the Chrome DevTools Protocol from the protocol definitions (JSON).

Beware, this tool is not a feat of engineering, it's only purpose is to generate the Golang API. It has gone thourgh many revisions while prototyping the API and might contain both messy and dead code.

## Installing

```console
go get -u github.com/mafredri/cdp/cmd/cdpgen
```

## Usage

The current protocol definitions are committed in this repository under the `protodef` directory.

### Generating the cdp package

```console
$ cdpgen -dest-pkg github.com/mafredri/cdp \
    -browser-proto $GOPATH/src/github.com/mafredri/cdp/cmd/cdpgen/protodef/browser_protocol.json \
    -js-proto $GOPATH/src/github.com/mafredri/cdp/cmd/cdpgen/protodef/js_protocol.json
```

### Updating protocol definitions

```console
$ ./update.sh
```

## Future improvements

- Better formatting for comments, consider sentence construction, proper casing and line length.

repository: mafredri/cdp

gha_language: Go

repo_name: mafredri/cdp


text:
---
layout: post
title: Server Bootstrap with Ansible
tags: ansible
---

Over the past few months, I’ve been posting on using Ansible for network automation.  Changing things up a bit, this post will cover using Ansible for server automation and I’ll share a few Ansible playbooks that I’ve built and have been using to bootstrap servers and prep them for various applications such as OpenStack and NSX deployments.

### Step 1 - Playbook 1
*Creating password-less root account*

Since Ansible uses SSH by default for connecting to the servers, you will realize the first thing that needs to be done is to copy the public key of where you will execute playbooks from onto the “new” server.  To do this, I use a playbook that is called server_one_time_run.yml.  You will notice that in this playbook, and only in this playbook, I have remote_user set to jedelman and sudo set to yes.

I’ve been testing against bare-metal and virtual machine installs using an Ubuntu ISO image.  During the OS install process, “jedelman” is the account that was created on all hosts and virtual machines.

This playbook runs and copies over the public key in the root directory.  We are essentially creating a password-less login for the root account, so going forward, all other playbooks can be run using the root account.  Realize this may not be best practice!

Three other things to remember and take note of:

* This first playbook needs to be with the --ask-sudo-pass and –k options.  This allows you to enter the SSH and sudo passwords for the account you created upon installing your Linux OS while running the playbook.  I was debugging ssh for longer than I’d like to admit to figure out the –k was needed
* You also need to install openssh-server (or another of your choosing) on the server before running this playbook.
* If like me and you are doing many re-builds in a short amount time, you may need to update/remote hosts from the local known_hosts file.  The ssh-keygen command can be used here, if needed.

After running this playbook, you can ssh to one of your servers with the root user and ensure you aren’t being prompted for a password.

### Step 2 - Playbook 2
*Baseline Apps Install*

The second playbook that I’ve been running gets a slew of apps installed onto the system, but first adds the Ubuntu Cloud Archive (for OpenStack Icehouse) to host’s source list.  This playbook’s name is base_apps.yml.  Note that all playbooks going forward are using “remote_user: root”

I was hitting a bug using older versions libvirt and OVS (from the standard repo) --- using the cloud archive cleared it up right away.  So net net, don’t install OVS or libvirt until after the Ubuntu Cloud key ring is added and an update and upgrade are performed, especially if you want to test OVS and libvirt with VLANs.  You can actually find this in some of the OpenStack install documentation as well.

This playbook finishes by adding a new user account and installing xrdp.  I’m just toying with building some hosted labs and “netops” is the account that I was using to login to rdp although any of them will work.

### Step 3 - Playbook 3
*OVS Install*

The next step is to get OVS installed.  This is using the ovs-default.yml playbook.  Because I was testing with NSX, I used a few OVS files specific to NSX.  This playbook copies the NSX files from my machine running Ansible to each hypervisor node and installs each .deb after the initial package was untar’d.  Assuming most of you aren't testing this with NSX, you can use the off the shelf OVS files.

### Step 4 - Playbook 4
*OVS & Network Config*

Once OVS is installed, the next step will be to get it configured. This time I used the playbook called ovs-config.  Because I was testing a few different variations not always using a management interface that wasn’t running OVS, many of the lines are still commented out, but if you had a dedicated management interface, most of it should run right through.  You can still try it, but you’ll get disconnected after making a change to the NIC you are SSH’d in through :).

The physical servers I’m testing with have 2 physical NICs.  Most often, one was being used for management and one was used for production, or virtual machine, traffic. A single OVS bridge was being used for each and they are carrying multiple VLANs over the links.  Note: I only have br-mgmt’s config in the playbook right now.

Note: there is more background that is required to understand libvirt with OVS and VLANs.  This is not that post although you should be able to learn more about it by reading through the playbooks.

You will also notice in line 31 in ovs-config.yml, there is a template file being copied over (again, from my machine) onto the target node.  This is replacing the /etc/network/interfaces file on the target machine with the updated settings I wanted for each node.

While I was going through the libvirt, VLANs, and OVS build out, Scott Lowe (@scott_lowe) was a huge help.  Big shout out to Scott!!  Hopefully, in the near future, I can write a single post on that without Ansible to articulate some nuances encountered along the way!

### Files

All playbook information described can be found on my github page [here](https://github.com/jedelman8/server-build-ansible).

Thanks,
Jason

Twitter: @jedelman8