text:
# Background Images

Before engaging in this lesson, it would be beneficial to be familiar with knowing how to [Shadow a
Simple Component](./ShadowA_SimpleComponent) and [Using Tailwind for Background
Images](../../Guides/TailwindGuide#using-tailwind-for-background-images).

## Overview

In this task we'll be customizing the default Vital footer to include a new brand-specific SVG logo,
as well as an SVG wave image on both desktop and mobile.

?> **Note:** For the code files used in this lesson, please see the
`packages/vital-examples/src/background-images` directory in your local repository or on
[GitHub](https://github.com/johnsonandjohnson/Bodiless-JS/tree/main/packages/vital-examples/src/background-images
':target=_blank').

## Assignment

To begin, we will create a React component from our SVG to be used to replace the brand logo on the
default Vital footer. Using your SVG-to-React conversion app of choice (e.g., [SVGR
Playground](https://react-svgr.com/playground/ ':target=_blank')), include your SVG in the body of a
functional component as illustrated below:

```tsx
import { stylable } from '@bodiless/fclasses';
import * as React from 'react';

const Logo = (props: React.SVGProps<SVGSVGElement>) => (
  // Insert your SVG element here
);

const LogoIcon = stylable(Logo);

export default LogoIcon;
```

For an example of the above, see:
[`logo.tsx`](https://github.com/johnsonandjohnson/Bodiless-JS/blob/main/packages/vital-examples/src/background-images/assets/images/logo.tsx
':target=_blank').

Next, you'll need to create the folder that will house your new footer component, `ExampleFooter`,
that will be used to override the default Vital footer.

You can structure this component's folder in a similar fashion to that of the Vital component found
[here](https://github.com/johnsonandjohnson/Bodiless-JS/tree/main/packages/vital-layout/src/components/Footer
':target=_blank'), or make use of the [component
scaffolder](../../Guides/ComponentTemplate#component-scaffolding) to create this component structure
automatically.

  Note: For more information on this component file structure, please see:

  - [Component Template : File Structure](../../Guides/ComponentTemplate#file-structure)
  - [Shadowing Tokens](../../Guides/ShadowingTokens)

### Adding Our Custom Brand Logo

In our 'Footer' token collection — named `exampleFooter.ts` — you'll replace the `Rewards` slot of
the footer component with your new custom brand logo, using the `startWith` HOC.

?> **Note:** You may have noticed that a similar HOC, `replaceWith`, can be used to achieve the same
result, but `startWith` is the preferred method in this instance, as it replaces a component while
still retaining any tokens previously applied to it. `replaceWith` is most often used to remove a
component or slot in its entirety (`replaceWith(() => null)`).

### Creating a New CSS Rule in Tailwind for Our Wave SVG Image Mask

Using the `addComponents` function provided by Tailwind, we can create a new class containing our
image mask path, size, and position, and apply it to our new footer in the next section.

?> **Note:** In most instances, the utility classes provided out-of-the-box by Tailwind will be
enough to satisfy all of your styling needs. However, in cases such as this one, where our footer
wave must be implemented through the use of an image mask (a CSS property for which no default
Tailwind utility class exists), we can construct a CSS rule directly in our Tailwind configuration
file.

```js
const twConfig = {
  plugins: [
    plugin(({ addComponents }) => {
      addComponents({
        '.footer-wave': {
          maskImage: "url('@bodiless/vital-examples/src/background-images/assets/images/desktopwave.svg')",
          maskPosition: 'bottom center',
          maskSize: '100%',
        },
        // ...
      });
    }),
  ],
};
```

### Adding Our 'wave' SVG Asset and Mobile Wave to the Footer Wrapper

01. Get your SVG asset set up via [Using Tailwind for Background
    Images](../../Guides/TailwindGuide#using-tailwind-for-background-images).
01. In our `exampleFooter.ts` file, we will construct a `WithTopWave` token, in which we will apply
    to the [appropriate domains](../../Guides/Tokens/TokenDomains) the Tailwind classes needed to
    render an SVG wave to the top of the footer.
01. On the `Wrapper` slot, we will apply our `.footer-wave` CSS rule, and, on the `Column2Wrapper`
    slot, we will apply the Tailwind classes necessary to render a similar SVG wave to the top of
    the footer on mobile and tablet devices.
01. We will then construct a `Default` token for our custom footer and apply our newly-created
    `WithTopWave` token to this token's `Compose` domain.

**`exampleFooter.ts`:**

[exampleFooter.ts](https://raw.githubusercontent.com/johnsonandjohnson/Bodiless-JS/main/packages/vital-examples/src/background-images/components/Footer/tokens/exampleFooter.ts
':include :type=code')

?> **Note:** Our `WithTopWave` token could easily be woven into the body of our `Default` footer
token, but imagine a future scenario where our design changes, and we no longer want that top wave
to be present. By encapsulating this styling in its own token, and applying it via the `Compose`
domain, we can easily add (and just as easily remove) a bit of styling or functionality to an
existing token, without embedding it so deeply within that making changes to it later becomes
unnecessarily cumbersome.

## Resources

- [Adding components | Tailwind CSS](https://tailwindcss.com/docs/plugins#adding-components
  ':target=_blank')
- [SVGR Playground](https://react-svgr.com/playground/ ':target=_blank') - For converting SVGs to
  React components.
- [Using Tailwind for Background Images](../../Guides/TailwindGuide#using-tailwind-for-background-images)

repository: johnsonandjohnson/Bodiless-JS

repo_name: johnsonandjohnson/Bodiless-JS


text:
# fastapi-planets
Planets implemented with FastAPI Framework

## Usage

`docker compose up -d`

`http :8000/planets/3`

`http :8000/planets`

But the most amazing part about using FastAPI is its integration with API Documentation and a built-in dev portal! Try it: [http://localhost:8000/docs](http://localhost:8000/docs)

## Miscellaneous
Did you know you can add a `build: .` stanza and use `docker compose up -d --build`? Well, you can! Fiddle w/ it here.

repository: aaronhmiller/fastapi-planets

branch_name: refs/heads/main

extension: md

license_type: permissive

repo_name: aaronhmiller/fastapi-planets


text:
I've got a bike, you can ride it if you like
    It's got a basket, a bell that rings
    And things to make it look good
    I'd give it to you if I could, but I borrowed it
*-- Pink Floyd*

# Bike reinvents two wheels

* First of all, it is [RDNZL](https://common-lisp.net/~loliveira/ediware/rdnzl/_darcs/current/doc/) reborn

* This time, on .Net Core, without a line of C++ code, and fully cross-platform

Now you have the batteries included! Which are of the size of Battersea Power Station.

[![CircleCI](https://circleci.com/gh/Lovesan/bike/tree/master.svg?style=svg)](https://circleci.com/gh/Lovesan/bike/tree/master)

## TL;DR

This library implements cross-platform Common Lisp interface to .Net Core platform, using lisp compatibility layers.

````lisp
(use-package :bike)

(named-readtables:in-readtable bike-syntax)

(import-assembly 'System.Runtime.InteropServices.RuntimeInformation)

(use-namespace 'System)
(use-namespace 'System.Runtime.InteropServices)

(defun hello ()
  (let* ((os [:RuntimeInformation %OSDescription])
         (delegate (new '(Action :string)
                        (lambda (who)
                          (format t "Hello ~a!~%You are running .Net Core~% inside ~a ~a~% on ~a"
                                  who
                                  (lisp-implementation-type)
                                  (lisp-implementation-version)
                                  os))))
         (user [:Environment %UserName]))
    [delegate Invoke user]))

(hello)

;; ==>

;; Hello lovesan!
;; You are running .Net Core
;;  inside SBCL 1.5.3
;;  on Linux 4.15.0-1041-aws #43-Ubuntu SMP Thu Jun 6 13:39:11 UTC 2019
````

## Installation

The most basic way to install the library at this moment would be to use [quicklisp](https://www.quicklisp.org/):

````lisp
(ql:quickload :bike)
````

Alternatively, you can drop the contents of the repository into ````~/quicklisp/local-projects/bike```` directory.

The library, once loaded, searches for .Net Core runtime and for ````BikeInterop.dll```` library in several places, like in the executable directory.

In case of the library is unable to locate .Net Core in one of the predefined places, it then asks ````dotnet```` command to list available runtimes and picks up latest one.

The interop .Net library(````BikeInterop.dll````), should be unavailable, is being built, again, by utilizing the ````dotnet```` command.

To build the library, you would, of course, need .Net Core SDK installed. But running the code in production should only require .Net Core runtime installed and the built interop binary nearby.

The library handles image restore, by utilizing ````uiop````. It searches for CoreCLR and interop layer again, then reloads cached types, and properly handles all the state.

Given this, you can deploy dumped images to other machines.

````lisp
(defun hello () (bike:invoke 'System.Console 'WriteLine "Hello, World!"))
(setf uiop:*image-entry-point* #'hello)
(uiop:dump-image "hello.exe" :executable t)

;; ./hello.exe
;; ==> Hello, World!
````

## Known Issues

### Task.Result and other things which block .Net code

Do not use this if you pass Lisp callbacks to .Net code - this may cause deadlocks.

### SBCL

SBCL is the main development and testing platform.

#### Windows

The library seems to work well on SBCL/Windows, the runtimes and garbage collectors seem to coexist peacefully. SBCL callbacks can even be utilized by .Net [System.Threading.Tasks](https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks?view=netcore-2.2)

There were some issues with exceptions in the past, but those were resolved.

The reason for those issues was described [in my (D.I.) SBCL patch that had been applied in 2019.](https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAK3-8Ji8XrjZd8ttKa0XOFPTewbg%2Bf2t5U3ZCwWGdcv6S6W_mQ%40mail.gmail.com/#msg36687909)

Basically, on x86-64 Windows, SBCL uses VEH, and its handler had been catching all the exceptions before .Net Core handlers even had a chance to look at their ones. This, next, sometimes led to a situation where SBCL disallowed .Net runtime to enter into the correct state, which led to the corruption of both runtimes and process crashes.

Seems like it has been resolved. [The latest patch from Luís Oliveira greatly enhanced SBCL exception handling.](https://github.com/sbcl/sbcl/commit/50085a82c7bd6dfb91599f236e3d002f49ebec72)

#### Linux

Early SBCL versions(namely [pre <IP_ADDRESS>-b656602a3](https://sourceforge.net/p/sbcl/sbcl/ci/b656602a309fc9647dd01255154c1068305f12f7/tree/)) were frequently crashing into LDB with a cryptic message of ```blockables unblocked``` if .Net Core runtime was present in a lisp process.

The reason for this is that SBCL and .Net Core stomp on each other signals, in a kind of a wrong way.

[Seems that it is not only a case of .Net Core.](https://irclog.tymoon.eu/freenode/lisp?around=1500933122)

Thankfully, Stas Boukarev(stassats) implemented a workaround in the latest SBCL.

We still have to understand what may that workaround do to .Net Core runtime, but at least, it solves a problem of unavoidable and frequent crashes.

On overall, this need to be debugged out further. Maybe we would ask for help someone from .Net Core team.

**UPD** **2019-07-13:**  CoreFX(the .Net Core stdlib) also establishes signals for handling System.Diagnostics.Process classes and Console Ctrl handlers. We let it handle processes, because it can handle that perfectly(that means, including processes started by lisp, e.g. using ```uiop:run-program```), but revert the SIGINT handler for lisp one.

#### MacOS X

Testers are welcome.

## TODO

* Documentation and tests are always good

* Add more examples which utilize third-party assemblies, NuGet, or something like that

* ```dotnet``` command interface

* NuGet interface

* Fancy async/await syntax

* MacOS X testing

* Implement some cache for parsed type definitions

* Expose DEFKNOW-alike API to the user

* Investigate CoreCLR interop on Linux. Fix SBCL crashes on Windows with NullReferenceException.

* Optimize invocation cache (maybe write some hash functions instead of using ```sxhash``` etc)

* Write compiler macros for API and type resolution

* etc.

license: MIT

repository: Lovesan/bike

branch_name: refs/heads/master

gha_language: Common Lisp

gha_license_id: MIT

repo_name: Lovesan/bike


text:
# Replace Resources Plugin

[![npm][npm-image]][npm-url]
[![MIT License][mit-license-image]][mit-license-url]

[npm-url]: https://www.npmjs.com/package/replace-resources-plugin
[npm-image]: https://img.shields.io/npm/v/replace-resources-plugin.svg?label=npm%20version
[mit-license-url]: LICENSE
[mit-license-image]: https://camo.githubusercontent.com/d59450139b6d354f15a2252a47b457bb2cc43828/68747470733a2f2f696d672e736869656c64732e696f2f6e706d2f6c2f7365727665726c6573732e737667

A webpack plugin to copy data from the source file to a target one

## Installation

`npm install --save-dev replace-resources-plugin`

## Usage

Add the plugin to your webpack config. For example:

**webpack.config.js**

```js
const ReplaceResourcesPlugin = require('replace-resource-plugin');

const webpackConfig = {
    plugins: [
        new ReplaceResourcesPlugin(/\.src\.js/, /\.dist\.js/),
    ],
};

module.exports = webpackConfig;
```
## Parameters

The plugin requires two parameters:

```js
new ReplaceResourcesPlugin(sourceRegExp, distRegExp [, options]),
```

Which must be regular expressions and mean to be used to detect a source file of data and a destination file where the data must be copied to.
The destination regular expression is applied firstly if it matches the file name. If this condition is true then the source regular expression is used to find whether there is the file matching it in the current working directory. If the source file is found the data of it is being copied to a destination one.

* **sourceRegExp**: `RegExp`
* **distRegExp**: `RegExp`
* **options**: `Object` - optional
    * **replaceDistFileIfHMR**: `Boolean`, default: `false` - defines if the plugin must process changes that are happening due to [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/) on a destination file. By default changes are happening in the runtime and detected by HMR will be ignored in order to avoid infinite loop of replacmemts between source and destination files.

repository: git-decadent/replace-resources-plugin

gha_language: JavaScript

repo_name: git-decadent/replace-resources-plugin


text:
streamBase64
============

A stream-based base64 encoder/decoder for Scala.  It provides these operations:
```
encode(Stream[Byte]): Stream[Char]
decode(Stream[Char]): Stream[Byte]
```
By using streams, the data to be encoded/decoded does not have to fit into memory.  These operations could also be inserted into a stream processing pipeline.


text:
# foreign_exchange
An utility to convert between available currencies for a given date. This repository provides a **Ruby library** for obtaining Foreign Exchange (FX) rates and a Ruby on Rails (RoR) **web application**.

## Exchange Rate Library

The code is allocated at web/lib/exchange_rate and it is packaged as a Ruby gem. If you want to test it, please run:

```
  cd web/lib/exchange_rate
  rake test
```

The different end-points to interact with the library are:

Method | Description
------------ | -------------
ExchangeRate.init | Fetches an XML file from a remote source specified at ExchangeRate.configuration.url_historical; parses it according to an XSD defined at [http://www.ecb.int/vocabulary/2002-08-01/eurofxref](http://www.ecb.int/vocabulary/2002-08-01/eurofxref); and persists the data pulled into a sqlite database allocated at ExchangeRate.configuration.dbname. Note, if the database is already populated, the above steps are ignored.
ExchangeRate.update | Feeds the database with new data from a remote source specified at ExchangeRate.configuration.url_daily. This method unlike ExchangeRate.init populates the database with new rates unless data for a given data/currency already exist. It becomes useful to be called within a scheduler cron on a daily basis.
ExchangeRate.reset | Destroys the database configured at ExchangeRate.configuration.dbname.
ExchangeRate.at({date, amount, from, to}) | Returns an exchange rate from currency 'from' to currency 'to' for a given date. If keyword date is missing, it defaults to Date.today. Similarly, if amount keyword is not given, it defaults to 1. The keywords from and to are expected to be strings (e.g. USD, GBP, PLN, etc).
### Configuration of the library

Should you want to change the default configuration options, below are the available variables that may be modified:

```
ExchangeRate.configure do |c|
  c.url_historical = 'foo'  # An URL to retrieve an historical (e.g. 90 days data) XML file for currencies/rates
  c.url_daily = 'bar' # An URL to retrieve a daily XML file for currencies/rates
  c.temp_file = '/tmp/foo.xml'  # A path for where the XML file will be cached for parsing/persisting
  c.dbname = 'db/bar.sqlite3' # A relative path for where the database will be allocated
end
```

## Web application

A RoR application is used to interact with the ExchangeRate library. Currently, only one controller (e.g. exchange_rates_controller.rb) is provided with the following actions:

Method | Description
------------ | -------------
exchange_rates#index | Asks the ExchangeRate library for the available Currencies and renders an HTML form located at web/app/views/exchange_rates/index.html.erb) together with a JS file. The JS file (app/assets/javascripts/exchangeRatesIndex.js) performs client-side validations and handles network responses to exchange_rates#at.
exchange_rates#at | Interacts with ExchangeRate.at through the parameters provided by the web client and returns a JSON string with a result key for a valid conversion or a detail message if any error is encountered (ArgumentError, RuntimeError, etc).

## Cron

There is set up a cronjob at the OS level that runs **ExchangeRate.update** method every day at 16:00 (UTC) and persists new data in the database for the library, if not already present there. See exchange-rate-cron and exchange-rate-cron.sh for specification details.

## How to install it

This utility runs on an isolated environment using Docker. If you have Docker installed locally, please type:
```
  docker build -t ubuntu-sqlite3-rails .
```
to build an Ubuntu OS image together with all the dependencies needed to run this code.
## How to run it

In order to run the app, please make sure that the image has been built successfully and afterwards you should be able to type:
```
  docker run --rm -it -v "$PWD/web":/usr/src/app -p 3000:3000 ubuntu-sqlite3-rails
```
which runs a container in an interactive mode that is auto-destroyed whenever is terminated. Note that a volume is mounted within the container to easy changing any code within web folder without needing to re-build the image. The web interface should be accessible through [http://localhost:3000/exchange_rates](http://localhost:3000/exchange_rates).


text:
Utils
=====

This directory contains standard data structures, common helper routines, and so on..

```
utils/
|-- README.md
|-- chained_list.c: A version of a List which grows slowly
|-- chained_list.h
|-- chained_pool.c: A version of a Pool which grows slowly
|-- chained_pool.h
|-- cli.c: Command Line Interface helper
|-- cli.h
|-- common.h: Some common definitions (false = 0, true = 1)
|-- hash.c: Hashing routines (md5, etc.)
|-- hash.h
|-- hashmap.c: An auto-hashing interface to a Map
|-- hashmap.h
|-- list.c: A List is a variable-length vector (i.e. an array)
|-- list.h
|-- map.c: A Map is a key->value mapping, where the key is a 64bit integer, or pointer
|-- map.h
|-- pool.c: A Pool is a sparse fixed-length vector
|-- pool.h
|-- test.c: The test suite entry point
|-- test.h: A micro-sized testing framework
`-- tests
    |-- test_chained_list.c
    |-- test_chained_pool.c
    |-- test_cli.c
    |-- test_hash.c
    |-- test_hashmap.c
    |-- test_list.c
    |-- test_map.c
    |-- test_pool.c
    `-- test_sanity.c

1 directory, 29 files
```

repository: synthetic-sky/Synth

repo_name: synthetic-sky/Synth


text:
# Assignment A

ResNet 18 trained on the TinyImageNet dataset: target validation accuracy - 50%

Augmentations Used:
1. Pad to `(72,72)`, random crop to `(64,64)`
2. Horizontal Flip - probability - `0.5`
3. CutOut - size `(32,32)`, probability - `0.5`

Training Technique:
1. SGD Optimizer, trained using One Cycle LR
2. Max LR: 1.0
3. Trained for 10 epochs

Achieves `53.80% validation accuracy`, on the 10th Epoch.

# Assignment B

COCO Dataset:
`id`: class id. Total unique classes in the dataset - 80
`width`, `height`: width, height of the image
`bbox`: format - `[x, y, width, height]`, `x`,`y` being the top-left corner of the bounding box

Normalized the bounding boxes based on image's `width`, `height` to be in range of `0,1`
CSV sheet with normalized data: `sample_coco.csv`

KMeans on bounding box's `width`, `height` with cluster sizes: 3, 4, 5, 6

Anchor Boxes:

Anchors - 3 Clusters:
```
[[0.28974134 0.28711913]
 [0.69289688 0.20134954]
 [0.20031795 0.69201832]]
```

Anchors - 4 Clusters:
```
[[0.49395323 0.23465354]
 [0.20139058 0.74280724]
 [0.22350963 0.3259426 ]
 [0.99057558 0.15940826]]
```

Anchors - 5 Clusters:
```
[[0.22548399 0.22692335]
 [0.15402617 0.99619036]
 [0.51352989 0.23484426]
 [1.00474685 0.15753439]
 [0.24406117 0.51136221]]
```

Anchors - 6 Clusters:
```
[[0.5546443  0.17502765]
 [0.18121752 0.55018471]
 [0.22449003 0.22389558]
 [1.0917331  0.15414845]
 [0.15521382 1.06159694]
 [0.41654505 0.40994462]]
 ```


text:
# Windows Cookbook

[![Build status](https://ci.appveyor.com/api/projects/status/9x4uepmm1g4rktie/branch/master?svg=true)](https://ci.appveyor.com/project/ChefWindowsCookbooks/windows/branch/master) [![Cookbook Version](https://img.shields.io/cookbook/v/windows.svg)](https://supermarket.chef.io/cookbooks/windows)

Provides a set of Windows-specific resources to aid in the creation of cookbooks/recipes targeting the Windows platform.

## Requirements

### Platforms

- Windows 7
- Windows Server 2008 R2
- Windows 8, 8.1
- Windows Server 2012 (R1, R2)
- Windows Server 2016

### Chef

- Chef 14.7+

## Resources

### windows_certificate_binding

Binds a certificate to an HTTP port to enable TLS communication.

#### Actions

- `:create` - creates or updates a binding.
- `:delete` - deletes a binding.

#### Properties

- `cert_name` - name attribute. The thumbprint(hash) or subject that identifies the certificate to be bound.
- `name_kind` - indicates the type of cert_name. One of :subject (default) or :hash.
- `address` - the address to bind against. Default is <IP_ADDRESS> (all IP addresses). One of:
  - IP v4 address `<IP_ADDRESS>`
  - IP v6 address `[::1]`
  - Host name `www.foo.com`
- `port` - the port to bind against. Default is 443.
- `app_id` - the GUID that defines the application that owns the binding. Default is the values used by IIS.
- `store_name` - the store to locate the certificate in. One of:
  - MY (Personal)
  - CA (Intermediate Certification Authorities)
  - ROOT (Trusted Root Certification Authorities)
  - TRUSTEDPUBLISHER (Trusted Publishers)
  - CLIENTAUTHISSUER (Client Authentication Issuers)
  - REMOTE DESKTOP (Remote Desktop)
  - TRUSTEDDEVICES (Trusted Devices)
  - WEBHOSTING (Web Hosting)
  - AUTHROOT (Third-Party Root Certification Authorities)
  - TRUSTEDPEOPLE (Trusted People)
  - SMARTCARDROOT (Smart Card Trusted Roots)
  - TRUST (Enterprise Trust)

#### Examples

```ruby
# Bind the first certificate matching the subject to the default TLS port
windows_certificate_binding "me.acme.com" do
end
```

```ruby
# Bind a cert from the CA store with the given hash to port 4334
windows_certificate_binding "me.acme.com" do
    cert_name    "d234567890a23f567c901e345bc8901d34567890"
    name_kind    :hash
    store_name    "CA"
    port        4334
end
```

### windows_dns

`Note`: This resource is now included in Chef 15 and later. If you are using newer versions of [windows](https://devblogs.microsoft.com/powershell/configuration-in-a-devops-world-windows-powershell-desired-state-configuration/) then should use the core [resource](https://github.com/chef/chef/blob/master/RELEASE_NOTES.md#windows_dns_record-resource) instead of windows_dns.

Configures A and CNAME records in Windows DNS. This requires the DNSCMD to be installed, which is done by adding the DNS role to the server or installing the Remote Server Admin Tools.

#### Actions

- :create: creates/updates the DNS entry
- :delete: deletes the DNS entry

#### Properties

- host_name: name attribute. FQDN of the entry to act on.
- dns_server: the DNS server to update. Default is local machine (.)
- record_type: the type of record to create. One of A (default) or CNAME
- target: for A records an array of IP addresses to associate with the host; for CNAME records the FQDN of the host to alias
- ttl: if > 0 then set the time to live of the record

#### Examples

```ruby
# Create A record linked to 2 addresses with a 10 minute ttl
windows_dns "m1.chef.test" do
    target         ['<IP_ADDRESS>', '<IP_ADDRESS>']
    ttl            600
end
```

```ruby
# Delete records. target is mandatory although not used
windows_dns "m1.chef.test" do
    action    :delete
    target    []
end
```

```ruby
# Set an alias against the node in a role
nodes = search( :node, "role:my_service" )
windows_dns "myservice.chef.test" do
    record_type    'CNAME'
    target        nodes[0]['fqdn']
end
```

### windows_http_acl

Sets the Access Control List for an http URL to grant non-admin accounts permission to open HTTP endpoints.

#### Actions

- `:create` - creates or updates the ACL for a URL.
- `:delete` - deletes the ACL from a URL.

#### Properties

- `url` - the name of the url to be created/deleted.
- `sddl` - the DACL string configuring all permissions to URL. Mandatory for create if user is not provided. Can't be use with `user`.
- `user` - the name (domain\user) of the user or group to be granted permission to the URL. Mandatory for create if sddl is not provided. Can't be use with `sddl`. Only one user or group can be granted permission so this replaces any previously defined entry. If you receive a parameter error your user may not exist.

#### Examples

```ruby
windows_http_acl 'http://+:50051/' do
    user 'pc\\fred'
end
```

```ruby
# Grant access to users "NT SERVICE\WinRM" and "NT SERVICE\Wecsvc" via sddl
windows_http_acl 'http://+:5985/' do
  sddl 'D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)'
end
```

```ruby
windows_http_acl 'http://+:50051/' do
    action :delete
end
```

### windows_schannel

Used to configure the schannel security settings in windows, this is used by dotnet apps and PowerShell to be able to speak to tls 1.2 endpoints

#### Actions

- `configure`: Configures the setting

#### Properties

property                 | type       | default       | description
------------------------ | ---------- | ------------- | -----------------------------------------------------------------------------------------------------------------------------------------------------------
`use_strong_crypto`             | True, False     | true | Enables or disables the setting

### windows_user_privilege

Adds the `principal` (User/Group) to the specified privileges (such as `Logon as a batch job` or `Logon as a Service`).

#### Actions

- `:add` - add the specified privileges to the `principal`
- `:remove` - remove the specified privilege of the `principal`

#### Properties

- `principal` - Name attribute, Required, String. The user or group to be granted privileges.
- `privilege` - Required, String/Array. The privilege(s) to be granted.

#### Examples

Grant the Administrator user the `Logon as a batch job` and `Logon as a service` privilege.

```ruby
windows_user_privilege 'Administrator' do
  privilege %w(SeBatchLogonRight SeServiceLogonRight)
end
```

Remove `Logon as a batch job` privilege of Administrator.

```ruby
windows_user_privilege 'Administrator' do
  privilege %w(SeBatchLogonRight)
  action :remove
end
```

#### Available Privileges

```
SeTrustedCredManAccessPrivilege      Access Credential Manager as a trusted caller
SeNetworkLogonRight                  Access this computer from the network
SeTcbPrivilege                       Act as part of the operating system
SeMachineAccountPrivilege            Add workstations to domain
SeIncreaseQuotaPrivilege             Adjust memory quotas for a process
SeInteractiveLogonRight              Allow log on locally
SeRemoteInteractiveLogonRight        Allow log on through Remote Desktop Services
SeBackupPrivilege                    Back up files and directories
SeChangeNotifyPrivilege              Bypass traverse checking
SeSystemtimePrivilege                Change the system time
SeTimeZonePrivilege                  Change the time zone
SeCreatePagefilePrivilege            Create a pagefile
SeCreateTokenPrivilege               Create a token object
SeCreateGlobalPrivilege              Create global objects
SeCreatePermanentPrivilege           Create permanent shared objects
SeCreateSymbolicLinkPrivilege        Create symbolic links
SeDebugPrivilege                     Debug programs
SeDenyNetworkLogonRight              Deny access this computer from the network
SeDenyBatchLogonRight                Deny log on as a batch job
SeDenyServiceLogonRight              Deny log on as a service
SeDenyInteractiveLogonRight          Deny log on locally
SeDenyRemoteInteractiveLogonRight    Deny log on through Remote Desktop Services
SeEnableDelegationPrivilege          Enable computer and user accounts to be trusted for delegation
SeRemoteShutdownPrivilege            Force shutdown from a remote system
SeAuditPrivilege                     Generate security audits
SeImpersonatePrivilege               Impersonate a client after authentication
SeIncreaseWorkingSetPrivilege        Increase a process working set
SeIncreaseBasePriorityPrivilege      Increase scheduling priority
SeLoadDriverPrivilege                Load and unload device drivers
SeLockMemoryPrivilege                Lock pages in memory
SeBatchLogonRight                    Log on as a batch job
SeServiceLogonRight                  Log on as a service
SeSecurityPrivilege                  Manage auditing and security log
SeRelabelPrivilege                   Modify an object label
SeSystemEnvironmentPrivilege         Modify firmware environment values
SeManageVolumePrivilege              Perform volume maintenance tasks
SeProfileSingleProcessPrivilege      Profile single process
SeSystemProfilePrivilege             Profile system performance
SeUnsolicitedInputPrivilege          "Read unsolicited input from a terminal device"
SeUndockPrivilege                    Remove computer from docking station
SeAssignPrimaryTokenPrivilege        Replace a process level token
SeRestorePrivilege                   Restore files and directories
SeShutdownPrivilege                  Shut down the system
SeSyncAgentPrivilege                 Synchronize directory service data
SeTakeOwnershipPrivilege             Take ownership of files or other objects
```

### windows_zipfile

`Note`: This resource has been deprecated as Chef Infra Client 15.0 shipped with a new archive_file resource, which natively handles multiple archive formats. Please update any cookbooks using this resource to instead use the `archive_file` resource: https://docs.chef.io/resource_archive_file.html

Most versions of Windows do not ship with native cli utility for managing compressed files. This resource provides a pure-ruby implementation for managing zip files. Be sure to use the `not_if` or `only_if` meta parameters to guard the resource for idempotence or action will be taken every Chef run.

#### Actions

- `:unzip` - unzip a compressed file
- `:zip` - zip a directory (recursively)

#### Properties

- `path` - name attribute. The path where files will be (un)zipped to.
- `source` - source of the zip file (either a URI or local path) for :unzip, or directory to be zipped for :zip.
- `overwrite` - force an overwrite of the files if they already exist.
- `checksum` - for :unzip, useful if source is remote, if the local file matches the SHA-256 checksum, Chef will not download it.

#### Examples

Unzip a remote zip file locally

```ruby
windows_zipfile 'c:/bin' do
  source 'http://download.sysinternals.com/Files/SysinternalsSuite.zip'
  action :unzip
  not_if {::File.exists?('c:/bin/PsExec.exe')}
end
```

Unzip a local zipfile

```ruby
windows_zipfile 'c:/the_codez' do
  source 'c:/foo/baz/the_codez.zip'
  action :unzip
end
```

Create a local zipfile

```ruby
windows_zipfile 'c:/foo/baz/the_codez.zip' do
  source 'c:/the_codez'
  action :zip
end
```

## Libraries

### WindowsHelper

Helper that allows you to use helpful functions in windows

#### installed_packages

Returns a hash of all DisplayNames installed

```ruby
# usage in a recipe
::Chef::Recipe.send(:include, Windows::Helper)
hash_of_installed_packages = installed_packages
```

#### is_package_installed?

- `package_name` - The name of the package you want to query to see if it is installed
- `returns` - true if the package is installed, false if it the package is not installed

Download a file if a package isn't installed

```ruby
# usage in a recipe to not download a file if package is already installed
::Chef::Recipe.send(:include, Windows::Helper)
is_win_sdk_installed = is_package_installed?('Windows Software Development Kit')

remote_file 'C:\windows\temp\windows_sdk.zip' do
  source 'http://url_to_download/windows_sdk.zip'
  action :create_if_missing
  not_if {is_win_sdk_installed}
end
```

Do something if a package is installed

```ruby
# usage in a provider
include Windows::Helper
if is_package_installed?('Windows Software Development Kit')
  # do something if package is installed
end
```

### Windows::VersionHelper

Helper that allows you to get information on the windows version running on your node. It leverages windows ohai from kernel.os_info, easy to mock and to use even on Linux.

#### core_version?

Determines whether the given node is running on a Windows Core.

```ruby
if ::Windows::VersionHelper.core_version? node
  fail 'Windows Core is not supported'
end
```

#### workstation_version?

Determines whether the given node is a windows workstation version (XP, Vista, 7, 8, 8.1, 10)

```ruby
if ::Windows::VersionHelper.workstation_version? node
  fail 'Only server version of windows are supported'
end
```

#### server_version?

Determines whether the given node is a windows server version (Server 2003, Server 2008, Server 2012, Server 2016)

```ruby
if ::Windows::VersionHelper.server_version? node
  puts 'Server version of windows are cool'
end
```

#### nt_version

Determines NT version of the given node

```ruby
case ::Windows::VersionHelper.nt_version node
  when '6.0' then 'Windows vista or Server 2008'
  when '6.1' then 'Windows 7 or Server 2008R2'
  when '6.2' then 'Windows 8 or Server 2012'
  when '6.3' then 'Windows 8.1 or Server 2012R2'
  when '10.0' then 'Windows 10'
end
```

## Usage

Place an explicit dependency on this cookbook (using depends in the cookbook's metadata.rb) from any cookbook where you would like to use the Windows-specific resources/providers that ship with this cookbook.

```ruby
depends 'windows'
```

## License & Authors

- Author:: Seth Chisamore ([schisamo@chef.io](mailto:schisamo@chef.io))
- Author:: Doug MacEachern ([dougm@vmware.com](mailto:dougm@vmware.com))
- Author:: Paul Morton ([pmorton@biaprotect.com](mailto:pmorton@biaprotect.com))
- Author:: Doug Ireton ([doug.ireton@nordstrom.com](mailto:doug.ireton@nordstrom.com))

```text
Copyright 2011-2018, Chef Software, Inc.
Copyright 2010, VMware, Inc.
Copyright 2011, Business Intelligence Associates, Inc
Copyright 2012, Nordstrom, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
```

repository: BaritoLog/consul-cookbook

gha_language: Ruby

repo_name: BaritoLog/consul-cookbook


text:
---
layout: default
---

# 1995-12-29 - Re:  blind validation

## Header Data

From: Hal<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: e87329c9131fd7fae2b16730d0c444f25537e00165aff6e2e9f5ce38e84e128a

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1995-12-29 07:37:40 UTC

Raw Date: Fri, 29 Dec 1995 15:37:40 +0800

## Raw message

```
{% raw  %}From: Hal<EMAIL_ADDRESS>Date: Fri, 29 Dec 1995 15:37:40 +0800
To<EMAIL_ADDRESS>Subject: Re:  blind validation
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Those are very interesting thoughts Alex Strasheim posted about
blind validations.  The issue of people handing out copies of their
validations ("credentials" is the term Chaum uses) can be significant.

Chaum's way around it was basically to have some mechanism to give
each person a unique number of some special form.  There doesn't have
to be any agency who knows what number each person has (in fact, there
isn't, in his scheme), but there is a mechanism to assure that one
person does not get two numbers.  This is sometimes loosely referred to
as an "is-a-person" credential (although in this specific context it is
not actually a credential, just an identifier).

One way to achieve the goal would be to make each person give a
thumbprint, or some other biometric identification, in exchange for
giving them the is-a-person credential.  Another way would be to use
conventional ID, making sure their credential is blinded.

Then, the blind validations are mathematically structured to be linked to
the identity number.  Only someone who has a specific identity number can
show a specific blind validation.

The idea here is that this addresses the copying-validation problem
because a person would not only have to give away the specific
validation, but also his identity number.  This would in effect let the
other person masquerade as the first, and any bad things he did would
come back to hurt the person who gave away the data.  You can't just walk
away as in a totally uncontrolled blind signature system because of the
linked nature of the credentials, and because you only get one identity
number.

So the result in effect is to make it difficult to give away just a
validation, without also giving away the ability to act as you.  Here
is an idea about another way to achieve the same thing, closer to
Alex's example:  Alice gets a blind validation as Alex describes based
on a simple blind signature.  (Alice hands a blinded number to Bob, he
signs it, Alice unblinds it, and uses the resulting signed number as
the validation to, say, access Bob's files.)  We add that Alice puts,
say, $100 into "escrow", encrypting it with the secret number and
putting it on some public server.  She proves to Bob that she has done
this using cut and choose.

Now if Alice gives away her secret number, anyone using it will be able
to access Bob's files, but they can also get the $100.  So now it costs
something for Alice to give away her secret.

(There are some major problems with this idea, the worst being that Alice
can extract and spend the $100 right after proving to Bob that she is
doing what she said, and before publishing her number.  Maybe someone
could think of some fixes.)

Hal

{% endraw %}
```

## Thread

+ Return to [December 1995](/archive/1995/12)

+ Return to "[Alex Strasheim <cp@proust.suba.com>](/authors/alex_strasheim_cp_at_proust_suba_com_)"
+ Return to "[Hal <hfinney@shell.portal.com>](/authors/hal_hfinney_at_shell_portal_com_)"

+ 1995-12-29 (Fri, 29 Dec 1995 15:37:40 +0800) - Re:  blind validation - _Hal<EMAIL_ADDRESS>  + 1995-12-29 (Sat, 30 Dec 1995 07:12:24 +0800) - [Re: blind validation](/archive/1995/12/edfd56540ffb2deb06a6b0c7b01b381ad0f2b36df3d42558df424004d4205fb3) - _Alex Strasheim<EMAIL_ADDRESS>


text:
Release notes for Agda version 2.5.1
====================================

Documentation
-------------

* There is now an official Agda User Manual:
  https://agda.readthedocs.io/

Installation and infrastructure
-------------------------------

* Builtins and primitives are now defined in a new set of modules available to
  all users, independent of any particular library. The modules are

  ```agda
  Agda.Builtin.Bool
  Agda.Builtin.Char
  Agda.Builtin.Coinduction
  Agda.Builtin.Equality
  Agda.Builtin.Float
  Agda.Builtin.FromNat
  Agda.Builtin.FromNeg
  Agda.Builtin.FromString
  Agda.Builtin.IO
  Agda.Builtin.Int
  Agda.Builtin.List
  Agda.Builtin.Nat
  Agda.Builtin.Reflection
  Agda.Builtin.Size
  Agda.Builtin.Strict
  Agda.Builtin.String
  Agda.Builtin.TrustMe
  Agda.Builtin.Unit
  ```

  The standard library reexports the primitives from the new modules.

  The `Agda.Builtin` modules are installed in the same way as
  `Agda.Primitive`, but unlike `Agda.Primitive` they are not loaded
  automatically.

Pragmas and options
-------------------

* Library management

  There is a new 'library' concept for managing include paths. A library
  consists of
    - a name,
    - a set of libraries it depends on, and
    - a set of include paths.

  A library is defined in a `.agda-lib` file using the following
  format:

  ```
  name: LIBRARY-NAME  -- Comment
  depend: LIB1 LIB2
    LIB3
    LIB4
  include: PATH1
    PATH2
    PATH3
  ```

  Dependencies are library names, not paths to `.agda-lib` files, and
  include paths are relative to the location of the library-file.

  To be useable, a library file has to be listed (with its full path)
  in `AGDA_DIR/libraries` (or `AGDA_DIR/libraries-VERSION`, for a
  given Agda version). `AGDA_DIR` defaults to `~/.agda` on Unix-like
  systems and `C:/Users/USERNAME/AppData/Roaming/agda` or similar on
  Windows, and can be overridden by setting the `AGDA_DIR` environment
  variable.

  Environment variables in the paths (of the form `$VAR` or `${VAR}`)
  are expanded. The location of the libraries file used can be
  overridden using the `--library-file=FILE` flag, although this is
  not expected to be very useful.

  You can find out the precise location of the 'libraries' file by
  calling `agda -l fjdsk Dummy.agda` and looking at the error message
  (assuming you don't have a library called fjdsk installed).

  There are three ways a library gets used:

    - You supply the `--library=LIB` (or `-l LIB`) option to
      Agda. This is equivalent to adding a `-iPATH` for each of the
      include paths of `LIB` and its (transitive) dependencies.

    - No explicit `--library` flag is given, and the current project
      root (of the Agda file that is being loaded) or one of its
      parent directories contains a `.agda-lib` file defining a
      library `LIB`. This library is used as if a `--librarary=LIB`
      option had been given, except that it is not necessary for the
      library to be listed in the `AGDA_DIR/libraries` file.

    - No explicit `--library` flag, and no `.agda-lib` file in the
      project root. In this case the file `AGDA_DIR/defaults` is read
      and all libraries listed are added to the path. The defaults
      file should contain a list of library names, each on a separate
      line. In this case the current directory is also added to the
      path.

      To disable default libraries, you can give the flag
      `--no-default-libraries`.

  Library names can end with a version number (for instance,
  `mylib-1.2.3`). When resolving a library name (given in a `--library`
  flag, or listed as a default library or library dependency) the
  following rules are followed:

    - If you don't give a version number, any version will do.

    - If you give a version number an exact match is required.

    - When there are multiple matches an exact match is preferred, and
      otherwise the latest matching version is chosen.

  For example, suppose you have the following libraries installed:
  `mylib`, `mylib-1.0`, `otherlib-2.1`, and `otherlib-2.3`. In this
  case, aside from the exact matches you can also say
  `--library=otherlib` to get `otherlib-2.3`.

* New Pragma `COMPILED_DECLARE_DATA` for binding recursively defined
  Haskell data types to recursively defined Agda data types.

  If you have a Haskell type like

  ```haskell
  {-# LANGUAGE GADTs #-}

  module Issue223 where

  data A where
    BA :: B -> A

  data B where
    AB :: A -> B
    BB :: B
  ```

  You can now bind it to corresponding mutual Agda inductive data
  types as follows:

  ```agda
  {-# IMPORT Issue223 #-}

  data A : Set
  {-# COMPILED_DECLARE_DATA A Issue223.A #-}
  data B : Set
  {-# COMPILED_DECLARE_DATA B Issue223.B #-}

  data A where
    BA : B → A

  {-# COMPILED_DATA A Issue223.A Issue223.BA #-}
  data B where
    AB : A → B
    BB : B

  {-# COMPILED_DATA B Issue223.B Issue223.AB Issue223.BB #-}
  ```

  This fixes Issue [#223](https://github.com/agda/agda/issues/223).

* New pragma `HASKELL` for adding inline Haskell code (GHC backend only)

  Arbitrary Haskell code can be added to a module using the `HASKELL`
  pragma. For instance,

  ```agda
  {-# HASKELL
    echo :: IO ()
    echo = getLine >>= putStrLn
  #-}

  postulate echo : IO ⊤
  {-# COMPILED echo echo #-}
  ```

* New option `--exact-split`.

  The `--exact-split` flag causes Agda to raise an error whenever a
  clause in a definition by pattern matching cannot be made to hold
  definitionally (i.e. as a reduction rule). Specific clauses can be
  excluded from this check by means of the `{-# CATCHALL #-}` pragma.

  For instance, the following definition will be rejected as the second clause
  cannot be made to hold definitionally:

  ```agda
  min : Nat → Nat → Nat
  min zero    y       = zero
  min x       zero    = zero
  min (suc x) (suc y) = suc (min x y
  ```

  Catchall clauses have to be marked as such, for instance:

  ```agda
  eq : Nat → Nat → Bool
  eq zero    zero    = true
  eq (suc m) (suc n) = eq m n
  {-# CATCHALL #-}
  eq _       _       = false
  ```

* New option: `--no-exact-split`.

  This option can be used to override a global `--exact-split` in a
  file, by adding a pragma `{-# OPTIONS --no-exact-split #-}`.

* New options: `--sharing` and `--no-sharing`.

  These options are used to enable/disable sharing and call-by-need
  evaluation.  The default is `--no-sharing`.

  Note that they cannot appear in an `OPTIONS` pragma, but have to be
  given as command line arguments or added to the Agda Program Args
  from Emacs with `M-x customize-group agda2`.

* New pragma `DISPLAY`.

  ```agda
  {-# DISPLAY f e1 .. en = e #-}
  ```

  This causes `f e1 .. en` to be printed in the same way as `e`, where
  `ei` can bind variables used in `e`. The expressions `ei` and `e`
  are scope checked, but not type checked.

  For example this can be used to print overloaded (instance) functions with
  the overloaded name:

  ```agda
  instance
    NumNat : Num Nat
    NumNat = record { ..; _+_ = natPlus }

  {-# DISPLAY natPlus a b = a + b #-}
  ```

  Limitations

  - Left-hand sides are restricted to variables, constructors, defined
    functions or types, and literals. In particular, lambdas are not
    allowed in left-hand sides.

  - Since `DISPLAY` pragmas are not type checked implicit argument
    insertion may not work properly if the type of `f` computes to an
    implicit function space after pattern matching.

* Removed pragma `{-# ETA R #-}`

  The pragma `{-# ETA R #-}` is replaced by the `eta-equality` directive
  inside record declarations.

* New option `--no-eta-equality`.

  The `--no-eta-equality` flag disables eta rules for declared record
  types.  It has the same effect as `no-eta-equality` inside each
  declaration of a record type `R`.

  If used with the `OPTIONS` pragma it will not affect records defined
  in other modules.

* The semantics of `{-# REWRITE r #-}` pragmas in parametrized modules
  has changed (see
  Issue [#1652](https://github.com/agda/agda/issues/1652)).

  Rewrite rules are no longer lifted to the top context. Instead, they
  now only apply to terms in (extensions of) the module context. If
  you want the old behaviour, you should put the `{-# REWRITE r #-}`
  pragma outside of the module (i.e. unindent it).

* New pragma `{-# INLINE f #-}` causes `f` to be inlined during
  compilation.

* The `STATIC` pragma is now taken into account during compilation.

  Calls to a function marked `STATIC` are normalised before
  compilation. The typical use case for this is to mark the
  interpreter of an embedded language as `STATIC`.

* Option `--type-in-type` no longer implies
  `--no-universe-polymorphism`, thus, it can be used with explicit
  universe
  levels. [Issue [#1764](https://github.com/agda/agda/issues/1764)] It
  simply turns off error reporting for any level mismatch now.
  Examples:

  ```agda
  {-# OPTIONS --type-in-type #-}

  Type : Set
  Type = Set

  data D {α} (A : Set α) : Set where
    d : A → D A

  data E α β : Set β where
    e : Set α → E α β
  ```

* New `NO_POSITIVITY_CHECK` pragma to switch off the positivity checker
  for data/record definitions and mutual blocks.

  The pragma must precede a data/record definition or a mutual block.

  The pragma cannot be used in `--safe` mode.

  Examples (see `Issue1614*.agda` and `Issue1760*.agda` in
  `test/Succeed/`):

  1. Skipping a single data definition.

     ```agda
     {-# NO_POSITIVITY_CHECK #-}
     data D : Set where
       lam : (D → D) → D
     ```

  2. Skipping a single record definition.

     ```agda
     {-# NO_POSITIVITY_CHECK #-}
     record U : Set where
       field ap : U → U
     ```

  3. Skipping an old-style mutual block: Somewhere within a `mutual`
     block before a data/record definition.

     ```agda
     mutual
       data D : Set where
         lam : (D → D) → D

       {-# NO_POSITIVITY_CHECK #-}
       record U : Set where
         field ap : U → U
     ```

  4. Skipping an old-style mutual block: Before the `mutual` keyword.

     ```agda
     {-# NO_POSITIVITY_CHECK #-}
     mutual
       data D : Set where
         lam : (D → D) → D

       record U : Set where
         field ap : U → U
     ```

  5. Skipping a new-style mutual block: Anywhere before the
     declaration or the definition of data/record in the block.

     ```agda
     record U : Set
     data D   : Set

     record U where
       field ap : U → U

     {-# NO_POSITIVITY_CHECK #-}
     data D where
       lam : (D → D) → D
     ```

* Removed `--no-coverage-check`
  option. [Issue [#1918](https://github.com/agda/agda/issues/1918)]

Language
--------

### Operator syntax

* The default fixity for syntax declarations has changed from -666 to 20.

* Sections.

  Operators can be sectioned by replacing arguments with underscores.
  There must not be any whitespace between these underscores and the
  adjacent nameparts. Examples:

  ```agda
  pred : ℕ → ℕ
  pred = _∸ 1

  T : Bool → Set
  T = if_then ⊤ else ⊥

  if : {A : Set} (b : Bool) → A → A → A
  if b = if b then_else_
  ```

  Sections are translated into lambda expressions. Examples:

  ```agda
  _∸ 1              ↦  λ section → section ∸ 1

  if_then ⊤ else ⊥  ↦  λ section → if section then ⊤ else ⊥

  if b then_else_   ↦  λ section section₁ →
                           if b then section else section₁
  ```

  Operator sections have the same fixity as the underlying operator
  (except in cases like `if b then_else_`, in which the section is
  "closed", but the operator is not).

  Operator sections are not supported in patterns (with the exception
  of dot patterns), and notations coming from syntax declarations
  cannot be sectioned.

* A long-standing operator fixity bug has been fixed. As a consequence
  some programs that used to parse no longer do.

  Previously each precedence level was (incorrectly) split up into
  five separate ones, ordered as follows, with the earlier ones
  binding less tightly than the later ones:

    - Non-associative operators.

    - Left associative operators.

    - Right associative operators.

    - Prefix operators.

    - Postfix operators.

  Now this problem has been addressed. It is no longer possible to mix
  operators of a given precedence level but different associativity.
  However, prefix and right associative operators are seen as having
  the same associativity, and similarly for postfix and left
  associative operators.

  Examples
  --------

  The following code is no longer accepted:

  ```agda
  infixl 6 _+_
  infix  6 _∸_

  rejected : ℕ
  rejected = 1 + 0 ∸ 1
  ```

  However, the following previously rejected code is accepted:

  ```agda
  infixr 4 _,_
  infix  4 ,_

  ,_ : {A : Set} {B : A → Set} {x : A} → B x → Σ A B
  , y = _ , y

  accepted : Σ ℕ λ i → Σ ℕ λ j → Σ (i ≡ j) λ _ → Σ ℕ λ k → j ≡ k
  accepted = 5 , , refl , , refl
  ```

* The classification of notations with binders into the categories
  infix, prefix, postfix or closed has
  changed. [Issue [#1450](https://github.com/agda/agda/issues/1450)]

  The difference is that, when classifying the notation, only
  *regular* holes are taken into account, not *binding* ones.

  Example: The notation

  ```agda
  syntax m >>= (λ x → f) = x <- m , f
  ```

  was previously treated as infix, but is now treated as prefix.

* Notation can now include wildcard binders.

  Example: `syntax Σ A (λ _ → B) = A × B`

* If an overloaded operator is in scope with several distinct
  precedence levels, then several instances of this operator will be
  included in the operator grammar, possibly leading to ambiguity.
  Previously the operator was given the default fixity
  [Issue [#1436](https://github.com/agda/agda/issues/1436)].

  There is an exception to this rule: If there are multiple precedences,
  but at most one is explicitly declared, then only one instance will be
  included in the grammar. If there are no explicitly declared
  precedences, then this instance will get the default precedence, and
  otherwise it will get the declared precedence.

  If multiple occurrences of an operator are "merged" in the grammar,
  and they have distinct associativities, then they are treated as
  being non-associative.

  The three paragraphs above also apply to identical notations (coming
  from syntax declarations) for a given overloaded name.

  Examples:

  ```agda
  module A where

    infixr 5 _∷_
    infixr 5 _∙_
    infixl 3 _+_
    infix  1 bind

    syntax bind c (λ x → d) = x ← c , d

  module B where

    infix  5 _∷_
    infixr 4 _∙_
    -- No fixity declaration for _+_.
    infixl 2 bind

    syntax bind c d = c ∙ d

  module C where

    infixr 2 bind

    syntax bind c d = c ∙ d

  open A
  open B
  open C

  -- _∷_ is infix 5.
  -- _∙_ has two fixities: infixr 4 and infixr 5.
  -- _+_ is infixl 3.
  -- A.bind's notation is infix 1.
  -- B.bind and C.bind's notations are infix 2.

  -- There is one instance of "_ ∷ _" in the grammar, and one
  -- instance of "_ + _".

  -- There are three instances of "_ ∙ _" in the grammar, one
  -- corresponding to A._∙_, one corresponding to B._∙_, and one
  -- corresponding to both B.bind and C.bind.
  ```

### Reflection

* The reflection framework has received a massive overhaul.

  A new type of reflected type checking computations supplants most of
  the old reflection primitives. The `quoteGoal`, `quoteContext` and
  tactic primitives are deprecated and will be removed in the future,
  and the `unquoteDecl` and `unquote` primitives have changed
  behaviour. Furthermore the following primitive functions have been
  replaced by builtin type checking computations:

  ```agda
  - primQNameType              --> AGDATCMGETTYPE
  - primQNameDefinition        --> AGDATCMGETDEFINITION
  - primDataConstructors       --> subsumed by AGDATCMGETDEFINITION
  - primDataNumberOfParameters --> subsumed by AGDATCMGETDEFINITION
  ```

  See below for details.

* Types are no longer packaged with a sort.

  The `AGDATYPE` and `AGDATYPEEL` built-ins have been
  removed. Reflected types are now simply terms.

* Reflected definitions have more information.

  The type for reflected definitions has changed to

  ```agda
  data Definition : Set where
    fun-def     : List Clause  → Definition
    data-type   : Nat → List Name → Definition -- parameters and constructors
    record-type : Name → Definition            -- name of the data/record type
    data-con    : Name → Definition            -- name of the constructor
    axiom       : Definition
    prim-fun    : Definition
  ```

  Correspondingly the built-ins for function, data and record
  definitions (`AGDAFUNDEF`, `AGDAFUNDEFCON`, `AGDADATADEF`,
  `AGDARECORDDEF`) have been removed.

* Reflected type checking computations.

  There is a primitive `TC` monad representing type checking
  computations. The `unquote`, `unquoteDecl`, and the new `unquoteDef`
  all expect computations in this monad (see below). The interface to
  the monad is the following

  ```agda
  -- Error messages can contain embedded names and terms.
  data ErrorPart : Set where
    strErr  : String → ErrorPart
    termErr : Term → ErrorPart
    nameErr : Name → ErrorPart

  {-# BUILTIN AGDAERRORPART       ErrorPart #-}
  {-# BUILTIN AGDAERRORPARTSTRING strErr    #-}
  {-# BUILTIN AGDAERRORPARTTERM   termErr   #-}
  {-# BUILTIN AGDAERRORPARTNAME   nameErr   #-}

  postulate
    TC         : ∀ {a} → Set a → Set a
    returnTC   : ∀ {a} {A : Set a} → A → TC A
    bindTC     : ∀ {a b} {A : Set a} {B : Set b} → TC A → (A → TC B) → TC B

    -- Unify two terms, potentially solving metavariables in the process.
    unify      : Term → Term → TC ⊤

    -- Throw a type error. Can be caught by catchTC.
    typeError  : ∀ {a} {A : Set a} → List ErrorPart → TC A

    -- Block a type checking computation on a metavariable. This will abort
    -- the computation and restart it (from the beginning) when the
    -- metavariable is solved.
    blockOnMeta : ∀ {a} {A : Set a} → Meta → TC A

    -- Backtrack and try the second argument if the first argument throws a
    -- type error.
    catchTC    : ∀ {a} {A : Set a} → TC A → TC A → TC A

    -- Infer the type of a given term
    inferType  : Term → TC Type

    -- Check a term against a given type. This may resolve implicit arguments
    -- in the term, so a new refined term is returned. Can be used to create
    -- new metavariables: newMeta t = checkType unknown t
    checkType  : Term → Type → TC Term

    -- Compute the normal form of a term.
    normalise  : Term → TC Term

    -- Get the current context.
    getContext : TC (List (Arg Type))

    -- Extend the current context with a variable of the given type.
    extendContext : ∀ {a} {A : Set a} → Arg Type → TC A → TC A

    -- Set the current context.
    inContext     : ∀ {a} {A : Set a} → List (Arg Type) → TC A → TC A

    -- Quote a value, returning the corresponding Term.
    quoteTC : ∀ {a} {A : Set a} → A → TC Term

    -- Unquote a Term, returning the corresponding value.
    unquoteTC : ∀ {a} {A : Set a} → Term → TC A

    -- Create a fresh name.
    freshName  : String → TC QName

    -- Declare a new function of the given type. The function must be defined
    -- later using 'defineFun'. Takes an Arg Name to allow declaring instances
    -- and irrelevant functions. The Visibility of the Arg must not be hidden.
    declareDef : Arg QName → Type → TC ⊤

    -- Define a declared function. The function may have been declared using
    -- 'declareDef' or with an explicit type signature in the program.
    defineFun  : QName → List Clause → TC ⊤

    -- Get the type of a defined name. Replaces 'primQNameType'.
    getType    : QName → TC Type

    -- Get the definition of a defined name. Replaces 'primQNameDefinition'.
    getDefinition : QName → TC Definition

  {-# BUILTIN AGDATCM                   TC                 #-}
  {-# BUILTIN AGDATCMRETURN             returnTC           #-}
  {-# BUILTIN AGDATCMBIND               bindTC             #-}
  {-# BUILTIN AGDATCMUNIFY              unify              #-}
  {-# BUILTIN AGDATCMNEWMETA            newMeta            #-}
  {-# BUILTIN AGDATCMTYPEERROR          typeError          #-}
  {-# BUILTIN AGDATCMBLOCKONMETA        blockOnMeta        #-}
  {-# BUILTIN AGDATCMCATCHERROR         catchTC            #-}
  {-# BUILTIN AGDATCMINFERTYPE          inferType          #-}
  {-# BUILTIN AGDATCMCHECKTYPE          checkType          #-}
  {-# BUILTIN AGDATCMNORMALISE          normalise          #-}
  {-# BUILTIN AGDATCMGETCONTEXT         getContext         #-}
  {-# BUILTIN AGDATCMEXTENDCONTEXT      extendContext      #-}
  {-# BUILTIN AGDATCMINCONTEXT          inContext          #-}
  {-# BUILTIN AGDATCMQUOTETERM          quoteTC            #-}
  {-# BUILTIN AGDATCMUNQUOTETERM        unquoteTC          #-}
  {-# BUILTIN AGDATCMFRESHNAME          freshName          #-}
  {-# BUILTIN AGDATCMDECLAREDEF         declareDef         #-}
  {-# BUILTIN AGDATCMDEFINEFUN          defineFun          #-}
  {-# BUILTIN AGDATCMGETTYPE            getType            #-}
  {-# BUILTIN AGDATCMGETDEFINITION      getDefinition      #-}
  ```

* Builtin type for metavariables

  There is a new builtin type for metavariables used by the new reflection
  framework. It is declared as follows and comes with primitive equality,
  ordering and show.

  ```agda
  postulate Meta : Set
  {-# BUILTIN AGDAMETA Meta #-}
  primitive primMetaEquality : Meta → Meta → Bool
  primitive primMetaLess : Meta → Meta → Bool
  primitive primShowMeta : Meta → String
  ```

  There are corresponding new constructors in the `Term` and `Literal`
  data types:

  ```agda
  data Term : Set where
    ...
    meta : Meta → List (Arg Term) → Term

  {-# BUILTIN AGDATERMMETA meta #-}

  data Literal : Set where
    ...
    meta : Meta → Literal

  {-# BUILTIN AGDALITMETA meta #-}
  ```

* Builtin unit type

  The type checker needs to know about the unit type, which you can
  allow by

  ```agda
  record ⊤ : Set where
  {-# BUILTIN UNIT ⊤ #-}
  ```

* Changed behaviour of `unquote`

  The `unquote` primitive now expects a type checking computation
  instead of a pure term. In particular `unquote e` requires

  ```agda
  e : Term → TC ⊤
  ```

  where the argument is the representation of the hole in which the
  result should go. The old `unquote` behaviour (where `unquote`
  expected a `Term` argument) can be recovered by

  ```agda
  OLD: unquote v
  NEW: unquote λ hole → unify hole v
  ```

* Changed behaviour of `unquoteDecl`

  The `unquoteDecl` primitive now expects a type checking computation
  instead of a pure function definition. It is possible to define
  multiple (mutually recursive) functions at the same time. More
  specifically

  ```agda
  unquoteDecl x₁ .. xₙ = m
  ```

  requires `m : TC ⊤` and that `x₁ .. xₙ` are defined (using
  `declareDef` and `defineFun`) after executing `m`. As before `x₁
  .. xₙ : QName` in `m`, but have their declared types outside the
  `unquoteDecl`.

* New primitive `unquoteDef`

  There is a new declaration

  ```agda
  unquoteDef x₁ .. xₙ = m
  ```

  This works exactly as `unquoteDecl` (see above) with the exception
  that `x₁ ..  xₙ` are required to already be declared.

  The main advantage of `unquoteDef` over `unquoteDecl` is that
  `unquoteDef` is allowed in mutual blocks, allowing mutually
  recursion between generated definitions and hand-written
  definitions.

* The reflection interface now exposes the name hint (as a string)
  for variables. As before, the actual binding structure is with
  de Bruijn indices. The String value is just a hint used as a prefix
  to help display the variable. The type `Abs` is a new builtin type used
  for the constructors `Term.lam`, `Term.pi`, `Pattern.var`
  (bultins `AGDATERMLAM`, `AGDATERMPI` and `AGDAPATVAR`).

  ```agda
  data Abs (A : Set) : Set where
    abs : (s : String) (x : A) → Abs A
  {-# BUILTIN ABS    Abs #-}
  {-# BUILTIN ABSABS abs #-}
  ```

  Updated constructor types:

  ```agda
  Term.lam    : Hiding   → Abs Term → Term
  Term.pi     : Arg Type → Abs Type → Term
  Pattern.var : String   → Pattern
  ```

* Reflection-based macros

  Macros are functions of type `t1 → t2 → .. → Term → TC ⊤` that are
  defined in a `macro` block. Macro application is guided by the type
  of the macro, where `Term` arguments desugar into the `quoteTerm`
  syntax and `Name` arguments into the `quote` syntax. Arguments of
  any other type are preserved as-is. The last `Term` argument is the
  hole term given to `unquote` computation (see above).

  For example, the macro application `f u v w` where the macro `f` has
  the type `Term → Name → Bool → Term → TC ⊤` desugars into `unquote
  (f (quoteTerm u) (quote v) w)`

  Limitations:

    - Macros cannot be recursive. This can be worked around by defining the
      recursive function outside the macro block and have the macro call the
      recursive function.

   For instance, suppose you have a solver

  ```agda
  magic : Type → Term
  ```

  that takes a reflected goal and outputs a proof (when successful). You can
  then define the following macro

  ```agda
  macro
    by-magic : Term → TC ⊤
    by-magic hole =
      bindTC (inferType hole) λ goal →
      unify hole (magic goal)
  ```

  This lets you apply the magic tactic without any syntactic noise at all:

  ```agda
  thm : ¬ P ≡ NP
  thm = by-magic
  ```

### Literals and built-ins

* Overloaded number literals.

  You can now overload natural number literals using the new builtin
  `FROMNAT`:

  ```agda
  {-# BUILTIN FROMNAT fromNat #-}
  ```

  The target of the builtin should be a defined name. Typically you would do
  something like

  ```agda
  record Number (A : Set) : Set where
    field fromNat : Nat → A

  open Number {{...}} public

  {-# BUILTIN FROMNAT fromNat #-}
  ```

  This will cause number literals `n` to be desugared to `fromNat n`
  before type checking.

* Negative number literals.

  Number literals can now be negative. For floating point literals it
  works as expected. For integer literals there is a new builtin
  `FROMNEG` that enables negative integer literals:

  ```agda
  {-# BUILTIN FROMNEG fromNeg #-}
  ```

  This causes negative literals `-n` to be desugared to `fromNeg n`.

* Overloaded string literals.

  String literals can be overladed using the `FROMSTRING` builtin:

  ```agda
  {-# BUILTIN FROMSTRING fromString #-}
  ```

  The will cause string literals `s` to be desugared to `fromString s`
  before type checking.

* Change to builtin integers.

  The `INTEGER` builtin now needs to be bound to a datatype with two
  constructors that should be bound to the new builtins `INTEGERPOS`
  and `INTEGERNEGSUC` as follows:

  ```agda
  data Int : Set where
    pos    : Nat -> Int
    negsuc : Nat -> Int
  {-# BUILTIN INTEGER       Int    #-}
  {-# BUILTIN INTEGERPOS    pos    #-}
  {-# BUILTIN INTEGERNEGSUC negsuc #-}
  ```

  where `negsuc n` represents the integer `-n - 1`. For instance, `-5`
  is represented as `negsuc 4`. All primitive functions on integers
  except `primShowInteger` have been removed, since these can be
  defined without too much trouble on the above representation using
  the corresponding functions on natural numbers.

  The primitives that have been removed are

  ```agda
  primIntegerPlus
  primIntegerMinus
  primIntegerTimes
  primIntegerDiv
  primIntegerMod
  primIntegerEquality
  primIntegerLess
  primIntegerAbs
  primNatToInteger
  ```

* New primitives for strict evaluation

  ```agda
  primitive
    primForce      : ∀ {a b} {A : Set a} {B : A → Set b} (x : A) → (∀ x → B x) → B x
    primForceLemma : ∀ {a b} {A : Set a} {B : A → Set b} (x : A) (f : ∀ x → B x) → primForce x f ≡ f x
  ```

  `primForce x f` evaluates to `f x` if x is in weak head normal form,
  and `primForceLemma x f` evaluates to `refl` in the same
  situation. The following values are considered to be in weak head
  normal form:

    - constructor applications
    - literals
    - lambda abstractions
    - type constructor (data/record types) applications
    - function types
    - Set a

### Modules

* Modules in import directives

  When you use `using`/`hiding`/`renaming` on a name it now
  automatically applies to any module of the same name, unless you
  explicitly mention the module. For instance,

  ```agda
  open M using (D)
  ```

  is equivalent to

  ```agda
  open M using (D; module D)
  ```

  if `M` defines a module `D`. This is most useful for record and data
  types where you always get a module of the same name as the type.

  With this feature there is no longer useful to be able to qualify a
  constructor (or field) by the name of the data type even when it
  differs from the name of the corresponding module. The follow
  (weird) code used to work, but doesn't work anymore:

  ```agda
  module M where
    data D where
      c : D
  open M using (D) renaming (module D to MD)
  foo : D
  foo = D.c
  ```

  If you want to import only the type name and not the module you have to hide
  it explicitly:

  ```agda
  open M using (D) hiding (module D)
  ```

  See discussion on
  Issue [#836](https://github.com/agda/agda/issues/836).

* Private definitions of a module are no longer in scope at the Emacs
  mode top-level.

  The reason for this change is that `.agdai-files` are stripped of
  unused private definitions (which can yield significant performance
  improvements for module-heavy code).

  To test private definitions you can create a hole at the bottom of
  the module, in which private definitions will be visible.

### Records

* New record directives `eta-equality`/`no-eta-equality`

  The keywords `eta-equality`/`no-eta-equality` enable/disable eta
  rules for the (inductive) record type being declared.

  ```agda
  record Σ (A : Set) (B : A -> Set) : Set where
    no-eta-equality
    constructor _,_
    field
      fst : A
      snd : B fst
  open Σ

  -- fail : ∀ {A : Set}{B : A -> Set} → (x : Σ A B) → x ≡ (fst x , snd x)
  -- fail x = refl
  --
  -- x != fst x , snd x of type Σ .A .B
  -- when checking that the expression refl has type x ≡ (fst x , snd x)
  ```

* Building records from modules.

  The `record { <fields> }` syntax is now extended to accept module
  names as well. Fields are thus defined using the corresponding
  definitions from the given module.

  For instance assuming this record type `R` and module `M`:

  ```agda
  record R : Set where
    field
      x : X
      y : Y
      z : Z

  module M where
    x = {! ... !}
    y = {! ... !}

  r : R
  r = record { M; z = {! ... !} }
  ```

  Previously one had to write `record { x = M.x; y = M.y; z = {! ... !} }`.

  More precisely this construction now supports any combination of explicit
  field definitions and applied modules.

  If a field is both given explicitly and available in one of the modules,
  then the explicit one takes precedence.

  If a field is available in more than one module then this is ambiguous
  and therefore rejected. As a consequence the order of assignments does
  not matter.

  The modules can be both applied to arguments and have import directives
  such as `hiding`, `using`, and `renaming`. In particular this construct
  subsumes the record update construction.

  Here is an example of record update:

  ```agda
  -- Record update. Same as: record r { y = {! ... !} }
  r2 : R
  r2 = record { R r; y = {! ... !} }
  ```

  A contrived example showing the use of `hiding`/`renaming`:

  ```agda
  module M2 (a : A) where
    w = {! ... !}
    z = {! ... !}

  r3 : A → R
  r3 a = record { M hiding (y); M2 a renaming (w to y) }
  ```

* Record patterns are now accepted.

  Examples:

  ```agda
  swap : {A B : Set} (p : A × B) → B × A
  swap record{ proj₁ = a; proj₂ = b } = record{ proj₁ = b; proj₂ = a }

  thd3 : ...
  thd3 record{ proj₂ = record { proj₂ = c }} = c
  ```

* Record modules now properly hide all their parameters
  [Issue [#1759](https://github.com/agda/agda/issues/1759)]

  Previously parameters to parent modules were not hidden in the record
  module, resulting in different behaviour between

  ```agda
  module M (A : Set) where
    record R (B : Set) : Set where
  ```

  and

  ```agda
  module M where
    record R (A B : Set) : Set where
  ```

  where in the former case, `A` would be an explicit argument to the module
  `M.R`, but implicit in the latter case. Now `A` is implicit in both cases.

### Instance search

* Performance has been improved, recursive instance search which was
  previously exponential in the depth is now only quadratic.

* Constructors of records and datatypes are not anymore automatically
  considered as instances, you have to do so explicitely, for
  instance:

  ```agda
  -- only [b] is an instance of D
  data D : Set where
    a : D
    instance
      b : D
    c : D

  -- the constructor is now an instance
  record tt : Set where
    instance constructor tt
  ```

* Lambda-bound variables are no longer automatically considered
  instances.

  Lambda-bound variables need to be bound as instance arguments to be
  considered for instance search. For example,

  ```agda
  _==_ : {A : Set} {{_ : Eq A}} → A → A → Bool

  fails : {A : Set} → Eq A → A → Bool
  fails eqA x = x == x

  works : {A : Set} {{_ : Eq A}} → A → Bool
  works x = x == x
  ```

* Let-bound variables are no longer automatically considered
  instances.

  To make a let-bound variable available as an instance it needs to be
  declared with the `instance` keyword, just like top-level
  instances. For example,

  ```agda
  mkEq : {A : Set} → (A → A → Bool) → Eq A

  fails : {A : Set} → (A → A → Bool) → A → Bool
  fails eq x = let eqA = mkEq eq in x == x

  works : {A : Set} → (A → A → Bool) → A → Bool
  works eq x = let instance eqA = mkEq eq in x == x
  ```

* Record fields can be declared instances.

  For example,

  ```agda
  record EqSet : Set₁ where
    field
      set : Set
      instance eq : Eq set
  ```

  This causes the projection function `eq : (E : EqSet) → Eq (set E)`
  to be considered for instance search.

* Instance search can now find arguments in variable types (but such
  candidates can only be lambda-bound variables, they can’t be
  declared as instances)

  ```agda
  module _ {A : Set} (P : A → Set) where

    postulate
      bla : {x : A} {{_ : P x}} → Set → Set

    -- Works, the instance argument is found in the context
    test :  {x : A} {{_ : P x}} → Set → Set
    test B = bla B

    -- Still forbidden, because [P] could be instantiated later to anything
    instance
     postulate
      forbidden : {x : A} → P x
  ```

* Instance search now refuses to solve constraints with unconstrained
  metavariables, since this can lead to non-termination.

  See [Issue [#1532](https://github.com/agda/agda/issues/1523)] for an
  example.

* Top-level instances are now only considered if they are in
  scope. [Issue [#1913](https://github.com/agda/agda/issues/1913)]

  Note that lambda-bound instances need not be in scope.

### Other changes

* Unicode ellipsis character is allowed for the ellipsis token `...`
  in `with` expressions.

* `Prop` is no longer a reserved word.

Type checking
-------------

* Large indices.

  Force constructor arguments no longer count towards the size of a datatype.
  For instance, the definition of equality below is accepted.

  ```agda
  data _≡_ {a} {A : Set a} : A → A → Set where
    refl : ∀ x → x ≡ x
  ```

  This gets rid of the asymmetry that the version of equality which indexes
  only on the second argument could be small, but not the version above which
  indexes on both arguments.

* Detection of datatypes that satisfy K (i.e. sets)

  Agda will now try to detect datatypes that satisfy K when
  `--without-K` is enabled. A datatype satisfies K when it follows
  these three rules:

  - The types of all non-recursive constructor arguments should satisfy K.

  - All recursive constructor arguments should be first-order.

  - The types of all indices should satisfy K.

  For example, the types `Nat`, `List Nat`, and `x ≡ x` (where `x :
  Nat`) are all recognized by Agda as satisfying K.

* New unifier for case splitting

  The unifier used by Agda for case splitting has been completely
  rewritten. The new unifier takes a much more type-directed approach
  in order to avoid the problems in issues
  [#1406](https://github.com/agda/agda/issues/1406),
  [#1408](https://github.com/agda/agda/issues/1408),
  [#1427](https://github.com/agda/agda/issues/1427), and
  [#1435](https://github.com/agda/agda/issues/1435).

  The new unifier also has eta-equality for record types
  built-in. This should avoid unnecessary case splitting on record
  constructors and improve the performance of Agda on code that
  contains deeply nested record patterns (see issues
  [#473](https://github.com/agda/agda/issues/473),
  [#635](https://github.com/agda/agda/issues/635),
  [#1575](https://github.com/agda/agda/issues/1575),
  [#1603](https://github.com/agda/agda/issues/1603),
  [#1613](https://github.com/agda/agda/issues/1613), and
  [#1645](https://github.com/agda/agda/issues/1645)).

  In some cases, the locations of the dot patterns computed by the
  unifier did not correspond to the locations given by the user (see
  Issue [#1608](https://github.com/agda/agda/issues/1608)). This has
  now been fixed by adding an extra step after case splitting that
  checks whether the user-written patterns are compatible with the
  computed ones.

  In some rare cases, the new unifier is still too restrictive when
  `--without-K` is enabled because it cannot generalize over the
  datatype indices (yet). For example, the following code is rejected:

  ```agda
  data Bar : Set₁ where
    bar : Bar
    baz : (A : Set) → Bar

  data Foo : Bar → Set where
    foo : Foo bar

  test : foo ≡ foo → Set₁
  test refl = Set
  ```

* The aggressive behaviour of `with` introduced in <IP_ADDRESS> has been
  rolled back
  [Issue [#1692](https://github.com/agda/agda/issues/1692)]. With no
  longer abstracts in the types of variables appearing in the
  with-expressions. [Issue [#745](https://github.com/agda/agda/issues/745)]

  This means that the following example no longer works:

  ```agda
  fails : (f : (x : A) → a ≡ x) (b : A) → b ≡ a
  fails f b with a | f b
  fails f b | .b | refl = f b
  ```

  The `with` no longer abstracts the type of `f` over `a`, since `f`
  appears in the second with-expression `f b`. You can use a nested
  `with` to make this example work.

  This example does work again:

  ```agda
  test : ∀{A : Set}{a : A}{f : A → A} (p : f a ≡ a) → f (f a) ≡ a
  test p rewrite p = p
  ```

  After `rewrite p` the goal has changed to `f a ≡ a`, but the type
  of `p` has not been rewritten, thus, the final `p` solves the goal.

  The following, which worked in <IP_ADDRESS>, no longer works:

  ```agda
  fails : (f : (x : A) → a ≡ x) (b : A) → b ≡ a
  fails f b rewrite f b = f b
  ```

  The rewrite with `f b : a ≡ b` is not applied to `f` as
  the latter is part of the rewrite expression `f b`.  Thus,
  the type of `f` remains untouched, and the changed goal
  `b ≡ b` is not solved by `f b`.

* When using `rewrite` on a term `eq` of type `lhs ≡ rhs`, the `lhs`
  is no longer abstracted in `rhs`
  [Issue [#520](https://github.com/agda/agda/issues/520)].  This means
  that

  ```agda
  f pats rewrite eq = body
  ```

  is more than syntactic sugar for

  ```agda
  f pats with lhs | eq
  f pats | _ | refl = body
  ```

  In particular, the following application of `rewrite` is now
  possible

  ```agda
  id : Bool → Bool
  id true  = true
  id false = false

  is-id : ∀ x → x ≡ id x
  is-id true  = refl
  is-id false = refl

  postulate
    P : Bool → Set
    b : Bool
    p : P (id b)

  proof : P b
  proof rewrite is-id b = p
  ```

  Previously, this was desugared to

  ```agda
  proof with b | is-id b
  proof | _ | refl = p
  ```

  which did not type check as `refl` does not have type `b ≡ id b`.
  Now, Agda gets the task of checking `refl : _ ≡ id b` leading to
  instantiation of `_` to `id b`.

Compiler backends
-----------------

* Major Bug Fixes:

  - Function clauses with different arities are now always compiled
    correctly by the GHC/UHC
    backends. (Issue [#727](https://github.com/agda/agda/issues/727))

* Co-patterns

  - The GHC/UHC backends now support co-patterns. (Issues
    [#1567](https://github.com/agda/agda/issues/1567),
    [#1632](https://github.com/agda/agda/issues/1632))

* Optimizations

  - Builtin naturals are now represented as arbitrary-precision
    Integers. See the user manual, section
    "Agda Compilers -> Optimizations" for details.

* GHC Haskell backend (MAlonzo)

  - Pragmas

    Since builtin naturals are compiled to `Integer` you can no longer
    give a `{-# COMPILED_DATA #-}` pragma for `Nat`. The same goes for
    builtin booleans, integers, floats, characters and strings which
    are now hard-wired to appropriate Haskell types.

* UHC compiler backend

  A new backend targeting the Utrecht Haskell Compiler (UHC) is
  available.  It targets the UHC Core language, and it's design is
  inspired by the Epic backend. See the user manual, section "Agda
  Compilers -> UHC Backend" for installation instructions.

  - FFI

    The UHC backend has a FFI to Haskell similar to MAlonzo's. The
    target Haskell code also needs to be compilable using UHC, which
    does not support the Haskell base library version 4.*.

    FFI pragmas for the UHC backend are not checked in any way. If the
    pragmas are wrong, bad things will happen.

  - Imports

    Additional Haskell modules can be brought into scope with the
    `IMPORT_UHC` pragma:

    ```agda
    {-# IMPORT_UHC Data.Char #-}
    ```

    The Haskell modules `UHC.Base` and `UHC.Agda.Builtins` are always in
    scope and don't need to be imported explicitly.

  - Datatypes

    Agda datatypes can be bound to Haskell datatypes as follows:

    Haskell:
    ```haskell
    data HsData a = HsCon1 | HsCon2 (HsData a)
    ```

    Agda:
    ```agda
    data AgdaData (A : Set) : Set where
      AgdaCon1 : AgdaData A
      AgdaCon2 : AgdaData A -> AgdaData A
    {-# COMPILED_DATA_UHC AgdaData HsData HsCon1 HsCon2 #-}
    ```

    The mapping has to cover all constructors of the used Haskell
    datatype, else runtime behavior is undefined!

    There are special reserved names to bind Agda datatypes to certain
    Haskell datatypes. For example, this binds an Agda datatype to
    Haskell's list datatype:

    Agda:
    ```agda
    data AgdaList (A : Set) : Set where
      Nil : AgdaList A
      Cons : A -> AgdaList A -> AgdaList A
    {-# COMPILED_DATA_UHC AgdaList __LIST__ __NIL__ __CONS__ #-}
    ```

    The following "magic" datatypes are available:

    ```
    HS Datatype | Datatype Pragma | HS Constructor | Constructor Pragma
    ()            __UNIT__          ()               __UNIT__
    List          __LIST__          (:)              __CONS__
                                    []               __NIL__
    Bool          __BOOL__          True             __TRUE__
                                    False            __FALSE__
    ```

  - Functions

    Agda postulates can be bound to Haskell functions. Similar as in
    MAlonzo, all arguments of type `Set` need to be dropped before
    calling Haskell functions. An example calling the return function:

    Agda:
    ```agda
    postulate hs-return : {A : Set} -> A -> IO A
    {-# COMPILED_UHC hs-return (\_ -> UHC.Agda.Builtins.primReturn) #-}
    ```

Emacs mode and interaction
--------------------------

* Module contents (`C-c C-o`) now also works for
  records. [See Issue [#1926](https://github.com/agda/agda/issues/1926) ]
  If you have an inferable expression of record type in an interaction
  point, you can invoke `C-c C-o` to see its fields and types.
  Example

  ```agda
  record R : Set where
    field f : A

  test : R → R
  test r = {!r!}  -- C-c C-o here
  ```

* Less aggressive error notification.

  Previously Emacs could jump to the position of an error even if the
  type-checking process was not initiated in the current buffer. Now
  this no longer happens: If the type-checking process was initiated
  in another buffer, then the cursor is moved to the position of the
  error in the buffer visiting the file (if any) and in every window
  displaying the file, but focus should not change from one file to
  another.

  In the cases where focus does change from one file to another, one
  can now use the go-back functionality to return to the previous
  position.

* Removed the `agda-include-dirs` customization parameter.

  Use `agda-program-args` with `-iDIR` or `-lLIB` instead, or add
  libraries to `~/.agda/defaults`
  (`C:/Users/USERNAME/AppData/Roaming/agda/defaults` or similar on
  Windows). See Library management, above, for more information.

Tools
-----

### LaTeX-backend

* The default font has been changed to XITS (which is part of TeX Live):

    http://www.ctan.org/tex-archive/fonts/xits/

  This font is more complete with respect to Unicode.

### agda-ghc-names

* New tool: The command

  ```
  agda-ghc-names fixprof <compile-dir> <ProgName>.prof
  ```

  converts `*.prof` files obtained from profiling runs of
  MAlonzo-compiled code to `*.agdaIdents.prof`, with the original Agda
  identifiers replacing the MAlonzo-generated Haskell identifiers.

  For usage and more details, see `src/agda-ghc-names/README.txt`.

Highlighting and textual backends
---------------------------------

* Names in import directives are now highlighted and are clickable.
  [Issue [#1714](https://github.com/agda/agda/issues/1714)] This leads
  also to nicer printing in the LaTeX and html backends.

Fixed issues
------------

See
[bug tracker (milestone 2.5.1)](https://github.com/agda/agda/issues?q=milestone%3A2.5.1+is%3Aclosed)

repository: agda/agda

gha_language: Haskell

gha_license_id: NOASSERTION

repo_name: agda/agda


text:
# The raise modalities

```agda
module orthogonal-factorization-systems.raise-modalities where
```

<details><summary>Imports</summary>

```agda
open import foundation.function-types
open import foundation.raising-universe-levels
open import foundation.universe-levels

open import orthogonal-factorization-systems.local-types
open import orthogonal-factorization-systems.modal-operators
open import orthogonal-factorization-systems.uniquely-eliminating-modalities
```

</details>

## Idea

The operations of
[raising universe levels](foundation.raising-universe-levels.md) are trivially
[higher modalities](orthogonal-factorization-systems.higher-modalities.md), and
in the case that `l1 ⊔ l2 = l1`, we recover the
[identity modality](orthogonal-factorization-systems.identity-modality.md).

## Definition

```agda
operator-raise-modality :
  (l1 l2 : Level) → operator-modality l1 (l1 ⊔ l2)
operator-raise-modality l1 l2 = raise l2

unit-raise-modality :
  {l1 l2 : Level} → unit-modality (operator-raise-modality l1 l2)
unit-raise-modality = map-raise
```

## Properties

### The raise modality is a uniquely eliminating modality

```agda
is-uniquely-eliminating-modality-raise-modality :
  {l1 l2 : Level} →
  is-uniquely-eliminating-modality (unit-raise-modality {l1} {l2})
is-uniquely-eliminating-modality-raise-modality {l1} {l2} _ P =
  is-local-family-is-equiv
    ( unit-raise-modality)
    ( is-equiv-map-raise)
    ( operator-raise-modality l1 l2 ∘ P)
```

### In the case that `l1 ⊔ l2 = l1` we recover the trivial modality

This remains to be made formal.

repository: UniMath/agda-unimath

gha_language: Agda

repo_name: UniMath/agda-unimath


text:
---
layout: post
title: Nimbus 3.0 is public
author: DamianM
---

Yes, we agree. Holding off this long was silly.

We (and a lot of others) have been running 3.0 in production for ages from the Myget feed. But a few bits of doco (mainly) were holding us back. We decided to push the button and push it live.

You can read the breaking changes [here](/2016/04/24/nimbus-30-nearing-release/).

We do need help with documentation, community management, and code. That much is obvious. If you'd like to help, please get in touch on [Gitter](https://gitter.im/NimbusAPI/Nimbus) or email<EMAIL_ADDRESS>and we can chat. We want Nimbus to be awesome, we want it to stick around, so we'd love to hear from you.

gha_language: CSS


text:
---
id: sidecar_template
title: Sidecar Template
sidebar_label: Sidecar Template
---

The following content is the common template ConfigMap defined for injecting IOChaos sidecar, you can also find this example [here](https://github.com/chaos-mesh/chaos-mesh/blob/master/manifests/chaosfs-sidecar.yaml):

## Template ConfigMap

```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: chaosfs-sidecar
  labels:
    app.kubernetes.io/component: template
data:
  data: |
    initContainers:
    - name: inject-scripts
      image: pingcap/chaos-scripts:latest
      imagePullPolicy: Always
      command: ["sh", "-c", "/scripts/init.sh -d {{.DataPath}} -f {{.MountPath}}/fuse-data"]
    containers:
    - name: chaosfs
      image: pingcap/chaos-fs:latest
      imagePullPolicy: Always
      ports:
      - containerPort: 65533
      securityContext:
        privileged: true
      command:
        - /usr/local/bin/chaosfs
        - -addr=:65533
        - -pidfile=/tmp/fuse/pid
        - -original={{.MountPath}}/fuse-data
        - -mountpoint={{.DataPath}}
      volumeMounts:
        - name: {{.VolumeName}}
          mountPath: {{.MountPath}}
          mountPropagation: Bidirectional
    volumeMounts:
    - name: {{.VolumeName}}
      mountPath: {{.MountPath}}
      mountPropagation: HostToContainer
    - name: scripts
      mountPath: /tmp/scripts
    - name: fuse
      mountPath: /tmp/fuse
    volumes:
    - name: scripts
      emptyDir: {}
    - name: fuse
      emptyDir: {}
    postStart:
      {{.ContainerName}}:
        command:
          - /tmp/scripts/wait-fuse.sh
```

Template config defines some variables by [Go Template](https://golang.org/pkg/text/template/) mechanism. This example has four arguments:

- DataPath: original data directory
- MountPath: after injecting chaosfs sidecar, data directory will be mounted to {{.MountPath}}/fuse-data
- VolumeName: the data volume name used by the pod
- ContainerName: to which container the sidecar is injected

For fields defined in this template, we have some brief descriptions below:

* **initContainers**: defines the [initContainer](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) need to be injected.
* **container**: defines the sidecar container need to be injected.
* **volumeMounts**: defines the new volumeMounts or overwrite the old volumeMounts of each containers in target pods.
* **volume**: defines the new volumes for the target pod or overwrite the old volumes in target pods.
* **postStart**: called after a container is created first. If the handler fails, the containers will failed.

> **Note:**
>
> Chaos controller-manager only watches template config map with the label selector specified by its flag `--template-labels`, by default this label
> is `app.kubernetes.io/component=template` if your Chaos Mesh is deployed by helm.
>
> Each template config map should be deployed in the same namespace as Chaos Mesh, and it is identified by the name of the config map, which is `chaosfs-sidecar` in the above example.
>
> The template config content should be in the `data` field. This means it is not possible to define two templates in one config map, you have to use two config maps like the example below.

```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: chaosfs-sidecar0
  labels:
    app.kubernetes.io/component: template
data:
  data: |
    xxxx

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: chaosfs-sidecar1
  labels:
    app.kubernetes.io/component: template
data:
  data: |
    xxxx
```

### Containers

#### `chaosfs`

`chaosfs` container is designed as a sidecar container and [chaosfs](https://github.com/chaos-mesh/chaos-mesh/tree/master/cmd/chaosfs) process runs in this container.

`chaosfs` uses [fuse libary](https://github.com/hanwen/go-fuse) and [fusermount](https://www.kernel.org/doc/Documentation/filesystems/fuse.txt) tool to implement a fuse-daemon service and mounts the application's data directory. `chaosfs` hijacks all the file system IO actions of the application, so it can be used to simulate various real-world IO faults.

The following configuration injects `chaosfs` container to the target pods and starts a `chaosfs` process in this container.

In addition, `chaosfs` container should be run as `privileged` and the [`mountPropagation`](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation) field in `chaosfs` Container.volumeMounts should be set to `Bidirectional`.

`chaosfs` uses `fusermount` to mount the data directory of the application container in `chaosfs` container.

If any Pod with `Bidirectional` mount propagation to the same volume mounts anything there, the Container with `HostToContainer` mount propagation will see it.

This mode is equal to `rslave` mount propagation as described in the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt).

More detail about `Mount propagation` can be found [here](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation).

```yaml
containers:
- name: chaosfs
  image: pingcap/chaos-fs
  imagePullpolicy: Always
  ports:
  - containerPort: 65534
  securityContext:
    privileged: true
  command:
    - /usr/local/bin/chaosfs
    - -addr=:65534
    - -pidfile=/tmp/fuse/pid
    - -original=/var/lib/tikv/fuse-data
    - -mountpoint=/var/lib/tikv/data
  volumeMounts:
    - name: tikv
      mountPath: /var/lib/tikv
      mountPropagation: Bidirectional
```

Description of `chaosfs`:

* **addr**: defines the address of the grpc server, default value: ":65534".
* **pidfile**: defines the pid file to record the pid of the `chaosfs` process.
* **original**: defines the fuse directory. This directory is usually set to the same level directory as the application data directory.
* **mountpoint**: defines the mountpoint to mount the original directory.

This value should be set to the data directory of the target application.

#### `chaos-scripts`

`chaos-scripts` container is used to inject some scripts to the target pods including [wait-fuse.sh](https://github.com/chaos-mesh/chaos-mesh/blob/master/hack/wait-fuse.sh).

`wait-fuse.sh` is used by application container to ensure that the fuse-daemon server is running normally before the application starts.

`chaos-scripts` is generally used as an initContainer to do some preparations.

The following config uses `chaos-scripts` container to inject scripts and moves the scripts to `/tmp/scripts` directory using `init.sh`. `/tmp/scripts` is an [emptyDir volume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) used to share the scripts with all containers of the pod.

So you can use `wait-fuse.sh` script in tikv container to ensure that the fuse-daemon server is running normally before the application starts.

In addition, `init.sh` creates a directory named `fuse-data` in the [PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) directory of the tikv as the original directory for fuse-daemon server and the original directory is required.

You should also create the original directory in the PersistentVolumes directory of the application.

```yaml
initContainers:
  - name: inject-scripts
    image: pingcap/chaos-scripts:latest
    imagePullpolicy: Always
    command: ["sh", "-c", "/scripts/init.sh -d /var/lib/tikv/data -f /var/lib/tikv/fuse-data"]
```

The usage of `init.sh`:

```bash
$ ./scripts/init.sh -h
USAGE: ./scripts/init.sh [-d data directory] [-f fuse directory]
Used to do some preparation
OPTIONS:
   -h                      Show this message
   -d <data directory>     Data directory of the application
   -f <fuse directory>     Data directory of the fuse original directory
   -s <scripts directory>  Scripts directory
EXAMPLES:
   init.sh -d /var/lib/tikv/data -f /var/lib/tikv/fuse-data
```

### Tips

1. The application Container.volumeMounts used to define data directory should be set to `HostToContainer`.
2. `scripts` and `fuse` emptyDir should be created and should be mounted to all container of the pod.
3. The application uses `wait-fuse.sh` script to ensure that the fuse-daemon server is running normally.

```yaml
postStart:
  tikv:
    command:
      - /tmp/scripts/wait-fuse.sh
```

The usage of `wait-fuse.sh`:

```bash
$ ./scripts/wait-fuse.sh -h
./scripts/wait-fuse.sh: option requires an argument -- h
USAGE: ./scripts/wait-fuse.sh [-a <host>] [-p <port>]
Waiting for fuse server ready
OPTIONS:
   -h                   Show this message
   -f <host>            Set the target file
   -d <delay>           Set the delay time
   -r <retry>           Set the retry count
EXAMPLES:
   wait-fuse.sh -f /tmp/fuse/pid -d 5 -r 60
```

repository: AngleNet/chaos-mesh

repo_name: AngleNet/chaos-mesh