text:
### Frequently Asked Questions

#### Why Vibora ?

 - I needed a framework like Flask but async by design.

 - Sanic is a good idea with some unforgiven mistakes IMHO.

 - Aiohttp is solid (and well thought) but I dislike some
   interfaces and I think it could be a lot sexier (lol).

 - I was unaware of Quart and I have mixed feelings about
   being __compatible__ with Flask.

 - Japronto is currently a proof of concept.

 - Apistar, although I like it, is far away from being like Flask.

 - Tornado, is too old to be sexy and fast.

 - Flask/Django are sync and always will.
   Don't get me wrong, being sync isn't bad but it just doesn't fit in some situations.
   You can do whatever magic you want to make them async but sync interfaces like "request.json" will haunt you.

 - I'm a big fan of type hints and very few projects use them.

#### Where the performance comes from ?

  - Cython. Critical framework pieces are written Cython so it can leverage "C speed" in critical stuff.

  - Common tasks as schema validation, template rendering and other stuff were made builtin in the framework,
    written from scratch with performance in mind.

#### Is it compatible with PyPy ?

  - No. PyPy's poor C extensions compatibility (performance-wise) is the biggest problem.
    Vibora would need to drop its C extensions or duplicate implementations (Cython powered X pure Python).
    In the end I would bet that Vibora on PyPy would still be slower than the Cython-powered version.
    I'm open to suggestions and I'm watching PyPy closely so who knows.

#### Why not use Jinja2 ?

  - Jinja2 was not built with async in mind.

  - I would need to write a cython compiler for it anyways (Vibora one is in-progress).

  - I want a bit more freedom in the template syntax.

  - And of course: because it looked like an exciting challenge.

#### Where is Japronto on benchmarks ?

  - Vibora was almost twice as fast before network flow control was a concern,
    what that means is that is very easy to write a fast server but not so easy to build a stable one.

  - Although Japronto inspired some pieces of this framework
    it's missing a huge chunk of fixes and features.

  - The author of the framework does not encourage the usage of it and so do I.

  - Japronto may be faster than Vibora on naked benchmarks thanks to impressive hand-coded C
    and faster HTTP parser (pico X noyent).

  - Vibora may use "picohttparser" in the future but right now I don't think it's a wise move because
    it's less battle tested.

  - Hand-coded C extensions can be a nightmare hell to non-expert C devs so I'm not
    willing to replace Cython with baby cared C code. Still I'm willing to replace Cython with Rust extensions
    if they get stable enough.

  - Compare a proof of concept against a fully featured framework is just dumb.

#### Why don't export the template engine into a new project ?

  - If people show interest, why not.

#### What about Trio ?

  - Trio has some interesting concepts and although it's better
  than asyncio in overral I'm not sure about it. Python async community
  is still young and splitting it is not good. We already have a bunch
  of libraries and uvloop so it's hard to move now. I would like to see
  some of it's concepts implemented on top of asyncio but that need some
  serious criativity because of asyncio design.

#### Can we make Vibora faster ?

  - Sure. I have a bunch of ideas but I'm one man army. Are you willing to help me ? :)

repository: PranayJain/vibora

repo_name: PranayJain/vibora


text:
# Installation of EFTfitter.jl

EFTfitter.jl is written in the [Julia programming language](https://julialang.org/).
To use it, you need to install Julia itself, the EFTfitter.jl and BAT.jl Julia packages as well as a few additional Julia packages.

## Installing Julia

Julia is available for Linux, OS-X and Windows, and easy to install:

* [Download Julia](https://julialang.org/downloads/).

* Extract the archive, resp. run the installer.

* You may want to add the Julia `bin` directory to your `$PATH`. To get the location of the Julia `bin` directory on OS-X or Windows, start a Julia session (via applications menu) and run the Julia command `Sys.BINDIR`.

## Installing EFTfitter.jl
EFTfitter.jl is a registered Julia package.
To install it, simply run:
```julia
julia> using Pkg
julia> pkg"add EFTfitter"
```

If you want to use the latest development version of BAT (main branch), instead of the latest stable release, use
```julia
julia> using Pkg
julia> pkg"add EFTfitter#main"
```
### Installing dependencies: BAT.jl and further Julia packages
BAT.jl (v.2.0) is required for EFTfitter. To install it, run:
```julia
julia> using Pkg
julia> pkg"add BAT"
```

You will also need to install the following Julia packages to run the EFTfitter.jl examples:
```julia
julia> using Pkg
julia> pkg"add Distributions IntervalSets Plots ValueShapes StatsBase"
```
## Further information
If you'd like to [precompile](https://docs.julialang.org/en/v1/manual/modules/index.html#Module-initialization-and-precompilation-1) all installed packages right aways (otherwise they'll get precompiled when loaded for the first time), run:

```julia
julia> pkg"precompile"
```

For further infortmation on how to set up Julia and BAT.jl see the [installation guide](https://bat.github.io/BAT.jl/dev/installation/) of the [BAT.jl documentation](https://bat.github.io/BAT.jl/dev/).

license: MIT

branch_name: refs/heads/main

extension: md

gha_language: Julia

gha_license_id: NOASSERTION

license_type: permissive


text:
# IEEE Paper Template for Pandoc

[![Build Status](https://travis-ci.org/stsewd/ieee-pandoc-template.svg?branch=master)](https://travis-ci.org/stsewd/ieee-pandoc-template)

## Requirements

- [Pandoc](http://pandoc.org/)
- [Texlive](https://www.tug.org/texlive/)

### Ubuntu

```sh
sudo apt update
sudo apt install pandoc pandoc-citeproc texlive-full
```

### Fedora

```sh
sudo dnf install pandoc pandoc-citeproc texlive-scheme-full
```

## Quick Start Guide

- Clone or download this repo.
- Put all your paper content in `paper.md`.
- Change the title and author in `metadata.yaml`.
- Run `make` in a terminal.
- The pdf will be on `build/paper.pdf`.

## Files

| File               | Description                                                                                |
|--------------------|-----------------------------------------------------------------------------------------------------------------------------------|
| `metadata.yml`     | On this file put all your metadata (author, title, abstract, etc) that will be use for rendering the final pdf.                   |
| `paper.md`         | Here you put all your paper content, if you wish, you could put your content on separate files, but you must edit the `makefile`. |
| `bibliography.bib` | Here put all the bibliography that is used in the paper.                                                                          |
| `bibliography.csl` | This file is for specify to pandoc how to display the cites (ieee format).                                                        |
| `template.latex`   | It is used to tell pandoc how to render the paper using the metadata and content of your paper.                                   |
| `makefile`         | It is used to compile the pdf, usually the default options are fine.                                                              |
| `build/`           | On this directory will be final pdf. Make sure to add this to your `.gitignore` file if you are using git.                        |

## Recommended Tools

### Editors

- [Vim](http://vim.org)/[Neovim](https://neovim.io/) + [vim-pandoc extension](https://github.com/vim-pandoc/vim-pandoc)
- [Atom](http://atom.io) + [language-pfm extension](https://atom.io/packages/language-pfm) + [autocomplete-bibtex extension](https://atom.io/packages/autocomplete-bibtex)

### Bibliography manager

- [Zotero](https://www.zotero.org/) + [Better Bibtext extension](https://github.com/retorquere/zotero-better-bibtex)

repository: stsewd/ieee-pandoc-template

branch_name: refs/heads/master

gha_language: TeX

gha_license_id: MIT

repo_name: stsewd/ieee-pandoc-template


text:
This repo contains a few implementations of concepts taught in
[Reinforcement Learning: An Introduction](http://incompleteideas.net/book/the-book-2nd.html)
by Sutton and Barto. I wrote these for my own understanding and practice,
but they may be helpful for fellow programmers working through the book.

license: Unlicense

repository: richardjs/sutton-barto

repo_name: richardjs/sutton-barto


text:
# RigidBodyTreeInspector

[![Build Status](https://travis-ci.org/rdeits/RigidBodyTreeInspector.jl.svg?branch=master)](https://travis-ci.org/rdeits/RigidBodyTreeInspector.jl)
[![codecov.io](https://codecov.io/github/rdeits/RigidBodyTreeInspector.jl/coverage.svg?branch=master)](https://codecov.io/github/rdeits/RigidBodyTreeInspector.jl?branch=master)

---

**Note:** This package should still work, but development has moved to [MeshCatMechanisms.jl](https://github.com/JuliaRobotics/MeshCatMechanisms.jl) which offers more features and fewer binary dependencies. New users are encouraged to use MeshCatMechanisms.jl instead of this package.

---

This package provides a simple tool for inspecting and manipulating the kinematic structure of a robot inside of an [IJulia](https://github.com/JuliaLang/IJulia.jl) notebook. It relies on several other packages to provide this functionality:

* [tkoolen/RigidBodyDynamics.jl](https://github.com/tkoolen/RigidBodyDynamics.jl) to parse and represent kinematic structures
* [RobotLocomotion/director](https://github.com/RobotLocomotion/director) for 3D visualization
* [rdeits/DrakeVisualizer.jl](https://github.com/rdeits/DrakeVisualizer.jl) to communicate with `director`
* [rdeits/LCMCore.jl](https://github.com/rdeits/LCMCore.jl) for message-passing and communication

## Demos

For detailed examples of usage, check out the IJulia notebook demos in [examples](https://github.com/rdeits/RigidBodyTreeInspector.jl/tree/master/examples).

# Examples

Here we show the three different visualization modes available in this package. In each case, we'll be looking at the NASA Valkyrie robot, which we loaded from the URDF files in <https://github.com/RobotLocomotion/drake/tree/master/drake/examples/Valkyrie>. These results are all taken from [examples/urdf.ipynb](https://github.com/rdeits/RigidBodyTreeInspector.jl/blob/master/examples/urdf.ipynb)

### Pure kinematic skeleton

This visualization shows every joint in the model as a sphere, with a cylindrical rod between every pair of connected joints. It's useful primarily for inspecting the way various joints and bodies can move.

![valkyrie skeleton](img/val_skeleton.png)

When rendered inside an IJulia notebook, a slider is created for each joint in the model:

![inspector sliders](img/sliders.png)

### Inertial ellipsoids

The inertial visualization adds to every link on the robot an ellipsoid which would have the same mass and rotational inertia as the robot's actual link. Note that different ellipsoids may have different densities, so this may produce strange results for robot links that have large rotational inertias but small masses (like the fingers in the Valkyrie model):

![valkyrie inertia](img/val_inertia.png)

### Meshes

Finally, we can render the actual meshes for each link in the robot:

![valkyrie meshes](img/val_mesh.png)


text:
# Example grunt-hologram style guide

This is an example project that uses
[hologram](http://trulia.github.io/hologram) to build [this style
guide](http://trulia.github.io/hologram-example). In order to build the
style guide yourself, run the following:

    cd hologram-library
    grunt hologram

View compiled styleguide at /docs/styleguide/index.html

**Note:** This example uses jQuery loaded from a CDN to build a simple menu navigation. You'll need to run a local server to see this menu in action.

# License

Like hologram itself, this example is licensed under the MIT license.


text:
---
title: Setup
weight: 900
---

## Main functions

### Power

The gateway gets its power by PoE (Power over Ethernet) through the UTP cable or by the 11-30 volt connector on the gateway. The 11-30 volt power connector makes it possible to combine the gateway with a DC solar system. There is also a backup battery inside the gateway which can provide up to 1 min of power to ensure a safe shutdown of the gateway.

The gateway supports both the 802.3af and 802.3at PoE specifications, although there are some incompatible PoE devices: TP-Link TL-POE150S, Cisco Catalyst 3850, TP-LINK TL-SF1008P, NETGEAR FS108PEU, Laird POE-48I. The bundled PoE adapter is usually 15W, for outdoor use 30W is recommended. The [default Microsemi one](https://www.microsemi.com/product-directory/single-port-non-rackmount-midspans/3931-pd-3501g-ac), Microsemi PD9001GR/AT/AC and Tenda PoE15F injectors seem to work correctly.

### Data

The gateway can be connected to the internet using ethernet or by a cellular GSM/3G network.

### Antenna

The antenna comes with a 1m of RG58 coax cable with N-type male connectors on each end. The antenna is a 3dBi gain omnidirectional. There is also a bracket to mount the antenna in the correct orientation to the gateway body.

![Antenna bracket](../kerlink-antenna.jpg)

It is advised to always have the antenna connected when switching on the gateway. Booting the gateway without an external antenna my result in damage to the low noise amplifier. Depending on the environment where the gateway is placed, earthing and surge protection is recommended.

## UTP cable

After unpacking the Kerlink Wirnet Station, open the case by putting a screwdriver in the bottom notch (where the antenna connector is located).

![Open the case](../utp-1.jpg)

Connect a UTP network cable to the green screw terminal. Cable colors are noted next to the connector. You can use an existing cable by cutting off the connector from one side, or you need to make up a new cable with an RJ45 connector on one end, [watching the color scheme](https://en.wikipedia.org/wiki/TIA/EIA-568).

![Attach ethernet cable](../kerlink-ethernet-connection.jpg)

Attach the UTP cable attached to the Kerlink Wirnet Station to the “data & power Out” port of the power adapter. Connect the “data IN” port of the power adapter to your existing network. If you use PoE switches, the power adapter is not needed.

![Attach the PoE injector](../utp-2.jpg)

After powering on, check your DHCP server which IP-address the gateway uses. In the rare case that your network doesn't use a DHCP server, the gateway will use the static IP `<IP_ADDRESS>`. The LEDs inside the gateway do not work by default, they only work for about a minute after shortly pressing the “Test” button. This includes the power LEDs.

![Test button](../utp-3.jpg)

To check if the gateway is online you can try to ping its IP address, or try and log into it using SSH.

## USB port

The USB 1.1 Type-A port is used for flashing gateway firmware.

## Debug port

The debug port can be used to attach to the Linux console of the gateway. See [Configuration]({{< relref "../config" >}}) for more information.

## SIM-card

If you'd like to use a GPRS/3G connection, insert the SIM-card now. The gateway uses a "standard SIM" / "regular SIM" / "Mini-SIM" / 2FF sized sim card.

1. Remove the SIM card holder of the Kerlink Wirnet Station by pressing the extraction button with a little screwdriver.
2. Place the SIM card in the SIM card holder.
3. Carefully insert the SIM card holder with the SIM card in the Kerlink Wirnet Station.
4. Configure the settings for the SIM card.

![SIM card holder](../sim.png)

repository: TheThingsNetwork/docs

gha_language: Go

repo_name: TheThingsNetwork/docs


text:
## Zip Ahoy
Zip Ahoy is a small convenience library for creating/extracting directories to/from zip-files in C#.

### Why
Although there are already high-level helper methods for this in the System.IO.Compression.* namespaces, they lack support for cancellation, and a way to get meaningful progress reporting at a more fine-grained level than per-file.

ZipAhoy adds these things in two simple high-level static methods.

### How to install
There is a nuget package, called ZipAhoy.

Alternatively, grab the source, and add the ZipAhoy class library to your project. If you want to run the tests, you need to install the XUnit test runner Visual Studio extension.

### Examples
There are usage examples in the ZipAhoy.Tests project.

### License
ZipAhoy is under the MIT license. See LICENSE.md for details.

repository: luiseduardohdbackup/zipahoy

repo_name: luiseduardohdbackup/zipahoy


text:
---
title: "Email Management: Filters and Rules"
slug: "email-management-filters-and-rules"
excerpt: "Use filters and create rules to customize how email integrations process events"
hidden: false
createdAt: "2017-05-10T15:59:28.238Z"
updatedAt: "2020-10-09T21:11:13.581Z"
---
# Advanced Email Management: Extracting Information with Regular Expressions

When using the **regular expression** (also called regex) option to create an incident key for email management rules, you will need to use a capture group, which in regex is defined as anything between a set of parentheses "( )".
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/860a907-ebbf611-Screen_Shot_2017-01-20_at_9.56.55_AM.png",
        "ebbf611-Screen_Shot_2017-01-20_at_9.56.55_AM.png",
        892,
        112,
        "#e3eaea"
      ]
    }
  ]
}
[/block]

[block:callout]
{
  "type": "warning",
  "title": "Important note regarding HTML emails and content encoding",
  "body": "Email management regular expressions are compared on the text of the email _after decoding_ per the encoding specified by `Content-Transfer-Encoding`. However, `Content-Type` is ignored, i.e. if after base64-decoding (if the encoding is base64) the underlying message is HTML, and there is no plain text copy of the email included, then *the regular expression will be run on the HTML code,* not on the text that would result after rendering the HTML or stripping out HTML tags.\n\nThus, if the emails are sent only as HTML (`Content-Type: text/html`), note that any regex written to match the text content alone may not work. HTML tags and hidden linebreaks / whitespace can potentially interfere with your regular expressions matching the input as expected.\n\nSee [Troubleshooting](#section-a-regular-expression-that-should-match-the-body-is-not-matching) for further details.
</Callout>

##Capture Group
A capture group will tell PagerDuty to create an incident key from the text contained within the parentheses. If the unique identifier within the capture group changes (i.e. a ticket ID # or host ID #) you can use `\d+`, which tells PagerDuty to capture all subsequent digits.

Similarly, if you want to capture a specific number of digits you could use `\d` to stand in place of each digit. For example, you could use `\d\d\d\d` or `\d{4}` if the unique identifier always contains 4 digits.

##What if my Unique Identifier Already has Parentheses?
In some instances your unique identifier may already have parentheses around it. For example, let’s say you want to create an incident key based on the ticket numbers contained within the parentheses of this Zendesk email:
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/7536a64-32fe6b0-zendesk.jpg",
        "32fe6b0-zendesk.jpg",
        606,
        106,
        "#494f5d"
      ]
    }
  ]
}
[/block]
In this case you would use a backslash (`\`) at the beginning; the backslash is an escape character that tells PagerDuty "the following character should be treated as text."
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/c6cfe85-6dc7e56-incident_key_zendesk.jpg",
        "6dc7e56-incident_key_zendesk.jpg",
        765,
        116,
        "#e4e4e3"
      ]
    }
  ]
}
[/block]
##Specifics of PagerDuty's Capture Group Implementation
PagerDuty's email management rules use Google's [RE2](https://github.com/google/re2) for regular expression handling, and additionally adds some custom behavior. Some specific things to be aware of:
- You are not allowed to use nested groups, so if you try and use this regular expression, you will get an error while saving the service `(([0-9])[0-9])`.
- If you give multiple capture groups, we will concatenate what is captured in each group together, using the `-` character. For example if you match `([a-z])([a-z])` against "ab", we will use "a-b" as the extracted data.
- We always add two options to your regular expression (both of which are documented in the RE2 documentation) when extracting data.
    - `s`, which means that the `.` special character this will also match newlines (`\n`).
    - `m`, this is called multi-line mode, which causes `^` and `$` to match the beginning and end of lines in addition to beginning and end of the entire text.
    - A consequence of these two behaviors and regex greediness is that `(.*)$` will match everything until the end of the document — we recommend using ([^\n]*) if you just want to match everything until the end of the line.

##External Resources
[Regex101](https://regex101.com/) is a regular expression editor and a great resource to double-check your regex, and it provides a quick reference for common expressions.  Be sure to select the **Golang** flavor in the left column and enable the *single line* and *multi line* flags.

##Other Options
One thing to note — it is not necessary to always use regex when building an incident key. Using the "all text between" drop down option is a quick and easy way to tell PagerDuty to create an incident key between A and B. Or if your incident key never changes you could use the "everything" drop-down.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/c3a9f65-56de3fe-Screen_Shot_2017-01-20_at_9.58.33_AM.png",
        "56de3fe-Screen_Shot_2017-01-20_at_9.58.33_AM.png",
        869,
        152,
        "#4770b5"
      ]
    }
  ]
}
[/block]
# Limit Noise with Email Integration Filters

Email filters in PagerDuty [email integrations](https://www.pagerduty.com/docs/guides/email-integration-guide/) allow you to disregard certain messages arriving at the integration email address. An email's subject, body, and from address can be checked against either a safelist or blocklist [regular expression](https://support.google.com/analytics/answer/1034324?hl=en) (regex) filter. Messages that don’t pass the filter will be silently discarded.

In general, we suggest using [Regex101](https://regex101.com/) to test your regular expressions. If your regular expression works with the sample text you enter into Regex101 using the **Golang** flavor with *single line* and *multi line* options enabled, it should work for text of the same format in PagerDuty also. Please reference our [regex tips and examples](#section-regular-expression-tips-examples) article for more information on how regex work.

## Configure a Regex Filter

To set up a regex filter:

1. Go to **Services** :fa-arrow-right: **Service Directory** and select the service with the email integration.
2. Go to the **Integrations** tab and click the email integration you want to edit, then click **Edit Integration**.
3. Under Email Filters, select one of the email filters:
    - **Accept all incoming email**: PagerDuty will not filter out any emails that are sent to your integration email address.
    - **Accept email only if it matches ONE OR MORE rules below**: Emails will only be accepted if they match at least one filter rule.
    - **Accept email only if it matches ALL of the rules below**: Emails will only be accepted if they match all filter rules
4. Configure your rules — whether the email subject, body, and from address should match or not match the regex.
5. In the edit fields, enter the value to match or not match (this field will not be available if **is anything** was selected).
6. Click **Save**.

<Callout type="info" title="Info">
Regular expressions are case sensitive. We suggest using a pipe (`|`) to capture different upper/lowercase strings. i.e. `(Down|DOWN|down)`",
  "title": "Note
</Callout>

Below is an example of how to use email filters to filter events based on their critical/noncritical status. In this example, you send emails with the subjects CRITICAL and NONCRITICAL to PagerDuty, but you only want those with CRITICAL in the subject to trigger incidents.
1.  Go to **Services** :fa-arrow-right: **Service Directory** and select the service with the email integration.
2. Go to the **Integrations** tab and click the email integration you want to edit, then click **Edit Integration**.
3. Under Email Filters, select **Accept email only if it matches ALL of the rules below**.
4. Add two filter rules:
    1. The first rule should be **The email subject matches the regex** `CRITICAL`.
    2. The second rule should be **The email subject does not match the regex** `NONCRITICAL`.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/1b16a53-86365ce-Screen_Shot_2017-02-07_at_1.45.09_PM.png",
        "86365ce-Screen_Shot_2017-02-07_at_1.45.09_PM.png",
        1004,
        466,
        "#f2f2f2"
      ]
    }
  ]
}
[/block]
The **Accept email only if it matches ALL of the rules below** option ensures that both rules will be applied to incoming events. The reason you need both filter rules is because NONCRITICAL contains the word CRITICAL, so the second rule prevents messages with the subject NONCRITICAL from being accepted, even though it contains the word CRITICAL.

It's also important to note that regex filters are case sensitive, so if your email subject contains **Critical**, **critical**, or any other variation that is not **CRITICAL**, the message will not be accepted using this example. Email filters cannot be made case insensitive using `(?i)` like email management rules can. We suggest using a pipe (`|`) to capture different upper/lowercase strings if you do not use one case everywhere, for example: `(Critical|critical|CRITICAL)`.
5. Click **Save changes**.

# Regular Expression Tips & Examples

Regular expressions are a fairly standard and well-documented way of matching text, and can be used in [email-based integrations](https://www.pagerduty.com/docs/guides/email-integration-guide/) to either include or exclude certain keywords from creating incidents. Even using Google on the first try for specialized regular expressions will often return good results, since people have been using them to complete the same simple tasks for decades.

Here is an example of a common regular expression:

Your service is receiving emails, however you only want the service to create incidents and notify you if they are either critical or severe, as determined by your monitoring system, which sends out notifications starting with the words "CRITICAL" or "SEVERE" in the subject line when the occasion arises.

The regular expression you would use to only match incidents of this type would be: `^(CRITICAL|SEVERE)`

The `^` means the subject line starts with this, and `(CRITICAL|SEVERE)` means the starting word can be either "CRITICAL" or "SEVERE".

##Case Sensitivity
Regular expression rules are case sensitive, so "DOWN", "down", and "Down" are all considered different strings and will not both match against the same regex. You can make your email management rules case insensitive by adding `(?i)` to the beginning of the line, for example: `(?i)(critical)`

This will capture all cases: "critical", "CRITICAL", "cRiTicAL", etc.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/3b50b74-Screen_Shot_2018-06-12_at_3.08.18_PM.png",
        "Screen Shot 2018-06-12 at 3.08.18 PM.png",
        1924,
        318,
        "#f6f6f6"
      ]
    }
  ]
}
[/block]

<Callout type="info" title="Info">
The case insensitivity modifier `(?i)` will only work with email management rules, it will **not work** with email filters. Due to this issue, we suggest using a pipe (`|`) to capture different upper/lowercase strings for email filters, for example: `(Down|DOWN|down)`",
  "title": "Note
</Callout>

##Testing
Writing regular expressions can be difficult, but [Regex101](https://regex101.com/) is a very helpful tool for editing regular expressions and making sure that the expression is correct.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/068e122-Screen_Shot_2020-09-24_at_12.39.39_PM.png",
        "Screen Shot 2020-09-24 at 12.39.39 PM.png",
        2380,
        894,
        "#f2f3f2"
      ]
    }
  ]
}
[/block]
To test an expression in Regex101, enter your test string (in this example, the body from which you want to extract the node for use as the alert key for grouping purposes) and then make sure that your entered regular expression shows a *Group 1* **match** within the test string.

##Examples
[block:parameters]
{
  "data": {
    "h-0": "Filtering For",
    "h-1": "Filter Options and Regular Expression",
    "0-0": "\"Open Escalations\" or \"[JIRA] Commented:\"",
    "0-1": "`((Open Escalations)|(\\[JIRA\\] Commented:))+`",
    "1-0": "- All emails that contain \"Priority 1\" or \"Priority 2\" and \"Failed\" in the subject\n- AND contains \"Warning to Failed\" or \"Normal to Failed\" in the message body\n- AND only accepts emails from<EMAIL_ADDRESS>    "1-1": "- The email subject matches the regex: `([\\s\\S]*)(Priority 1 | Priority 2)+([\\s\\S]*)(Failed)+`\n- AND the email body matches the regex: `(Warning to Failed)|(Normal to Failed)`\n- AND the from address matches the regex<EMAIL_ADDRESS>    "2-0": "Only trigger incidents from specific domains",
    "2-1": "`(domain1.com|domain2.com|domain3.com|domain4.com)+`",
    "3-0": "Filter out e-mail replies that include \"RE:\" or \"FWD:\" at the beginning of the e-mails",
    "3-1": "The email subject does not match the regex `\\ARE:|\\AFWD:`"
  },
  "cols": 2,
  "rows": 4
}
[/block]
# Replies and Email Forwards are Triggering a New Incident

By default, PagerDuty email integrations accept any messages from any sender, including messages addressed to multiple recipients. When someone replies to all recipients on an email with recipients that include the email integration address, an email will be sent to the email integration address. This results in a new incident being opened in addition to the original incident from the initial send.

If you want to forward emails to your email integration address, and have additional forwards de-duplicate to your open incident, you can use email management rules to prevent replies from triggering extraneous incidents.

To set up the email management rule:
1. Go to your email integration and click **Edit**.
2. Under **Email Management**, select the option **Open and resolve alerts based on custom rules**.
3. Create a rule:
    1. **Trigger** an incident if **Any of the following conditions apply:**
    2. The email **subject matches the regular expression:** `.*`
    3. For the incident key, have the rule state: **In the email subject, match this regular expression:** `(?:(?i)re: |fwd: )?(.*)`
4. Click **Save changes** at the bottom of the page.

<Callout type="info" title="Info">
This regular expression is case insensitive, so any version of \"RE:\" or \"FWD:\" will de-duplicate the email trigger to the open incident.",
  "title": "Note
</Callout>

[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/8291ef1-2b2ad20-RE_-_Email_Parse_-_PagerDuty.jpg",
        "2b2ad20-RE_-_Email_Parse_-_PagerDuty.jpg",
        1152,
        799,
        "#ece9ec"
      ]
    }
  ]
}
[/block]
Replies and forwards will now be appended to the existing incident as additional triggers.

# Trigger and Resolve Alerts with Email Management Rules

By default, PagerDuty opens a new incident every time an email is received at the integration address of an [email integration](https://www.pagerduty.com/docs/guides/email-integration-guide/). Depending on how your monitoring tool works, this behavior might not be desirable.

The first line of defense in limiting unnecessary noise in email integrations are [email filters](#section-limit-noise-with-email-integration-filters). These filters select which of your inbound events will become events on your service, and which events will be discarded.

Once an event is accepted by your email filters, email management rules may be used to determine the way accepted events will behave. PagerDuty's email management feature allows you to automatically resolve incidents from email integrations by creating custom rules to parse messages and specify how they should be handled.
- [Control when a New Incident is Triggered](#section-control-when-a-new-incident-is-triggered)
- [Auto-Resolve Existing Events with Alert/Incident Keys](#auto-resolve-existing-events-with-alert/incident-keys)
- [Creating your Rules](#section-creating-your-rules)

##Control when a New Incident or Alert is Triggered

You can control when PagerDuty creates new incidents or alerts in response to emails by adjusting your integration settings.

To set how new incidents will be created in your email integration:
1.  Go to **Services** :fa-arrow-right: **Service Directory**.
2. Click on the name of the service that contains the integration, then go to the **Integrations** tab and click the name of the integration to find the **Edit** button.
3. Under the **Email Management** section, choose a new setting, then click **Save**.

The following settings are available, stating either incident *or* alert depending on how you've configured your service's Incident Behavior settings (step 6 of [this section](https://support.pagerduty.com/docs/services-and-integrations#section-create-a-new-service)):

- **Open a new incident/alert for each trigger email**: Each email sent to the integration email address opens a new incident.
- **Open a new incident/alert for each new trigger email subject**: Emails with the same subject line de-duplicate. For example, if PagerDuty previously opened a new incident because it received an email with the subject “Host Down”, a second email with the same subject will not cause create a new incident. Instead, the new email will be appended to the existing incident’s activity log.
- **Open a new incident/alert only if an open incident does not already exist**: The integration can have only one open incident at any time. If an email is received while the integration already has an open incident, it is appended to the existing incident’s activity log.
- **Open and resolve incident/alerts based on custom rules**: This option will be explored in-depth in the next section of this article.

The last two options above will append incoming emails matching the criteria to existing alerts/incidents, as shown below:
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/db9101e-89bd320-Screen_Shot_2017-01-27_at_5.08.49_PM.png",
        "89bd320-Screen_Shot_2017-01-27_at_5.08.49_PM.png",
        903,
        480,
        "#f5f7f5"
      ]
    }
  ]
}
[/block]
##Auto-Resolve Existing Events with Alert/Incident Keys
Selecting the last option in your email management rules -- **create and resolve incidents based on custom rules** -- allows you to automatically resolve incidents from email integrations by parsing message content.

Email management uses a set of rules that is applied to any incoming email. Each rule has three components:
1. A **condition** that tells PagerDuty if the email should create an event
2. A **condition** that tells PagerDuty if the email should resolve an event
2. An **alert** or **incident key** that tells PagerDuty how to match one email with another email.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/ec16b93-64bdf9d-Screen_Shot_2017-01-31_at_4_00_31_PM.png",
        "64bdf9d-Screen_Shot_2017-01-31_at_4_00_31_PM.png",
        927,
        216,
        "#e0e5de"
      ]
    }
  ]
}
[/block]
In the example above, the **alert/incident** key has been highlighted in green. The **conditions** are in caps: DOWN for trigger, UP for resolve.
[block:callout]
{
  "type": "info",
  "title": "Auto-Resolving with an Alert Key",
  "body": "For a pair of trigger and resolve email management rules to work together, the alert key in both rules **must be a perfect match.** The alert key is what allows your service to pair events and apply resolve rules to existing events.
</Callout>

##Creating your Rules
1. Specify if PagerDuty should trigger or resolve an incident and the criteria of the email.
2. Specify the alert/incident key — the alert/incident key de-duplicates emails that have the same identifiers, and will append the email to an existing alert or incident.
3. Optional — you can add additional criteria in the Custom Field if you'd like to extract additional data from the email. This can be useful with certain integrations, like Zendesk. This allows you to bring the most pertinent information from your emails to the foreground. As an example, here is an incident where a rule was written pulling all text from the body of the email after the word **hello** into Custom Details:
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/5a96370-email-management-custom-details-example.png",
        "email-management-custom-details-example.png",
        719,
        535,
        "#f2f2f3"
      ]
    }
  ]
}
[/block]

<Callout type="info" title="Info">
If an email matches your \"resolve\" rule but there is no open incident for that email to resolve **OR** the email's incident key does not match an existing open incident, then this rule will not be applied.",
  "title": "Note
</Callout>

Just as with email filters, you can use regular expressions to create complex management rules - however regular expression are not mandatory. You can review how to create a regular expression in [Regular Expression Tips & Examples](#section-regular-expression-tips-examples).

In some cases, you may want to create an additional rule by clicking **Add Another Rule**. When you create multiple rules, PagerDuty will apply the first rule to the incoming email, and if it doesn't match it will attempt to apply the second rule. The hierarchy continues in this order until it reaches your last rule. There is a limit of ten rules per service. Rules may be re-arranged by clicking the **Move up** and **Move down** buttons on each rule.

Finally, if an email doesn't match any of the rules, PagerDuty will either create a generic incident or discard the email. Use the drop down menu to specify your preference — you can either **create a generic incident** or **discard it** (the email).
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/fa6f368-35cdbdf-Screen_Shot_2017-01-31_at_5.59.17_PM.png",
        "35cdbdf-Screen_Shot_2017-01-31_at_5.59.17_PM.png",
        1005,
        301,
        "#4472bd"
      ]
    }
  ]
}
[/block]
# Troubleshooting Email Management Rules

Email management is a powerful tool for giving responders an accurate state of your system, but it can sometimes be tricky.

Here are some solutions to frequently seen problems.
* [My trigger emails are not making it through](#section-trigger-email-are-not-making-it-through)
* [My resolve emails are not resolving incidents](#section-resolve-emails-are-not-resolving-incidents)
* [I'm getting an error message](#section-error-message-email-handler-email-action-rules-value-extractors-matcher-must-have-at-least-one-capture-group-)
* [A Regular Expression That Should Match the Body Is Not Matching](#section-a-regular-expression-that-should-match-the-body-is-not-matching)

##Trigger Email are not Making it Through
First, check your email filters. PagerDuty evaluates email filters before management rules in order to reduce noise and ensure all emails come from a verified sending address.

If you think the filters might be dropping email, try resetting them to "Accept all incoming email" and then try again. Keep in mind that changes to your email filters will not be applied to events that came in before the changes were made.

If you are using filters, double-check your regular expressions to ensure that you are actually letting your desired emails through.

If you're still not seeing emails you expect, scroll to the bottom of your email management rules, and make sure "Create a generic incident" is selected. This is the default setting for handling emails that don't match your rules, but if another user changed it, any unmatched emails will be discarded.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/d6dd5c9-e407d40-email_management.png",
        "e407d40-email_management.png",
        1219,
        591,
        "#e8e9e7"
      ]
    }
  ]
}
[/block]
##Resolve Emails are not Resolving Incidents
Three things are required to successfully resolve an incident:
1. A rule that tells PagerDuty when an email should be considered a trigger notice
2. A rule that tells PagerDuty when an email should be considered a resolve notice
3. A shared incident key between the two emails

Verify that you have the correct rules set. PagerDuty will display the extracted incident key on the incident page, so you can verify it is the same between your trigger and resolve emails.
[block:image]
{
  "images": [
    {
      "image": [
        "https://files.readme.io/9543e47-0e9dd37-email_management_2_.png",
        "0e9dd37-email_management_2_.png",
        1002,
        225,
        "#e3ede4"
      ]
    }
  ]
}
[/block]
Specific reasons a resolve email might not be successfully resolving:
1. You are extracting an incident key with a regular expression, and it is not extracting the key correctly.
2. The email body was poorly encoded in some way (for example, if it was UTF-8 encoded, but contained the byte \xFF).
3. There is a trailing space in either your trigger or resolve rules, but not in both. This means that one email has an incident key with an additional space, and therefore will not match.

##Error Message: "Email handler email action rules value extractors matcher must have at least one capture group"
This error message means that you need to specify a capture group in your regular expression. Oftentimes, this can be resolved by enclosing your regular expression in parentheses.

## A Regular Expression That Should Match the Body Is Not Matching

If you have checked your email management rules against the email, and it seems like a regular expression that should match isn't working for some strange reason, check to see whether the emails are being sent in both plain text and HTML, or plain text. If the emails are only getting sent in HTML, the HTML tags may be interfering with the pattern matching.

If the email also includes a plain text version, then the rule will still be able to find a match. However, if the emails are being sent as HTML-only, note that the regular expression may not match because there are HTML tags and elements interspersed within the text content that makes up the searched-for pattern. It may help to view the raw email that was checked for a match in the email rules.
[block:callout]
{
  "type": "info",
  "title": "To view the source code of the email sent to the integration",
  "body": "Go to **View Message** in the incident detail view. This should take you to a page displaying the full details of the original event sent in. The URL should be formatted as follows:\n\n```\nhttps://{subdomain}.pagerduty.com/incidents/{incident_id}/log_entries/{log_entry_id}\n```\n\nNext, click \"View Raw Message\" and you will see the source code of the email including headers.
</Callout>

While viewing the source code, note that email management rules that operate on the body of the email use the raw body as input, after decoding (i.e. if the `Content-Transfer-Encoding` of the body is `base64`, it will be decoded from base 64, or if it's `quoted-printable`, then QP escape sequences will be replaced with the actual characters to represent the underlying content of the message). Thus, to view the true source of the email that the regular expressions are compared against, one must decode the text.

### Base64-encoded Text

```
Content-Transfer-Encoding: base64
```

Base64-encoded messages are not humanly readable, but are easily decoded into a plain text message using a broad variety of software. One of the simplest and most effective is the `base64` command line program already available on many Linux-based and Unix-based systems, including Mac OS X.
[block:callout]
{
  "type": "info",
  "title": "Example of base64-encoded text",
  "body": "**Decoded** (Regex runs on this text):\n```\nAll work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy.\nThe quick fox jumps over the lazy brown dog.\n```\n\n**Encoded** (Regex does not run on this text):\n```\nQWxsIHdvcmsgYW5kIG5vIHBsYXkgbWFrZXMgSmFjayBhIGR1bGwgYm95LiBBbGwgd29yayBhbmQg\nbm8gcGxheSBtYWtlcyBKYWNrIGEgZHVsbCBib3kuClRoZSBxdWljayBmb3gganVtcHMgb3ZlciB0\naGUgbGF6eSBicm93biBkb2cuCg=\n```\n\nDecoding with `base64`:\n```\nbase64 -D < file-containing-base64-message.txt\n# or this:\ncat file-containing-base64-message.txt | base64 -D\n```
</Callout>

### Quoted-Printable Text

```
Content-Transfer-Encoding: quoted-printable
```

Messages with [Quoted-printable](https://en.wikipedia.org/wiki/Quoted-printable) encoding are much easier for humans to read without decoding (if the message is written in mostly [ASCII](https://en.wikipedia.org/wiki/ASCII) characters), but there are also a variety of tools available for decoding.

When reading quoted-printable encoded text raw, one must be aware of the _escape sequences_  of characters that constitute part of the encoding or that are a representation of a character and not their literal selves. Non-[ASCII](https://en.wikipedia.org/wiki/ASCII) characters will be represented as escape sequences, as will equals signs.

Furthermore, lines are limited to 76 characters, and if need be to limit line length, the line in the final encoded text will be broken two or more lines with a linebreak and an equals sign at the end of every line but the last in the series.
[block:callout]
{
  "type": "info",
  "title": "Example of quoted-printable encoding",
  "body": "**Decoded** (Regex runs on this text):\n\n```\nAll work and no play makes Jack a dull boy.  All work and no play makes Jack=\n a dull boy.\nThe quick fox jumps over the lazy brown dog.\nE =3D mc^2\n```
</Callout>

repository: tpgaviria/pd-kb

repo_name: tpgaviria/pd-kb


text:
# Users

## Synopsis

Add configuration data to manage users

Place any number of json files in this folder.
Each file should contain an array of objects.
What properties to place on each object depends on the parameters present on the relevant 'Register-*'-Command.
For a full description of the supported properties, see the parameter descriptions:

  Get-Help Register-DMUser -Detailed

repository: ActiveDirectoryManagementFramework/ADMF

gha_language: PowerShell

repo_name: ActiveDirectoryManagementFramework/ADMF


text:
# bf19 interpreter

This is an interpreter for [bf19](https://esolangs.org/wiki/Brainfuck%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B%2B), an esoteric programming language created by CosmicMan08#1975, written in Rust. bf19 was designed to be really terrible, and to continue with this theme (and definitely not because I am too lazy to test the things I make), this interpreter is also very terrible. Enjoy!

It currently implements every instruction except for `1` and `7`, which I may or may not add in the future.

## usage
Run the program and enter your bf19 code on the first line of stdin


text:
---
layout: post
title:  "Reinventing the Wheel"
date:   2016-12-21 17:00:00 +1300
tags: c# wpf
excerpt_separator: <!--more-->
---
It's an age-old question that just about every WPF developer has asked:  How can I bind an event to a command?

<!--more-->

The internet would have you believe that the only way to bind a command on the view model to an event in the view is by using the *Microsoft.Windows.Interactivity* library.  This works, but the syntax to accomplish it is so remarkably verbose that it's almost a hindrance.

Suppose you wanted to execute a command when the focus left a text box.  The *Interactivity* way to do this is:

```xml
<TextBox Text="{Binding SomeText}">
  <i:Interaction.Triggers>
    <i:EventTrigger EventName="LostFocus">
      <i:InvokeCommandAction Command="{Binding SomeCommand}"/>
    </i:EventTrigger>
  </i:Interaction.Triggers>
</TextBox>
```

That's a lot of code for a simple binding!

## An attempt was made

Caliburn.Micro has completely mooted the issue by its strange "convention" black magic.  I, for one, prefer to be able to read my code (and that written by my peers), and many of the things that they do simply serve to obfuscate the intent.  They use runtime reflection to "bind" handlers on the view model by name.  There are a lot of options, but rather than replicate them here, I'll [link to the docs](https://caliburnmicro.codeplex.com/wikipage?title=Cheat%20Sheet) instead.  (They even mention the method above as their "long version.")  You can see that there's a lot of Angular-style magic happening here.

Another problem with what they've done is there's little to no design-time support.  It's all just magic strings, and if it's not set up just right, it won't work.

On the other hand, being explicit with your bindings tends to aid code readability.  And if you use the `d:DataContext` directive to set a view model type, you get design-time checking and Intellisense for view model properties on bindings.  If something isn't right, you'll get at least a warning from the compiler.

There are other issues that I have with this framework, but that's not what this post is about.  In fact, I like many parts of it and use a reduced version in my own private and professional development.

## A (The) new solution

What we need is a way to bind the command to the event <u>in a familiar way</u> that also provides as much design-time checking as possible.

Enter the `EventBinding` class.  This is a special markup extension that solves this pesky problem.  Using `EventBinding`, a handler can be attached which invokes the desired command and with the familiar binding markup syntax.

```xml
<TextBox Text="{Binding SomeText}"
         LostFocus="{fmwk:EventBinding SomeCommand}"/>
```

That's it!  When the event fires, the command will execute.

## How it works

First, in order to use any class as a markup extension, it must derive from `MarkupExtension`.  So let's start there.

```c#
public class EventBinding : MarkupExtension
{
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        throw new NotImplementedException();
    }
}
```

Right now it only explodes.  But we can still use it if we like crashing our application.

To get the command name, we need to add a constructor that accepts a single string argument.  We'll save that name for later.

```c#
private string _commandName;

public EventBinding(string commandName)
{
    if (_commandName == null)
        throw new ArgumentNullException(nameof(commandName));

    _commandName = commandName;
}
```

Next, consider that an event is just a delegate.  In order to execute the command, we'll need something that wraps the execution in a method which matches the event delegate signature.  Then we just return the method as a new delegate.

*Just*.  As if it were that simple.  The problem is that different event handlers have different signatures, so we need to make sure that our method can morph into the common event handler delegate signatures.  Fortunately they tend to follow a pattern: an `object`-typed sender, a typed event argument, and a void return.  We can use this pattern combined with generics to our advantage.

To wrap the command, we'll create a new class.  It should be private and contained within `EventBinding` since it's an implementation detail and nothing else needs to know about it.

```c#
private class EventCommandHandler
{
    private readonly ICommand _command;

    public EventCommandHandler(ICommand command)
    {
        if (command == null)
            throw new ArgumentNullException(nameof(command));

        _command = command;
    }

    public void Handle<T>(object sender, T e)
    {
        if (_command.CanExecute(e))
            _command.Execute(e);
    }
}
```

Not much to that.  We'll handle providing a type for the generic parameter within the implementation of `ProvideValue()`.  But first, let's turn our attention to the delegate we wish to return.

To create a delegate, we'll need a few things:

- the type of the event handler delegate
- an `EventCommandHandler` instance
- the `MethodInfo` for the `EventCommandHandler.Handle<T>()` method with generic type provided

Getting the handler instance is easy: we create it.  But to do that we need the command instance from the view model (it's a parameter in the `EventCommandHandler` constructor).  To get *that*, we cheat a little.

Instead of jumping through hoops to manually evaluate a binding, we let bindings work for us.  We need an object that has a data context and an `ICommand`-typed dependency property.  We could use an existing control like a `Button`, but by creating one we incur slightly less overhead.  This class should be private to `EventBinding` as well.

```c#
private class BindingTarget : FrameworkElement
{
    public static readonly DependencyProperty CommandProperty =
        DependencyProperty.Register("Command", typeof(ICommand),
                                    typeof(BindingTarget),
                                    new PropertyMetadata(null));

    public ICommand Command
    {
        get { return (ICommand)GetValue(CommandProperty); }
        set { SetValue(CommandProperty, value); }
    }
}
```

Now we instantiate our `BindingTarget`, set the data context, and apply the binding, then the `Command` property should be the instance on the view model.  So where do we get the data context?

Fortunately for us, `ProvideValue()` comes with an `IServiceProvider` parameter.  And yes, it's exactly what it says it is.  Since it's built into WPF we just smile and nod; we don't argue about how service providers are a hideous anti-pattern from the devil.  In this case, it benefits us.  We need an instance of an `IProvideValueTarget`.  This exposes two properties: `TargetObject` which gives us the control that contains our event, and `TargetProperty` which gives us (in this case) an `EventInfo` for the event we're trying to handle.  With these two properties (properly cast) we can acquire all the information we need to ultimately create our delegate.

Since we have an immediate need for the binding target, let's start there.  First we check whether our target has a `DataContext` property by ensuring it derives from `FrameworkElement`.

```c#
var target = provider.TargetObject as FrameworkElement;
if (target == null)
    throw new ArgumentException(
        "Event bindings can only be set on types derived from FrameworkElement.");
```

Next we create a new `BindingTarget` instance, set the data context, and apply the binding.

```c#
var tempTarget = new BindingTarget {DataContext = target.DataContext};
var binding = new Binding(_commandName);
BindingOperations.SetBinding(tempTarget, BindingTarget.CommandProperty, binding);
```

Now we can get the view model's command instance from our temporary target.

```c#
var command = tempTarget.Command;
```

And we can finally create our `EventCommandHandler` instance.

```c#
var handler = new EventCommandHandler(command);
```

That takes care of the handler instance.  We still need a typed `MethodInfo` for the `Handle<T>()` method and the event handler delegate type.  To get the typed `MethodInfo` we need to know the type of event arguments used by the event handler delegate.  Since we can get the parameter type from the event delegate type, let's start there.

```c#
var handledEvent = provider.TargetProperty as EventInfo;
Type eventType;
if (handledEvent == null)
{
    var handledMethod = provider.TargetProperty as MethodInfo;
    if (handledMethod == null)
        throw new ArgumentException("Event bindings can only be set on events.");
    eventType = handledMethod.GetParameters()
                             .Last()
                             .ParameterType;
}
else
    eventType = handledEvent.EventHandlerType;

var eventType = handledEvent.EventHandlerType;
```

***EDIT** In testing this code, I found that events like `MouseEnter` and `LostFocus` actually come through the `TargetProperty` as methods, not events.  This is because these events forward their implementation to the `Mouse` and `FocusManager` classes, respectively.  I *did* find, however, that there was a pattern here as well: the last parameter in these methods is the event handler, so we can grab it from there.*

That's our event delegate type.  The parameter type just requires a little reflection.

```c#
var eventArgsType = eventType.GetMethod("Invoke")
                             .GetParameters()
                             .Last()
                             .ParameterType;
```

Now we use a little more reflection to get a typed `MethodInfo` from the handler and we can create our delegate.

```c#
var handlerMethod = typeof(EventCommandHandler)
                        .GetMethod(nameof(handler.Handle))
                        .MakeGenericMethod(eventArgsType);

return Delegate.CreateDelegate(eventType, handler, handlerMethod);
```

And we're done.  We have successfully bound a command to an event.

Technically, it's not a true binding in that updates on the view model won't be reflected in the view.  It's more akin to a one-time binding: the handler is created once.  And if the command isn't set by the time the view binds to the view model, then you'll likely get a nasty run-time error.

### Design-time support

Sadly, support for custom markup extensions is somewhat limited.  [This SO answer](http://stackoverflow.com/a/1702978/878701) gives a good explanation as to why and a possible workaround if you're into that sort of thing.  But since his workaround isn't something that can easily be packaged, I've decided to just live with the shortcomings.

The parts that aren't supported are the two exceptions we throw in `ProvideValue()`.  If you try to use this binding on a property instead of an event, or if you manage to bind to an event on a non-`FrameworkElement`, you won't hear about it until runtime.

Interestingly, however, the property checking and Intellisense still work.  So if you mistype your property name, the compiler will complain about it.  It's not anything specific that we did; it just works.  +1 for the win!

### The completed code

You can find the complete class [here](https://1drv.ms/u/s!AsfebNc2nZnZhqJZalJvB8YSJx2dAA), if you'd like to download and go.  I'll also consider putting it up on Nuget if any interest is shown.

repository: gregsdennis/coding-for-smarties

gha_language: HTML

repo_name: gregsdennis/coding-for-smarties


text:
# Data Product Enrichment

In this tutorial we will look at data product enrichment - adding new
or derived information to an existing data product.

## Preliminaries

Of course we need the client so we can talk to the server...

```python
#!/usr/bin/python3
from terminusdb_client import WOQLClient
import os
import json
import urllib.parse

team = os.environ['TERMINUSDB_TEAM']
team_quoted = urllib.parse.quote(team)
client = WOQLClient(f"https://cloud.terminusdb.com/{team_quoted}/")
client.connect(db="nuclear", team=team, use_token=True)
```

## Calculated Values

Our power plants have information about their capacity, and they have
information about their annual production, but they don't give us
their capacity factor.

We can actually calculate this with a little work!

First we'll add a bit of data verification code - just so we know that
our calculations are working with the right units when we make manipulations.

```python
def quantity_of(quantity,unit):
    if quantity['unit'] == unit:
        return quantity['quantity']
    else:
        raise Exception(f"Need quantity in {unit}")
```

With this we can extract the values safely, knowing they are what we
think they are.

## Safety first

But we are modifying the core database with enriched data. This might
not be a good idea. It's very possible that we mess something up in
our calculations, and people might be using the production database.

We are also deriving data - and sometimes when you derive data its a
good idea to keep it segregated from the underived data. This way you
know what is "ground truth" and you can re-run your processes to
obtain the derived facts later.

Luckily, we have an easy way of doing this: *branching*.

```python
branch = "capacity_factors"
try:
    client.delete_branch(branch)
except Exception as E:
    print(E.error_obj)
    print("Branch did not yet exist")

client.create_branch(branch)
client.branch = branch
```

We have created a safe space in which to do our experiments. If we
mess it up, we can just delete the branch.

Next, we will actually do the calculation. We loop over every power
plant in the database, we loop over each year for which we have
calculated data, then we enrich the document with the calculated
capacity factor for a given year, and return it to the database!

```python

plants = client.query_document({ '@type' : 'NuclearPowerPlant' })
for plant in plants:
    capacity = quantity_of(plant['capacity'],'Unit/MWe')
    print(f"capacity {capacity}")
    if 'output' in plant:
        output = plant['output']
        capacity_factors = []
        for output_year in output:
            year = output_year['year']
            GWh = quantity_of(output_year['output'],'Unit/GWh')
            if not(GWh == 0):
                capacity_factor = GWh * 1000 / (capacity * 24 * 365)
                capacity_factors.append({ '@type' : 'AnnualCapacityFactor',
                                          'year' : year,
                                          'capacity_factor' : capacity_factor })
        plant['capacity_factor'] = capacity_factors
        try:
            result = client.update_document(plant)
            plant_id = plant['@id']
            print(f"Updated... {plant_id}")
        except Exception as E:
            if hasattr(E,'error_obj'):
                print(json.dumps(E.error_obj, indent=4, sort_keys=True))
            else:
                print("Unknown error")
                print(E)

```

Now that we've seen some enrichment based on inference from data which
we already have, you might be interested in how to further improve our
data in [Part 3: Scraping Data](./scraping.md).

repository: massimosammito/terminusdb-tutorials

repo_name: massimosammito/terminusdb-tutorials


text:
---
title: Pelican
homepage: https://blog.getpelican.com/

description: Pelican is a static site generator that requires no database or server-side logic.

intro: |
    Pelican is a static site generator that "requires no database or
    server-side logic." It features a modular plugin system and an
    officially-maintained
    [plugin repository](https://github.com/getpelican/pelican-plugins).

language:
  name: Python
  link: https://www.python.org/
  icon: devicon-python-plain colored

templating:
  name: Jinja2
  link: https://jinja.palletsprojects.com/en/2.10.x/

license:
  name: AGPL-3.0
  slug: aglp-3

features:
  localization:
    type: plugin
    link: https://github.com/getpelican/pelican-plugins/tree/master/i18n_subsites
  versioning: false
  custom_output: false
  asset_pipelines:
    type: plugin
    link: https://github.com/getpelican/pelican-plugins/tree/master/assets
  data_files: false
  image_processing:
    type: plugin
    link: https://github.com/whiskyechobravo/image_process
  extensible:
    link: https://docs.getpelican.com/en/stable/plugins.html

localization: true
versioning: false
theming: true

adoc: true
md: true
rst: true

twitter: getpelican
repo: getpelican/pelican
---

## Markup

Pelican has native support for [Python-Markdown][1] (a [non-standard][2] Markdown implementation) and reStructuredText. AsciiDoc is supported through a [third-party plugin][3].

{{% chart-tabs %}}

[1]: https://github.com/Python-Markdown
[2]: https://github.com/Python-Markdown/markdown/issues/338
[3]: https://github.com/getpelican/pelican-plugins/tree/master/asciidoc_reader

repository: errata-ai/static-school

gha_language: CSS

repo_name: errata-ai/static-school


text:
[![Build Status](https://scrutinizer-ci.com/g/lizardmedia/php-process-manager/badges/build.png?b=master)](https://scrutinizer-ci.com/g/lizardmedia/php-process-manager/build-status/master)
[![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/lizardmedia/php-process-manager/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/lizardmedia/php-process-manager/?branch=master)
[![Latest Stable Version](https://poser.pugx.org/lizardmedia/php-process-manager/v/stable)](https://packagist.org/packages/lizardmedia/php-process-manager)
[![License](https://poser.pugx.org/lizardmedia/php-process-manager/license)](https://packagist.org/packages/lizardmedia/php-process-manager)

# PHP Process Manager #
PHP library for creating and managing PHP-processes.

## Getting started ##
This instructions will tell You how to get a copy of library and use it to manage processes

### Prerequsites ###
* PHP 7.0

### Installing ###
#### Using composer ####
Add to your project using composer:
```
composer require lizardmedia/php-process-manager
```

####Download ZIP ####
Download zip archive and unpack it to your project

## Usage ##

### CLI ###
Commands using Symfony console:
```$xslt
./bin/phppm-background {script to run} {log file}
```

Example:
```$xslt
./bin/phppm-background "example/ProcessExample.php" script.log > pid
```

## Contributing

Please read [CONTRIBUTING.md](https://gist.github.com/PurpleBooth/b24679402957c63ec426) for details on our code of conduct, and the process for submitting pull requests to us.

## 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

* **Michał Adamiak** - Lizard Media
* **Mateusz Procner** - Lizard Media

See also the list of [contributors](https://github.com/lizardmedia/php-process-manager/graphs/contributors) who participated in this project.

## License

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

## To do

* Add killing and managing processes

repository: lizardmedia/php-process-manager

repo_name: lizardmedia/php-process-manager


text:
---
title: Utilities
---

### Template Component

The `<Template>` svelte component lets you define markup that is reused as a template. It is currently used to render listItems in the `<listView>` component.

#### Basic usage

```html
<page>
  <listView items="{items}">
    <Template let:item={i}>
      <label text="{i}" />
    </Template>
  </listView>
</page>
<script>
  import { Template } from 'svelte-native/components'
  let items = ['one', 'two', 'three']
</script>
```

> **NOTE** The template element here has a capital `T` and is imported from `svelte-native/components`. This is because it is a Svelte component not a NativeScript element.

#### Advanced usage

You can use `Template` to implement custom NativeScript elements that require a template or multiple templates.

When `Template` is rendered by svelte, it outputs a special DOM element called `template` which has a `component` attribute. Implementations such as svelte native's binding to `listView` look for the `template` elements and use the component to instantiate and render the template content.

Any extra properties added to the `Template` component are passed down and added to the `template` DOM element.

For a concrete example of this pattern see svelte native's [listView element source](https://github.com/halfnelson/svelte-native/blob/master/src/dom/native/ListViewElement.ts#L50).

### Property Element

Some NativeScript controls have properties that expect NativeScript views as values. To make this possible using markup, Svelte Native introduce two helpers, the property element and the `prop` directive.

This property element works like the ones in the NativeScript core documentation and set some property of their parent view with the value of the first child of the property element. The tag name is the name of the parent element followed by the property name. For example `<page.actionbar>` would set the `actionbar` property of the parent `page` element.

#### An Example

The `<radSideDrawer>` component is part of the [Progress NativeScript UI](https://docs.nativescript.org/ui/professional-ui-components/SideDrawer/getting-started) package.

The `<radSideDrawer>` component requires the `drawerContent` and `mainContent` properties to be set to `View` instances. Using Property Elements, you can do this with a few lines of code:

```html
<radSideDrawer>
  <radSideDrawer.drawerContent>
    <stackLayout />
  </radSideDrawer.drawerContent>
  <radSideDrawer.mainContent>
    <stackLayout />
  </radSideDrawer.mainContent>
</radSideDrawer>
```

Without the Property Elements, you need to go a more tedious and error-prone route:

```html
<radSideDrawer bind:this="{drawer}">
  <stackLayout bind:this="{drawerContent}" />
  <stackLayout bind:this="{mainContent}" />
</radSideDrawer>
```

```js
import { onMount } from 'svelte'

let drawer
let drawerContent
let mainContent

onMount(() => {
  drawer.nativeView.mainContent = mainContent.nativeView
  drawer.nativeView.drawerContent = drawerContent.nativeView
})
```

### Property Directive

The Property Element is useful but can be a little verbose. Svelte native also introduces a custom svelte directive called `prop`. The prop directive will take the native view of the component it is on an assign it to a property of the parent element.

For example our side drawer example from Property Element
```html
<radSideDrawer>
  <radSideDrawer.drawerContent>
    <stackLayout />
  </radSideDrawer.drawerContent>
  <radSideDrawer.mainContent>
    <stackLayout />
  </radSideDrawer.mainContent>
</radSideDrawer>
```

can be written using the prop element as

```html
<radSideDrawer>
  <stackLayout prop:drawerContent />
  <stackLayout prop:mainContent/>
</radSideDrawer>
```

### Implicit Property Directives

Many advanced controls (including those in the nativescript-ui packages) use elements to provide configuration. These configuration properties need to be assigned to a parent property but often only have one valid parent property to which they can be assigned, so the `prop:` or Property Element becomes boilerplate

Take this example from `nativescript-ui-dataform`:

```html
 <radDataForm source={ticket} metadata={ticketMetadata}>
    <entityProperty prop:properties  name="price" index="4" readOnly="true">
        <propertyEditor prop:editor type="Decimal" />
    </entityProperty>
    <entityProperty prop:properties name="numberOfTickets" displayName="Number of Tickets" index="5">
        <propertyEditor prop:editor type="Stepper">
            <propertyEditorParams prop:params minimum="0" maximum="100" step="2" />
        </propertyEditor>
    </entityProperty>
</radDataForm>
```

on a large form, the `prop:properties` `prop:editor` and `prop:params` can get repetitive. Svelte Native lets you register a configuration element with a default property name for the `prop:` directive. When this is set, the `prop:` directive is not needed at all:

```html
<radDataForm source={ticket} metadata={ticketMetadata}>
    <entityProperty name="price" index="4" readOnly="true">
        <propertyEditor type="Decimal" />
    </entityProperty>
    <entityProperty name="numberOfTickets" displayName="Number of Tickets" index="5">
        <propertyEditor type="Stepper">
            <propertyEditorParams minimum="0" maximum="100" step="2" />
        </propertyEditor>
    </entityProperty>
</radDataForm>
```

repository: Erudition/elm-native

repo_name: Erudition/elm-native


text:
# GooseMod Changelog

## v5.3.1 [2020-12-04]

  - ### Fixes
    - Fixed easter egg's audio not playing correctly

## v5.3.0 [2020-12-04]

  - ### Features
    - [GitHub PR #6 by Fjorge](https://github.com/GooseMod/Injector/pull/6): Add audio property to easter eggs
    - [GitHub PR #8 by Fjorge](https://github.com/GooseMod/Injector/pull/8): Let modules have author as an array

## v5.2.0 [2020-11-30]

  - ### Fixes
    - Updated Module Store's Sidebar selection UI to use Discord's new radio buttons

## v5.1.2 [2020-11-29]

  - ### Fixes
    - Fixed getting localStorage / loading erroring out when using (B)BD

## v5.1.1 [2020-11-16]

  - ### Fixes
    - Fixed extra info not being sent to handlers properly for context menu patcher
    - Removed extra unneeded logging in context menu patcher

## v5.1.0 [2020-11-15]

  - ### Features
    - Clicking on (some) authors now opens their profile in Module Store

  - ### Tweaks
    - Clicking title / main text on card no longer toggles switch in Module Store

  - ### Fixes
    - Fixed toggling modules in Module Store with switch would try and call the module's loading finished event handler even if it did not exist

## v5.0.1 [2020-11-12]

  - ### Tweaks
    - Removed some extra debug logging

  - ### Fixes
    - Fixed GooseMod settings being injected in all sidebars instead of just settings

## v5.0.0 [2020-11-09]

  - ### Features
    - Native / React settings sidebar injection instead of DOM, resulting in no lag caused by GooseMod when opening settings and them being there with no delay
    - Added native patcher library / API (based on Powercord <3)
    - Added native context menu injection library / API, this now allows modules to easily add their own entries to context menus with only a couple lines oF JS instead of needing to reinvent the wheel everytime
    - Moved version info into separate version info section, there is now a divider after Discord's version info and then GooseMod's own

  - ### Tweaks
    - Slightly optimized Module Store settings UI generation
    - Module Store no longer readjusts settings UI width again when importing or removing a module

## v4.10.0 [2020-11-05]

  - ### Features
    - Added author and imported sections to Module Store sidebar

  - ### Fixes
    - Fixed GooseMod changelog being cached
    - Fixed Module Store's card container rows being too high and resulting in strange gaps (sometimes when filtering)

## v4.9.0 [2020-11-03]

  - ### Features
    - Changed Manage Modules setting into "Local Modules", only shows and allows management of local modules (imported local files) to avoid confusion / duplication

## v4.8.1 [2020-11-02]

  - ### Features
    - Made new version checking asynchronous so it does not result in delay when initialising

## v4.8.0 [2020-11-02]

  - ### Features
    - Added hash checksum and version checking on initation for security / verification

## v4.7.0 [2020-11-02]

  - ### Features
    - Module Store UI improvements, now keeps search bar and sidebar filtering after importing or removing modules via buttons

  - ### Tweaks
    - Shrunk Module Store UI's sidebar slightly to allow more cards

## v4.6.0 [2020-11-01]

  - ### Tweaks
    - No longer uses janky CSP bypass, instead now relies on it being disabled when GooseMod is injected
    - Cleaned up some code, removed some now unneeded logging and some unnecessary old comments

## v4.5.0 [2020-10-31]

  - ### Features
    - Added complete new dialog / wizard for setup / first time injection, now asks what "pack" (set of modules) you want to install as well as what theme you want to install. Pre-existing users won't be affected.

## v4.4.1 [2020-10-30]

  - ### Tweaks
    - Stopped using version specific / special changelog images

  - ### Fixes
    - Fixed changelog sometimes being glitchy, could sometimes occur when some Discord experiments / special changelog types override the changelog

## v4.4.0 [2020-10-30]

  - ### Features
    - Added custom component to settings UI API

  - ### Tweaks
    - Reduced old logging in sidebar settings generation

## v4.3.0 [2020-10-29]

 - ### Features
   - Added GooseMod changelog, it appears whenever GooseMod updates with the latest info from Injector repo's CHANGELOG.md
   - Rewrote CSP Bypasser, it now uses the object's fetch function directly
   - Added UserScript support in CSP Bypasser, thanks to [AAGaming](https://github.com/AAGaming00) for creating a UserScript for web

## v4.2.2

  - ### Tweaks
    - Added class to injected GooseMod settings to allow easier styling of them

## v4.2.1

  - ### Fixes
    - Fixed local module importing and only ask for one file
    - Fix large (>~1MB) modules failing to load

## v4.2.0

  - ### Features
    - Added color picker to Settings UI API
    - New CSP bypasser which uses standard URI

## v4.1.0

  - ### Features
    - Added sidebar to Module Store UI

## v4.0.0

  - ### Tweaks
    - Hid local reinstall option (and divider) as it is mostly useless / never used

  - ### Backend
    - Rewrote to not use global / window object - fixes many potential bugs and is more secure
    - Moved some misc. settings options into goosemod.settings instead of bloating the parent scope
    - Module functions are no longer binded to goosemod scope, instead it is avaliable as an object in the module eval

## v3.2.1

  - ### Features
    - Added separator to Module Store UI

  - ### Fixes
    - Fixed being able to input newlines in Module Store UI search box

## v3.2.0

  - ### Features
    - Revamped Module Store UI to use cards, and now has a search bar

## v3.1.0

  - ### Features
    - Added hash checking to Module Store for each module

  - ### Fixes
    - Fixed local module importing being broken
    - Fixed reinjecting after being removed in the past not working and still thinking it had been removed

  - ### Backend
    - Sleep and ab2str specific util JS files / imports as they are used through out (more than once)
    - Cleaned up some code when initially loading

## v3.0.1

  - ### Tweaks
    - Removed migration code replacing for modules to fix issues
    - Removed old unneeded logging on startup
    - New way of getting injector version hash
    - Add version toast on injection

## v3.0.0

  - ### Backend
    - Rewritten to use multiple JS files with Parcel

## v2.4.0

  - ### Features
    - Added new settings injector backup system to fix settings injection when settings button click event fails
    - Added module JS cache - installed modules have their JS code installed and that cache is used if there are no updates for the module, reducing network requests and latency

## v2.3.0

  - ### Features
    - Put theme and hardcoded color fixer to start of to install modules on injection always
    - Made Dracula Theme new default theme (used to be Darkest)

## v2.2.2

  - ### Fixes
    - Fixed some issues when injecting whilst settings are open

## v2.2.1

  - ### Fixes
    - Fixed loading toast remaining on screen after injection if not new user

## v2.2.0

  - ### Features
    - New loading process - instead of Discord-like whole screen loading screen, now uses toasts to be less intrusive
    - Only open settings on injection if first time using GooseMod (no settings saved)
    - Better settings injection starting process - fixes bug where settings would sometimes not be injected, also makes it less slow to inject

  - ### Tweaks
    - Text inside toasts are now centered (for multi-line)
    - Return toast element and close function from creating toast function

  - ### Fixes
    - Don't use window object for base scope

## v2.1.1

  - ### Fixes
    - Fixed local (not from module store) modules being saved breaking next install

## v2.1.0

  - ### Tweaks
    - New CSP Bypass URL

## v2.0.1

  - ### Fixes
    - Fixed bug with toasts not displaying properly sometimes

## v2.0.0

  - ### Features
    - Added version hash
    - Added enabling and disabling of modules
    - Added saving settings of modules
    - Only install previously installed modules (mostly for tethered)
    - No longer remove untethered version from being accessible on injection

## v1.11.1

  - ### Fixes
    - Fixed CORS bypasser image method not using CORS proxy variable

## v1.11.0

  - ### Features
    - Allow not using CORS proxy with CSP bypasser methods
    - No longer use CORS proxy with Module Store requests

## v1.10.1

  - ### Tweaks
    - Use new API

## v1.10.0

  - ### Features
    - Added toast API for modules to use
    - May or may not have added easter eggs

## v1.9.1

  - ### Tweaks
    - Updated loading screen to show and link to new GitHub stuff

## v1.9.0

  - ### Tweaks
    - Updated module store URLs to GitHub

## v1.8.1

  - ### Tweaks
    - Tethered version -> Untethered version

## v1.8.0

  - ### Features
    - Added text element to settings API
    - Convert dashes to spaces in categories with Module Store settings UI

## v1.7.0

  - ### Features
    - In injecting loading screen, improve importing default modules step by using newlines and full proper names
    - Better support for GooseMod Tethered
    - Added support for accessing webpack modules

## v1.6.0

  - ### Features
    - Added WYSIWYG Messages, Custom Sounds, Dev Mode and Twitch Emotes to default modules
    - When importing default modules on injection / loading, show which one and the progress

## v1.5.1

  - ### Features
    - Injection loading screen now fades to dark color at the start

  - ### Fixes
    - Fixed loading image / video of Discord logo not looping
    - Fixed importing local module not fully updating settings properly

## v1.5.0

  - ### Features
    - Added local storage support (will help make a lot of modules previously impossible possible)

  - ### Fixes
    - Fixed console error when removing a module not from module store

## v1.4.0

  - ### Features
    - Module store now has remove buttons instead of reimport
    - Renamed reinstall to local reinstall
    - No longer show module manager in browser as it serves no purpose there
    - Hide manage modules in browser as the only purpose it has now is to import local modules

  - ### Fixes
    - Fixed some bugs when updating the module store index

## v1.3.0

  - ### Features
    - Added default (auto-install on injection) modules
    - Settings no longer have to be reopened when importing modules, removing them, etc.

  - ### Fixes
    - Fixed reimport button not turning back into import button not working

## v1.2.0

  - ### Features

    - #### Injector
      - Module Store setting is now filtered into categories and sorted alphabetically
      - CSP Bypasser now queries gateway instead of non-existant page to be more steathy
      - Added Discord-like loading screen when injecting
      - CSP Bypasser initialisation is now much (speeds up entire injection by ~2x) faster as it actually waits for the iframe to load instead of just waiting for 1 second (also will increase reliability)

## v1.1.2

  - ### Fixes

    - #### Injector
      - Increased duration between settings reopen to fix sometimes overlapping settings

## v1.1.1

  - ### Fixes

    - #### Injector
      - Fix bug where module would be deleted before running module store deletion handler

## v1.1.0

  - ### Features

    - #### Injector
      - Added image and blob support to CSPBypasser
      - Now removes reinstall button on browser (unsupported)

  - ### Fixes

    - #### Injector
      - Fixed bug on Windows where closing settings would close Discord
      - Fixed crash
      - Fixed CSPBypasser sometimes failing on some origins

  - ### Other Changes

    - Removed easy injector
    - Moved modules to API repository

## Release v1.0.0

  - ### Features

    - #### Injector
      - Added separator between other GooseMod options and reinstall and uninstall
      - Added Module store
      - Added normal (brand) button and text setting option
      - Now reopens settings when doing some things instead of just closing
      - Removed embedded

## Beta v0.9.2

  - ### Features

    - #### Injector
      - Reallow importing modules in embedded mode, but desktop client only

## Beta v0.9.1

  - ### Features

    - #### Injector
      - Disable importing modules in embedded mode

## Beta v0.9.0

  - ### Features

    - #### Embedder
      - Added embedded mode

## Beta v0.8.1

  - ### Features

    - #### Injector
      - Automatically opens settings on the manage modules page when injected

    - #### Module: RainbowCord (v1.0.0)
      - Added module

    - #### Module: Role Colored Messages (v1.0.0)
      - Added module

    - #### Module: Egg Scrambler (v1.0.0)
      - Added module

  - ### Fixes

    - #### Module: Message Scrambler (v1.0.1)
      - Fixed some potential symbol conversion errors

## Beta v0.8.0

  - ### Features

    - #### Injector
      - Added module descriptions to module manager
      - Added subtext option for toggles and danger button setting components
      - Remade module headers for module manager, now including author

    - #### Module: Twitch Emotes (v1.0.0)
      - Added module

    - #### Module: Message Scrambler by Fjorge (v1.0.0)
      - Added module

    - #### Module: Visual Tweaks (v2.0.1)
      - Added description and author
      - Added subtext to some options

    - #### Module: Fucklytics (v1.1.2)
      - Added description and author
      - Added subtext to some options

    - #### Module: Dev Mode (v1.0.1)
      - Added description and author

  - ### Backend / Structural Changes

    - Modules now in "category" folders

  - ### Fixes

    - #### Injector
      - Fixed that modules without setting would fail to be removed

## Beta v0.7.0

  - ### Features

    - #### Injector
      - No longer ask for modules on injection immediately
      - Module manager now shows deletion button instead of toggle for removing modules

    - #### Easy Injector
      - Renamed Quick Injector to Easy Injector
      - Reduced size

  - ### Fixes

    - #### Injector
      - Fixed that removing a module would not remove the setting in the current settings layer (from v0.6.0)

## Beta v0.6.0

  - ### Features

    - #### Injector
      - Uninstall option is now colored red like "Log Out" option
      - GooseMod options are now inserted before "Log Out" option
      - Added Reinstall option

    - #### Quick Injector
      - Added quick injector

  - ### Tweaks

    - #### Injector
      - No longer use custom logging for logging version on run
      - Removed version iteration as it was mostly unused
      - Added Discord version channel and desktop version to startup import logging

## Beta v0.5.0

  - ### Features

    - #### Injector
      - Uninstall confirmation uses Discord's confirmation box instead of Electron's (thanks Upsidedown!)
      - Cancelling uninstall no longer shows empty "Uninstall Cancelled" page
      - Added Manage Modules to easily import and remove modules
      - Moved modules into own settings category

    - #### Module: Visual Tweaks (v2.0.0)
      - Profile popup background is now colored correctly according to theme
      - Server boost page is now colored correctly according to theme
      - Tweaked some backgrounds for darkest mode
      - Added version and name to export
      - Darkest mode is now default

    - #### Module: Fucklytics (v1.1.1)
      - Added version and name to export

    - #### Module: Dev Mode (v1.0.0)
      - Added version and name to export

## Alpha v0.4.4

  - ### Features

    - ### Module: Visual Tweaks (v1.4.0)
      - Properly color mention and slash autocompletion menu

## Alpha v0.4.3

  - ### Features

    - ### Module: Visual Tweaks (v1.3.0)
      - Properly color friends container section

## Alpha v0.4.2

  - ### Features

    - ### Module: Visual Tweaks (v1.2.0)
      - Added better highlighting for messages on hover for darker (and darkest) modes

## Alpha v0.4.1

  - ### Features

    - #### Injector
      - Added confirmation to Uninstall from settings

## Alpha v0.4.0

  - ### Features

    - #### Injector
      - Modules now have remove handler
      - No longer uses global window variable, much more hidden now
      - Added uninstall option to end of settings which uninstalls / removes GooseMod without reloading / refresh (leaves some small amounts of code but no visual or noticable changes remain, small traces can be removed by refreshing / reloading)

    - #### Module: Visual Tweaks (v1.1.0)
      - Now disables all tweaks on remove handler

    - #### Module: Fucklytics (v1.1.0)
      - Reverts proxy function remove handler

## Alpha v0.3.0 (Bump from Pre-alpha to Alpha!)

  - ### Features

    - #### Injector
      - Now injects version in to info in settings sidebar
      - Made subtitle for settings header in settings pages settable

    - #### Module: Visual Tweaks (v1.0.1)
      - Added version to settings header

    - #### Module: Fucklytics (v1.0.1)
      - Added version to settings header

  - ### Tweaks

    - #### Injector
      - Tweaked version logging in console

  - ### Fixes

    - #### Module: Visual Tweaks (v1.0.1)
      - Fixed help button not being hidden when first imported even when enabled

## Pre-alpha v0.2.1

  - ### Misc. Changes

    - Removed `test` module as it served no use
    - Removed `Test` setting entry

## Pre-alpha v0.2.0

  - ### Features

    - #### Module: Visual Tweaks
      - Added "Darker Mode" to Visual Tweaks Module
      - Added "Darkest Mode" to Visual Tweaks Module

    - #### Injector
      - Added version displaying when injector is ran

  - ### Fixes

    - #### Module: Visual Tweaks
      - Fixed tweaks being enabled on import even if being "false"

    - #### Injector
      - Fixed potential future errors in logger if region is not found and not a module
      - Fixed toggles in settings not having bottom margin
      - Fixed headers (not first one) not having top margin
      - Fixed toggles not having dividers after them

  - ### Backend / Structural Changes

    - Renamed `base` directory to `modules` as it is a more accurate and understanding name

## Pre-alpha v0.1.0
  - Initial (Public) Release

repository: cryptofyre/Injector

repo_name: cryptofyre/Injector


text:
# Image-Search-Engine
Content-Based Image Retrieval System Implemented Using Python, Flask And OpenCV.
* Given a query image, this app returns other images from database in order of similar color content.
* Uses a color histogram to define the color content of an image, uses chi-squared distance to determine
how similar two image histograms are.

## Usage Guide
1. To use a different image dataset (optional)
    * Populate image DB in `app/static/images`
    * Then in Terminal (you can use a virtualenv):
```bash
>> pip3 install -r requirements.txt
>> cd app
>> python3 index.py --dataset static/images --index index.csv
```

2. Run locally using Docker
    * Install [Docker](https://docs.docker.com/install/#supported-platforms)
    * Then in Terminal:
```bash
>> docker build --tag=imagesearch .
>> docker run -p 80:8000 imagesearch
```
* You should be able to access app at `localhost:80` in browser

### Sources
* [pyimagesearch.com](https://www.pyimagesearch.com/start-here-learn-computer-vision-opencv/)
* [flask docs](http://flask.pocoo.org)
* [content-based image retrieval](https://en.wikipedia.org/wiki/Content-based_image_retrieval)

Project was made possible thanks to the many guides provided by [@Adrian Rosebrock](https://twitter.com/pyimagesearch) on [pyimagesearch.com](https://www.pyimagesearch.com/start-here-learn-computer-vision-opencv/)

gha_language: Python


text:
---
layout: default
---

# 1998-02-13 - Re:  Regulators back down on SEC/NASD email snooping rules

## Header Data

From: Information Security<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: bf19c5965e6d92a08dd70f5d2a763e409ffcbcd2f30d9d91c6b3c7e6e611c795

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1998-02-13 04:19:27 UTC

Raw Date: Thu, 12 Feb 1998 20:19:27 -0800 (PST)

## Raw message

```
{% raw  %}From: Information Security<EMAIL_ADDRESS>Date: Thu, 12 Feb 1998 20:19:27 -0800 (PST)
To<EMAIL_ADDRESS>Subject: Re:  Regulators back down on SEC/NASD email snooping rules
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

   >   From: Don "Free Radical" McLean<EMAIL_ADDRESS>   >   Date: Thu, 12 Feb 1998 14:27:19 -0800 (PST)
   >   Subject: Regulators back down on SEC/NASD email snooping rules
   >
   >   Last Friday I wrote in Netly about the SEC approving rules dealing with
   >   email snooping on home computers and the potential privacy violations:
   >
   >    http://cgi.pathfinder.com/netly/opinion/0,1042,1731,00.html
   >
   >   These rules were to take effect on February 15. Now, citing "concerns that
   >   have been voiced," the NASD has backed down and is considering changes.
   >
   >   Score one for privacy, or at least a more cautious approach.

Damn, wish I could affect the real world too.

----

The "cautious approach" is simply ordering all employees
to send work-related email via the company systems.
---guy

   Where I can monitor it.

{% endraw %}
```

## Thread

+ Return to [February 1998](/archive/1998/02)

+ Return to "[Information Security <guy@panix.com>](/authors/information_security_guy_at_panix_com_)"

+ 1998-02-13 (Thu, 12 Feb 1998 20:19:27 -0800 (PST)) - Re:  Regulators back down on SEC/NASD email snooping rules - _Information Security<EMAIL_ADDRESS>