text:
# :palm_tree: Palmtree Form

[![License](http://img.shields.io/packagist/l/palmtree/form.svg)](LICENSE)
[![Build](https://img.shields.io/github/workflow/status/palmtreephp/form/Build.svg)](https://github.com/palmtreephp/form/actions/workflows/build.yml)

PHP Form builder with [Bootstrap](https://getbootstrap.com/) v4 classes, validation, [Google Recaptcha](https://www.google.com/recaptcha/intro/) support and other goodies

## Requirements
* PHP >= 7.1
* jQuery (If you want to use Recaptcha and/or AJAX submissions)

## Installation

Use composer to add the package to your dependencies:
```sh
composer require palmtree/form
```

## Usage Example

#### Build
```php
use Palmtree\Form\FormBuilder;
use Palmtree\Form\Captcha\GoogleRecaptcha;

$builder = (new FormBuilder('my_form'))
    ->add('name', 'text', ['error_message' => 'Please enter your name'])
    ->add('email_address', 'email')
    ->add('message', 'textarea', [
        'required' => false,
        'label' => 'Enter your message',
    ])
    ->add('recaptcha', 'captcha', [
        'captcha' => new GoogleRecaptcha('<site_key>', '<secret>'),
    ]);

$builder->add('send_message', 'submit');

$form = $builder->getForm();
// Set $form to some variable accessible in a view

```

#### Render
```html
<script src="/path/to/palmtree-form.pkgd.min.js"></script> <!-- Optional -->
<div class="container">
    <?= $form->render(); ?>
</div>
```

#### Process
```php
$form->handleRequest();

if ($form->isSubmitted() && $form->isValid()) {
    // Send an email/save to database etc
    $name = $form->get('name')->getData();
}
```

See the [examples](examples) directory for examples using AJAX, file uploads, collections and more.

## Collections

The `CollectionType` can be used to add/remove multiple entries of the same field or set of fields:

```php
use Palmtree\Form\FormBuilder;
$builder = (new FormBuilder('collection_example'))
    ->add('name', 'collection', [
        'entry_type'    => 'text',
        'classes'       => ['names-collection']
    ])
    ->add('submit', 'submit');
```

```html
<script src="/path/to/palmtree-form.pkgd.js"></script>
<script>
$(function () {
    $('.names-collection').palmtreeFormCollection({
        minEntries: 1,
        maxEntries: 4,
        labels: {
            add: 'Add person',
            remove: 'Remove person'
        }
    });
});
</script>
```

See the [collection example](examples/collection) for a more advanced use-case.

## Constraints

Constraints allow you to validate a field type. The current built in constraints are:

| Constraint       | Description |
| ------------- |-------------|
| [NotBlank](src/Constraint/NotBlank.php)  | Ensures the field is not empty. Allows values of '0'
| [Email](src/Constraint/Email.php)        | Ensures the field is a valid email address
| [Number](src/Constraint/Number.php)      | Ensures the field is numeric and optionally between a range
| [Length](src/Constraint/Length.php)      | Ensures the field has a minimum and/or maximum length of characters
| [Matching](src/Constraint/Matching.php)  | Ensures the field matches another fields value. Useful for password confirmations

By default, all required fields have a NotBlank constraint.
Email fields have an email constraint and number fields a Number constraint.

## Using Constraints
```php
// Add an age field where the value must be between 18 and 80
$builder->add('age', 'number', [
    'constraints' => [
        new Constraint\Number(['min' => 18, 'max' => 80])
    ]
]);

// Add a password and confirm password field with a minimum length of 8 characters
$builder->add('password', 'repeated', [
    'repeatable_type' => 'password',
    'constraints' => [
        new Constraint\Length(['min' => 8])
    ]
]);

```

You can also implement your own constraints, they just need to implement the [ConstraintInterface](src/Constraint/ConstraintInterface.php)

## File Uploads

### UploadedFile Object

When you retrieve a FileType's data from a form, an instance of [UploadedFile](src/UploadedFile.php) will be returned.
This is a small wrapper object around PHP's native uploaded file array.

### File Constraints

The following constraints can be used on the FileType field:

| Constraint       | Description |
| ------------- |-------------|
| [Extension](src/Constraint/File/Extension.php)  | Ensures the file has an allowed extension
| [MimeType](src/Constraint/File/MimeType.php)  | Ensures the file has an allowed mime type
| [Size](src/Constraint/File/MimeType.php)  | Ensures the file size is between an allowed range

See the [file upload example](examples/fileupload/index.php) for usage examples of these constraints

## Shorthand Type Values

Shorthand values for [built in types](src/Type) are determined by lower-casing the class name and removing the "Type" suffix.
For example:

| Class          | Shorthand Value
| -------------  |-------------|
| TextType       | text        |
| NumberType     | number      |
| EmailType      | email       |
| CollectionType | collection  |

## Examples

The simplest way to run the examples is run the serve.sh script. This script starts a small PHP Docker container
and serves the examples using PHP's built-in web server.

```sh
./examples/serve.sh
```

## License

Released under the [MIT license](LICENSE)


text:
notr
====

## Motivation

There are a ton of complicated notification frameworks out there. What I need is:

* Simple (no need for different animations)
* Simple (no jQuery)
* Simple (no built in icons)
* Simple (reasonable defaults)

## Compatibility

* IE9+, FF, Chrome, Safari, iOS5+, Android

Note that the transition effect may not work devices not supporting
the `transition` CSS style.

## Installing with NPM

```bash
npm install -S notr
```

### Installing with Bower

```bash
bower install -S notr
```

## Usage

Require it

```coffee
notr = require('notr')
```

Simple message, shows for 4 seconds.

```coffee
notr('Hello <b>World!</b>')
```

Complicated message, stays until clicked.

```coffee
notr({
    html: 'Hello <b>World!</b>'
    stay: 0
})
```

Hide message manually.

```coffee
el = notr({
    html: 'Hello <b>World!</b>'
    stay: 0
})

... # sometime later

el.hide() # div is extended with hide function
```

Callback on hide

```javascript
notr('Hello <b>World!</b>', function() {
    console.log('it closed');
});
```

Change content of existing

```
notr({
    html: 'Hello <b>World!</b>'
    id: 'myhello'
})

... # sometime later

notr({
    html: 'Goodbye cruel world!'
    id: 'myhello'
})
```

## API

#### notr(html, callback)

Short form, equivalent to `el = notr({html:html, callback:callback})`

#### notr(opts)

Show a notification with possible options. Returns the `<div>` element.

args        | desc
:---------- | :-----------------
`html`      | Text `.innerHTML` of the notification `<div>`.
`className` | `.className` of `<div>` in addition to `"notr"`. Default `"alert alert-info"`
`stack`     | Stack to place the notification in. See `notr.defineStack()`. Default `"def"`
`stay`      | Milliseconds to stay on screen. 0 to stay forever. Default 4000
`id`        | Id to change content/settings of notification on subsequent calls. Default `null`
`onclick`   | Click handler. Default `null` which hides the `<div>`
`callback`  | Callback when notification is about to hide.

Returns `<div>` extended with a `.hide()` function.

#### notr.defineStack(name, parent, styles)

To define a stack on screen where notifications appear. The default
(which can be changed) is:

```coffee
notr.defineStack('def', 'body', {top:'65px', right:'15px'})
```

args        | desc
:---------- | :-----------------
`name`      | Name of the stack. The default notification stack is `"def"`
`parent`    | `document.querySelector` or element of where to `.appendChild` the stack.
`styles`    | `el.style` styles to define for the stack.

#### Default CSS styles

The notr default styles can be altered by overriding the default `.notr` css rule.

However. Notr uses the `margin-top` and `opacity` css style to do the
transition animation. It's probably a bad idea to alter this value.

```css
.notr {
    margin-top: 0; // do not change margin-top
    opacity: 1.0;  // do not change opacity
    float: left;   // probably a bad idea to change
    clear: both;   // probably a bad idea to change
    transition: margin-top 0.2s, opacity 0.2s;

    min-width: 270px;
    min-height: 50px;
    margin-bottom: 3px;
    background: white;
    border: 1px solid #999;
    padding: 5px;
    box-shadow: 0 0 3px rgba(0,0,0,0.4);
    cursor: pointer;
}
.notrstack {
    position: fixed;
    min-width: 270px;
    min-height: 50px;
    z-index: 9000;
}
```

#### Events

Some DOM events that are dispatched on the returned `<div>`.

event             | desc
:---------------- | :-----------------
`notr:beforeshow` | Before showing.
`notr:show`       | When showing.
`notr:beforehide` | Before hiding. Just before `opts.callback`.
`notr:hide`       | After hiding.

Example

```javascript
el = notr('Hi there')
el.addEventListener('notr:show', function() {
    console.log('here we go');
});
```

License
-------

The MIT License (MIT)

Copyright © 2015 TT Nyhetsbyrån

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

license: MIT

repository: ttab/notr

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: ttab/notr


text:
---
speaker: Anish Ghosh (TIFR Mumbai)
title: "The Siegel-Veech transform in dynamics and number theory"
date: 15 March, 2023
time: 2 PM
series: "Number Theory Seminar"
venue: LH-1
website: https://math.iisc.ac.in/~maheshkakde/currentseminar.html
---

The Siegel-Veech transform is a basic tool in homogeneous as well as Teichmuller dynamics. I will introduce the transform and explain how it can be used in counting problems.

repository: siddhartha-gadgil/DeptWeb

gha_language: HTML

gha_license_id: MIT

repo_name: siddhartha-gadgil/DeptWeb


text:
# _Room to Grow: Plant Daycare_

#### _This app was developed as a helpful guide for plant owners, latest update 12/03/2020 Version 1.0_

#### By _**Mai and Lana**_

## Description

_This application monitors your plant watering needs based on the current weather conditions at your location._

## Project Specifications

- use weather map api
- figure out how to use file io to put a plant guide on users computer
- include testing(start project using tdd)

| Behavior | Input | Output |
|---|---|---|
| The user is welcomed with an introduction |   |   |
| The user is prompted to enter a new plant|   |   |
| The user is prompted with options of plants (choose which plant they are caring for)|   |   |
| The program stores this info, creates a new instance of plant object|   |   |
| The user is prompted to enter which city they live in|   |   |
| Weather map api accepts call with the city as a param|   |  |
| The weather forcast for that area is displayed to the user|   |   |
| The user is then given options for watering (or other care methods) based on weather|   |   |
| The user has the option to quit|   |   |
| The user is asked if they would like a care guide before they leave( if yes, a text file with plant care instructions is added to their comp)|  |  |

## Setup/Installation Requirements

_In Terminal:_

* Navigate to where you want this application to be saved, i.e.:
```cd desktop```
* Clone the file from GitHub with HTTPS
```git clone https://github.com/lchebib/room-to-grow-plant-daycare.git```
* Open file in your preferred text editor
* On Mac: ```open -a {your text editor} beep-boop```
* On Windows: ```beep-boop```

_To Download Manually:_

* Navigate to https://github.com/lchebib/room-to-grow-plant-daycare.git.
* Click green "Clone or Download" button.
* Click "Download ZIP".
* Click downloaded file to unzip.
* Open folder called "beep-boop-master".
* Right click "index.html" and select your preferred browser or text editor.

## Known Bugs

_No known bugs at this time._

## Support and contact details

_Have a bug or an issue with this application? [Open a new issue](https://github.com/lchebib/room-to-grow-plant-daycare/issues) here on GitHub._

## Technologies Used

* _Python3_
* _unittest library_
* _Weather maps API_

### License

[MIT](https://choosealicense.com/licenses/mit/)

Copyright (c) 2020 **_Lana and Mai_**

repository: lchebib/room-to-grow-plant-daycare

repo_name: lchebib/room-to-grow-plant-daycare


text:
# Discrete Event Simulation Framework
(c) Pavel Kalvoda 2011
License: "Original" BSD license - read further

DESF is a simple library for discrete event simulation. It provides you with basic tools -
the simulation calendar (clock), queues, loggers, etc.

DESF is heavily event oriented, the best way to utilize it is to use pre-implemented observer pattern.
As events are the essence of dicrete simulation techniques, everything DESF try to take advantage of
them to enable entity object to be cleaner and smaller.

The main aim is to provide enviroment in wich programmers can focus on the practical aspect
of tasks. As I have about a month or two to finish it, all proposals are welcome. Especially technical
advices, as I'm used to Ruby and PHP, so I'm having a hard time with C#.

Tlačipoznámka pro zasvěcené: Chacha, doprdele s Pascalem!

Copyright (c) 2011, Pavel Kalvoda
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the author.

4. Neither the name of the author nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

extension: markdown


text:
---
layout: page
title: Membership Information
subtitle: Benefits of becoming a KAOC member!
bigimg:
  - "/img/big-imgs/col03.jpg" : ""
  - "/img/big-imgs/ker02.jpg" : ""
  - "/img/big-imgs/col05.jpg" : ""
  - "/img/big-imgs/ker04.jpg" : ""
---
Hi there,

We have started the membership drive for the year 2021.

Membership is open to all those who are interested in organizing, participating and enjoying cultural, social and entertainment programs conducted by the association. We have 3 options for you to make the payment.

1. Pay via PayPal

2. Pay to a committee member(Credit Card/Check/Cash)

3. Pay via mail

**Membership fees**

		Membership Type	Cost

		Family	$90

		Individual	$50

		Sr. Citizen (60 years or above)	$35

**Mail a  check:**

Make payments to: Kerala Association of Colorado

Memo: email address/phone number

Mailing Address: Treasurer, PO BOX 3411, Parker, CO 80134

**Pay online via secure www.paypal.com website.**
<form action="https://www.paypal.com/cgi-bin/webscr" method="post" target="_top">
<input type="hidden" name="cmd" value="_s-xclick">
<input type="hidden" name="hosted_button_id" value="N37ZT48H4SQVW">

<input type="hidden" name="on0" value="Subscription">Subscription

<select name="os0">
	<option value="Family Membership">Family Membership $90.00 USD</option>
	<option value="Individual Membership">Single Membership $50.00 USD</option>
	<option value="Sr. Citizen Membership">Sr. Citizen Membership $35.00 USD</option>
</select>

<input type="hidden" name="currency_code" value="USD">
<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_paynowCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">

</form>

Membership **benefits** include:
1. **Free admission** to association organized events such as Music Night, Indian Dance Festival, Picnic, Onam and Christmas
2. **Free food/snacks** during Picnic, Onam and Christmas events
3. **Free Yuva membership** for youth
4. **Free Malayalam classes** for children
5. **Access to a great platform** for showcasing talents
6. **Being part of a rich cultural organization** while supporting and helping the Malayalee and Indian Communities
7. **Right to vote** in association organized referendums & elections
8. **Other discounts** as passed on by association’s esteemed sponsors

Please note that membership expires at the end of calendar year on December 31st, 2020.

gha_language: JavaScript


text:
# Toolchain installation on macOS

We recommend using the Contiki-NG Docker image for easy setup of a consistent development environment: [doc:docker].

Alternatively, you can install the toolchains natively on your system.
This page describes how to do so, for OS X.

## Install development tools for Contiki-NG
Start by installing Xcode Command Line Utilities
```bash
$ xcode-select --install
```

This guide makes extensive usage of [homebrew](https://brew.sh/). If you don't already have it, install it:

```bash
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```

Using homebrew, install a bunch of helper tools, such as git, srecord, doxygen (to build the API documentation), mosquitto (to test Contiki-NG's MQTT functionality), tuntap (for tunslip and to run native examples with networking), rlwrap (for shell history), python (python 3 for running scripts and pip).

```bash
$ brew install git git-lfs srecord doxygen uncrustify ant mosquitto wget libmagic rlwrap python make gawk
$ brew tap caskroom/cask
$ brew cask install tuntap
```

You may also need to update your PATH environment variable to use GNU Make 4 when running the "make" command. This can be set in your shell initialization file (e.g., ~/.zshrc) as follows.

```bash
$ echo 'PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH"' >> ~/.zshrc
```

Note that if Homebrew is installed in a different path, you have to modify the command accordingly.

### Install some python packages
Those are used/needed by some Contiki-NG Python scripts.

```bash
$ pip install intelhex pyserial python-magic
```

### Install the ARM GCC toolchain

An ARM compiler is needed to compile for ARM-based platforms.

#### Using homebrew

You can install the arm-gcc toolchain using homebrew.

```bash
# to tap the repository
$ brew tap contiki-ng/contiki-ng-arm
# to install the toolchain
$ brew install contiki-ng-arm-gcc-bin
```

This will automatically install the same version as the one currently installed in the [docker image](/doc/getting-started/Docker) and used by the CI tests.

The formula itself is hosted under [contiki-ng/homebrew-contiki-ng-arm](https://github.com/contiki-ng/homebrew-contiki-ng-arm)

#### Manual Installation

You should download the toolchain from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads or you can grab an older version from launchpad.net.

```bash
$ wget https://launchpad.net/gcc-arm-embedded/5.0/5-2015-q4-major/+download/gcc-arm-none-eabi-5_2-2015q4-20151219-mac.tar.bz2
$ tar jxf gcc-arm-none-eabi-5_2-2015q4-20151219-mac.tar.bz2
```

This will create a directory named `gcc-arm-none-eabi-5_2-2015q4` in your current working dir. Add `<working-directory>/gcc-arm-none-eabi-5_2-2015q4/bin` to your path.

You can also try using the latest version, but be prepared to get compilation warnings and/or errors.

### Install the MSP430 toolchain

The best way to achieve this on OS X is through homebrew, using a formula provided in a tap. Follow the instructions here: https://github.com/tgtakaoka/homebrew-mspgcc

### Install Java JDK for the Cooja network simulator
Nothing exciting here, just download and install Java for OSX. You will need the JDK 17, not just the runtime.

### Install a CoAP client (libcoap)
Optionally and if you want to use CoAP examples, you can install the CoAP client distributed with [libcoap].

Firstly you will need the following packages:

* automake
* autoconf
* libtool
* pkg-config

They can be installed with homebrew:
```
$ brew install automake pkg-config libtool autoconf
```

Then clone libcoap, compile and build it:
```
$ git clone --recursive https://github.com/obgm/libcoap.git
$ cd libcoap/
$ ./autogen.sh
$ ./configure --disable-doxygen --disable-documentation --disable-shared
$ make
$ make install
```
This will install `coap-client` under `/usr/local/bin`

```
$ coap-client
coap-client v4.2.0alpha -- a small CoAP implementation
(c) 2010-2015 Olaf Bergmann<EMAIL_ADDRESS>
usage: coap-client [-A type...] [-t type] [-b [num,]size] [-B seconds] [-e text]
		[-m method] [-N] [-o file] [-P addr[:port]] [-p port]
		[-s duration] [-O num,text] [-T string] [-v num] [-a addr] [-U]

		[-u user] [-k key] [-r] URI
[...]
```
## Clone Contiki-NG

```bash
$ git clone https://github.com/contiki-ng/contiki-ng.git
$ cd contiki-ng
$ git submodule update --init --recursive
```

*Note*: we recommend cloning and then initializing the submodules rather than using `git clone --recursive`.
The latter results in submodules that use absolute paths to the top-level git, rather than relative paths, which are more flexible for a number of reasons.

[doc:docker]: /doc/getting-started/Docker
[libcoap]: https://libcoap.net/

repository: contiki-ng/contiki-ng

branch_name: refs/heads/develop

gha_language: C

repo_name: contiki-ng/contiki-ng


text:
# How to integrate mlmmjadmin with your own mail server

* File `libs/mlmmj.py` handles mlmmj related data on file system. Usually you
  don't need to modify this file.

* File `backends/bk_<X>.py` handles mailing list account related data on
  your SQL/LDAP/... backend, so that your MTA (e.g. Postfix) knows it's a
  mailing list account and calls `mlmmj-receive` program to deliver the email.

    Few functions are required:

    - `def is_domain_exists(domain, conn=None):`

        Used to detect whether domain of the mailing list account exists.

    - `def is_email_exists(mail, conn=None):`

        Used to detect whether given email address exists in your backend.

    - `def is_maillist_exists(mail, conn=None):`

        Used to detect whether given mailing list account (email address)
        exists in your backend.

    - `def add_maillist(mail, form, conn=None):`

        Add required SQL/LDAP/... data in your backend to create a mailing list
        account.

    - `def remove_maillist(mail, conn=None):`

        Remove related SQL/LDAP/... data in your backend to remove a mailing list
        account.

    - `def update_maillist(mail, form, conn=None):`

        Remove related SQL/LDAP/... data in your backend to remove a mailing list
        account.

repository: iredmail/mlmmjadmin

gha_language: Python

repo_name: iredmail/mlmmjadmin


text:
# Fish Theme: 8o8

Based on: clearance

A minimalist [fish shell](http://fishshell.com/) theme for people who use git

![8o8 theme](https://raw.github.com/bobisme/fish-theme-8o8/master/8o8-fish_preview.png)

## Like it?

Check out other versions of this theme for OSX Terminal or VIM!


text:
Given the list from the main migration status page:
1.	Using Azure DevOps for CI
2.	Using shared toolset (Arcade SDK)
3.	Engineering dependency flow
4.	Internal builds from dnceng

[Edited] Estimated timeline
1.	Early January
2.	Mid January
3.	Mid January
4.	End of January

repository: dotnet/test-templates

branch_name: refs/heads/main

gha_language: Rich Text Format

repo_name: dotnet/test-templates


text:
# Description

This cookbook install VMWare harbor [https://github.com/vmware/harbor]

It doesn't install docker engine required for this installation.

# Requirements

## Platform:

* debian
* ubuntu

## Cookbooks:

* docker

# Attributes

* `node['harbor']['foo']` -  Defaults to `bar`.

# Recipes

* harbor::default - Installs and configures VMWare Harbor

# License and Maintainer

Maintainer:: Yauhen Artsiukhou<EMAIL_ADDRESS>Source:: https://github.com/jsirex/harbor-cookbook
Issues:: https://github.com/jsirex/harbor-cookbook/issues

License:: MIT

repository: jsirex/harbor-cookbook

repo_name: jsirex/harbor-cookbook


text:
---
layout: default
---

# 1994-11-28 - Transparent Email (WAS disable telnet to port 25)

## Header Data

From: Alex Strasheim<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: bb969eb89e1682fcc6a80e0e9321ef4596c8367cfa460f7864face54d5a8c8fd

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1994-11-28 08:34:08 UTC

Raw Date: Mon, 28 Nov 94 00:34:08 PST

## Raw message

```
{% raw  %}From: Alex Strasheim<EMAIL_ADDRESS>Date: Mon, 28 Nov 94 00:34:08 PST
To<EMAIL_ADDRESS>Subject: Transparent Email (WAS disable telnet to port 25)
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text

-----BEGIN PGP SIGNED MESSAGE-----

> I don't have an answer to your question, but you did bring up something
> I've been meaning to ask about for some time and I never really got
> around to it; Are there any short-term plans to press for an RFC
> utilizing digital signatures?  With the exponential increase of mail
> users, as well and the influx of Compu$erv, AOL, Prodigy and other users,
> some methods for the transparent use of digital signatures needs to be
> worked out before it becomes too difficult to implement change because
> the commercial services have all the power.  (or worse, before the
> government decides for us.)

Some still unformed thoughts on this subject:

The big problem with transparent encryption and signatures is key
distribution:  if you've never sent a letter to me, your mailer will have
to get my key (invisibly) before the mail can be sent.  The big problem
with key distribution is the web of trust:  who gets to decide which keys
are good?

This is a subtle advantage that systems with centralized key generation
have over systems like PGP, which let users generate their own keys.  If
big brother mints all the keys, then big brother can set up an
authoritative keyserver.

The best answer that I can come up with for this problem is to allow for
several webs of trust to function simultaneously.  Perhaps we would have
a default web, which would have everyone's key in it.  The idea behind
the default web is that it should be able to return a key as often as
possible, so we don't want to make it too difficult to submit keys for
this web.

But anyone else could devise his or her own web, and administer it however
he or she pleased.  A request to a keyserver would include a list of webs,
in order of preference, that the user would be willing to deal with.  At
the end of the list would be the default web, in case nothing better was
available.

A web could be defined by a single top-level public key and a set of
rules.  Perhaps a text based program -- a sort of "meta-pgp" -- could
check chains of signatures to validate a key.

Suppose, for example, that I'm administering a web of trust.  I set up
the web so that I can deputize notaries who can in turn sign user keys.
Lets further assume that all signatures are good for a year.  A keyserver
would return a text file containing: (a) the user's key, concated with a
header specifiying the date it was signed by the notary, and (b) the
notary's key, concated with a header specifiying the date it was singed
by me.

We'd want "meta-pgp" to be able to handle complex rules which would give
it the flexibility to implement a wide variety of webs.  Perhaps it could
use prolog-ish style induction to determine if a key was good.

Does this make sense?  Is it something that was already proposed and
discarded?

==
Alex Strasheim | finger<EMAIL_ADDRESS><EMAIL_ADDRESS>| for my PGP 2.6.1. public key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLtmV+hEpP7+baaPtAQH3kgP8DmycpNrZKQRpyK1rclxJnIY2bdT5m4iM
p7IQ7nI07PSMn+ldye2xG5jjms42CR0BVvk4hhdGzDJwcgdd3FHFC7xNHvhk+SOE
4EHqpyW+YdNSe3A7+sMZp30mgWEnvHOpnrU9UiMUIaC8gcLk3GlkXdxDG+SWGwv/
1yesnbaUxYM=
=p2UQ
-----END PGP SIGNATURE-----

{% endraw %}
```

## Thread

+ Return to [November 1994](/archive/1994/11)

+ Return to "[Alex Strasheim <alex@omaha.com>](/authors/alex_strasheim_alex_at_omaha_com_)"
+ Return to<EMAIL_ADDRESS>(Eric Hughes)](/authors/eric_at_remailer_net_eric_hughes_)"

+ _Unknown thread root_
  + 1994-11-28 (Mon, 28 Nov 94 00:34:08 PST) - Transparent Email (WAS disable telnet to port 25) - _Alex Strasheim<EMAIL_ADDRESS>    + 1994-11-28 (Mon, 28 Nov 94 13:53:29 PST) - [Re: Transparent Email](/archive/1994/11/4fd2e121b36586fe3bdd4cba1c2e8a8ef4f7b6a07933c17399aeafa0b1c0d92d) -<EMAIL_ADDRESS>(Eric Hughes)_


text:
# PWA Budget-Tracker

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) ![Contributor](https://img.shields.io/badge/Contributor-1-green.svg) ![Nodejs](https://img.shields.io/badge/AppWith-NodeJS-red.svg) ![JavaScript](https://img.shields.io/badge/AppWith-ExpressJS-green.svg) ![Nodejs](https://img.shields.io/badge/Database-MongoDB-green.svg) ![PWA](https://img.shields.io/badge/Tech-PWA-blue.svg)

## General Information

* [Deployed Web Application](https://sheltered-mountain-98720.herokuapp.com/)
* [GitHub repository of Budget-Tracker](https://github.com/ZahraMertens/Budget-Tracker.git)

## Table of Contents
1. [General Information](#general-information)
2. [Task Description](#task-description)
3. [Mock-Up](#mock-up)
4. [Installation Instructions](#installation-instructions)
5. [Technologies Used](#technologies-used)
6. [User Story](#user-story)
7. [Business Context](#business-context)
8. [Usage](#usage)
9. [Credits](#credits)

## Task Description

The Web Application is a Budget-Tracker which allows a user to to able to keep track of their expenses. The user is able to add and substract funds into the tracker and a graph displays the progress of the users expenses. The web application is also a PWA (Progressive Web App) which allows the user to add the webpage as a bookmark on the homescreen of the phone or desktop and can operate offline. When the user adds expenses offline and goes back online, the offline entries shold be added to the tracker.

## Mock-Up

🎥 The GIF shows the Web Applications offline functionality:

![Code-Demo](./assets/gif.gif)

![Screenshot](./assets/screenshotApp.png) ![Screenshot](./assets/screenshotApp2.png)

## Installation Instructions

### Installation as "Add to homescreen" Application of phone:

![Screenshot](./assets/installation.gif)

### Installation of Code:

* First the user must clone the [GitHub Repo](https://github.com/ZahraMertens/Budget-Tracker.git) on its OS.

* Open the repository on your device with VS Code (or any other program)

* Open the command line at the folder location OR the integrated terminal

* First, you MUST install the npm packages by running "npm install" in the terminal

* To initialize the database the user must have mongoDB installed and then run "mongo" in the terminal

* To un the application on your local device the user must run "npm start" in the terminal and will see a link such as "http://localhost:3000" if the user runs the link in the browser the application should run on the local host.

## Technologies Used

* JavaScript
* Node.JS
* Express.JS
* MongoDB
* Dotenv
* Mongoose
* MongoDB Atlas (Cloud)
* Service Worker
* Web Manifest
* IndexedDB

## User Story

```
AS AN avid traveller
I WANT to be able to track my withdrawals and deposits with or without a data/internet connection
SO THAT my account balance is accurate when I am traveling
```

## Business Context

A consumer is more aware of his/her expenses when entering all expenses and deposits into the budget tracker.

## Usage

* WHEN I open the application in the browser THEN I am presented with a graph and input fields

* WHEN I input an expense name and amount i can decide to substract funds or add funds to my budget tracker

* WHEN I enter the funds a list of all entered expenses will appear above the graph and the graph will display my expenses more visially

* WHEN the user inputs a withdrawal or deposit when offline THEN it will be shown on the page, and added to their transaction history when their connection is back online.

## Credits

* https://www.mongodb.com/
* https://mongoosejs.com/docs/
* https://cloudconvert.com/mp4-to-gif
* https://developer.mozilla.org/en-US/docs/Web/Manifest
* https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
* https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

© 2021 Zahra Mertens, Budget-Tracker

repository: ZahraMertens/Budget-Tracker

repo_name: ZahraMertens/Budget-Tracker


text:
# RSS

KirBot can be configured to subscribe to RSS feeds and post new updates to a given channel.

An example use case of this would be subscribing to a Youtuber's RSS feed and being notified of new
uploads.

KirBot's RSS feeds refresh every 15 minutes.

## Configuring

View a list of all currently configured RSS feeds in the current channel with the `!rss` command.
This will send a message with all the currently monitored feeds as well as its id to the channel.

### Subscribing

To subscribe to an RSS feed, use the `!rss subscribe <url>` command. After a successful invocation,
new RSS feed items will be posted in the channel every time the feed is refreshed (defaults to every
15 minutes).

### Unsubscribing

To unsubscribe from an RSS feed, grab teh feed's ID (the 10 digit alphanumberic string) with `!rss`.
Afterwards, run `!rss unsubscribe <id>`. This will immediately unsubscribe KirBot from the feed.

### Manual Refresh

Manually refreshing the RSS feed is accomplished with `!rss refresh <feed id>`. This will immediately
refresh the feed and post new entries to the channel.

#### Feed Errors

If KirBot fails to refresh a feed during one of its periodic refreshes, it will enter a failed state.
Feeds that have failed will not be automatically refreshed, but will need to be refreshed manually.
If the refresh is successful, KirBot will continue automatically refreshing the feed.

## Commands
* `!rss` -- Lists all RSS feeds configured in the channel
* `!rss add <url>` -- Subscribes to an RSS feed
* `!rss remove <id>` -- Unsubscribes from an RSS feed

gha_language: Kotlin


text:
---
id: getting-started-quickstart
title: Quickstart
---

> For this quickstart you'll need:
>
> - a recent version of [docker](https://docs.docker.com/install/)
> - a recent version of [nodejs](https://nodejs.org/en/)

## Set up StaticDeploy with docker

- start StaticDeploy:

  ```sh
  docker run --rm --init \
    -e MANAGEMENT_HOSTNAME=local.staticdeploy.io \
    -e ENFORCE_AUTH=false \
    -p 80:80 \
    staticdeploy/staticdeploy
  ```

- visit the Management Console at
  [local.staticdeploy.io](http://local.staticdeploy.io/) (which points to
  `<IP_ADDRESS>`)

## Publish a static app

> Note: we'll be publishing a demo app taken from the StaticDeploy repository,
> but you can publish any directory on your computer just as easily

- install the StaticDeploy CLI:

  ```sh
  npm install --global @staticdeploy/cli
  ```

- configure the CLI using environment variables:

  ```sh
  export STATICDEPLOY_API_URL=http://local.staticdeploy.io/api
  ```

- clone the StaticDeploy repository and `cd` into it:

  ```sh
  git clone https://github.com/staticdeploy/staticdeploy.git
  cd staticdeploy
  ```

- create a bundle for the demo static app in `website/demo-static-app`:

  ```sh
  staticdeploy bundle \
    --from website/demo-static-app \
    --name demo-static-app \
    --tag master \
    --description "version 1.0.0"
  ```

- deploy the bundle to `demo-static-app.staticdeploy.io`:

  ```sh
  staticdeploy deploy \
    --app demo-static-app \
    --entrypoint demo-static-app.staticdeploy.io/ \
    --bundle demo-static-app:master
  ```

- visit
  [demo-static-app.staticdeploy.io](http://demo-static-app.staticdeploy.io/)
  (which also points to `<IP_ADDRESS>`)

- check out the deployment on the Management Console at
  [local.staticdeploy.io](http://local.staticdeploy.io/). Try modifying the
  entrypoint configuration and see how
  [demo-static-app.staticdeploy.io](http://demo-static-app.staticdeploy.io/)
  changes

repository: Pendulla/staticdeploy

repo_name: Pendulla/staticdeploy


text:
#  20170526 Technology Transfer Meeting

**Date: May 26, 2017**

**Time: 10 a. m. – 11: a. m.**

**Agenda:**
1.	DOE Code overview and impact
2.	Questions and Answers

**Proceedings:**

This was a meeting to explore possibilities for DOE Code and Office of Technology Transitions collaboration.  Attendees explained their roles and responsibilities in their respective positions at OTI and OTT. There was a new group member who explained his background in data modeling and analysis, and with EERE.

1.	The DOE Code team provided a high-level overview of DOE Code, emphasizing how the open source movement has impacted software development and practices, necessitating the need for a different model than ESTSC.
  Someone from the team expressed how surprised they were that ESTSC was not better known, questioning why we would build a new software center rather than look to commercial products or companies for the solution.
  The DOE Code team explained how OSTI provides unique expertise in building STI archival solutions, and described the requirements for a DOE software center.  No one commercial service would accommodate their needs.  Also, part of this effort is to build a community that will provide ongoing contributions to development.

2.	There were other questions posed about the metadata, qualitative descriptors, content, and taxonomy that the DOE Code will employ.  The DOE Code team members explained the modernized 241.1 and the basis for all required elements.  They also provided the location of the metadata folder, Github.com/doecode/doecode, where the metadata application profile could be viewed.
  Later, a group member emphasized the importance of collaboration.

**Conclusions/ Actions:**
A meeting will be scheduled for next Friday for a detailed discussion of slides with team members.

repository: doecode/doecode

gha_language: Java

repo_name: doecode/doecode


text:
# Donald Trump: 'Very Slow' Joe Biden a 'Delusional Democrat Fantasy' | Breitbart

Published at: **2019-11-02T03:22:55+00:00**

Author: **Charlie Spiering**

Original: [Breitbart](https://www.breitbart.com/politics/2019/11/01/donald-trump-very-slow-joe-biden-a-delusional-democrat-fantasy/)

“In the delusional democrat fantasy, I am now supposed to be afraid of someone called one percent Joe,” Trump said.
The president pointed out that Biden struggled to get more than one percent support when he ran for president in 1988 and 2007, until Barack Obama selected him as his running mate.
“We’ve now named him very slow Sleepy Joe,” Trump said. “He’s gotten slower and slower. I’m afraid that if he gets the nomination, he’ll be so slow, we’ll have the lowest-rated debates in history.”
The president commented on Biden during his rally in Mississippi on Friday, again criticizing the vice president and his son Hunter Biden for their corruption in Ukraine.
He reminded his supporters that he beat the Clinton and Bush dynasties in 2016 despite President Barack Obama’s attempt to campaign for Hillary Clinton.
“Then they figured they could take us out a different way, very dishonestly right?” he asked.
The crowd roared with support for the president.
Trump said it was nonsense that he was afraid of Biden, requiring him to try to get Ukraine to help him win the election.
“These people are sick!” Trump said.

license: Unlicense

repository: dsadlollioygjmzvcxv/tdc-exported

repo_name: dsadlollioygjmzvcxv/tdc-exported


text:
# delayq
Delayed queue in golang

An example

``` golang
package main

import (
	"fmt"
	"time"

	"github.com/srishina/delayq"
)

const (
	delayDuration = 4 * time.Second
)

func main() {
	delayedq := delayq.NewDelayQueue(12)
	defer delayedq.Close()

	testItem := "Hello world!"
	// place an item into the queue with the delay duration
	delayedq.Put(testItem, delayDuration)

	// the input items are delayed
	done := make(chan struct{})
	go func() {
		defer close(done)
		item, _ := delayedq.Get()
		fmt.Println("Delayed item received, value: ", item)
	}()

	fmt.Println("Wait till the delayed item is received...")

	select {
	case <-time.After(delayDuration + time.Second):
		fmt.Println("error: shoud not timeout")
	case <-done:
		fmt.Println("Finished...")
	}
}
```

LICENSE
-------
MIT

repository: srishina/delayq

repo_name: srishina/delayq


text:
# Demo: Integrating a Google Compute Engine VM with Istio

This demo shows how to connect a Google Compute Engine virtual machine to an Istio service
mesh running in Google Kubernetes Engine.

This example is relevant if you're running an application outside
of Kubernetes, but still want to enjoy the full benefits of Istio for that service.

We will use the [Hipstershop](https://github.com/GoogleCloudPlatform/microservices-demo) sample app for this demo, with the following topology:

![screenshot](screenshots/topology.png)

Here, the `productcatalog` service will be our "monolith" running in a VM outside of
Kubernetes. For demonstration purposes, we'll run productcatalog in a raw Docker container
inside the VM, then integrate it with the rest of the in-mesh services running in GKE.

## prerequisites

- A GCP project with billing enabled
- helm CLI
- gcloud
- kubectl

## GCP Setup

For this demo, the GCE VM and the GKE cluster will live in the same GCP project. Set an
environment variable for your project ID.

```
export PROJECT_ID=<your-project-id>
```

## 1- Create a GKE Cluster

Create a 4-node GKE cluster named `mesh-exp-gke`:

```
./scripts/1-create-gke.sh
```

Wait for the GKE cluster to be `RUNNING` -

```
gcloud container clusters list
```

Connect to the cluster:

```
gcloud container clusters get-credentials mesh-exp-gke --zone us-central1-b --project $PROJECT_ID
```

## 2- Install Istio on GKE

*Optional*: Set [Istio Version](https://github.com/istio/istio/releases):

```
ISTIO_VERSION=<version>
```

Install Istio on the cluster:

```
./scripts/2-install-istio-gke.sh
```

## 3- Create a GCE Instance

This script will create a Ubuntu GCE instance in your GCP Project. The VM is named `istio-gce`.

```
./scripts/3-create-gce.sh
```

## 4- Prepare the VM for Mesh Expansion

In order for mesh expansion to work, we must send Istio information from GKE to the VM.
This includes a script, which will run on the VM in step 6.

```
./scripts/4-configure-mesh-exp.sh
```

At the end of the script output, you should see:

```
6-configure-vm.sh                                                    100% 1806    48.4KB/s   00:00
cluster.env                                                          100%   83     2.3KB/s   00:00
cert-chain.pem                                                       100% 1139    31.4KB/s   00:00
key.pem                                                              100% 1675    46.3KB/s   00:00
root-cert.pem                                                        100% 1054    29.6KB/s   00:00
...done.
```

## 5- Add VM to the GKE Istio Mesh

```
./scripts/5-expand-mesh.sh
```

You will see some long output from `istioctl register`. If the VM Endpoint registration
is successful, you should see this message:

```
	Successfully updated productcatalogservice, now with 1 endpoints
```

Then, check to make sure a service exists for the VM-based productcatalog.
`EXTERNAL_IP` should be `none`, since we aren't directly exposing productcatalog to the Internet.

```
$ kubectl get svc

NAME                    TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
kubernetes              ClusterIP   <IP_ADDRESS>     <none>        443/TCP    51m
productcatalogservice   ClusterIP   <IP_ADDRESS>   <none>        3550/TCP   43s
```

## 6- Install Istio on the VM / Run ProductCatalog

To finish up Istio Mesh Expansion, we must ssh into the VM:

```
gcloud compute --project $PROJECT_ID ssh --zone "us-central1-b" "istio-gce"
```

From the VM, run the mesh expansion script:

```
chmod +x ./6-configure-vm.sh; ./6-configure-vm.sh
```

This script:
- installs Docker on the VM
- downloads the Istio remote binary
- runs the Istio remote components (`pilot-agent` and `node-agent`)
- configures the Istio remote to "call home" to Istio running on your GKE cluster
- runs ProductCatalog inside a Docker container.

When the script runs successfully, you should be able to run:

```
sudo docker ps
```

And you should see the ProductCatalog container running:
```
CONTAINER ID        IMAGE                                                                   COMMAND                  CREATED             STATUS              PORTS                    NAMES
521d9d0de04b        gcr.io/google-samples/microservices-demo/productcatalogservice:v0.1.0   "/productcatalogserv…"   2 minutes ago       Up 2 minutes        <IP_ADDRESS>:3550->3550/tcp   inspiring_hawking
```

Exit out of the VM shell.

## 7- Deploy Hipstershop

The last step is to deploy the rest of Hipstershop (without ProductCatalog) on the Istio-enabled GKE
cluster.

**Note**: The Hipstershop Deployments, here, refer to `productcatalog` as if it were an
in-mesh service (`productcatalogservice:3550`). This is because in step 5, we created a
`ServiceEntry` of type `MESH_INTERNAL` for our VM / port 3550.

Deploy the app:

```
./scripts/7-deploy-hipstershop.sh
```

And wait until all the pods are running:

```
NAME                                     READY   STATUS    RESTARTS   AGE
adservice-6cd6965787-29zk8               2/2     Running   0          4m
cartservice-57c6949b9-cgmf9              2/2     Running   0          4m
checkoutservice-6848667dd7-md66j         2/2     Running   0          4m
currencyservice-668f49f985-zmvwk         2/2     Running   0          4m
emailservice-796bb9588b-8c55p            2/2     Running   0          4m
frontend-6dcd4969b4-hn6z8                2/2     Running   0          4m
paymentservice-548657568f-lnnn9          2/2     Running   0          4m
recommendationservice-5fb85f46df-kslhp   2/2     Running   0          4m
shippingservice-5f5d75bf65-q6cf5         2/2     Running   0          4m
```

## Verify that mesh expansion is working

Get the Frontend's `EXTERNAL_IP` address:

```
kubectl get svc -n istio-system istio-ingressgateway
```

Then open Hipstershop in the browser using that IP. if you see a list of products (fetched
from ProductCatalog), this means that the `frontend` service can successfully use our
`ServiceEntry` to reach `productcatalog` running in the GCE VM.

![hipstershop-frontend](screenshots/hipstershop-default.png)

Congratulations, you just set up Istio Mesh Expansion on GCP! 🎉

## Clean up

To delete the GCE VM:

```
gcloud compute instances --project $PROJECT_ID delete --zone "us-central1-b" "istio-gce"
```

To delete the GKE cluster:

```
gcloud container clusters delete mesh-exp-gke --zone us-central1-b
```

## Learn More

To read more about VM Mesh Expansion with Istio, see the [Istio documentation](https://preliminary.istio.io/docs/setup/kubernetes/additional-setup/mesh-expansion/).

Or to run another Mesh Expansion example (BookInfo and MySQL), see the
[example](https://preliminary.istio.io/docs/examples/integrating-vms/).

repository: tjovicic/istio-samples

repo_name: tjovicic/istio-samples


text:
## Configuration

To use this provider, add an entry to `creds.json` with `TYPE` set to `DNSMADEEASY`
along with your `api_key` and `secret_key`. More info about authentication can be found in [DNS Made Easy API docs](https://api-docs.dnsmadeeasy.com/).

Example:

{% code title="creds.json" %}
```json
{
  "dnsmadeeasy": {
    "TYPE": "DNSMADEEASY",
    "api_key": "1c1a3c91-4770-4ce7-96f4-54c0eb0e457a",
    "secret_key": "e2268cde-2ccd-4668-a518-8aa8757a65a0"
  }
}
```
{% endcode %}

## Records

ALIAS/ANAME records are supported.

This provider does not support HTTPRED records.

SPF records are ignored by this provider. Use TXT records instead.

## Metadata
This provider does not recognize any special metadata fields unique to DNS Made Easy.

## Usage
An example configuration:

{% code title="dnsconfig.js" %}
```javascript
var REG_NONE = NewRegistrar("none");
var DSP_DNSMADEEASY = NewDnsProvider("dnsmadeeasy");

D("example.com", REG_NONE, DnsProvider(DSP_DNSMADEEASY),
    A("test", "<IP_ADDRESS>")
);
```
{% endcode %}

## Activation
You can generate your `api_key` and `secret_key` in [Control Panel](https://cp.dnsmadeeasy.com/) in Account Information in Config menu.

API is only available for Business plan and higher plans.

## Caveats

### Global Traffic Director
Global Traffic Director feature is not supported.

## Development

### Debugging
Set `DNSMADEEASY_DEBUG_HTTP` environment variable to dump all API calls made by this provider.

### Testing
Set `sandbox` key to any non-empty value in credentials JSON alongside `api_key` and `secret_key` to make all API calls against DNS Made Easy sandbox environment.

repository: StackExchange/dnscontrol

gha_language: Go

repo_name: StackExchange/dnscontrol


text:
## JavaScript Ruleset Format

Spectral v6.0 added support for a JavaScript ruleset format, similar to the JSON and YAML formats.

This has a few benefits:

- It lets you explicitly load formats or rulesets to get control over versioning.
- You can load common functions from popular JS libraries.
- It feels a lot more welcoming to developers experienced with JavaScript, especially when it comes to working with custom functions.

**Example**

To create a JavaScript ruleset, the first step is creating a folder. In your terminal, run the following commands:

```
mkdir style-guide
cd style-guide
```

Next, install two dependencies using [npm](https://www.npmjs.com/):

```
npm install --save @stoplight/spectral-functions
npm install --save @stoplight/spectral-formats
```

Installing these packages isn't required for creating a JavaScript ruleset, but you'll use them in the example to create some common rules used with Spectral and to target a specific OpenAPI format.

Next, create a JavaScript file to hold your ruleset:

```
touch spectral.js
```

Inside the file, create a couple of rules:

```js
import { truthy, undefined as pattern, schema } from "@stoplight/spectral-functions";
import { oas3 } from "@stoplight/spectral-formats";

export default {
  rules: {
    "api-home-get": {
      description: "APIs root path (`/`) MUST have a GET operation.",
      message: "Otherwise people won't know how to get it.",
      given: "$.paths[/]",
      then: {
        field: "get",
        function: truthy,
      },
      severity: "warn",
    },

    // Author: Phil Sturgeon (https://github.com/philsturgeon)
    "no-numeric-ids": {
      description: "Avoid exposing IDs as an integer, UUIDs are preferred.",
      given: '$.paths..parameters[*].[?(@property === "name" && (@ === "id" || @.match(/(_id|Id)$/)))]^.schema',
      then: {
        function: schema,
        functionOptions: {
          schema: {
            type: "object",
            not: {
              properties: {
                type: {
                  const: "integer",
                },
              },
            },
            properties: {
              format: {
                const: "uuid",
              },
            },
          },
        },
      },
      severity: "error",
    },

    // Author: Nauman Ali (https://github.com/naumanali-stoplight)
    "no-global-versioning": {
      description: "Using global versions just forces all your clients to do a lot more work for each upgrade. Please consider using API Evolution instead.",
      message: "Server URL should not contain global versions",
      given: "$.servers[*].url",
      then: {
        function: pattern,
        functionOptions: {
          notMatch: "/v[1-9]",
        },
      },
      formats: [oas3],
      severity: "warn",
    },
  },
};
```

If you use custom functions, the keywords `functions` and `functionOptions` have been removed, as they were designed to help Spectral find your functions. Now functions are passed as a variable, instead of using a string that contains the name like the JSON/YAML formats.

Next, publish the ruleset as an npm package, and then install that package as part of your API project and reference it in your Spectral ruleset as:

```
extends: ["@your-js-ruleset"]
```

Or using unpkg:

```
extends:
  - https://unpkg.com/@your-js-ruleset
```

For a more detailed example of creating a JavaScript ruleset and publishing it to npm, check out [Distribute Spectral Style Guides with npm](https://apisyouwonthate.com/blog/distribute-spectral-style-guides-with-npm) at APIs You Won't Hate.

repository: stoplightio/spectral

gha_language: TypeScript

repo_name: stoplightio/spectral


text:
## Example applications

Data for four example application can be found here: [nba](https://www.dropbox.com/s/baqb01thxvfthk5/nba_db_psql.sql?dl=0), [usmap](https://www.dropbox.com/s/youvfap909mk1m3/usmap_db_psql.sql?dl=0), [forest](https://www.dropbox.com/s/39ji04m926lfx5i/forest_db_psql.sql?dl=0) and [flare](https://www.dropbox.com/s/ugr3cx63ul3tt0k/flare_db_psql.sql?dl=0).

To load data of `app` (can be one of `nba`, `usmap`, `forest` or `flare`) into our docker container, run the following under root git directory:

      $ ./docker-scripts/load-sql.sh app.sql --dbname app


text:
# Libraries
```
library(tidyverse)
library(gridExtra)
```
# CSVs
* FamilyFC.csv
This contains data of the Floral Coverage Quadrants, Cover Values, and Plant Families.
* FamilyPSC.csv
This contains data of the Plant Species Coverage Quadrants, Cover Values, and Plant Families.
* nativePSC.csv
This contains data of the Plant Species Coverage Quadrants and Cover Values for native plant species.
* nonNativePSC.csv
This contains data of the Plant Species Coverage Quadrants and Cover Values for non-native plant species.
* nativeFC.csv
This contains data of the Floral Coverage Quadrants and Cover Values for native plant species.
* nonNativeFC.csv
This contains data of the Floral Coverage Quadrants and Cover Values for non-native plant species.
```
FamilyFC <- read_csv("FamilyFC.csv", col_types = cols(X1 = col_skip()))
FamilyPSC <- read_csv("FamilyPSC.csv", col_types = cols(X1 = col_skip()))
nativePSC <- read_csv("nativePSC.csv", col_types = cols(X1 = col_skip()))
nonNativePSC <- read_csv("nonNativePSC.csv", col_types = cols(X1 = col_skip()))
nativeFC <- read_csv("nativeFC.csv", col_types = cols(X1 = col_skip()))
nonNativeFC <- read_csv("nonNativeFC.csv", col_types = cols(X1 = col_skip()))
```
# Plots
Coverage Value is a number assigned to a scale of the percentage of the Quadrant covered by the plant.
1 -- < 5%
2 -- 5 - 25%
3 -- 26 - 50%
4 -- 51 - 75%
5 -- 76 - 95%
6 -- > 99%.

## Research Question 2: How does the factor of being native versus non-native affect the plant growth of species in the fields tested?
### Multi-Plot of Density per Floral Cover
![](MultiFC.png)
This plot is a side-by-side look at the Floral Coverage of native vs non-native plant species. It shows the differences in how often they had cover values of 1-3. 4-6 was never hit so the graph was shrunk to 3. Native plants species had a higher density at 1 and 2 but had no values of 3 recorded. The differences at the value of 1 is small but could mean native plants have a higher chance to start up.
```
densityNonNativeFC <- ggplot(nonNativeFC[c(2,9,10)], aes(nonNativeFC$`Cover Value`)) + geom_density() + scale_x_discrete(name ="Cover Value",limits=c("1","2","3","4","5","6"))  + scale_y_discrete(name="Density",limits=c(0.0,0.25,0.5,0.75,1.0,1.25,1.5,1.75,2.0)) + ggtitle("Density of Non-Native Floral Cover")
densityNativeFC <- ggplot(nativeFC[c(2,9,10)], aes(nativeFC$`Cover Value`)) + geom_density() + scale_x_discrete(name ="Cover Value",limits=c("1","2","3","4","5","6"))  + scale_y_discrete(name="Density",limits=c(0.0,0.25,0.5,0.75,1.0,1.25,1.5,1.75,2.0)) + ggtitle("Density of Native Floral Cover")
MultiFC <- grid.arrange(densityNonNativeFC, densityNativeFC)
```
### Multi-Plot of Density for Plant Species Cover
![](MultiPSC.png)
This plot is a side-by-side look at the Plant Species Coverage of native vs non-native plant species. The plant species coverage is a measure of how established the plant is within a quadrant. The higher the value the better the growth. The plots show that the native plants have a higher density in the coverage values 1:4. This is showing that the early establishment of native plants is stronger than non-native plants. Values 5 and 6 show very similar densities between native and non-native plant species but the density is very small for each.
```
densityNativePSC <- ggplot(nativePSC[c(2,9,10)], aes(nativePSC$`Cover Value`)) + geom_density() + scale_x_discrete(name ="Cover Value",limits=c("1","2","3","4","5","6"))  + scale_y_discrete(name="Density",limits=c(0.0,0.25,0.5,0.75,1.0,1.25,1.5)) + ggtitle("Density of Native Plant Species Cover")
densityNonNativePSC <- ggplot(nonNativePSC[c(2,9,10)], aes(nonNativePSC$`Cover Value`)) + geom_density() + scale_x_discrete(name ="Cover Value",limits=c("1","2","3","4","5","6"))  + scale_y_discrete(name="Density",limits=c(0.0,0.25,0.5,0.75,1.0,1.25,1.5)) + ggtitle("Density of Non-Native Plant Species Cover")
MultiPSC <- grid.arrange(densityNativePSC, densityNonNativePSC)
```

## Reasearch Question 3: Do certain plant families show a greater cover value than others plant families?
### Density of Floral Cover by Plant Family
![](densityFamilyFC.png)
This plot shows that many of the families did not have much data in regards to Floral Coverage. The Aster, Mint, and Pea families were the only ones with recorded data. There is not many conclusions to be drawn from this plot. It is shown that the Aster and Mint family are recorded very highly at the value of 1, which indicates they started growing well, even if only covering a small amount. The Pea family while having less density at the value of 1, has the largest density of 2. The Mint family was the highest at 3, meaning it covered the most amount of the quadrant of any plant family measured by floral coverage.
```
densityFamilyFC <- ggplot(FamilyFC, aes(FamilyFC$`Cover Value`)) + geom_density() + scale_x_discrete(name ="Cover Value",limits=c("1","2","3"))  + scale_y_continuous(name="Density") + facet_grid(~FamilyFC$Family) + ggtitle("Density of Floral Cover per Plant Family"); densityFamilyFC
```
### Density of Plant Species Cover per Plant Family
![](densityFamilyPSC.png)
This plot shows each plant families density of cover data in regards to Plant Species Coverage. Bellflower, Figwort, Pea, Potato, and Verbana show very small, if any density past the Cover Value of 3. This means that the did not grow to cover as much of the quadrant as some of the other families did. Aster, Grass, and Poaceae families showed the highest densities at 6, the top cover value. This means that these families had the highest coverage of their quadrants.
```
densityFamilyPSC <- ggplot(FamilyPSC, aes(FamilyPSC$`Cover Value`)) + geom_density() + scale_x_discrete(name ="Cover Value",limits=c("1","2","3","4","5","6"))  + scale_y_continuous(name="Density") + facet_grid(~FamilyPSC$Family) + ggtitle("Density of Plant Species Cover per Plant Family"); densityFamilyPSC
```

repository: eeiler/EUREKA

repo_name: eeiler/EUREKA


text:
Prezto
------

This is the prezto module. It installs prezto for a user and changes
their shell to zsh. It has been tested under Ubuntu.

This module is based on acme/ohmyzsh

prezto is a community-driven framework for managing your zsh configuration: https://github.com/sorin-ionescu/prezto

```
class { 'prezto': }
prezto::install { 'username':
  git_repo => 'git://github.com/baopham/prezto.git',
}
```

License
-------

Apache License, Version 2.0.

repository: MartijnBraam/puppet-baopham-prezto

repo_name: MartijnBraam/puppet-baopham-prezto


text:
# Object Detection and OCR
[![license](https://img.shields.io/github/license/mashape/apistatus.svg)](LICENSE)

This project implement object detection with YOLOv4 and tensorflow. YOLOv4 use deep convolutional neural network to object object detection. I take the initiave use this library to perform detection, the OCR on lisence plate, and crop the detection.

Here the Result of the project after perform the ocr and vehicle detection using th is library.

## Lisence Plate Detection and OCR

##### detect car license plate

##### Crop the detection

##### Use Tesseract to extract text from image

:covid19)

## Getting Started
To get started, yyou are required to install the dependencies via pip. In this project we are using Google Colab as a platform to complete this projects.

### Prerequisites
* Tensorflow 2.3.0rc0
* pytesseract
* opencv

## Download pre-trained YOLOv4 weights.

My object detection uses YOLOv4 to perform the detection. I am using the existing pre-trained model (YOLOv4) that able to detect the car plate and vehicle. Attachment below is the link to download the model for car plate detection and vehicle detection.

License Plate Detection : https://drive.google.com/file/d/1EUPtbtdF0bjRtNjGv436vDY28EN5DXDH/view?usp=sharing

Car Detection : https://drive.google.com/open?id=1cewMfusmPjYWbrnuJRuKhPMwRe_b9PaT

### To run the program, you may copy the syntax i provided below

```bash
python detect.py --weights ./checkpoints/yolov4-tiny-416 --size 416 --model yolov4 --image 'YOUR DATA'
```

### Todo

* [x] Detect the license plate
* [x] Crop the Detection
* [x] Perform the OCR on detection
* [ ] Perform the OCR on PDF file

### References

   My project is inspired by these previous fantastic YOLOv4 implementations:
  * [Yolov4 tflite](https://github.com/hunglc007/tensorflow-yolov4-tflite)

repository: irwanmazlin/Object-Detection

path: /OCR using YOLOV4/README.md

repo_name: irwanmazlin/Object-Detection


text:
# Configuring Spin Data Format Configuration

This example describes how to configure a data format provided by Camunda Spin. It showcases the configuration of the Jackson-based JSON data format that Spin provides out-of-the-box. JSON serialization is customized by registering a Jackson module with a custom serializer and deserializer.

In particular, we examine how to customize the serialization of the class [Car](src/main/java/org/camunda/bpm/example/spin/dataformat/configuration/Car.java):

```java
public class Car {

  protected Money price;

  public Money getPrice() {
    return price;
  }

  public void setPrice(Money price) {
    this.price = price;
  }
}
```

`Car` references [Money](src/main/java/org/camunda/bpm/example/spin/dataformat/configuration/Money.java):

```java
public class Money {

  protected int amount;

  public Money(int amount) {
    this.amount = amount;
  }

  public int getAmount() {
    return amount;
  }
}
```

With default Jackson serialization, an object `new Car(1000)` is serialized as `{"price" : {"amount" : 1000}}`. In the following, we describe how to configure the serialization such that the result is `{"price" : 1000}` and give an example how this integrates with process variables and process execution.

We use the following process:

![JSON serialization process](src/main/resources/testProcess.png)

The script task *Extract price* expects a `Car` JSON object in the format of `{"price" : 1000}` and fails otherwise.

# Overview

## How to run it

1. Checkout the project with Git
2. Read and run the [unit test](src/test/java/org/camunda/bpm/example/spin/dataformat/configuration/JacksonConfiguratorTest.java)

## How it works

When a data format is accessed for the very first time, Spin performs a look up of all data formats on the classpath. After having instantiated the data formats, Spin detects so-called data format configurators and calls these with the detected format instances. Users may provide custom configurators to be able to influence the way a data format serializes and deserializes objects, which is what this example shows.

Configuring data formats requires to implement the SPI [DataFormatConfigurator](https://github.com/camunda/camunda-spin/blob/master/core/src/main/java/org/camunda/spin/spi/DataFormatConfigurator.java) and declare implementations of it in a file `META-INF/services/org.camunda.spin.spi.DataFormatConfigurator`. Here, the class [JacksonDataFormatConfigurator](src/main/java/org/camunda/bpm/example/spin/dataformat/configuration/JacksonDataFormatConfigurator.java) is such an implementation. It has the following contents:

```java
import org.camunda.spin.impl.json.jackson.format.JacksonJsonDataFormat;
import org.camunda.spin.spi.DataFormatConfigurator;

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.module.SimpleModule;

public class JacksonDataFormatConfigurator implements DataFormatConfigurator<JacksonJsonDataFormat> {

  public void configure(JacksonJsonDataFormat dataFormat) {
    ObjectMapper objectMapper = dataFormat.getObjectMapper();
    SimpleModule module = new SimpleModule();
    module.addDeserializer(Money.class, new MoneyJsonDeserializer());
    module.addSerializer(Money.class, new MoneyJsonSerializer());
    objectMapper.registerModule(module);
  }

  public Class<JacksonJsonDataFormat> getDataFormatClass() {
    return JacksonJsonDataFormat.class;
  }

}
```

The method `getDataFormatClass` declares the kind of data formats a configurator is able to configure. The method `configure` is the callback invoked by the Spin runtime after data format instantiation. Here, we register in form of the classes [MoneyJsonSerializer](src/main/java/org/camunda/bpm/example/spin/dataformat/configuration/MoneyJsonSerializer.java) and [MoneyJsonDeserializer](src/main/java/org/camunda/bpm/example/spin/dataformat/configuration/MoneyJsonDeserializer.java) a Jackson serializer and deserializer for the `Money` class. These make sure that a `Car` object is serialized in the way we need it.

The script task *Extract price* makes use of that structure by defining the following script:

```javascript
var carJson = execution.getVariableTyped("car").getValueSerialized();
var price = S(carJson ).prop("price").numberValue();
execution.setVariable("price", price);
```

In the [test case](src/test/java/org/camunda/bpm/example/spin/dataformat/configuration/JacksonConfiguratorTest.java), we assert that the *price* property was successfully populated.

For this to work, it is crucial that the Spin runtime is able to lookup the `DataFormatConfigurator` implementation. That means, the artifact containing the data format configurator and the corresponding `META-INF/services` file must be on Spin's classpath.

You can find the Spin documentation on configuring data formats [here](https://docs.camunda.org/manual/reference/spin/extending-spin/#configuring-data-formats).

## How it works on an application server with shared engine

This example demonstrates the configuration functionality via a unit test.

In order to configure data formats on an application server and a shared engine scenario, do the following:

* Make sure to use the [camunda-spin-core](https://docs.camunda.org/manual/user-guide/data-formats/configuring-spin-integration/#camunda-spin-core) dependencies in your application server, not  [camunda-spin-dataformat-all](https://docs.camunda.org/manual/user-guide/data-formats/configuring-spin-integration/#camunda-spin-dataformat-all)
* Implement a configurator as in this example
* Build the Maven project; the result is a jar file that contains the configurator and the declaration file under `META-INF/services`
* Ensure that the jar file is available on the classpath of the `camunda-spin-core` artifact

*Known limitation*:
The configuration artifact can not be deployed as part of a process application if Spin itself is not part of it. That means, dependencies of the configuration artifact can also not be part of the process application.

repository: jonashackt/camunda-bpm-examples

repo_name: jonashackt/camunda-bpm-examples


text:
---
layout: default
title: UMD Project: Samples
---
[Back](./)
<br/>
### Samples
This section will showcase how to integrate the `umd-viewer.min.js` in a custom webapp or website.

##### Sample 1
This will allow the user to upload an UMD file from the local drive and display on the web page.
(umd-with-file.html)(./umd-with-file.html)
{:target="_blank"}

##### Sample 2
This will allow the user to upload an UMD file by entering the URL of the file stored on an internet server (with CORS enabled!).
(umd-with-url.html)(./umd-with-url.html)
{:target="_blank"}

repository: rrrepos/umd-project-org

repo_name: rrrepos/umd-project-org


text:
---
layout: page
title: Vue.js Notes
share-img: "/img/pages/vue-logo.png"
---

These are notes I took while learning Vue.js, I publish them as some other learners might find them useful.

- [Vue.js Template](/pages/vue-notes/vue-template/)
- [Vue.js Instance](/pages/vue-notes/vue-instance/)
- [Vue.js File Example](/pages/vue-notes/vue-file-example/)


text:
# Code Management

Code is at the centre of all of our work. Keeping it clean and tidy is
fundamental to an efficient, manageable and sustainable process.

The following are guides to how we wrangle 100s of repositories:

* [Git](git.md)
* [Git For Shopify](git-shopify.md)

repository: JoseMPena/cookbook

repo_name: JoseMPena/cookbook


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

# Summary
This package contains type definitions for Microsoft ActiveX Data Objects 6.0 Library - ADODB (https://msdn.microsoft.com/en-us/library/jj249010.aspx).

# Details
Files were exported from https://github.com/DefinitelyTyped/DefinitelyTyped.git/tree/master/types/activex-adodb

Additional Details
 * Last updated: Sat, 19 May 2018 00:15:19 GMT
 * Dependencies: activex-interop
 * Global values: ADODB

# Credits
These definitions were written by Zev Spitz <https://github.com/zspitz>.


text:
## About

The API for a real-time game, built with [Feathers](http://feathersjs.com). The game is about guessing animals from blurred images. This API works in tandem with this client: https://github.com/shakahari/animal-safari

This project taught us a lot about using real-time socket.io connections to build a real-time game.

## Getting Started

Getting up and running is as easy as 1, 2, 3.

1. Make sure you have [NodeJS](https://nodejs.org/) and [npm](https://www.npmjs.com/) installed.

2. Install your dependencies

    ```
    cd path/to/games-api-b9; npm install
    ```

3. Start your app

    ```
    npm start
    ```

## License

Copyright (c) 2016

Licensed under the [MIT license](LICENSE).

repository: jansi-z/safari-api

repo_name: jansi-z/safari-api


text:
backbone.flow
=============

Specialized container for creating a workflow of views.

Prerequisites
-------------
* Node.js (v0.10.x)

Features
--------
* View Container
* Event Management
* Render Management
* Cleanup Management

Motivation
----------

While the general [recommendations](http://addyosmani.github.io/backbone-fundamentals/)
surrounding `Backbone.View` reuse are simply to trash views rather risk
[memory leaks](https://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/)
due to [complex event cleanup](http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always-simple/),
there are some scenarios where _temporal_ reuse may prove useful.  For example,
consider the case of a user attempting to login via two-factor authentication,
performing a password reset, or placing an online order as part of a multi-step
process.

Each of these scenarios represent a `Single Workflow Item`, whereby both
the application and the user need the ability to switch freely between these views
either by direct user interaction, or in the event of certain types of failures; not
to mention that each view may need to share access to the same models for state
and react to events.

Architecture
------------

The principle behind the `Backbone.Container.Flow` is to act as a logical container
for the views, define the transitions between them, and manage event cleanup on your
behalf during transitions to prevent memory leaks. In essence, each child view should
not know that it is part of a container, and should still function as a standalone unit.

Furthermore, the `Backbone.Container.Flow` expects child views to be injected
upon construction, with each of the shared models already injected into the
corresponding child views.  The diagram below helps to better illustrate these concepts:

![architecture](doc/architecture.png)

Disclaimer
----------

When transitioning between views within a flow, the container will remove the DOM
event bindings but not `listenTo` bindings so that views can still react to model
events (if necessary).  This may lead to unintended consequences, as was described
in backbone [best practices](http://addyosmani.github.io/backbone-fundamentals/),
so use _responsibly_.  However, once `Backbone.Container.Flow.remove()` has been
explicitly called, all container and child view events will be cleaned up.

Usage and Documentation
-----------------------
Please ensure all dependencies have been installed prior to usage.

### Setup

Switch to the project root directory and run the `setup.sh` script (`setup.bat` for Windows):
```bash
$ cd backbone.flow
$ ./bin/setup.sh
```

### Workflow

The `grunt serve` (watch, build, test) loop is designed to accelerate development workflow:
```bash
$ grunt serve
```

Alternatively, to simply build the component, invoke:
```bash
$ grunt build
```

Project Structure
-----------------
<pre>
/
|-- bower.json: runtime dependencies (backbone, underscore)
|-- package.json: build dependencies (grunt plugins)
|-- Gruntfile.js: all grunt build, deploy, compile, serve tasks
|-- dist: deployment-ready assets
|-- src: all component code
    |-- scripts (javascript assets)
        |-- backbone (backbone plugins)
            |-- container (container-based plugins)

</pre>

### Usage: Backbone
```javascript

// app namespace structure
var App = App || {};
App.Views = App.Views || {};
App.Models = App.Models || {};
App.Templates = App.Templates || {};

// define shared model
App.Models.SharedModel = Backbone.Model.extend({});

// define child views
App.Views.First = Backbone.View.extend({
  template: App.Templates['demo/first'],
  events: {
    'submit': 'update'
  },
  initialize: function (options) {
    this.listenTo(this.model, 'sync', this.success);
  },
  render: function () {
    this.$el.html(this.model.toJSON());
    this.hook.html(this.el);

    return this;
  },
  update: function (e) {
    this.model.save();
  },
  success: function () {
    this.trigger('demo:next');
  }
});

App.Views.Second = Backbone.View.extend({
  template: App.Templates['demo/second'],
  events: {
    'click a[href=#back]': 'back',
    'click a[href=#reload]': 'reload'
  },
  initialize: function (options) {
    this.hook = options.hook;
  },
  render: function () {
    this.$el.html(this.model.toJSON());
    this.hook.html(this.el);

    return this;
  },
  back: function () {
    this.trigger('demo:back');
  },
  reload: function () {
    this.trigger('demo:reload');
  }
});

// define flow view
App.Views.DemoFlow = Backbone.Container.Flow.extend({
  initialize: function (options) {
    options = options || {};
    this.vent = options.vent;
    this.views = options.views || this.views;

    // define view transitions by subscribing to events
    this.listenTo(this.views[0], 'demo:next', this.demoNext);
    this.listenTo(this.views[1], 'demo:back', this.demoBack);
    this.listenTo(this.views[1], 'demo:reload', this.demoReload);

    // set initial view
    this.next = this.views[0];
  },
  demoNext: function () {
    // set next view and call show (render and rebind events)
    this.next = this.views[1];
    this.show();
  },
  demoBack: function () {
    // set next view and call show (render and rebind events)
    this.next = this.views[0];
    this.show();
  },
  demoReload: function () {
    // notify application to unload and reload the Demo Flow
    this.vent.trigger('demo:show');
  }
});

// create event bus to allow container to notify application of events
var vent = _.extend({}, Backbone.Events);

// instantiate model and child views
var model = new App.Models.SharedModel();
var first = new App.Views.First({model: model, hook: $('#main')});
var second = new App.Views.Second({model: model, hook: $('#main')})

// instantiate flow, inject child views and vent, and render the flow
var flow = new App.Views.DemoFlow({views: [first, second], vent: vent});
flow.render();

```

License
-------
Released under the MIT License.  See the LICENSE file for further details.


text:
# Revision History

## Revision 0.7.5
- Modified code so that when grids are rudeced by the minkowski method
  a smaller absolute tolerance is used.

## Revision 0.7.4 (WSM)
- Reverted lots of changes to the initial 0.7.0 release.
- Disabled delinter for now.
- Moved offset selection back to original location in `find_grids.f90`.
- Reverted how offsets are selected.
- Reverted behavior for cases with fewer number of k-points so that they
  are not handled differently, this was a mistake.

## Revision 0.7.3 (WSM)
- Changed search domains to adapt with grid size.
- Changed offests to just be permutations of 0.5 and 0.

## Revision 0.7.2 (WSM)
- Moved the location of code that selects possible offsets.
- Changed the code so that it searches for offsets based off the grid
  generating vectors and not the parent lattic.
- Moved space group generating to earlier in the code to reduce number
  of calls to the subroutine.

## Revision 0.7.1 (WSM)
- Added a check for new POSCAR formats.
- Fixed un-initialized variables in delinter.
- Fixed delinter POSCAR writing formats.
- Fixed allocation of ratio array for fining grids with the fewest
  k-points.

## Revision 0.7.0 (WSM)
- Added `RMIN` as an input option to determine the number of k-points.
- Added symmetry options to the inputs that restrict the number of
  symmetry operations used.
- Added an option to force the minimum number of k-points be returned.
- Added code so that if fewer than 500 k-points are wanted then the
  code will loop over all the grids possible and select the one with the
  fewest points.

## Revision 0.6.8 (GLWH)
- Updated `README.md`

## Revision 0.6.7 (WSM)
- Modified the mods in `sphnfs` to compare long ints to long ints so
  the unit tests will run.
- Fixed logic bug in the `tric` `sphnfs` that the unit tests found.
- Fixed some unit tests.

## Revision 0.6.6 (WSM)
- Changed the workflow to catch errors thrown by `kgridGen`.
- Increased the number of cubic cases checked so that if errors occure
  with `kgridGen` we have more than 3 cubic cases to use (this will
  not happen very often but it's there just in case).
- Changed all cases in `sp_hnfs.f90` so that if `grid_selection`
  doesn't return a grid due to errors in `kgridGen` then the code
  handles it properly.
- Added a check at the end of `find_grid` so that if no grids are
  found it prints an error and stops instead of segfaulting.
- Fixed the offsets so that they no longer trigger warnings in
  `kgridGen` and fixed the triclinic cells offsets (it was allocating
  8 instead of 2).

## Revision 0.6.5 (WSM)
- Changed the code workflow so that the packing fraction is used to
  rule out some grids.
- Changed the code workflow so that at least 5 grids are compared for
  non-cubic and non-triclinic cells.
- Cleaned up the code so that it compiles cleanly.

## Revision 0.6.4 (WMS)
- Added a function tha checks that the point group matches the niggli
  id and stops the code if it doesn't.

## Revision 0.6.3 (WSM)
- Fixed most of the finite precision problems we've been having with
  the interface with `kgridGen`.

## Revision 0.6.2 (WSM)
- Fixed multiple allocations that were causing out of bounds errors.
- Reduced the search space of offsets by taking into account the order
  of the vectors that the user provided.
- Started adding OpenMP functionality.
- Fixed calculation of reciprocal lattice volume in control file.

## Revision 0.6.1 (WSM)
- Changed the search intervals for each crystal class.

## Revision 0.6.0 (WSM)
- Changed the contral file name to KPGEN.
- Changed control file to use key words instead of line numbers for
  greater flexibility.
- Added the ability in the code to search over multiple k-point
  offsets.
- Made the users specified offset get passed all the way through the
  code to ensure we get the best folding for that offset.
- Added the offsets to search over by grid type.

## Revision 0.5.5 (WSM)
- Changed the code so that comparisons to the old rmin and new are
  more flexible.

## Revision 0.5.4 (WSM)
- Changed the code so that it will consider the two largest rmin
  values found in order to explore a larger regoin of the search
  space, this is neccessary because in many cases we weren't finding
  the "optimal" grid because it had a slightly smaller rmin but much
  better folding.
- Changed the default eps value to 1E-3 instead of 1E-6, this makes
  more sence is practice and should be sufficient for our purposes.
- Increased the eps value passed to the k-point folding code in cases
  where the determinant of the new grid is approximately the size of
  the eps value, or when it is smaller than eps but still larger than
  1E-10.

## Revision 0.5.3 (WSM)
- Implemented a faster selection implementation in which a minimal set
  of grids is folded.

## Revision 0.5.2 (WSM)
- Implemented changes that John suggested to fix/improve the
  algorithms.
- Debugged new triclinic case.
- Fixed bugs in sm_34_35 inroduced by refactor.
- Fixed bugs in tric_31_44 introduced by refactor.
- Fixed bugs in bco_8 introduced by refactor.
- Fixed bugs in bcc_5 introduced by refactor.
- Fixed bugs in stet_21 introduced by refactor.
- Fixed bugs in fco_16 introduced by refactor.
- Fixed basis for sm_34 in python and fortran niggli id routines.
- Added the python script used to make test output for fortran to the
  repo in testing_codes/make_output.py.
- Added plotting notebook and some plots.
- Reformatted niggli.f90 to make it a little easier to read.
- Fixed a bug in fing_kgrids.f90 in which the count variable wasn't
  getting set.

## Revision 0.5.1 (WSM)
- Fixed lots of compiler errors in sp_hnfs.f90 and grid_utils.f90.
- Added grid_utils.f90 to the Makefile.
- Removed `smallest_prime` from sp_hnfs.f90.
- Refactored find_grids.f90 to match new code format.
- Rewrote driver.
- Fixed a bug in the cubic k-point number finding algorithm that was
  causing it to skip values at large N.
- Made cubic algorithms integer only, somehow they got missed before.
- Fixed allocations and other problems.
- Added the reciprocal lattice calculation to the comparison routines.

## Revision 0.5.0 (WSM)
- Changed sp_hnfs.f90 to use integers instead of reals.
- Changed sp_hnfs.f90 to return only one grid per determinant size
  unless the `all` bool is set to true in which case it returns all
  the HNFs and no grids. Basically the first round of grid selection
  is now done as the HNFs are being constructed.

## Revision 0.4.1 (WSM)
- Fixed a bug in the fortran driver where a negative determinant was
  being used to find the number of k-points wanted.
- Update basis 2 and 4 with better algorithm.

## Revision 0.4.0 (WSM)
- Fixed the driver to work with the new code setup.
- Fixed the issues in the makefile.
- Cleaned up code so it compiles without warnings.

## Revision 0.3.15 (WSM)
- Fixed a bug in the python code where the users basis and our basis
  got switched.
- Fixed integer rounding errors in fortran code.
- Swapped order of d and e placement in the HNF of baseco_38_13 to
  match the python code.
- Fixed base centered monoclinic 28 for fortran code in sphnfs.f90. It
  was looping over the values of b but not placing them in the HNF.
- Fixed a bug in find_grids.f90 that was preventing the code from
  finding HNFs for basis 29.
- Finished implementing code for grid selection.
- Changed the niggli code so that the path taken to reduce the cell is
  not printed with extra white space.

## Revision 0.3.14 (WSM)
-Changed the type of the L matrix in transform_supercell in find_kgrid.f90.
-Implemented unit tests of transform_supercell.

## Revision 0.3.13 (WSM)
- Re-wrote the get_kpd_cubic subroutine in find_kgrds.f90 to match the
  python functions.
- Fixed bugs in find_kgrids.f90 that prevented it from compiling.
- Added subroutine to find_kgrids.f90 find the kpd and ratio to use
  for triclinic cases.
- Fixed bug with floating point division in universal.py.

## Revision 0.3.12 (WSM)
- Removed redundandt call to base_mono_27 in universal.py.
- Fixed basis determination for triclinic cases in universal.py.

## Revision 0.3.11 (WSM)
- Fixed a sign error in the lattice definition for face centered
  orthorhombic cell 16.

## Revision 0.3.10 (WSM)
- Changed how find_volumes works in universal.py so that all valume
  factors are greater than or equal to the desired k-point
  density. Also made it so that in the cumbic cases only 3 values are
  returned and for all other cases 11 values are returned.
- Updated our basis for face centered orthorhombic case 16 in
  niggli_lat_id.py to match the new one we found.
- Changed find_supercells in universal.py so that it only returns
  supercells for the first 5 non-trivial determinant sizes tried.

## Revision 0.3.9 (WSM)
- Fixed some bugs in the find_volumes subroutine in universal.py.
- Added unit tests for some of the functions in universal.py.
- Changed universal.py so that it only keeps the symmetry presereving
  HNFs of a given size if there are more than 1 of them.
- Fixed bug in the volume finding algorithm.
- Removed deprecated code from hex.py.
- Started adding tests of the find_suprcells python algorithm.

## Revision 0.3.8 (WSM)
- Removed the transpose statements from our basis assignments in
  id_cell.
- Replaced eps*D with eps for the tolerance for niggli case 40 in
  niggli_id.

## Revision 0.3.8 (WSM)
- Fixed sign error in get_params subroutine.
- Fixed unit tests outputs for get_params subroutine (python hadn't
  saved enough digits of precision).
- Fixed the assignment of eps in reduce_cell to be related to abs(vol)
  instead of (vol).
- Fixed logical error when checking to see if the reduced cell
  satisfies the niggli conditions in reduce_cell.
- Changed name of niggli_check to condition_check.

## Revision 0.3.7 (WSM)
- Changed M to temp_M in niggli.f90 to fix compiler errors.
- Removed the manually entered parameters in favor of using num_types.
- Fixed various array declaration typos.
- Fixed several syntax errors.
- Changed a, b, and c in id_cell to temp_a, temp_b, temp_c to fix
  compiler errors.
- Fixed several type declarations.
- Removed ```if ((.not. equal(size(IN,1),3,0))
  .or. (.not. equal(size(IN,2),3,0))) stop "Input matrix must be
  3x3."``` from niggli.f90 since it is redudnant with the array
  declaration.
- Changed others

## Revision 0.3.6 (WSW)
- Added the initial unit testse for the fortran niggli reduction.

## Revision 0.3.5 (WSM)
- Fixed bug in bct_15 and added 2 more tests.
- Fixed some minor bugs in niggli.f90.
- Added niggli.xml.

## Revision 0.3.4 (WSM)
- Fixed and debuged basis bco_42, baseco_23, bct_18, basecm_41,
  basecm_20_25, rhom_24, bco_8, st_21, fco_16, sm_34, basecm_29_30,
  basecm_10_17, and basecm_27.
- Fixed typo in documentation for rhom_24 in rhom.py.
- Added test output and input for smallest_prime function.

## Revision 0.3.3 (WSM)
- Fixed and debugged basis rhom_4_2, baseco_40, basecm_43,
  basecm_37_39, bct_6, hex_22, basecm_28, baseco_36, and bct_7.
- Added testing script for easier fortran to python comparison.

## Revision 0.3.2 (WSM)
- Added unit tests files on each of the niggli cell spHNF supercell
  finding subroutines.
- Fixed some initial bugs in spHNFs.f90 so that tests would compile
  and run.

## Revision 0.3.1 (WSM)
- Fixed a bug in the get_kpd routine, with the change to the new
  niggli approach the lattice id for the fcc, bcc, and sc cases
  changed, that change was not reflected in the get_kpd routine.

## Revision 0.3.0 (WSM)
- Added the algorithms for each niggli basis to sp_hnfs.f90.
- Added niggli.f90 to the code (reduces a cell to its niggli form and
  identifies which niggli cell it is along with 'our' basis choince).
- Modified the find_kgrids.f90 routine to use the new niggli basis
  approach.

## Revision 0.2.13 (WSM)
- Added the sm basis to niggli_id.
- Improved the reliability and accuracy of the niggli reduction
  code. It still needs a bit of work on finding an adaptive floating
  point tolerance.

## Revision 0.2.12 (PH)
- Added the simple monoclinic algorithms.

## Revision 0.2.11 (WSM)
- Added correct basis to the output of the niggli lattice
  identification subroutine (niggli_id).
- Fixed typos.
- Added new subroutine to universal.py to find the transformed
  supercells.
- Rewrote and added to basis_check.py to include all the basis and the
  new transformation.
- Fixed a bug in niggli_lat_id.py where the cell was considered
  positive when the angles were effectively but not actually zero. The
  problem was fixed by replace angle >0 by angle-eps>0.

## Revision 0.2.10 (WSM)
- Implemented unit tests for all niggli cases so far designed.
- Renamed trig.py to rhom.py.
- Removed body_tet_srHNFs_2 from body_tet.py as it is no longer useful.
- Removed base_ortho_23_2 from base_ortho.py as it is no longer useful.
- Removed body_ortho_8_2, body_ortho_42_2, and body_ortho_19_2 from
  body_ortho.py as they are no longer useful.
- Removed face_ortho_16_2 from face_ortho.py as it is no longer useful.
- Renamed sc_srHNFs to sc_3, bcc_srHNFs to bcc_5, fcc_srHNFs to fcc_1,
  trig_srHNFs to rhom_9, stet_srHNFs to stet_11, hex_srHNFs to hex_12,
  body_tet_srHNFs to body_tet_15, base_ortho_srHNFs to
  base_ortho_38_13, body_ortho_srHNFs to body_ortho_19,
  face_ortho_srHNFs to face_ortho_26, and base_mono_srHNFs to
  base_mono_14 to match niggli cell numbers and new naming convention.
- Moved test_basis.py to basis_check.py.
- Added .travis.yml to repo.
- Removed lat_type.py from repo since it's been replaced by
  niggli_lat_id.py.
- Implemented unit tests on niggli_lat_id.py.
- Implemented missing niggli basis 36.
- Started implementing new symmetry preserving grid algorithm.

## Revision 0.2.9 (WSM)
- Implemented all the base centered monoclinic cells.

## Revision 0.2.8 (WSM)
- Implemented all basis options for base centered orthorhombic cells.
- Improved/expanded the basis choices for face centered orthorohmbic cells.
- Added option to print the 'path' of the Niggli Reduction.

## Revision 0.2.7 (WSM)
- Fixed an incerroctly labeled niggli cell hexagnoal cell to the correct family.
- Added option to pass G vector directly into niggli_id.
- Added additional basis options to the body centered orthorohmbic cases.
- Added first additional basis for the face centered orthorhombic cases.
- Identified a niggli cell for each of the remaining base centered
  orthorhombic, simple monoclinic, and base centered monoclinic cells
  in the mathematica notebooks.

## Revision 0.2.6 (WSM)
- Fixed an error in the niggli lat id subroutine in which the wrong
  logic was instituted on some angle comparisons.
- Increased the number of iterations allowed by the niggli reduction
  to allow for larger cells.
- Made the default floating point tolerance dependent on cell volume
  in the niggli reduction process.
- Implemented face centered orthorhombic cell number 26.

## Revision 0.2.5 (WSM)
- Fixed cell number 19 though it's still really slow.
- Implemented cell number 42, the last of the body centered
  orthorhombic cells.

## Revision 0.2.4 (WSM)
- Added body centered orthorhrombic cells for niggli cell 8 and 19. 19
  still has bugs in it though and both are really slow.

## Revision 0.2.3 (WSM)
-Added 4 body centered tetragonal cells to the repository.

## Revision 0.2.2 (WSM)
- Fixed bugs in rhombohedral 24 and rhombohedral 9, the former works
  correctly now and the latter had an incoorect basis, it now runs on
  about the same time scale as rhombehdral 2 and 4.
- Added contitions to rhombohedral_2_4 to make it faster.
- Added function to find the symmetry preserving HNFs for both of the
  hexagonal niggli cells.
- Added the second simple tetragonal niggli basis.

## Revision 0.2.1 (WSM)
- Added tolerances to all comparisons in the niggli identification
  script.
- Added tolerances to all comparsions made in the niggli condition
  checking code.
- Added functions to find the symmetry preserving HNFs for all 4
  niggli rhombohedral cells (rhombohedral 24 is wrong though and
  rhombohedral 9 is painfully slow, rhombohedral 2_4 is about 20 times
  slower than the standard trigonal approach).

## Revision 0.2.0 (WSM)
- Added python niggli reduction code and identification script (still
  needs unit testing).

## Revision 0.1.6 (WSM)
-Added second algorithm for generating the body centered tetragonal
 HNFs.
-Added new output to lat_type that may help the basis
 transformation. It now also outputs the order of the basis vectors
 according to size.
-Fixed bug reported in [issue #4](https://github.com/msg-byu/opf_kgrids/issues/4).
-Added a new text file where I'm writing the comparison between methods section.
-Fixed and updated a number of unit tests.

## Revision 0.1.5 (JJ)
- Renamed unit test test_jeremy.py test_sym_grids.py.
- Fixed remaining import calls.

## Revision 0.1.4 (JJ)
- Fixed import calls in a few modules but some are still missing.
- Renamed jeremy.py sym_grids.py.
- Added latex code for the paper we will submit in the directory named
  paper. Completed rough draft of introduction.
- Added notebooks which will test our symmetry preserving grids on
  empirical pseudopotentials in python (must have BZI to run tests).
- Started tests on empirical pseudopotentials in a notebook called
  Search for Figure of Merit.

## Revision 0.1.3
- Fixed a bug in the python code concerning commencerate lattices.

## Revision 0.1.2
- Updated the driver to print the k-points in reciprocal lattice
  coordinates instead of cartesian. Still needs to be tested to see if
  VASP reads it in properly.

## Revision 0.1.1
- Fixed the first few bugs in the make KPOINTS file routine.

## Revision 0.1.0
- Made a driver that makes a kpoints file from the POSCAR and a file
  containing the desired k-point density and offset.
- Implemented the rest of the code needed to find the optimal k_grid.

## Revision 0.0.14
- Added remaining crystal classes to sp_hnf.f90.
- Added unit tests for all crystal classes.

## Revision 0.0.13
- Added hex, trigonal, simple tetragonal and body centered tetragonal
  cases to sp_hnf.f90.

## 0.0.12
- Began implementing the fortran version of the code (created sc, bcc,
  and fcc subroutines).

## 0.0.11
- Implemented faster algorithms for bcc, fcc, sc, and body centered tetragonal cells.
- Fixed integer division in universal.py for python 3.
- Fixed a bug in lat_type.py that was caused by the appearance of
  negative angles from the dot products.
- Fixed jeremey.py. The loop over the grids was indented to far.

## 0.0.10
- Fixed bugs in jeremy.py and in universal.py.
- Added some new unit tests to check for the bugs.
- Added additional supporting info.

## 0.0.9
- Created driver for grid generation src/opf_python/gengrid.py. The
  driver is still incomplete.
- Created new subroutines in universal.py. The first is to find the
  symmetry preserving grids given a lattice and target density. The
  second returns the volume factors that will be used for generating
  the srHNFs. Both subroutines still need work.
- Added number and time scaling plots for face centered cubic and face
  centered orthorhombic.
- Added a module for Jeremy's test to use, jeremy.py.

## 0.0.8
- Fixed some bugs in lat_type.py.
- Impltemented unit tests for lat_type.py

## 0.0.7
- Added python modules for each of the remaining lattice types to the
src/opf_python directory, as well as their unit tests (all modules
agree to with the brute force method for volumes factors of 1 to 500
in the tests except monoclinic lattices which have only been tested on
volumes of 1 to 150 for time reasons).
-Fixed error in notes/body_centered_ortho.nb.
-Added lat_type.py to repo. It's a module that identifies the lattice type.

## 0.0.6
- Added src/python/trig.py to the repo. It finds the srHNFs for the trigonal case.
- Fixed a logic error in the simple, body centered, and face centered
  cubic cases and added the math for the mathematica notebook in the notes for the
  each case.
- Added src/python/stet.py for the simple tetrogonal case as well as a
  mathematica notebook in the notes folder.
- Added a mathematica notebooks for all remaining lattices.
- Added the paper `Space Group Subgroups generated by Sublattice
  Relations` to the notes folder.
- Fixed an infinite loop in trig.py.
- Implemented unit tests on all existing python modules.

## 0.0.5
- Added the 'canonical' parent lattice to the documentation for each crystal class.
- Fixed bugs in the conditions for bcc and fcc. They now find HNFs at
  the correct volumes in the range (1-100).
- Added jupyter-notebook that shows how to identify the lattice type for the code.
- Added plots of the HNF and srHNF scaling the brute force way in
  addition to the notebook that generated the plots.

## 0.0.4
-Renamed the fcc and bcc subroutines so that they are called fcc and
 bcc. Also changed the comments to reflect that change.

## 0.0.3
- Added python code that handles the sc, bcc, and fcc lattices using
  Rod's divisor method.
- Also added an jupyter notebook that shows the timing for the
  generation of the grids for a single determinant at a time. It
  scales really nicely.

## 0.0.2
- Added the testing_codes dir. This directory contains the brute force
  fortran code that is being used to test how large of an volume
  factor we can generate the srHNFs in a given time is and to
  determine which volumes matter mast.
- Added the src directory which will contain code designed for future
  distribution.
- Added the nots directory in which we can store notes from
  collaborations. For now I'm including Rod's divisors writeup and the
  history of or dialog with Dr. Campbell.

## 0.0.1
- Initial commit

repository: msg-byu/autoGR

gha_language: Mathematica

repo_name: msg-byu/autoGR