text:
---
title: "Minimum Maven"
date: "2020-04-15"
featuredImage: "../images/maven.png"
---
No one ever chooses to start working with Apache Maven - it's one of those things you get stuck with because of factors outside your control. I think Maven is probably one of the most frustrating aspects for people moving over to the Java world - the errors are cryptic, the documentation is dry, and the whole thing just seems way more complicated than it should be. I think part of the problem is that most people's first encounter with Maven is when they start working on an existing project, with an existing Maven config that has lots of moving parts. It's a lot to take in at once. In this post I'm going to try and keep it simple. I'll give a bit of background on Maven and talk about the absolute minimum Maven project you could create.

## Why is Maven so complicated?
If you come from a Python background, turning java code into a running application can seem a lot more effort than it needs to be. Part of this is because Java makes fewer assumptions about the environment it is going to run in - this means that you need to supply this information when building the the app.

Maven was created as a way of simplifying and standardising the way that this build information is specified. The most obvious benefit it provides is package management - automatically pulling the libraries you need from the web - but that is only part of what it does. Maven provides a very flexible way of packaging code up so it can be used elsewhere. It can be used to build desktop applications, components that run as part of a web-service, android applications, and all sorts of other forms of applications. It can be used to compile Scala, Clojure, different versions of java than the one running. It can run your unit tests and deploy your artefacts to remote locations.

Maven achieves this flexibility by having most components implemented as plugins. When you configure it you specify which plugins to use and how each of *those* plugins are configured in turn. The two main plugins you will encounter are the **compiler** plugin and the **surefire** - the unit-test plugin.

## Configuring a Maven Project
Maven is configured using a file called `pom.xml`. When you run the `mvn` command, it will automatically load this file and use it. For full details of the contents of `pom.xml` please see [this document](http://maven.apache.org/pom.html). It's well worth the read and contains exciting words like "Jarmageddon".

### Minimum Config
According to the link above, the the absolute minimum you can have in your `pom.xml` is:
* `modelVersion` - This specifies the type of POM you are using, it **has** to be `4.0.0`. Don't confuse this with the version of your project.
* `groupId` - Some unique group that this project belongs to. This doesn't have to have any relationship to your java packages (it doesn't even need to be dot notation) but it helps if they are similar.
* `artifactId`- The name of your project.
* `version` - The version number of your project.

The `groupId`, `artifactId`, `version` values are referred to as the Maven Coordinates of the project. They are the values that people will use to locate your project if you release it into the wild - they're like latitude and longitude for software components.

Here is a complete, minimal `pom.xml`.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                        http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>io.github.bwalshe</groupId>
    <artifactId>mini-project</artifactId>
    <version>1.0</version>
</project>
```

It's pretty useless, but you could actually get this to package up a project, provided you have no dependencies and you are OK with the default settings for all of your Maven plugins.

## Packaging a project
For a laugh, let's try using the minimal config to package up a very simple project. By default, Maven's compiler plugin will expect your source files to be under `src/main/java` and your test files to be under `src/test/java` - which is pretty reasonable. It's also going to expect them to be Java 5 - which is pretty unreasonable. If there are no issues with the compilation, the build process moves on to the test phase which is handled by the Surefire plugin.

Surefire is going to run every function that starts with the word "test", in any class in the test directory that contains the word "Test", and will stop the build process if any of these functions throw an exception. If there are no issues with the tests then the Jar plugin will package all of the classes in the main directory into a `.jar` file.

OK, set your files up with the following structure:
```
.
├── pom.xml
└── src
    ├── main
    |   └── java
    |       └── HelloWorld.java
    └── test
        └── java
            └── DummyTest.java
```

In the file `HelloWorld.java` paste the following:
```java
public final class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}
```

In the file `DummyTest.java`, copy in the following:
```Java
public class DummyTest {
    public void testOne() {
        System.out.println("This test does nothing.");
    }
    public void testTwo() {
        System.out.println("This test also does nothing.");
    }
}
```

Let's run it...

```bash{height: 200px; overflow: scroll}
brian@DESKTOP:~/maven_mini_example$ mvn package
...
```

I actually got an error here. I have OpenJDK 11 on my system, and that won't compile anything earlier than Java 6. Maven's default is to compile Java 5, so they're not going to work together. The correct thing would be to set the Java version on the Maven compiler plugin, but I don't want to touch that just now, so let's just use OpenJDK 8 temporarily.

```
brian@DESKTOP:~/maven_mini_example$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn package
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building mini-example 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
...
...
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running DummyTest
This test does nothing.
This test also does nothing.
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mini-example ---
[INFO] Building jar: /home/brian/maven_mini_example/target/mini-example-1.0.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.523 s
[INFO] Finished at: 2020-04-15T22:39:32+01:00
[INFO] Final Memory: 17M/304M
[INFO] ------------------------------------------------------------------------
```

That was pretty verbose (I left out a few of the more boring lines) but you can see that after compiling everything, it ran both of our tests which just printed some text to the console. They didn't really test anything, but they didn't throw any exceptions - so as far as the Surefire plugin is concerned, they were fine.

After running the tests without any failures, you can see that a file named `mini-example-1.0.jar` was produced in the `target` directory. Note that the name of the jar file is a combination of the `artifactId` and `version` values we set in the POM.

Let's see what the jar contains...

```
brian@DESKTOP:~/maven_mini_example$ jar tf target/mini-example-1.0.jar
META-INF/
META-INF/MANIFEST.MF
HelloWorld.class
META-INF/maven/
META-INF/maven/org.codehaus.mojo/
META-INF/maven/org.codehaus.mojo/mini-example/
META-INF/maven/org.codehaus.mojo/mini-example/pom.xml
META-INF/maven/org.codehaus.mojo/mini-example/pom.properties
```

There are a lot of extra files in there, but among them you should be able to see `HelloWorld.class`. We can run it from the jar
```
brian@DESKTOP:~/maven_mini_example$ java -cp target/mini-example-1.0.jar HelloWorld
Hello World!
```
We could have also just run the tests or run the `HelloWorld` class directly using Maven without having to package it, but this is something I will have to cover in another article.

## Summary
The only information that you **have** to give to Maven is the `groupId`, `artifactId` and `version` of your project. Everything else needed to package up a project has a default value, but it's almost certain that you will want to change those defaults. You will at least want to change the Java standard being used, and probably add some dependencies. (I didn't do that in this article.)

When you package a project, by default Maven goes through several phases. These include:
* Compiling the source code
* Running the test cases
* Packaging the classes into a jar

If any of the phases fails then the build process stops. Also, you don't have to run all the phases, you could just compile or run the tests.


text:
can you add additional validation with the fluent API?
how could you validate nested objects (Customer > Address) - examples or how do you nest configs?
if no reporter is passed around you could just pull it from the object validated object using ValidationEngine or something
make sure the underlying properties are not enumerable

1. add notes to the blog post - initial release without complex binding / rendering
1. plan for release the following week with better bindingBehavior

possible to have a single binding behavior that pulls in the renderer from the container instead of explicitly having it used and having to share the logic around
  a. register a global renderer
  b. rename the binding behavior to validate
  c. get the reporter and the renderer from DI

infer the reporter from source.bindingContext and add a note to the blog post to explain that isn't needed long term but just for now.

Can use getContextFor(source, propName); to get the object.

let obj = { first: '' };

let validator = new Validator(obj);

validator(obj).ensure('first').required();

validator(obj).validate();

let two = class Person {
  @required firstName;
}

this.validator = new Validator(two).validate();

license: MIT

repository: enanglaw/Clients

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: enanglaw/Clients


text:
# Arguments

This simple program focuses on the [**arguments**][ar] object that is passed to JavaScript functions.

This object is "array-like", but it is not an array. It does, however, have a **length** property.

[ar]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments

repository: charliecalvert/JsObjects

gha_language: JavaScript

gha_license_id: NOASSERTION

repo_name: charliecalvert/JsObjects


text:
# s2i-wildfly
WildFly Source To Image for OpenShift

# Build Image

`docker build -t airhacks/s2i-wildfly .`


text:
# Test requirements

We want you to create a simple CRUD application that will consume an Api Stub (Instructions Below).

- Please spend no more than 2 hours on the task (from first to last commit). We don’t mind if you don’t finish the app, We’re more focussed on code quality
- We’re looking for small and clear commits
- Unit testing IS A MUST

As a general consideration please follow SPA best practices.

Good luck!

## Build System

`Webpack` handles all file-related concerns:
* Transpiling from ES6 to ES5 with `Babel`
* Loading HTML files as modules
* Transpiling stylesheets and appending them to the DOM
* Refreshing the browser and rebuilding on file changes
* Hot module replacement for transpiled stylesheets
* Bundling the app
* Loading all modules
* Doing all of the above for `*.spec.js` files as well

`Gulp` is the orchestrator:
* Starting and calling Webpack
* Starting a development server (yes, Webpack can do this too)
* Generating boilerplate for the Angular app

## Getting Started

### Dependencies
Tools needed to run this app:
* `node` and `npm` (We recommend node v4+)
Once you have these, install the following as globals:
`npm install -g gulp karma karma-cli webpack json-server`

### Installing
* `npm install -g gulp karma karma-cli webpack json-server` install global cli dependencies
* `npm install` to install dependencies

### Starting the App
* `gulp serve` to start the app.
* Navigate to `http://localhost:8080/`

## Testing Setup
All tests are also written in ES6. We use Webpack to take care of the logistics of getting those files to run in the various browsers, just like with our client files. This is our testing stack:
* Karma
* Webpack + Babel
* Mocha
* Chai

To run tests, type `npm test` or `karma start` in the terminal.

## Stub API
We have created a stub api for you to perform REST api calls.

### Getting started
- Start API stub `npm run stubapi`
- Navigate to `http://localhost:3000/`

### API endpoints
- `/api/accounts/create`
- `/api/accounts/all`
- `/api/accounts/delete/:id`
- `/api/accounts/update/:id`

repository: elroyantao/crud

repo_name: elroyantao/crud


text:
# msgCodeChallenge
My entry for the msg get_in_it challenge

HOW TO RUN:

1. Download and unzip the project
2. Open Project using VISUAL STUDIO
3. Run Solution
4. Result should appear in a console window

Algorithm used: Nearest Neighbour

HOW IT WORKS:
1. Read the .CSV file and store it as string array.
2. Left shift the array to remove the first line, which we don't need.
3. Transform the data to a XML format for easier processing of the data.
4. Extract the destination name and coordinates. We dont need anything else.
5. Assuming that you can travel from any city to any other; we have to calculate all possible distances between every single city.
6. Store the distance information in a 2d matrix (21x21)
7. Solve the Traveling Salesman Problem using the "Nearest Neighbour" approach.

repository: BCuracao/travelling-salesman-solution

repo_name: BCuracao/travelling-salesman-solution


text:
# atom

> A cross-platform pluggable text editor.
> Plugins are managed by `apm`.

- Open a file or folder:

`atom {{path/to/file/or/folder}}`

- Open a file or folder in a new window:

`atom -n {{path/to/file/or/folder}}`


text:
---
layout: page
title: Courses
permalink: "courses.html"
---

### Fall 2021 (upcoming)
- Math 142 Calculus 2
- Math 550 Real Analysis

### Spring 2021

- Math 350 Mathematical Software
	- Course page (videos, homework, notes): [Math 350](https://rtullydo.github.io/math350/)

### Winter 2021

- Math 344 Linear Analysis 2
	- video lectures: [YouTube playlist](https://www.youtube.com/watch?v=_ZBXYHb38lQ&list=PLd-yyEHYtIhKhXrzklfwupcbfe_LCcfoV)

### Fall 2020

- Math 142 Calculus 2
	- video lectures: [YouTube playlist][1]

### Previous courses:

- Math for Liberal Arts
- Modern Geometry
- Precalculus
- Calculus (year sequence)
- Multivariate Calculus
- Vector Calculus
- Differential Equations
- Real Analysis
- Graduate Real Analysis
- Linear Algebra (year sequence)
- Advanced Linear Algebra
- Modern Algebra
- Discrete Math and Combinatorics
- Mathematical Cryptography
- Elementary Statistics
- Probability and Statistics for Engineers
- Probability and Statistics (year sequence)
- Mathematical Modeling
- Advanced Mathematical Modeling
- Numerical Analysis
- Mathematical Programming

[1]:<https://www.youtube.com/watch?v=FkNEW2BmSpw&list=PLd-yyEHYtIhLDzn9d4wt4-SUCi-NAopmf>


text:
---
layout: page
title: Finding Example Source Code
---

Often time to solve a problem, you just need to adapt someone else's solution.
There's no shame in doing so: it saves time, teaches you new methods, and is
arguably the way culture and technology evolve.

Besides typical public resources like [Stack Overflow](https://stackoverflow.com),
UCD specific source code can be found at [github.com/ucdavis](https://github.com/ucdavis)
and BitBucket. You should also feel free to ask for example source code from your
colleagues.

Notably, there is the UCD project registry found on this website. It will enable you
to see some projects for whom source code has been published and is cross-referenced by
relevant tags such as whether a project uses CAS, Banner, LDAP, etc. This will help
you find what you're looking for quickly.

repository: ucdavis/appdev

branch_name: refs/heads/gh-pages

gha_language: SCSS

gha_license_id: MIT

repo_name: ucdavis/appdev


text:
---
title: mv
version: 0.66.1
usage: |
  Move files or directories.
---

# {{ $frontmatter.title }}

{{ $frontmatter.usage }}

## Signature

```> mv (destination) ...source(s) --verbose --interactive```

## Parameters

 -  `destination`: the location to move files/directories to
 -  `...source(s)`: the location(s) to move files/directories from
 -  `--verbose`: make mv to be verbose, showing files been moved.
 -  `--interactive`: ask user to confirm action

## Examples

Rename a file
```shell
> mv before.txt after.txt
```

Move a file into a directory
```shell
> mv test.txt my/subdirectory
```

Move many files into a directory
```shell
> mv *.txt my/subdirectory
```

branch_name: refs/heads/main


text:
---
title: Editor and IDE Support
kind: misc
weight: 2
---

OPA can be integrated into editors and IDEs to provide features like syntax highlighting, query
evaluation, policy coverage, and more.

## Integrations

> Note: See each integration for what features are supported! Not all support the same features.

| Editor | Link |
| --- | --- |
| Atom | [https://github.com/open-policy-agent/opa/tree/main/misc/syntax/atom](https://github.com/open-policy-agent/opa/tree/main/misc/syntax/atom) |
| Emacs | [https://github.com/psibi/rego-mode](https://github.com/psibi/rego-mode) |
| IntelliJ IDEA | [https://github.com/open-policy-agent/opa-idea-plugin](https://github.com/open-policy-agent/opa-idea-plugin) |
| Nano | [https://github.com/scopatz/nanorc](https://github.com/scopatz/nanorc) |
| Sublime Text | [https://github.com/open-policy-agent/opa/tree/main/misc/syntax/sublime](https://github.com/open-policy-agent/opa/tree/main/misc/syntax/sublime) |
| TextMate | [https://github.com/open-policy-agent/opa/tree/main/misc/syntax/textmate](https://github.com/open-policy-agent/opa/tree/main/misc/syntax/textmate) |
| Vim | [https://github.com/tsandall/vim-rego](https://github.com/tsandall/vim-rego) |
| Visual Studio Code | [https://marketplace.visualstudio.com/items?itemName=tsandall.opa](https://marketplace.visualstudio.com/items?itemName=tsandall.opa) |

## Rego Playground

The Rego Playground provides a great editor to get started with OPA and share policies. Try it out at [https://play.openpolicyagent.org/](https://play.openpolicyagent.org/)

repository: open-policy-agent/opa

gha_language: Go

repo_name: open-policy-agent/opa


text:
# Pipelines Model (aka Manifest)

The Pipelines Model represents an inventory of _Environments_, _Applications_ and _Services_ within a GitOps setup.  This model allows tools to perform operations on GitOps setup without the needs for querying cluster resources which is often hard if not impossible to do.  The actual execution of operations is driven by Git PullRequests.  In other words, tools generate or update resources to be pushed to Git.

Within a GitOps setup, there can be many [Environments](#Environment), [Applications](#Application), and [Services](#Service).  The following diagram shows the structure of the Pipelines Model.

![Manifest Model](img/pipelines_model.png)

Pipelines Model is defined in a yaml file.  Here is an example pipelines.yaml

```yaml
config:
  argocd:
    namespace: argocd
  pipelines:
    name: cicd
environments:
- apps:
  - name: app-taxi
    services:
    - name: taxi
      pipelines:
        integration:
          bindings:
          - dev-app-taxi-taxi-binding
          - gitlab-push-binding
      source_url: https://gitlab.com/rhd-example-gitops/taxi.git
      webhook:
        secret:
          name: webhook-secret-dev-taxi
          namespace: cicd
  name: dev
  pipelines:
    integration:
      bindings:
      - gitlab-push-binding
      template: app-ci-template
- name: stage
gitops_url: https://github.com/<your organization>/<your repository>
```

## Environment

There are three types of Environments
* CI/CD Environment
* ArgoCD Environment
* (Plain old) Environment

### CI/CD Environment

The CI/CD Environment is a special Environment that contains CI/CD pipelines.  These pipelines respond to changes in GitOps configuration repository and Application/Service soruce repositories.  They are responisble for keeping the resources in the cluster in-sync with the configurations in Git and re-build/re-deploy application/service images.

### ArgoCD Environment

ArgoCD is used to perform Continuous Delivery of Applications.  When an Application is created in the target Environment an ArgoCD application is also created and kept in the ArgoCD Environment.  The user is reponsible for creating deployment.yaml in the "config" folder for the application.  ArgoCD will deploy the application based on the user-provided deployment specification and re-deploy it automatically when the specification is changed.

### (Plain Old) Enviroment

Within a Pipelines Model, there are many Environments which hold Applications and Services.  Each Environment has its own namespace.

## Application

An Application is a logical grouping of Services.  It contains references to Services.  When an Application is deployed, all referenced Services are deployed.  Two Applications can reference to a same Service.  Each Application can have specific customization to the Service it references/deploys.  A Service is not intendedto  be deployed by itself (without an Application).

## Service

A Service can have a source repository and an image repository.  Services are unique within an Environment.  However, no two Services can share a same source Git reposiotry even though they belong to different Environments.

## GitOps Repository

A GitOps repository is just a Git repository organized to be used with GitOps tools. It organizes the Environments, Applications, and Services with any customization necessary for deployment.

Different Environments are stored in different directories under the `environments/` directory in the GitOps repository. Configuration in is then separated into layers reflected by these sub-directories:

- `env/` - Configuration specific to the namespace / Environment.
- `apps/*` - Configuration folders specific to each Application.
- `services/*` - Configuration folders specific to each Service.

Each configuration directory will contain Kustomization files structured like this:

```
.
├── base
│   ├── *.yaml
│   └── kustomization.yaml
└── overlays
    ├── *.yaml
    └── kustomization.yaml
```

Each Service is defined in its `.../services/<service-name>/base/` directory in various YAML files, and its `overlays/` directory includes more specific details such as pod scaling and environment variables. The configuration of each service can be maintained by just a development team, and should be individually deployable with a `kubectl apply -k ` command, which allows for quick testing.

Each Application’s `.../apps/<app-name>/base/kustomization.yaml` will refer to each Service which it uses. Again, the `overlays/` directory will include new specific configuration files required for the application, for example new labels or other details to connect the services.

Finally, the `.../env/base/kustomization.yaml` will refer to each application which is to be deployed in the environment, and the `env/overlays/` directory will contain any specifics required for the environment. For example, details about service accounts and specific Ingress URLs could be specified here. It will also have a `.../env/kustomization.yaml` file so that the fully-configured applications can be deployed into the environment with this command:

```shell
$ oc apply -k environments/<env-name>/env/
```

repository: bonomali/kam

repo_name: bonomali/kam


text:
---
title: "The implications of the 2012 minimum wage rise on the Mexican labour market"
author: Jorge Bouchot
header:
  teaser: "https://farm5.staticflickr.com/4076/4940499208_b79b77fb0a_z.jpg"
  caption: "Photo credit: [**Unsplash**](https://unsplash.com)"
categories:
  - Seminars
  - PhD
  - Talks
tags:
  - Minimum Wage
  - Informal Employment
  - Distribution of Earnings
---

Jorge Bouchot, four year PhD student in Economics, talked about
"The implications of the 2012 minimum wage rise on the Mexican labour market"

His presentation is available [here](https://github.com/MexicanSocietyUoB/seminars/blob/master/assets/slides/jbouchot112017/slides.pdf)

## Abstract

## Author

Jorge Bouchot is originally from Pachuca, Hidalgo, Mexico.
He received her bachelor degree in Economics at Universidad Autonoma de Hidalgo
and his masters degree at El Colegio de Mexico. He is mainly interested in
evaluation of social programs. Jorge is currently doing a PhD in Economics
under the supervision of
[Anindya Banerjee](https://www.birmingham.ac.uk/staff/profiles/business/banerjee-anindya.aspx)
and [Marco Ercolani](https://www.birmingham.ac.uk/staff/profiles/business/ercolani-marco.aspx)
Additionally to that, he is enthusiastic about labour economics and economic development
and his doctoral dissertation has been awarded with two prizes in Mexico:
the Citibanamex National Prize in Economics, 2016, and the National Prize in
Economic Research Víctor L. Urquidi, 2016.

repository: MexicanSocietyUoB/seminars

repo_name: MexicanSocietyUoB/seminars


text:
# file-fetch

`file-fetch` is a [nodeify-fetch](https://www.npmjs.com/package/nodeify-fetch) compatible fetch for read and write access to the local file system using `file://` URLs.

## Usage

Only the URL is required to read a file:

```
const fileFetch = require('file-fetch')

fileFetch('file://etc/hosts').then((res) => {
  res.body.pipe(stdout)
})

```

To write files the method `PUT` must be used and readable stream must be given as body:

```
fileFetch('file://tmp/example.log', {
  method: 'PUT',
  body: stream
})
```

gha_language: HTML


text:
# Flutter Mimic

## Features

All the *.dart files and/or folders that you create/rename/move in test or lib folder will be mirrored in the other.

Limitations:
It only mimics .dart files and folders, it wont work with any other extension file. This is a open-source project so feel free to
extend and change this behaviour.

**ATTENTION: Only for *.dart files and folders**

Deletion, i choose not to automatic delete. So for deletion you have to do it all by hand. This is to avoid, accidental
deletions of test suites.

## Known Issues

I didnt find a way to identify directories by some sort of concrete type, so folders are identified by not having a
extension (example "*.mp4"). Dont know if this can cause any issue, but avoid using dots on folder names.

## Release Notes

Users appreciate release notes as you update your extension.

### 1.0.0

Mimics *.dart files in folders lib and test

-----------------------------------------------------------------------------------------------------------

### LICENSE

Copyright <2021> <COPYRIGHT ItzBala>

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

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

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


text:
# Algorithms and Data Structures in Kotlin

This project is a collection of code samples and wiki articles on basic data structures and algorithms that are created
using Kotlin. This project is useful if you are trying to get more fluency in Kotlin or need a refresher to do interview
prep for software engineering roles.

1. I strongly recommend reading my tutorials on [developerlife.com](https://developerlife.com/category/CS/) that are
   based on the code that's provided in this repo. These tutorials are a great companion to the source code in this repo
   and will help you understand the code and the algorithms.
2. Once you’ve cloned the repo, type `./gradlew run` in order to build and run this project from the command line.
3. This project uses the`classgraph` API to load all the classes in the `algorithms` package. You can read more about it
   [here](https://github.com/classgraph/classgraph/wiki).

## Screen capture of project in action

## Change master to main (2020-06-27)

The
[Internet Engineering Task Force (IETF) points out](https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1)
that "Master-slave is an oppressive metaphor that will and should never become fully detached from history" as well as
"In addition to being inappropriate and arcane, the
[master-slave metaphor](https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask?WT.mc_id=-blog-scottha#L231-L232)
is both technically and historically inaccurate." There's lots of more accurate options depending on context and it
costs me nothing to change my vocabulary, especially if it is one less little speed bump to getting a new person excited
about tech.

You might say, "I'm all for not using master in master-slave technical relationships, but this is clearly an instance of
master-copy, not master-slave"
[but that may not be the case](https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html). Turns out the
original usage of master in Git very likely came from another version control system (BitKeeper) that explicitly had a
notion of slave branches.

- https://dev.to/lukeocodes/change-git-s-default-branch-from-master-19le
- https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

[#blacklivesmatter](https://blacklivesmatter.com/)

repository: nazmulidris/algorithms-in-kotlin

gha_language: Kotlin

repo_name: nazmulidris/algorithms-in-kotlin


text:
# FEZ Cerb40
---
![FEZ Cerb40](images/fez-cerb40.jpg)

DIP40 form factor board. Not really a Gadgeteer board but it is very small!

* [Schematic](http://files.ghielectronics.com/downloads/Schematics/FEZ/FEZ%20Cerb40%20Rev%201.1%20Schematic.pdf)

# FEZ Cerb40 II
![FEZ Cerb40](images/fez-cerb40_II.jpg)

Same as the FEZ Cerb40 with an added regulator chip.

* [Schematic](http://files.ghielectronics.com/downloads/Schematics/FEZ/FEZ%20Cerb40%20II%20Rev%202.0%20Schematic.pdf)

repository: ghi-electronics/Docs

branch_name: refs/heads/dev

gha_language: Makefile

repo_name: ghi-electronics/Docs


text:
# count_files

* count_files.sh
1) [find . -type f -o -type d] will output the name of the matched files, line by line.
2) [wc -l] will count the number of lines.
3) [tr -d ' '] will delete any space.
```
find . -type f -o -type d | wc -l | tr -d ' '
```


text:
# Contributing

We'd love for you to contribute to gitlint. Thanks for your interest!
Sometimes it takes a while for [me](https://github.com/jorisroovers) to get back to you (sometimes up to a few months,
this is a hobby project), but rest assured that we read your message and appreciate your interest!
We maintain a [wishlist on our wiki](https://github.com/jorisroovers/gitlint/wiki/Wishlist),
but we're obviously open to any suggestions!

# Guidelines

When contributing code, please consider all the parts that are typically required:

- [Unit tests](https://github.com/jorisroovers/gitlint/tree/master/gitlint/tests) (automatically
  [enforced by Travis](https://travis-ci.org/jorisroovers/gitlint)). Please consider writing
  new ones for your functionality, not only updating existing ones to make the build pass.
- [Integration tests](https://github.com/jorisroovers/gitlint/tree/master/qa) (also automatically
  [enforced by Travis](https://travis-ci.org/jorisroovers/gitlint)). Again, please consider writing new ones
  for your functionality, not only updating existing ones to make the build pass.
- [Documentation](https://github.com/jorisroovers/gitlint/tree/master/docs)

Since we want to maintain a high standard of quality, all of these things will have to be done regardless before code
can make it as part of a release. If you can already include them as part of your PR, it's a huge timesaver for us
and it's likely that your PR will be merged and released a lot sooner. Thanks!
# Development #

There is a Vagrantfile in this repository that can be used for development.
```bash
vagrant up
vagrant ssh
```

Or you can choose to use your local environment:

```bash
virtualenv .venv
pip install -r requirements.txt -r test-requirements.txt -r doc-requirements.txt
python setup.py develop
```

To run tests:
```bash
./run_tests.sh                       # run unit tests and print test coverage
./run_test.sh gitlint/tests/test_body_rules.py::BodyRuleTests::test_body_missing # run a single test
./run_tests.sh --no-coverage         # run unit tests without test coverage
./run_tests.sh --integration         # Run integration tests (requires that you have gitlint installed)
./run_tests.sh --build               # Run build tests (=build python package)
./run_tests.sh --pep8                # pep8 checks
./run_tests.sh --stats               # print some code stats
./run_tests.sh --git                 # inception: run gitlint against itself
./run_tests.sh --lint                # run pylint checks
./run_tests.sh --all                 # Run unit, integration, pep8 and gitlint checks
```

The ```Vagrantfile``` comes with ```virtualenv```s for python 2.6, 2.7, 3.3, 3.4, 3.5, 3.6 and pypy2.
You can easily run tests against specific python environments by using the following commands *inside* of the Vagrant VM:
```
./run_tests.sh --envs 26               # Run the unit tests against Python 2.6
./run_tests.sh --envs 27,33,pypy2      # Run the unit tests against Python 2.7, Python 3.3 and Pypy2
./run_tests.sh --envs 27,33 --pep8     # Run pep8 checks against Python 2.7 and Python 3.3 (also works for ```--git```, ```--integration```, ```--pep8```, ```--stats``` and ```--lint```).
./run_tests.sh --envs all --all        # Run all tests against all environments
./run_tests.sh --all-env --all         # Idem: Run all tests against all environments
```

!!! important
    Gitlint commits and pull requests are gated on all of our tests and checks.

# Packaging #

To see the package description in HTML format
```
pip install docutils
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
python setup.py --long-description | rst2html.py > output.html
```

# Documentation #
Outside the vagrant box (on your host machine):
```bash
mkdocs serve
```

Then access the documentation website on your host machine on [http://localhost:8000]().
Note that this is only supported for python >= 2.7.

repository: byrney/gitlint

repo_name: byrney/gitlint


text:
# Dataset Specification

Dataset is an important part of machine learning. Subsequent models are built based on datasets. We need to manage datasets. The following is the standard format of the dataset that Pipcook should save after the data is collected through the `datasource` script.

For different dataset formats, `datasource` script is used to smooth the differences.

#### Image

PascalVOC Dataset format, the detailed directory is as follows:

```
📂dataset
   ┣ 📂annotations
   ┃ ┣ 📂train
   ┃ ┃ ┣ 📜...
   ┃ ┃ ┗ 📜${image_name}.xml
   ┃ ┣ 📂test
   ┃ ┗ 📂validation
   ┗ 📂images
     ┣ 📜...
     ┗ 📜${image_name}.jpg
```

Or representing in XML:

```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<annotation>
  <folder>folder path</folder>
  <filename>image name</filename>
  <size>
    <width>width</width>
    <height>height</height>
  </size>
  <object>
    <name>category name</name>
    <bndbox> <!--this is not necessary for image classification problem-->
      <xmin>left</xmin>
      <ymin>top</ymin>
      <xmax>right</xmax>
      <ymax>bottom</ymax>
    </bndbox>
  </object>
</annotation>
```

#### Text

The text category should be a CSV file. The first column is the text content, and the second column is the category name. The delimiter is ',' without a header.

```csv
name, category
prod1, type1
prod2, type2
prod3, type2
prod4, type1
```

repository: alibaba/pipcook

gha_language: TypeScript

repo_name: alibaba/pipcook


text:
---
Lay Out: Post
Tittle: Why to adopt a cat.
---

![Cats for Adoption](/images/kitten.jpg)

## Cat Adoption

Why cats are better to adpot is not that really hard to think about. Cats are nice and sweet animals that are easy to take care of. All cats do is sleep, eat, and play. But unlike any other animal you don't need expensive toys, all you need is a peice of string or something like that.  And you can find your purr-fect cats here at this link. [Cat Adoption](https://www.adoptapet.com/cat-adoption)


text:
# Serialization
## "What the standard library for C++11 is missing."
Serialization is a small serialization library I use for small projects, which leverages the C++11 standard library. Serialization applies a good spin on serialization encapsulating all of the pointer arithematic used in traditional serialization.

## Introduction
Serialization is easey to use:
```C++
void function_to_serialize() {
    ByteArray array;
    ByteStream stream(&array, OpenMode::ReadWrite);
    int i = 1;
    int j = 6;

    stream << 1;
    stream << 6;
}
```

## Build
Serialization is a simple library, there are no dependencies! It's a cmake3 build system too. So you've got two easy choices for building:

### In-Source Build

An in-source build does just that, it builds the project in the source directory. It's pretty easy to do with the following steps

```
cd {project_root_directory}
cmake .
make
```

That's it the binaries and libraries will be built in place, and not installed yet. We'll cover installation later.

### Out-of-Source Build

An out-of-source build will generate your Makefiles and binaries outside the source directory in a directory of your choice.
I like this build option more, it keeps things neat and clean, and it's pretty easy to rm -rf you build directory, and nuke your current build. You can do this with the following steps.

```
mkdir build
cd build
cmake {path_to_source_directory}
make
```

You can place the build directory wherever you'd like, and you can name it whatever you like, I generally choose build, because that's what it is; It's a build. Keep it simple.

## Installation

Just run make install, its that easy

```
cd {directory_where_your_build_is}
sudo make install
```

## Building Documentation

In source doxygen documentation can be found in serialization. You can build it by installing Doxygen, and running the below command

```
cd {directory_where_your_build_is}
make doc
```

### Comments

If anyone has any comments, please feel free to ask away. I'll try to answer them the best I can.

repository: HaasCM/serialization

repo_name: HaasCM/serialization


text:
# POTENTIOMETRIC DIGITAL-TO-ANALOG CONVERTER
The project aims to design a 10-bit Potentiometric Digital to Analog Converter using end-to-end Open-source EDA tools.
The target is to design 10-bit potentiometric DAC with 3.3v analog voltage, 1.8v digital voltage and 1 off-chip external voltage reference using sky130nm technology node.
## Table of Content
- [1.Purpose of Digital to Analog Converter (DAC)](#1purpose-of-digital-to-analog-converter-dac)
- [2.IP Block Design Specifications](#2ip-block-design-specifications)
     - [IP Block Diagram](#ip-block-diagram)
     - [Terminal Functions](#terminal-functions)
- [3.EDA tools used to implement Potentiometric DAC](#3eda-tools-used-to-implement-potentiometric-dac)
-	[4.Implementation of 10Bit Potentiometric DAC](#4implementation-of-10bit-potentiometric-dac)
-	[5.Pre-layout Designs and Simulations](#5pre-layout-designs-and-simulations)
    -	[Switch design and simulation](#switch-design-and-simulation)
    -	[2-Bit DAC design and simulation](#2-bit-dac-design-and-simulation)
    -	[3-Bit DAC design and simulation](#3-bit-dac-design-and-simulation)
    -	[4-Bit DAC design and simulation](#4-bit-dac-design-and-simulation)
    -	[5-Bit DAC design and simulation](#5-bit-dac-design-and-simulation)
    -	[6-Bit DAC design and simulation](#6-bit-dac-design-and-simulation)
    -	[7-Bit DAC design and simulation](#7-bit-dac-design-and-simulation)
    -	[8-Bit DAC design and simulation](#8-bit-dac-design-and-simulation)
    -	[9-Bit DAC design and simulation](#9-bit-dac-design-and-simulation)
    -	[10-Bit DAC design and simulation](#10-bit-dac-design-and-simulation)
    -	[INL and DNL Waveforms](#inl-and-dnl-outputs)
-	[6.Post-Layout Designs and Simulations](#6post-layout-designs-and-simulations)
    -   [Resistor 250 layout and value](#resistor-250-layout-and-value)
    -   [Resistor 500 layout and value](#resistor-500-layout-and-value)
    -   [Inverter layout](#inverter-layout)
    -   [Switch layout and simulation](#switch-layout-and-simulation)
    -	[2-Bit DAC layout and simulation](#2-bit-dac-layout-and-simulation)
    -	[3-Bit DAC layout and simulation](#3-bit-dac-layout-and-simulation)
    -	[4-Bit DAC layout and simulation](#4-bit-dac-layout-and-simulation)
    -	[5-Bit DAC layout and simulation](#5-bit-dac-layout-and-simulation)
    -	[6-Bit DAC layout and simulation](#6-bit-dac-layout-and-simulation)
    -	[7-Bit DAC layout and simulation](#7-bit-dac-layout-and-simulation)
    -	[8-Bit DAC layout and simulation](#8-bit-dac-layout-and-simulation)
    -	[9-Bit DAC layout and simulation](#9-bit-dac-layout-and-simulation)
    -	[10-Bit DAC layout and simulation](#10-bit-dac-layout-and-simulation)
    -	[INL and DNL Waveforms](#inl-and-dnl-outputs-postlayout)
-	[7.Instructions to get started with the design](#7instructions-to-get-started-with-the-design)
    -	[Spice simulation speed improvement (Multi threading)](#spice-simulation-speed-improvement-multi-threading)
    -	[Pre-layout Simulation commands](#pre-layout-simulation-commands)
    -	[Post-layout Simulation commands](#post-layout-simulation-commands)
-	[8.Future Works](#8future-works)
-	[9.Contributors](#9contributors)
-	[10.Acknowledgments](#10acknowledgments)

## 1.Purpose of Digital to Analog Converter (DAC)
In real world, most of the data available is in the form of analog in nature. We have two types of converters analog to digital converter and digital to analog converter. These two converting interfaces are essential to obtain the required operations of a processor to manipulate the data of digital electronic equipment and an analog electric equipment.
Digital to Analog Converter (DAC) is a device that transforms digital data into an analog signal in order to interact with the real world. The digital signal is represented with a binary code, which is a combination of bits 0’s and 1’s. The digital data can be produced from a microprocessor, Field Programmable Gate Array (FPGA), or Application Specified Integrated Circuit (ASIC). There are two commonly used DAC conversions – Weighed resistors method and R-2R ladder network method.
Applications of a DAC: audio amplifier, video encoder, display electronics, data acquisition systems, calibration, Digital potentiometer.

## 2.IP Block Design Specifications

### IP Block Diagram
![avsdDAC3v3](https://user-images.githubusercontent.com/73480418/109257152-7deed980-77c5-11eb-888c-805d33d2b3dc.PNG)

### Terminal Functions
|Name	   |Pin No. |	I/O |	Description       |
|:-------|:-------|:----|:------------------|
|D [0:9] |1-10	  |I	  |Digital inputs     |
|EN	     |11	    |I	  |Enable pin|
|VDD	   |12	    |I  	|Digital power supply (1.8)|
|VSS	|13	|I	|Digital ground|
|OUT	|14	|O	|DAC analog voltage output|
|VDDA	|15	|I	|Analog voltage supply (3.3)|
|VSSA	|16	|I	|Analog ground|
|VREFH	|17	|I	|Reference voltage high for DAC(3.3)|
|VREFL	|18	|I	|Reference voltage low for DAC|

## 3.EDA tools used to implement Potentiometric DAC
The design has been built using open-source EDA tools. The library used is sky130.
This design is implemented using [xschem](https://xschem.sourceforge.io/stefan/index.html), and [ngspice](http://ngspice.sourceforge.net/download.html) is used to run the simulations & verify the circuitry. For circuit layout implementation, [Magic](http://opencircuitdesign.com/magic/) will be used.
The step to install xschem with sky130 and ngspice can be found [here](https://github.com/bluecmd/learn-sky130/blob/main/schematic/xschem/getting-started.md#installation-of-xschem).

## 4.Implementation of 10Bit Potentiometric DAC
The basic idea is to divide the voltage into N different voltage values in the range of VREFH and VREFL- for an N-Bit DAC. The design used here to achieve this is the simple resistor string DAC which consists of resistors in series. These resistors are then connected to various switches in such a fashion that it routes the exact voltage to the output. The problem of the largeness of the circuit is reduced by building hierarchical subcircuits of 10-Bit potentiometric DAC – Switch, 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, 7-bit, 8-bit, 9-bit and 10-bit.

![Conventional DAC](https://user-images.githubusercontent.com/73480418/109262054-e2fafd00-77ce-11eb-91ad-d75cca9803a2.png)

*Basic Architecture of Potentiometric DAC*
## 5.Pre-layout Designs and Simulations
#### *Switch design and simulation*

Switch design implementation and respective waveform are shown below

![Switch Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/TG_schematics.PNG)

![Switch waveform](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/switch_outputfinal.png)

To see this waveform run `switch.spice` file

#### *2-Bit DAC design and simulation:*

2Bit DAC is implemented using 3 switch instances. 2-Bit circuitry and waveform are shown below

![2Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/2bit_schematic.PNG)

![2Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/2bit_waveform.PNG)

To see this waveform run `my_2bitdac.spice` file

#### *3-Bit DAC design and simulation:*

3Bit DAC is implemented using 2 2-Bit DACs and 1 switch instances. 3-Bit circuitry and waveform are shown below

![3Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/3bit_schematic.PNG)

![3Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/3bit_waveform.PNG)

To see this waveform run `my_3bitdac.spice` file

#### *4-Bit DAC design and simulation:*

4Bit DAC is implemented using 2 3-Bit DACs and 1 switch instances. 4-Bit circuitry and waveform are shown below

![4Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/4bit_schematic.PNG)

![4Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/4bit_waveform.PNG)

To see this waveform run `my_4bitdac.spice` file

#### *5-Bit DAC design and simulation:*

5Bit DAC is implemented using 2 4-Bit DACs and 1 switch instances. 5-Bit circuitry and waveform are shown below

![5Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/5bit_schematics.PNG)

![5Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/5bit_waveform.PNG)

To see this waveform run `my_5bitdac.spice` file

#### *6-Bit DAC design and simulation:*

6Bit DAC is implemented using 2 5-Bit DACs and 1 switch instances. 6-Bit circuitry and waveform are shown below

![6Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/6bit_schematics.PNG)

![6Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/6bit_waveform.PNG)

To see this waveform run `my_6bitdac.spice` file

#### *7-Bit DAC design and simulation:*

7Bit DAC is implemented using 2 6-Bit DACs and 1 switch instances. 7-Bit circuitry and waveform are shown below
![7Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/7bit_schematics.PNG)

![7Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/7bit_waveform.PNG)

To see this waveform run `my_7bitdac.spice` file

#### *8-Bit DAC design and simulation:*

8Bit DAC is implemented using 2 7-Bit DACs and 1 switch instances. 8-Bit circuitry and waveform are shown below

![8Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/8bit_schematics.PNG)

![8Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/8bit_waveform.PNG)

To see this waveform run `my_8bitdac.spice` file

#### *9-Bit DAC design and simulation:*
9Bit DAC is implemented using 2 8-Bit DACs and 1 switch instances. 9-Bit circuitry and waveform are shown below

![9Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/9bit_schematics.PNG)

![9Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/9bit_waveform.png)

To see the waveform run `my_9bitdac.spice` file.

#### *10-Bit DAC design and simulation:*
10Bit DAC is implemented using 2 9-Bit DACs and 1 switch instances. 10-Bit circuitry and waveform are shown below

![10Bit DAC Design](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/10bit_schematics.PNG)

![10Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/Pictures/10bit_waveform.png)

To see the wavefrom run `my_10bitdac.spice` file.

Every block of the circuit until 10 bit DAC are tested and spice models until 10 bit dac are included in [specified folders](https://github.com/Shalini24Kanna/P-DAC_INTERNSHIP/tree/main/10Bit_Potentiometeric_DAC_Conventional_Design/spicefiles).
### INL AND DNL outputs

![DNL_LSB](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/DNL_LSB.png)

![INL_LSB](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Prelayout/INL_LSB.png)

## 6.Post-layout Designs and Simulations
#### *Resistor 250 layout and value*

![Resistor 250 layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/res250%20layout%20design.PNG)

R = 249.8ohms

#### *Resistor 500 layout and value*

![Resistor 500 layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/res500%20layout%20design.PNG)

R = 497.2ohms

#### *Inverter layout*

Inverter Implementation is shown below

![Inverter Layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/INV%20layout%20design.PNG)

#### *Switch layout and simulation*
Switch layout implementation and its respective waveform are shown below

![Switch Layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/Switch%20layout%20design.PNG)

![Switch layout waveform](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/switch%20layout%20waveform.png)

To see this waveform run `switch_layout_test.spice` file

#### *2-Bit DAC layout and simulation*
2Bit DAC is implemented using 3 switch instances. 2-Bit layout and waveform are shown below

![2Bit DAC Layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/2bitdac%20layout%20design.PNG)

![2Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/2bitdac%20layout%20waveform.png)

To see this waveform run `2bitdac_layout_test.spice` file

#### *3-Bit DAC layout and simulation*
3Bit DAC is implemented using 2 2-Bit DACs and 1 switch instances. 3-Bit layout and waveform are shown below
![3bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/3bitdac%20layout%20design.PNG)

![3Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/3bitdac%20layout%20waveform.png)

To see the wavefrom run `3bitdac_layout_test.spice` file.

#### *4-Bit DAC layout and simulation*
4Bit DAC is implemented using 2 3-Bit DACs and 1 switch instances. 4-Bit layout and waveform are shown below

![4bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/4bitdac%20layout%20design.PNG)

![4Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/4bitdac%20layout%20waveform.png)

To see the wavefrom run `4bitdac_layout_test.spice` file.

#### *5-Bit DAC layout and simulation*
5Bit DAC is implemented using 2 4-Bit DACs and 1 switch instances. 5-Bit layout and waveform are shown below

![5bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/5bitdac%20layout%20design.PNG)

![5Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/5bitdac%20layout%20waveform.png)

To see the wavefrom run `5bitdac_layout_test.spice` file.

#### *6-Bit DAC layout and simulation*
6Bit DAC is implemented using 2 5-Bit DACs and 1 switch instances. 6-Bit layout and waveform are shown below

![6bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/6bitdac%20layout%20design.PNG)

![6Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/6bitdac%20layout%20waveform.PNG)

To see the wavefrom run `6bitdac_layout_test.spice` file.

#### *7-Bit DAC layout and simulation*
7Bit DAC is implemented using 2 6-Bit DACs and 1 switch instances. 7-Bit layout and waveform are shown below

![7bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/7bitdac%20layout%20design.PNG)

![7Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/7bitdac%20layout%20waveform.PNG)

To see the wavefrom run `7bitdac_layout_test.spice` file.

#### *8-Bit DAC layout and simulation*
8Bit DAC is implemented using 2 7-Bit DACs and 1 switch instances. 8-Bit layout and waveform are shown below

![8bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/8bitdac%20layout%20design.PNG)

![8Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/8bitdac%20layout%20waveform.PNG)

To see the wavefrom run `8bitdac_layout_test.spice` file.

#### *9-Bit DAC layout and simulation*
9Bit DAC is implemented using 2 8-Bit DACs and 1 switch instances. 9-Bit layout and waveform are shown below

![9bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/9bitdac%20layout%20desing.PNG)

![9Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/9bitdac%20layout%20waveform.png)

To see the wavefrom run `9bitdac_layout_test.spice` file.

#### *10-Bit DAC layout and simulation*
10Bit DAC is implemented using 2 9-Bit DACs and 1 switch instances. 10-Bit layout and waveform are shown below

![10bit DAC layout](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/10bitdac%20layout%20desing.PNG)

![10Bit DAC WaveForm](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/10bitdac%20layout%20waveform.png)

To see the wavefrom run `10bitdac_layout_test.spice` file.

### INL AND DNL outputs postlayout

![DNL_LSB](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/DNL_LSB_layout.png)

![INL_LSB](https://github.com/vsdip/avsddac_3v3_sky130_v1/blob/main/Postlayout/Pictures/INL_LSB_layout.png)

## 7.Instructions to get started with the design
#### Spice simulation speed improvement (Multi threading)
 Ngspice provides multithreading options to improve the simulation time. To enable multithreading following steps are to be followed:

 o Install ngspice from tarball

 o `sudo apt-get install -y autoconf`

 o `sudo apt-get install -y libtool`

 o `tar -zxvf ngspice`

 o `cd ngspice`

 o `./autogen.sh`

 o `./configure --enable-xspice --enable-openmp --disable-debug --with-readline=yes`

 o `make clean`

 o `make`

 o `sudo make install`

  Then in the netlist's control section, add the following:
  `set num_threads=4` (or more)

![Multithreading](https://user-images.githubusercontent.com/73480418/110157539-46c88b80-7db6-11eb-894d-096e770abd39.PNG)

However, multithreading option is effective if the major part of the circuit are MOSFETs (BSIM 3V8 or BSIM4V5),since the DAC consits of more number of resistors, multithreading option was not helpful to increase the simulation speed.
#### Pre-layout Simulation commands
o	Clone the git repo with following command

        git clone https://github.com/vsdip/avsddac_3v3_sky130_v1.git

o   Open the terminal from the cloned folder or run below command after cloning while in the same path

            cd avsddac_3v3_sky130_v1/

o	Command to simulate .Spice files of conventional design

            cd Prelayout/

            ngspice my_nbitdac.spice

#### Post-layout Simulation commands
o   Clone the git repo with following command (if you haven't cloned for pre-layout simulation)

            git clone https://github.com/vsdip/avsddac_3v3_sky130_v1.git

o   Open the terminal from the cloned folder or run below command after cloning while in the same path

        cd avsddac_3v3_sky130_v1/

o	Command to simulate .Spice files of conventional design layout

       cd Postlayout/

       ngspice nbitdac_layout_test.spice

o type `y` when simulation asks for

## 8.Future Works

Runtime for layout can be reduced further.

## 9.Contributors

Shalini Kanna, Master of Science in Computer Engineering, University of Massachusetts Lowell, Lowell,MA, USA; Contact<EMAIL_ADDRESS>[LinkedIn](https://www.linkedin.com/in/shalini-kanna/)

Harshitha Basavaraju, PhD Scholar @ University of Bundeswehr, Munich, Germany; Contact<EMAIL_ADDRESS>[LinkedIn](https://www.linkedin.com/in/harshitha-basavaraju-a91842b8/)

Skandha Deepsita S, PhD Scholar @ IIITDM Kancheepuram; Contact<EMAIL_ADDRESS>[LinkedIn](https://www.linkedin.com/in/skandha-deepsita-sarvepalli-027433ba)

Kunal Ghosh, Co-founder, VSD Corp. Pvt. Ltd. -<EMAIL_ADDRESS>
## 10.Acknowledgments
Kunal Ghosh, Co-founder, VSD Corp. Pvt. Ltd. -<EMAIL_ADDRESS>


text:
---
title: Database Configuration
menu:
  influxdb_1_2:
    weight: 70
    parent: administration
---

The InfluxDB configuration file contains configuration settings specific to a local node.

#### Content

* [Using configuration files](#using-configuration-files)
    * [Configuration options overview](#configuration-options-overview)
    * [Environment variables](#environment-variables)
* [Configuration options by section](#configuration-options-by-section)
    * [Global options](#global-options)
        * [reporting-disabled](#reporting-disabled-false)
        * [bind-address](#bind-address-8088)
    * [[meta]](#meta)
        * [dir](#dir-var-lib-influxdb-meta)
        * [retention-autocreate](#retention-autocreate-true)
        * [logging-enabled](#logging-enabled-true)
    * [[data]](#data)
        * [dir](#dir-var-lib-influxdb-data)
        * [wal-dir](#wal-dir-var-lib-influxdb-wal)
        * [trace-logging-enabled](#trace-logging-enabled-false)
        * [query-log-enabled](#query-log-enabled-true)
        * [cache-max-memory-size](#cache-max-memory-size-1048576000)
        * [cache-snapshot-memory-size](#cache-snapshot-memory-size-26214400)
        * [cache-snapshot-write-cold-duration](#cache-snapshot-write-cold-duration-10m)
        * [compact-full-write-cold-duration](#compact-full-write-cold-duration-4h)
        * [max-series-per-database](#max-series-per-database-1000000)
        * [max-values-per-tag](#max-values-per-tag-100000)
    * [[coordinator]](#coordinator)
        * [write-timeout](#write-timeout-10s)
        * [max-concurrent-queries](#max-concurrent-queries-0)
        * [query-timeout](#query-timeout-0s)
        * [log-queries-after](#log-queries-after-0s)
        * [max-select-point](#max-select-point-0)
        * [max-select-series](#max-select-series-0)
        * [max-select-buckets](#max-select-buckets-0)
    * [[retention]](#retention)
        * [enabled](#enabled-true)
        * [check-interval](#check-interval-30m0s)
    * [[shard-precreation]](#shard-precreation)
        * [enabled](#enabled-true-1)
        * [check-interval](#check-interval-10m)
        * [advance-period](#advance-period-30m)
    * [[admin]](#admin)
        * [enabled](#enabled-false)
        * [bind-address](#bind-address-8083)
        * [https-enabled](#https-enabled-false)
        * [https-certificate](#https-certificate-etc-ssl-influxdb-pem)
    * [[monitor]](#monitor)
        * [store-enabled](#store-enabled-true)
        * [store-database](#store-database-internal)
        * [store-interval](#store-interval-10s)
    * [[subscriber]](#subscriber)
        * [enabled](#enabled-true-3)
        * [http-timeout](#http-timeout-30s)
        * [insecure-skip-verify](#insecure-skip-verify-false)
        * [ca-certs](#ca-certs)
        * [write-concurrency](#write-concurrency-40)
        * [write-buffer-size](#write-buffer-size-1000)
    * [[http]](#http)
        * [enabled](#enabled-true-2)
        * [bind-address](#bind-address-8086)
        * [auth-enabled](#auth-enabled-false)
        * [realm](#realm-influxdb)
        * [log-enabled](#log-enabled-true)
        * [write-tracing](#write-tracing-false)
        * [pprof-enabled](#pprof-enabled-true)
        * [https-enabled](#https-enabled-false-1)
        * [https-certificate](#https-certificate-etc-ssl-influxdb-pem-1)
        * [https-private-key](#https-private-key)
        * [shared-secret](#shared-secret)
        * [max-row-limit](#max-row-limit-0)
        * [max-connection-limit](#max-connection-limit-0)
        * [unix-socket-enabled](#unix-socket-enabled-false)
        * [bind-socket](#bind-socket-var-run-influxdb-sock)
    * [[[graphite]]](#graphite)
        * [enabled](#enabled-false-1)
        * [database](#database-graphite)
        * [retention-policy](#retention-policy)
        * [bind-address](#bind-address-2003)
        * [protocol](#protocol-tcp)
        * [consistency-level](#consistency-level-one)
        * [batch-size](#batch-size-5000)
        * [batch-pending](#batch-pending-10)
        * [batch-timeout](#batch-timeout-1s)
        * [udp-read-buffer](#udp-read-buffer-0)
        * [separator](#separator)
    * [[[collectd]]](#collectd)
        * [enabled](#enabled-false-2)
        * [bind-address](#bind-address-25826)
        * [database](#database-collectd)
        * [retention-policy](#retention-policy-1)
        * [typesdb](#typesdb-usr-local-share-collectd)
        * [security-level](#security-level-none)
        * [auth-file](#auth-file-etc-collectd-auth-file)
        * [batch-size](#batch-size-5000-1)
        * [batch-pending](#batch-pending-10-1)
        * [batch-timeout](#batch-timeout-10s)
        * [read-buffer](#read-buffer-0)
    * [[[opentsdb]]](#opentsdb)
        * [enabled](#enabled-false-3)
        * [bind-address](#bind-address-4242)
        * [database](#database-opentsdb)
        * [retention-policy](#retention-policy-2)
        * [consistency-level](#consistency-level-one-1)
        * [tls-enabled](#tls-enabled-false)
        * [certificate](#certificate-etc-ssl-influxdb-pem)
        * [log-point-errors](#log-point-errors-true)
        * [batch-size](#batch-size-1000)
        * [batch-pending](#batch-pending-5)
        * [batch-timeout](#batch-timeout-1s-1)
    * [[[udp]]](#udp)
        * [enabled](#enabled-false-4)
        * [bind-address](#bind-address-8089)
        * [database](#database-udp)
        * [retention-policy](#retention-policy-3)
        * [batch-size](#batch-size-5000-2)
        * [batch-pending](#batch-pending-10-2)
        * [batch-timeout](#batch-timeout-1s-2)
        * [read-buffer](#read-buffer-0-1)
        * [precision](#precision)
    * [[continuous_queries]](#continuous-queries)
        * [enabled](#enabled-true-4)
        * [log-enabled](#log-enabled-true-1)
        * [run-interval](#run-interval-1s)

## Using Configuration Files

The system has internal defaults for every configuration file setting.
View the default configuration settings with the `influxd config` command.

Most of the settings in the local configuration file
(`/etc/influxdb/influxdb.conf`) are commented out; all
commented-out settings will be determined by the internal defaults.
Any uncommented settings in the local configuration file override the
internal defaults.
Note that the local configuration file does not need to include every
configuration setting.

There are two ways to launch InfluxDB with your configuration file:

* Point the process to the correct configuration file by using the `-config`
option:

    ```bash
    influxd -config /etc/influxdb/influxdb.conf
    ```
* Set the environment variable `INFLUXDB_CONFIG_PATH` to the path of your
configuration file and start the process.
For example:

    ```
    echo $INFLUXDB_CONFIG_PATH
    /etc/influxdb/influxdb.conf

    influxd
    ```

InfluxDB first checks for the `-config` option and then for the environment
variable.

### Configuration Options Overview

Every configuration section has configuration options and every configuration option is optional.
If you do not uncomment a configuration option, the system uses its default setting.
The configuration options in this document are set to their default settings.

Configuration options that specify a duration support the following duration units:

`ns`        nanoseconds
`us` or `µs` microseconds
`ms`        milliseconds
`s`      seconds
`m`      minutes
`h`      hours
`d`      days
`w`      weeks

>**Note:** This page documents configuration options for the latest official release - the [sample configuration file on GitHub](https://github.com/influxdb/influxdb/blob/1.2/etc/config.sample.toml) will always be slightly ahead of what is documented here.

### Environment Variables

All configuration options can be specified in the configuration file or in an
environment variable.
The environment variable overrides the equivalent option in the configuration
file.
If a configuration option is not specified in either the configuration file
or in an environment variable, InfluxDB uses its internal default
configuration.

In the sections below we name the relevant environment variable in the
description for the configuration setting.

> **Note:**
To set or override settings in a config section that allows multiple
configurations (any section with [[`double_brackets`]] in the header supports
multiple configurations), the desired configuration must be specified by ordinal
number.
For example, for the first set of `[[graphite]]` environment variables,
prefix the configuration setting name in the environment variable with the
relevant position number (in this case: `0`):
>
    INFLUXDB_GRAPHITE_0_BATCH_PENDING
    INFLUXDB_GRAPHITE_0_BATCH_SIZE
    INFLUXDB_GRAPHITE_0_BATCH_TIMEOUT
    INFLUXDB_GRAPHITE_0_BIND_ADDRESS
    INFLUXDB_GRAPHITE_0_CONSISTENCY_LEVEL
    INFLUXDB_GRAPHITE_0_DATABASE
    INFLUXDB_GRAPHITE_0_ENABLED
    INFLUXDB_GRAPHITE_0_PROTOCOL
    INFLUXDB_GRAPHITE_0_RETENTION_POLICY
    INFLUXDB_GRAPHITE_0_SEPARATOR
    INFLUXDB_GRAPHITE_0_TAGS
    INFLUXDB_GRAPHITE_0_TEMPLATES
    INFLUXDB_GRAPHITE_0_UDP_READ_BUFFER
>
For the Nth Graphite configuration in the configuration file, the relevant
environment variables would be of the form `INFLUXDB_GRAPHITE_(N-1)_BATCH_PENDING`.
For each section of the configuration file the numbering restarts at zero.

## Global Options

### reporting-disabled = false

InfluxData, the company, relies on reported data from running nodes
primarily to track the adoption rates of different InfluxDB versions.
This data helps InfluxData support the continuing development of
InfluxDB.

The `reporting-disabled` option toggles
the reporting of data every 24 hours to `usage.influxdata.com`.
Each report includes a randomly-generated identifier, OS, architecture,
InfluxDB version, and the
number of [databases](/influxdb/v1.2/concepts/glossary/#database),
[measurements](/influxdb/v1.2/concepts/glossary/#measurement), and
unique [series](/influxdb/v1.2/concepts/glossary/#series).  Setting
this option to `true` will disable reporting.

>**Note:** No data from user databases is ever transmitted.

Environment variable: `INFLUXDB_REPORTING_DISABLED`

### bind-address = ":8088"

The bind address to use for the RPC service for [backup and restore](/influxdb/v1.2/administration/backup_and_restore/).

Environment variable: `INFLUXDB_BIND_ADDRESS`

## [meta]

This section controls parameters for InfluxDB's metastore,
which stores information on users, databases, retention policies, shards, and
continuous queries.

### dir = "/var/lib/influxdb/meta"

The `meta` directory.
Files in the `meta` directory include `meta.db`.

>**Note:** The default directory for macOS installations is `/Users/<username>/.influxdb/meta`

Environment variable: `INFLUXDB_META_DIR`

### retention-autocreate = true

Retention policy auto-creation automatically creates the [`DEFAULT` retention policy](/influxdb/v1.2/concepts/glossary/#retention-policy-rp) `autogen` when a database is created.
The retention policy `autogen` has an infinite duration and is also set as the
database's `DEFAULT` retention policy, which is used when a write or query does
not specify a retention policy.
Disable this setting to prevent the creation of this retention policy when creating databases.

Environment variable: `INFLUXDB_META_RETENTION_AUTOCREATE`

### logging-enabled = true

Meta logging toggles the logging of messages from the meta service.

Environment variable: `INFLUXDB_META_LOGGING_ENABLED`

## [data]

This section controls where the actual shard data for InfluxDB lives and how it is flushed from the WAL. `dir` may need to be changed to a suitable place for you system, but the WAL settings are an advanced configuration. The defaults should work for most systems.

### dir = "/var/lib/influxdb/data"

The directory where InfluxDB stores the data.
This directory may be changed.

>**Note:** The default directory for macOS installations is `/Users/<username>/.influxdb/data`

Environment variable: `INFLUXDB_DATA_DIR`

### wal-dir = "/var/lib/influxdb/wal"

The WAL directory is the location of the [write ahead log](/influxdb/v1.2/concepts/glossary/#wal-write-ahead-log).

Environment variable: `INFLUXDB_DATA_WAL_DIR`

### trace-logging-enabled = false

Toggles logging of additional debug information within the TSM engine and WAL.

Environment variable: `INFLUXDB_DATA_TRACE_LOGGING_ENABLED`

### query-log-enabled = true

The query log enabled setting toggles the logging of parsed queries before execution.
Very useful for troubleshooting, but will log any sensitive data contained within a query.

Environment variable: `INFLUXDB_DATA_QUERY_LOG_ENABLED`

### cache-max-memory-size =<PHONE_NUMBER>

The cache maximum memory size is the maximum size (in bytes) a shard's cache can reach before it starts rejecting writes.

Environment variable: `INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE`

### cache-snapshot-memory-size = 26214400

The cache snapshot memory size is the size at which the engine will snapshot the cache and write it to a TSM file, freeing up memory.

Environment variable: `INFLUXDB_DATA_CACHE_SNAPSHOT_MEMORY_SIZE`

### cache-snapshot-write-cold-duration = "10m"

The cache snapshot write cold duration is the length of time at which the engine will snapshot the cache and write it to a new TSM file if the shard hasn't received writes or deletes.

Environment variable: `INFLUXDB_DATA_CACHE_SNAPSHOT_WRITE_COLD_DURATION`

### compact-full-write-cold-duration = "4h"

The compact full write cold duration is the duration at which the engine will compact all TSM files in a shard if it hasn't received a write or delete.

Environment variable: `INFLUXDB_DATA_COMPACT_FULL_WRITE_COLD_DURATION`

### max-series-per-database = 1000000

The maximum number of [series](/influxdb/v1.2/concepts/glossary/#series) allowed
per database.
The default setting is one million.
Change the setting to `0` to allow an unlimited number of series per database.

If a point causes the number of series in a database to exceed
`max-series-per-database` InfluxDB will not write the point, and it returns a
`500` with the following error:

```
{"error":"max series per database exceeded: <series>"}
```

> **Note:** Any existing databases with a series count that exceeds `max-series-per-database`
will continue to accept writes to existing series, but writes that create a
new series will fail.

Environment variable: `INFLUXDB_DATA_MAX_SERIES_PER_DATABASE`

### max-values-per-tag = 100000

The maximum number of [tag values](/influxdb/v1.2/concepts/glossary/#tag-values)
allowed per [tag key]((/influxdb/v1.2/concepts/glossary/#tag-key).
The default setting is `100000`.
Change the setting to `0` to allow an unlimited number of tag values per tag
key.
If a tag value causes the number of tag values of a tag key to exceed
`max-values-per-tag` InfluxDB will not write the point, and it returns
a `partial write` error.

Any existing tag keys with tag values that exceed `max-values-per-tag`
will continue to accept writes, but writes that create a new tag value
will fail.

Environment variable: `INFLUXDB_DATA_MAX_VALUES_PER_TAG`

## [coordinator]

This section contains configuration options for query management.
For more on managing queries, see [Query Management](/influxdb/v1.2/troubleshooting/query_management/).

### write-timeout = "10s"

The time within which a write request must complete on the cluster.

Environment variable: `INFLUXDB_COORDINATOR_WRITE_TIMEOUT`

### max-concurrent-queries = 0

The maximum number of running queries allowed on your instance.
The default setting (`0`) allows for an unlimited number of queries.

Environment variable: `INFLUXDB_COORDINATOR_MAX_CONCURRENT_QUERIES`

### query-timeout = "0s"

The maximum time for which a query can run on your instance before InfluxDB
kills the query.
The default setting (`0`) allows queries to run with no time restrictions.
This setting is a [duration](#configuration-options).

Environment variable: `INFLUXDB_COORDINATOR_QUERY_TIMEOUT`

### log-queries-after = "0s"

The maximum time a query can run after which InfluxDB logs the query with a
`Detected slow query` message.
The default setting (`"0"`) will never tell InfluxDB to log the query.
This setting is a
[duration](#configuration-options).

Environment variable: `INFLUXDB_COORDINATOR_LOG_QUERIES_AFTER`

### max-select-point = 0

The maximum number of [points](/influxdb/v1.2/concepts/glossary/#point) that a
`SELECT` statement can process.
The default setting (`0`) allows the `SELECT` statement to process an unlimited
number of points.

Environment variable: `INFLUXDB_COORDINATOR_MAX_SELECT_POINT`

### max-select-series = 0

The maximum number of [series](/influxdb/v1.2/concepts/glossary/#series) that a
`SELECT` statement can process.
The default setting (`0`) allows the `SELECT` statement to process an unlimited
number of series.

Environment variable: `INFLUXDB_COORDINATOR_MAX_SELECT_SERIES`

### max-select-buckets = 0

The maximum number of `GROUP BY time()` buckets that a query can process.
The default setting (`0`) allows a query to process an unlimited number of
buckets.

Environment variable: `INFLUXDB_COORDINATOR_MAX_SELECT_BUCKETS`

## [retention]

This section controls the enforcement of retention policies for evicting old data.

### enabled = true

Set to `false` to prevent InfluxDB from enforcing retention policies.

Environment variable: `INFLUXDB_RETENTION_ENABLED`

### check-interval = "30m0s"

The rate at which InfluxDB checks to enforce a retention policy.

Environment variable: `INFLUXDB_RETENTION_CHECK_INTERVAL`

## [shard-precreation]

Controls the precreation of shards so that shards are available before data arrive.
Only shards that, after creation, will have both a start- and end-time in the future are ever created.
Shards that would be wholly or partially in the past are never precreated.

### enabled = true

Environment variable: `INFLUXDB_SHARD_PRECREATION_ENABLED`

### check-interval = "10m"

Environment variable: `INFLUXDB_SHARD_PRECREATION_CHECK_INTERVAL`

### advance-period = "30m"

The maximum period in the future for which InfluxDB precreates shards.
The `30m` default should work for most systems.
Increasing this setting too far in the future can cause inefficiencies.

Environment variable: `INFLUXDB_SHARD_PRECREATION_ADVANCE_PERIOD`

## [monitor]

This section controls InfluxDB's [system self-monitoring](https://github.com/influxdb/influxdb/blob/1.2/monitor/README.md).

By default, InfluxDB writes the data to the `_internal` database.
If that database does not exist, InfluxDB creates it automatically.
The `DEFAULT` retention policy on the `_internal` database is seven days.
If you want to use a retention policy other than the seven-day retention policy, you must [create](/influxdb/v1.2/query_language/database_management/#retention-policy-management) it.

### store-enabled = true

Set to `false` to disable recording statistics internally.
If set to `false` it will make it substantially more difficult to diagnose issues with your installation.

Environment variable: `INFLUXDB_MONITOR_STORE_ENABLED`

### store-database = "\_internal"

The destination database for recorded statistics.

Environment variable: `INFLUXDB_MONITOR_STORE_DATABASE`

### store-interval = "10s"

The interval at which InfluxDB records statistics.

Environment variable: `INFLUXDB_MONITOR_STORE_INTERVAL`

## [admin]

Controls the availability of the built-in, web-based [admin interface](/influxdb/v1.2/tools/web_admin/).

> **Note:** The Admin UI is deprecated as of InfluxDB 1.2.

### enabled = false

Set to `true` to enable the admin interface.

Environment variable: `INFLUXDB_ADMIN_ENABLED`

### bind-address = ":8083"

The port used by the admin interface.

Environment variable: `INFLUXDB_ADMIN_BIND_ADDRESS`

### https-enabled = false

Set to `true` to enable HTTPS for the admin interface.

>**Note:** HTTPS must be enable for the [[http]](/influxdb/v1.2/administration/config/#http) service for the admin UI to function properly using HTTPS.

Environment variable: `INFLUXDB_ADMIN_HTTPS_ENABLED`

### https-certificate = "/etc/ssl/influxdb.pem"

The path of the certificate file.

Environment variable: `INFLUXDB_ADMIN_HTTPS_CERTIFICATE`

## [http]

This section controls how InfluxDB configures the HTTP endpoints.
These are the primary mechanisms for getting data into and out of InfluxDB.
Edit the options in this section to enable HTTPS and authentication.
See [Authentication and Authorization](/influxdb/v1.2/query_language/authentication_and_authorization/).

### enabled = true

Set to `false` to disable HTTP.
Note that the InfluxDB [command line interface (CLI)](/influxdb/v1.2/tools/shell/) connects to the database using the HTTP API.

Environment variable: `INFLUXDB_HTTP_ENABLED`

### bind-address = ":8086"

The port used by the HTTP API.

Environment variable: `INFLUXDB_HTTP_BIND_ADDRESS`

### auth-enabled = false

Set to `true` to require authentication.

Environment variable: `INFLUXDB_HTTP_AUTH_ENABLED`

### realm = "InfluxDB"

Realm is the JWT realm used by the http endpoint.

Environment variable: `INFLUXDB_HTTP_REALM`

### log-enabled = true

Set to `false` to disable logging.

Environment variable: `INFLUXDB_HTTP_LOG_ENABLED`

### write-tracing = false

Set to `true` to enable logging for the write payload.
If set to `true`, this will duplicate every write statement in the logs and is thus not recommended for general use.

Environment variable: `INFLUXDB_HTTP_WRITE_TRACING`

### pprof-enabled = true

Determines whether the pprof endpoint is enabled.  This endpoint is used for
troubleshooting and monitoring.

Environment variable: `INFLUXDB_HTTP_PPROF_ENABLED`

### https-enabled = false

Set to `true` to enable HTTPS.

Environment variable: `INFLUXDB_HTTP_HTTPS_ENABLED`

### https-certificate = "/etc/ssl/influxdb.pem"

The path of the certificate file.

Environment variable: `INFLUXDB_HTTP_HTTPS_CERTIFICATE`

### https-private-key = ""

The separate private key location.
If only the `https-certificate` is specified, the httpd service will try to load
the private key from the `https-certificate` file.
If a separate `https-private-key` file is specified, the httpd service will load
the private key from the `https-private-key` file.

Environment variable: `INFLUXDB_HTTP_HTTPS_PRIVATE_KEY`

### shared-secret = ""

The shared secret used for JWT signing.

Environment variable: `INFLUXDB_HTTP_SHARED_SECRET`

### max-row-limit = 0

Limits the number of rows that the system can return in a [non-chunked](/influxdb/v1.2/tools/api/#query-string-parameters) query.
The default setting (`0`) allows for an unlimited number of rows.
InfluxDB includes a `"partial":true` tag in the response body if query results exceed the `max-row-limit` setting.

{{% warn %}}
In versions 1.2.0 and 1.2.1, the `max-row-limit` option is set to 10,000 by default.
That default setting can lead to unexpected behavior in [Grafana](https://grafana.com/) panels; if a panel's query returns more than 10,000 points, the panel appears to show [truncated/partial data](https://github.com/influxdata/influxdb/issues/8050).
In versions 1.2.2+, `max-row-limit` is set to `0` by default and allows an unlimited number of returned rows.
{{% /warn %}}

Environment variable: `INFLUXDB_HTTP_MAX_ROW_LIMIT`

### max-connection-limit = 0

Limit the number of connections for the http service.  0 is unlimited.

Environment variable: `INFLUXDB_HTTP_MAX_CONNECTION_LIMIT`

### unix-socket-enabled = false

Set to `true` to enable http service over unix domain socket.

Environment variable: `INFLUXDB_HTTP_UNIX_SOCKET_ENABLED`

### bind-socket = "/var/run/influxdb.sock"

The path of the unix domain socket.

Environment variable: `INFLUXDB_HTTP_UNIX_BIND_SOCKET`

## [subscriber]

This section controls how [Kapacitor](/kapacitor/v1.2/) will receive data.

### enabled = true

Set to `false` to disable the subscriber service.

Environment variable: `INFLUXDB_SUBSCRIBER_ENABLED`

### http-timeout = "30s"

Controls how long an http request for the subscriber service will run before it times out.

Environment variable: `INFLUXDB_SUBSCRIBER_HTTP_TIMEOUT`

### insecure-skip-verify = false

Allows insecure HTTPS connections to subscribers.
This is useful when testing with self-signed certificates.

Environment variable: `INFLUXDB_SUBSCRIBER_INSECURE_SKIP_VERIFY`

### ca-certs = ""

The path to the PEM encoded CA certs file.
If the empty string, the default system certs will be used.

Environment variable: `INFLUXDB_SUBSCRIBER_CA_CERTS`

### write-concurrency = 40

The number of writer goroutines processing the write channel.

Environment variable: `INFLUXDB_SUBSCRIBER_WRITE_CONCURRENCY`

### write-buffer-size = 1000

The number of in-flight writes buffered in the write channel.

Environment variable: `INFLUXDB_SUBSCRIBER_WRITE_BUFFER_SIZE`

## [[graphite]]

This section controls one or many listeners for Graphite data.
See the [README](https://github.com/influxdb/influxdb/blob/1.2/services/graphite/README.md) on GitHub for more information.

### enabled = false

Set to `true` to enable Graphite input.

Environment variable: `INFLUXDB_GRAPHITE_0_ENABLED`

### database = "graphite"

The name of the database that you want to write to.

Environment variable: `INFLUXDB_GRAPHITE_0_DATABASE`

### retention-policy = ""

The relevant retention policy.
An empty string is equivalent to the database's `DEFAULT` retention policy.

Environment variable: `INFLUXDB_GRAPHITE_0_RETENTION_POLICY`

### bind-address = ":2003"

The default port.

Environment variable: `INFLUXDB_GRAPHITE_0_BIND_ADDRESS`

### protocol = "tcp"

Set to `tcp` or `udp`.

Environment variable: `INFLUXDB_GRAPHITE_PROTOCOL`

### consistency-level = "one"

The number of nodes that must confirm the write.
If the requirement is not met the return value will be either `partial write` if some points in the batch fail or `write failure` if all points in the batch fail.
For more information, see the Query String Parameters for Writes section in the [Line Protocol Syntax Reference ](/influxdb/v1.2/write_protocols/line_protocol_reference/).

Environment variable: `INFLUXDB_GRAPHITE_CONSISTENCY_LEVEL`

*The next three options control how batching works.
You should have this enabled otherwise you could get dropped metrics or poor performance.
Batching will buffer points in memory if you have many coming in.*

### batch-size = 5000

The input will flush if this many points get buffered.

Environment variable: `INFLUXDB_GRAPHITE_BATCH_SIZE`

### batch-pending = 10

The number of batches that may be pending in memory.

Environment variable: `INFLUXDB_GRAPHITE_BATCH_PENDING`

### batch-timeout = "1s"

The input will flush at least this often even if it hasn't reached the configured batch-size.

Environment variable: `INFLUXDB_GRAPHITE_BATCH_TIMEOUT`

### udp-read-buffer = 0

UDP Read buffer size, 0 means OS default.
UDP listener will fail if set above OS max.

Environment variable: `INFLUXDB_GRAPHITE_UDP_READ_BUFFER`

### separator = "."

This string joins multiple matching 'measurement' values providing more control over the final measurement name.

Environment variable: `INFLUXDB_GRAPHITE_SEPARATOR`

## [[collectd]]

This section controls the listener for collectd data. See the
[README](https://github.com/influxdata/influxdb/tree/master/services/collectd)
on Github for more information.

### enabled = false

Set to `true` to enable collectd writes.

Environment variable: `INFLUXDB_COLLECTD_ENABLED`

### bind-address = ":25826"

The port.

Environment variable: `INFLUXDB_COLLECTD_BIND_ADDRESS`

### database = "collectd"

The name of the database that you want to write to.
This defaults to `collectd`.

Environment variable: `INFLUXDB_COLLECTD_DATABASE`

### retention-policy = ""

The relevant retention policy.
An empty string is equivalent to the database's `DEFAULT` retention policy.

Environment variable: `INFLUXDB_COLLECTD_RETENTION_POLICY`

### typesdb = "/usr/local/share/collectd"

The collectd service supports either scanning a directory for multiple types
db files, or specifying a single db file.
A sample `types.db` file
can be found
[here](https://github.com/collectd/collectd/blob/master/src/types.db).

Environment variable: `INFLUXDB_COLLECTD_TYPESDB`

### security-level = "none"

Environment variable: `INFLUXDB_COLLECTD_SECURITY_LEVEL`

### auth-file = "/etc/collectd/auth_file"

Environment variable: `INFLUXDB_COLLECTD_AUTH_FILE`

*The next three options control how batching works.
You should have this enabled otherwise you could get dropped metrics or poor performance.
Batching will buffer points in memory if you have many coming in.*

### batch-size = 5000

The input will flush if this many points get buffered.

Environment variable: `INFLUXDB_COLLECTD_BATCH_SIZE`

### batch-pending = 10

The number of batches that may be pending in memory.

Environment variable: `INFLUXDB_COLLECTD_BATCH_PENDING`

### batch-timeout = "10s"

The input will flush at least this often even if it hasn't reached the configured batch-size.

Environment variable: `INFLUXDB_COLLECTD_BATCH_TIMEOUT`

### read-buffer = 0

UDP Read buffer size, 0 means OS default.
UDP listener will fail if set above OS max.

Environment variable: `INFLUXDB_COLLECTD_READ_BUFFER`

## [[opentsdb]]

Controls the listener for OpenTSDB data.
See the [README](https://github.com/influxdb/influxdb/blob/1.2/services/opentsdb/README.md) on GitHub for more information.

### enabled = false

Set to `true` to enable openTSDB writes.

Environment variable: `INFLUXDB_OPENTSDB_0_ENABLED`

### bind-address = ":4242"

The default port.

Environment variable: `INFLUXDB_OPENTSDB_BIND_ADDRESS`

### database = "opentsdb"

The name of the database that you want to write to.
If the database does not exist, it will be created automatically when the input is initialized.

Environment variable: `INFLUXDB_OPENTSDB_DATABASE`

### retention-policy = ""

The relevant retention policy.
An empty string is equivalent to the database's `DEFAULT` retention policy.

Environment variable: `INFLUXDB_OPENTSDB_RETENTION_POLICY`

### consistency-level = "one"

Sets the write consistency level: `any`, `one`, `quorum`, or `all` for writes.

Environment variable: `INFLUXDB_OPENTSDB_CONSISTENCY_LEVEL`

### tls-enabled = false

Environment variable: `INFLUXDB_OPENTSDB_TLS_ENABLED`

### certificate = "/etc/ssl/influxdb.pem"

Environment variable: `INFLUXDB_OPENTSDB_CERTIFICATE`

### log-point-errors = true

Log an error for every malformed point.

Environment variable: `INFLUXDB_OPENTSDB_0_LOG_POINT_ERRORS`

*The next three options control how batching works.
You should have this enabled otherwise you could get dropped metrics or poor performance.
Only points metrics received over the telnet protocol undergo batching.*

### batch-size = 1000

The input will flush if this many points get buffered.

Environment variable: `INFLUXDB_OPENTSDB_BATCH_SIZE`

### batch-pending = 5

The number of batches that may be pending in memory.

Environment variable: `INFLUXDB_OPENTSDB_BATCH_PENDING`

### batch-timeout = "1s"

The input will flush at least this often even if it hasn't reached the configured batch-size.

Environment variable: `INFLUXDB_OPENTSDB_BATCH_TIMEOUT`

## [[udp]]

This section controls the listeners for InfluxDB line protocol data via UDP.
See the [UDP page](/influxdb/v1.2/write_protocols/udp/) for more information.

### enabled = false

Set to `true` to enable writes over UDP.

Environment variable: `INFLUXDB_UDP_ENABLED`

### bind-address = ":8089"

An empty string is equivalent to `<IP_ADDRESS>`.

Environment variable: `INFLUXDB_UDP_BIND_ADDRESS`

### database = "udp"

The name of the database that you want to write to.

Environment variable: `INFLUXDB_UDP_DATABASE`

### retention-policy = ""

The relevant retention policy for your data.
An empty string is equivalent to the database's `DEFAULT` retention policy.

Environment variable: `INFLUXDB_UDP_RETENTION_POLICY`

*The next three options control how batching works.
You should have this enabled otherwise you could get dropped metrics or poor performance.
Batching will buffer points in memory if you have many coming in.*

### batch-size = 5000

The input will flush if this many points get buffered.

Environment variable: `INFLUXDB_UDP_0_BATCH_SIZE`

### batch-pending = 10

The number of batches that may be pending in memory.

Environment variable: `INFLUXDB_UDP_0_BATCH_PENDING`

### batch-timeout = "1s"

The input will flush at least this often even if it hasn't reached the configured batch-size.

Environment variable: `INFLUXDB_UDP_BATCH_TIMEOUT`

### read-buffer = 0

UDP read buffer size, 0 means OS default.
UDP listener will fail if set above OS max.

Environment variable: `INFLUXDB_UDP_BATCH_SIZE`

### precision = ""

[Time precision](/influxdb/v1.2/query_language/spec/#durations) used when decoding time values.  Defaults to `nanoseconds` which is the default of the database.

Environment variable: `INFLUXDB_UDP_PRECISION`

## [continuous_queries]

This section controls how [continuous queries (CQs)](/influxdb/v1.2/concepts/glossary/#continuous-query-cq) run within InfluxDB.
CQs are automated batches of queries that execute over recent time intervals.
InfluxDB executes one auto-generated query per `GROUP BY time()` interval.

### enabled = true

Set to `false` to disable CQs.

Environment variable: `INFLUXDB_CONTINUOUS_QUERIES_ENABLED`

### log-enabled = true

Set to `false` to disable logging for CQ events.

Environment variable: `INFLUXDB_CONTINUOUS_QUERIES_LOG_ENABLED`

### run-interval = "1s"

The interval at which InfluxDB checks to see if a CQ needs to run. Set this option to the lowest interval at which your CQs run. For example, if your most frequent CQ runs every minute, set `run-interval` to `1m`.

Environment variable: `INFLUXDB_CONTINUOUS_QUERIES_RUN_INTERVAL`

gha_language: Less


text:
# Self-Driving Car Project 9. PID Control

## Overview

This project implements a [PID controller](https://en.wikipedia.org/wiki/PID_controller) to control a car in the car simulator([which can be downloaded here](https://github.com/udacity/self-driving-car-sim/releases)). The simulator sends cross-track error, speed and angle to the PID controller using [WebSocket](https://en.wikipedia.org/wiki/WebSocket) and it receives the steering angle ([-1, 1] normalized) and the throttle to drive the car. The PID uses the [uWebSockets](https://github.com/uNetworking/uWebSockets) WebSocket implementation.

## Dependencies

* cmake >= 3.5
 * All OSes: [click here for installation instructions](https://cmake.org/install/)
* make >= 4.1(mac, linux), 3.81(Windows)
  * Linux: make is installed by default on most Linux distros
  * Mac: [install Xcode command line tools to get make](https://developer.apple.com/xcode/features/)
  * Windows: [Click here for installation instructions](http://gnuwin32.sourceforge.net/packages/make.htm)
* gcc/g++ >= 5.4
  * Linux: gcc / g++ is installed by default on most Linux distros
  * Mac: same deal as make - [install Xcode command line tools]((https://developer.apple.com/xcode/features/)
  * Windows: recommend using [MinGW](http://www.mingw.org/)
* [uWebSockets](https://github.com/uWebSockets/uWebSockets)
  * Run either `./install-mac.sh` or `./install-ubuntu.sh`.
  * If we install from source, checkout to commit `e94b6e1`, i.e.
    ```
    git clone https://github.com/uWebSockets/uWebSockets
    cd uWebSockets
    git checkout e94b6e1
    ```
    Some function signatures have changed in v0.14.x. See [this PR](https://github.com/udacity/CarND-MPC-Project/pull/3) for more details.
* Simulator. We can download these from the [project intro page](https://github.com/udacity/self-driving-car-sim/releases) in the classroom.

There's an experimental patch for windows in this [PR](https://github.com/udacity/CarND-PID-Control-Project/pull/3).

## Basic Build Instructions

1. Clone this repo
2. Make a build directory: `mkdir build && cd build`
3. Compile: `cmake .. && make`
4. Run it: `./pid`

Tips for setting up our environment can be found [here](https://classroom.udacity.com/nanodegrees/nd013/parts/40f38239-66b6-46ec-ae68-03afd8a601c8/modules/0949fca6-b379-42af-a919-ee50aa304e6a/lessons/f758c44c-5e40-4e01-93b5-1a82aa4e044f/concepts/23d376c7-0195-4276-bdf0-e02f1f3c665d)

## Editor Settings

Here in this project, we use the following settings:
* Indent using spaces
* Set tab width to 4 spaces (keeps the matrices in source code aligned)

## Coding Style

Please (do our best to) stick to [Google's C++ style guide](https://google.github.io/styleguide/cppguide.html).

## Test the PID Controller

### Start the Simulator

Here is the start view of the simulator:

![Start View of the Simulator](README-images/start.png)

(Note: Click the "Select" button to start the simulation.)

### Start the PID Controller

Run the `./pid`, and here is the output:
```
Listening to port 4567
Connected!!!
```

which means the our PID controller has connected to the simulator successfully.

### PID Controller with Final HyperParameters

The PID controller built with the final hyperparameters can successfully drive more than one lap around the track. And, this is a short video of the driving: [./README-videos/PID-with-final-parameters.mov](./README-videos/PID-with-final-parameters.mov).

And, here is a snapshot on the execution log of the PID controller in the terminal:
![PID with Final HyperParameters Log](./README-images/PID-with-final-parameters-log.png)

### PID Controller with Only the Proportional Component

The proportional component tries to steer the car toward the center line (against the cross-track error). If only the proportional component is used, the car overshoots the central line very easily and go out of the road very quickly. Here is an example video recording on only this component is used: [./README-videos/PID-with-only-proportional.mov](./README-videos/PID-with-only-proportional.mov).

And, here is a snapshot on the execution log of the PID controller in the terminal:
![PID with Final HyperParameters Log](./README-images/PID-with-only-proportional-log.png)

### PID Controller with Only the Integral Component

The integral component tries to eliminate a possible bias on the controlled system that could prevent the error from being eliminated. If only the proportional component is used, it makes the car to go in circles. In the case of the simulator, no bias is present. Here is an example video recording on only this component is used: [./README-videos/PID-with-only-integral.mov](./README-videos/PID-with-only-integral.mov).

And, here is a snapshot on the execution log of the PID controller in the terminal:
![PID with Final HyperParameters Log](./README-images/PID-with-only-integral-log.png)

### PID Controller with Only the Differential Component

The differential component helps to counteract the proportional trend to overshoot the center line by smoothing the approach to it. Here is an example video recording on only this component is used: [./README-videos/PID-with-only-differential.mov](./README-videos/PID-with-only-differential.mov).

And, here is the execution log of the PID controller in the terminal:
![PID with Final HyperParameters Log](./README-images/PID-with-only-differential-log.png)

### Choose the Final HyperParameters

The hyperparameters were chosen manually by try and error as in following steps:

**Step 1**. Make sure the car can drive straight with all the hyperparameters as 0.0

**Step 2**. Add the proportional component, and we can see that the car starts going on following the road but it starts overshooting and then goes out of the road

**Step 3**. Add the differential component to try to smooth the overshooting

**Step 4**. We can try to use the integral component but we can see that it only moves the car out of the road, so let's make it 0.0

**Step 5**. Now we can see that the car can drive without going out of the road, we can try to increase the parameters to minimize the average cross-track error on a single track lap

After the try and error, here are the final hyperparameters:

| HyperParameter | Value |
| :------------- | :---- |
| P | 1.4 |
| I | 0.0 |
| D | 2.6 |

## Implementation of the PID Controller

The PID procedure follows what was taught in the lessons. The PID implementation is in the [./src/PID.cpp](./src/PID.cpp). The method [PID::UpdateError](./src/PID.cpp#L34) calculates proportional, integral and derivative errors and the [PID::GetTotalError](./src/PID.cpp#L60) calculates the total error using the appropriate coefficients.

repository: wuzhanglin/CarND-PID-Control-Project

repo_name: wuzhanglin/CarND-PID-Control-Project