text:
---
title: "Modals"
asOf: 1.0.0
description: "A modal is a smaller window that is displayed on top of the main application/site window. The main page is still visible, but the background is darkened to direct focus to the content of the modal window."
requiresJs: true
status: "Ready"
methods:
    -
        title: "Modal.init(context)"
        description: |
            - Initializes the `Modal` component
            - Accepts an optional DOM element. If no element is provided in the argument it defaults to the `document` element.
            - NOTE: the `init()` method is called automatically when `rivet.js` is loaded.
    -
        title: "Modal.destroy(context)"
        description: |
            - Destroys any currently initialized Modals and removes their event listeners.
            - Accepts a optional DOM element. If no element is provided in the argument it defaults to the `document` element. **NOTE**: the optional `context` argument only needs to be passed into `.destroy()` if a DOM element was passed into the `.init()` method. If so, it must be the DOM element that was passed into `.init()` when the Modal was initialized.
    -
        title: "Modal.open(id, callback)"
        description: |
            - `id` - The unique id of the Modal. This corresponds to the value `data-modal-trigger`/`id` attributes of the modal you want to **open**. **NOTE**: In previous versions of Rivet, the `Modal.open()` method accepted a Modal DOM Element. The `.open()` method will still work if you pass it a DOM element (the modal element itself), but **this functionality will be deprecated in the next major version of Rivet**.
            - `callback` - An optional callback function that is executed after the modal is opened.
    -
        title: "Modal.close(id, callback)"
        description: |
            - `id` - The unique id of the modal. This corresponds to the value `data-modal-trigger`/`id` attributes of the modal you want to **close**.
            - `callback` - An optional callback function that is executed after the modal is opened.
            - **NOTE**: In previous versions of Rivet, the `Modal.close()` method accepted a Modal DOM Element. The `.close()` method will still work if you pass it a DOM element (the Modal element itself), but **this functionality will be deprecated in the next major version of Rivet**.
    -
        title: "Modal.focusModal(id)"
        description: |
            Moves focus the currently active/open modal. This is a helper method that can be used to focus modals that have been opened programmatically via the `Modal.open()` method. It takes one argument, the unique id (String) of the modal you wan to move focus to. This method can be used as the callback to the `Modal.open()` method to move focus to the modal after it has been opened via your own scripts.
    -
        title: "Modal.focusTrigger(id)"
        description: |
            Moves focus to the trigger (`data-modal-trigger`) that opened the currently active modal, if it exists.

events:
    -
        title: "modalOpen"
        description: |
            Emitted when the Modal is opened (using the `Modal.open()` method, or the `data-modal-trigger` attribute). The value of the modal `id` attribute is also passed along via the custom event’s detail property and is available to use in your scripts as `event.detail.name()`
    -
        title: "modalClose"
        description: |
            Emitted when the Modal is closed (using the `Modal.close()` method, or the `data-modal-trigger` attribute). The value of the modal `id` attribute is also passed along via the custom event’s detail property and is available to use in your scripts as `event.detail.name()`
---
{{< alert variant="warning" title="Migrating to Rivet 2" >}}
This version of Rivet is deprecated. [View the dialog documentation on the Rivet 2 website](https://v2.rivet.iu.edu/docs/components/dialog/).
{{< /alert >}}

## Modal example
{{< example lang="html" >}}<button type="button" class="rvt-button" data-modal-trigger="modal-example-basic">Open modal example</button>

Modal title

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

            <button type="button" class="rvt-button">OK</button>
            <button type="button" class="rvt-button rvt-button--secondary" data-modal-close="modal-example-basic">Cancel</button>

        <button type="button" class="rvt-button rvt-modal__close" data-modal-close="modal-example-basic">
            Close
            <svg aria-hidden="true" xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewBox="0 0 16 16">
                <path fill="currentColor" d="M9.41,8l5.29-5.29a1,1,0,0,0-1.41-1.41L8,6.59,2.71,1.29A1,1,0,0,0,1.29,2.71L6.59,8,1.29,13.29a1,1,0,1,0,1.41,1.41L8,9.41l5.29,5.29a1,1,0,0,0,1.41-1.41Z"/>
            </svg>
        </button>

{{< /example >}}

## When to use
- For single specific tasks related to a goal on the main page of the application
- To help users determine information needed in their main workflow e.g. calculating a number, looking up a code

## When to consider something else
- When you need to display an error message consider using an [alert]({{< relref "alerts.md" >}}) on the page in which the error occurred.
- When you need to display large amounts of information for multiple tasks consider using a dedicated page instead.

## Implementation notes
The modal component is made up of the following elements:

- `.rvt-modal` and `.rvt-modal__inner` - An overlay and inner container, which wraps all other elements
- `.rvt-modal__header` — A header with a title that is used to label the modal
- `.rvt-modal__body` — A modal body that holds the main content of the modal
- `.rvt-modal__controls` — An optional footer element that holds modal controls, like "Save" and "Cancel"
- `.rvt-modal__close` — An optional close button at the top of the modal

### Required elements
The only elements required in order for the modal to work are the `.rvt-modal`, `.rvt-modal__inner`, and `.rvt-modal__body`, but it is advisable to use the `.rvt-modal__header` element to help describe what the modal is use for. Likewise, the `.rvt-modal__controls` element provides an easy way to add additional actions to the modal like "Save" and "Close".

### Modal controls
The `.rvt-modal__controls` element provides a space to add additional controls like buttons. It is advisable to **stick to one or two buttons** action buttons in a modal. The primary action should **always appear as the left-most button** in the group with secondary actions, like "Cancel" appearing after.

### Modal set up
To use the modal component you'll need to do a few things. First, add the markup to your document.

{{}}<button type="button" class="rvt-button" data-modal-trigger="my-modal-id">Open the modal</button>

    modal markup here...

    <button type="button" class="rvt-button rvt-button--plain rvt-modal__close" data-modal-close="my-modal-id">
        button markup here...
    </button>

{{}}

In the code above, `my-modal-id` should correspond to the `id` attribute on the the `.rvt-modal` container and the `data-modal-trigger` attribute on a `<button>` element that triggers the modal.

The `data-modal-close` attribute is used as a hook to close the modal. You can add the `data-modal-close` attribute to other buttons in the modal like a "**Cancel**" button if you need to allow users other options for closing the modal. The value of `data-modal-close` should be the same as the `id` attribute of the modal it closes.

Multiple modals can be placed on the same page, as long as each has a unique `id` and corresponding `data-modal-trigger` element.

## Modal dialog
We use the generic term "Modal" to mean any smaller window that is displayed on top of the main application, but there are some subtle differences between a modal and a dialog.

A modal dialog is similar to a regular modal except that **it requires the user to interact with it** before continuing any interaction with the main application. The user must select from the available actions in the dialog—they cannot disregard and simply close the window.

{{< example lang="html" >}}<button type="button" class="rvt-button" data-modal-trigger="modal-dialog-example">Open modal dialog</button>

Modal Dialog

A modal dialog:

Is not dismissible i.e. doesn't have an (X) button

Requires user input before they continue their work

            <button type="button" class="rvt-button">Yes</button>
            <button type="button" class="rvt-button rvt-button--secondary" data-modal-close="modal-dialog-example">No, thanks</button>

{{< /example >}}

### When to use a dialog
- Confirmation dialogs are used to verify the action a user selected, especially when that action will result in the loss of data. For example, ‘All files in this folder will be deleted. Do you want to continue?’
- Provide the user with clarifying information before they continue with a task or action. For example, "A 10% fee will be charged to your account. Do you want to continue?"

### When to consider something else
- Do not use to second guess the users’ choice of actions when no destruction or loss of data will occur.
- When you need to create a focused space for users to complete a small subtask, use a regular modal instead.

## Accessibility notes
- When a modal is opened the modal itself receives focus, so that screen readers begin at the top of the modal content.
- When the modal is closed the focus should be returned to the button/trigger that was used to open the modal so that keyboard only users and those using assistive technologies do not lose their place in the document.
- A modal should trap focus inside of itself so that when a keyboard-only user navigates from the last focusable element in the modal it returns back to the first focusable element.

## Microcopy notes
Follow [UX Planet’s recommendations for modal text](https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows-c00c66cddd8c):

- The button that launches the modal should clearly describe the action (“Submit feedback”)
- Use the launch button text as the modal title. This reminds the user what to do, within the context of the overall page.

## JavaScript API
If you use the appropriate data attribute/id combination in your markup, modals will work without the need for any additional JavaScript. But if you need to control the modal programmatically, there are a handful of methods from the Rivet modal’s API you can use:

{{< apidocs type="methods" >}}{{< /apidocs >}}

### Managing focus
When a modal is triggered using the default data attribute method via a click event on the modal trigger (`data-modal-trigger`), the modal script will store a reference to the element that triggered it, and return focus to that element when the modal is closed.

**Please note**: If you open the modal programmatically using `Modal.open()` based on some other event, it is your responsibility to return focus to the appropriate element after the modal is closed. The `.focusTrigger()` method can be combined with the `.close()` method's callback function to accomplish this.

{{}}Modal.close('my-modal-id', function() {
    Modal.focusTrigger('my-modal-id');
});
{{}}

### Custom Events
The Rivet Modal also emits various custom events that you can listen for in your own scripts.

{{< apidocs type="events" >}}{{< /apidocs >}}

#### Custom event example
Note here that the `event.detail.name()` property of the `customEvent` object is a function that returns a String. Read more about custom events on the [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent).

{{}}// Listen for a custom "modalOpen" event
document.addEventListener('modalOpen', event => {
  if (event.detail.name() === 'my-modal') {
    alert('Hey, you opened the modal!')
  }
  // Maybe send some data via an AJAX request, etc...
}, false);
{{}}

repository: indiana-university/rivet-docs

branch_name: refs/heads/develop

repo_name: indiana-university/rivet-docs


text:
# cdl-2020-hackathon

This repository is created for participatoin to the hackathon of the 2020 [Quantum stream of Creative Destruction Lab](https://www.creativedestructionlab.com/streams/quantum/).
We have taken the challenge by DWave to address our first attempts of floorplanning design. Floorplanning is used in electronic design automation (EDA) for schematics representation of tentative placement of major functional blocks in an integrated circuit.

System large-scale integration (LSI) or system-on-a-chip (SoC) is an essential device in today’s highly sophisticated information society. System LSI is already used widely in the world such as personal computers, servers, mobile phones, automobiles, and consumer electronics. Many SoCs with higher information processing are expected to be more and more needed. In these kinds of system designs, it is required to design a high-performance and small area of a system LSI with a lower cost and a shorter time period. A chip planner is a central tool in hierarchical top-down very-large-scale integration (VLSI) design. The set of the transistors of a circuit is assumed to be divided into so-called `cells` in form of a hierarchical wiring diagram. The chip planner is meant to place the cells of one hierarchy level onto a given area nearly optimally.

Floorplanning is an instance of the so called bin packing or pallet loading problem.
Other applications include:
- _cutting stock_ problem
- _filling up containers_
- _loading with weight capacity constraints_
- _creating file backups in media_
- other _technology mappings in semiconductor chip design_.

## This repository contains:
- Code for formulating a QUBO instance of rectangle packing problem by several different approaches in `drafts` directory
- Code for running the QUBO on DWave machine or simulators or hybrid in `dwave_solution` directory`
- Tools for vizualization in the `plаnner` directory
- A jupyter notebook for a demo

license: MIT

branch_name: refs/heads/master

extension: md

gha_language: Jupyter Notebook

gha_license_id: MIT

license_type: permissive


text:
# polarishub
A p2p file transfer program via LAN.

## Implementation
This program is implemented with Django Framework. External libraries required: MyQR for generating QR code.

## Usage
1. Before start using it, run setup.py or dist/setup/setup.exe or simply dist/setup.bat to initialize your PolarisHub.
2. Then, you can run *python manage.py runserver <IP_ADDRESS>:8000* or simply dist/polarishub.bat to turn on your PolarisHub.
3. You will then generate a server end with the local IP and port 8000 (can be changed manually). Enter localhost:8000 in your Browser to manage your PolarisHub.
4. You can easily share your document with your url or a QR code to your friend. As long as you are under the same LAN, your friend can get access to your documents with high speed.
5. Once you finish sharing, close the console application to shutdown.

repository: XieGuochao/polarishub

repo_name: XieGuochao/polarishub


text:
# PageableAR
Model, Collection, and Pageable Collection for Angular Active Record

## Installation
```
bower install PageableAR
```

## Demo
Click [here](https://rawgit.com/twhtanghk/PageableAR/master/test/test.html) for demo

## Usage
Follow the prototype of Model, Collection, and PageableCollection defined in [backbonejs](http://backbonejs.org/)
```
  $scope.collection = new pageableAR.Collection (i for i in [1..100])
  $scope.controller = new ListView collection: $scope.collection

  <ul ng-controller="ListCtrl">
	<li ng-repeat="model in collection.models">{{model}}</li>
	<div infinite-scroll="controller.loadMore()"></div>
  </ul>
```

To interface with socket.io (sails) server, simply call setTransport to override the static method pagaeble.Model.sync with the pre-defined pageableAR.Model.iosync. The default is to interface with restful Web Server by pageableAR.Model.restsync. The following module is to define the default model interface to be 'io' and Device model interface to be other restful Web Server.
```
angular.module('model', ['PageableAR'])
	.factory 'resource', (pageableAR) ->
		pageableAR.setTransport(pageableAR.Model.iosync)

		urlRoot = (model, url, root = '/context') ->
			if model.transport() == 'io' then "#{url}" else "#{root}#{url}"

		class RosterItem extends pageableAR.Model
			$urlRoot: ->
				urlRoot(@, '/api/roster')

		class Device extends pageableAR.Model
			$urlRoot: ->
				urlRoot(@, '/api/device', 'https://mob.myvnc.com/device')

			@sync: pageableAR.Model.restsync

		RosterItem: RosterItem
		...
```

repository: twhtanghk/PageableAR

repo_name: twhtanghk/PageableAR


text:
# Steps

## Install Ruby:
Reference: https://guides.rubyonrails.org/getting_started.html#installing-ruby

`brew install ruby`
`ruby -v`
    `ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin19]`

`brew install rbenv`

## Install Rails
https://guides.rubyonrails.org/getting_started.html#creating-a-new-rails-project-installing-rails-installing-rails

`gem install rails`
`rbenv rehash`
`rails -v`
    `Rails <IP_ADDRESS>`

## Install Node.js and yarn
https://guides.rubyonrails.org/getting_started.html#installing-node-js-and-yarn

`node -v`
    `v12.19.0`

## Install yarn
`yarn -v`
    `1.22.10`

 ## Install SQLite3
 https://guides.rubyonrails.org/getting_started.html#installing-sqlite3

`sqlite3 --version`
    `3.28.0`

 ## New rails application

 `rails new instautomation`

 <!-- ## Install Bundler

`gem install bundler` -->

 ## Go to the app

 `cd instautomation`

 ### Things that maybe be aditionally needed

 ```
 Webpacker requires Node.js >= 8.16.0 and you are using 8.15.0
Please upgrade Node.js https://nodejs.org/en/download/
```

Do:
* `nvm install 12`
* `nvm use 12`

 ## Start the server

 ```
 rails server
 ```

 * Open: <IP_ADDRESS>:3000

 ### Errors:

 ```
 Webpacker configuration file not found /Users/elizabethflores/dev/instautomation-test/instautomation/config/webpacker.yml. Please run rails webpacker:install Error: No such file or directory @ rb_sysopen - /Users/elizabethflores/dev/instautomation-test/instautomation/config/webpacker.yml (RuntimeError)
 ```

 Run:
 ```
 rails webpacker:install
 ```

```
Yarn not installed. Please download and install Yarn from https://yarnpkg.com/lang/en/docs/install/
```

```
brew install yarn
```

```
yarn install
```

## Run Tests

```
rails test
```

Will see:

```
/Users/elizabethflores/dev/instautomation-test/instautomation/db/schema.rb doesn't exist yet. Run `rails db:migrate` to create it, then try again. If you do not intend to use a database, you should instead alter /Users/elizabethflores/dev/instautomation-test/instautomation/config/application.rb to limit the frameworks that will be loaded.
```

* Run: `rails db:migrate`

* Run tests again: `rails test`

```
Running via Spring preloader in process 73961
Run options: --seed 26301

# Running:

Finished in 0.124719s, 0.0000 runs/s, 0.0000 assertions/s.
0 runs, 0 assertions, 0 failures, 0 errors, 0 skips
```

* Run tests with verbose: `rails test -v`
```
Running via Spring preloader in process 32757
Run options: -v --seed 26094

# Running:

PhotosControllerTest#test_should_get_index = 0.13 s = .

Finished in 0.170620s, 5.8610 runs/s, 5.8610 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
```

## Deployment to Heroku

> Based on: https://guides.railsgirls.com/heroku

* Follow https://devcenter.heroku.com/articles/getting-started-with-ruby

### Heroku Setup
`brew install heroku/brew/heroku`
`bundle config set without 'production'`

### Create the app in Heroku

`heroku create [APP_NAME]`
`heroku buildpacks:set heroku/ruby`
`git push heroku main`

### Deployment to heroku

> Need to connect the repository in Heroku.

* Go to: https://dashboard.heroku.com/apps/instautomation-test-1/deploy/github
* Click on Connect to GitHub
* Authorize Heroku App
* Choose the repository you want to deploy
* Enable Automatic Deployments

## Instructions

### Local Setup
1. Clone repository: `git clone ...`
1. cd `repository`
1. `ruby -v`
1. `rails -v`
2. `rails db:migrate`
3. `rails test`
4. `rails server`
5.  Open: http://<IP_ADDRESS>:3000

### Heroku

#### Create new app

1. Go to: https://dashboard.heroku.com/new-app
1. Select an app name
1. Select a region

#### Connect to GitHub in Heroku

1. Select the app you created
1. Go to the Deploy Tab and Select GitHub: https://dashboard.heroku.com/apps/powerful-ridge-83474/deploy/github
1. Click on Connect to GitHub
1. This will redirect you to GitHub where you need to authorize the Heroku App
1. Back in Heroku, enter the GitHub repository name
1. Click on _Search_
1. You will see the repository name: `ely-saucelabs/instautomation-test`
1. Click on Connect
1. Choose the `main` branch

#### Create a deployment pipeline

1. Select the app you created
1. Go to the Deploy Tab and on the _Add this app to a pipeline_, select _Choose a pipeline_ -> _Create new pipeline_, e.g. instautomation-deployment
1. Choose a stage to add this app to and select _production_ (we won't have a _staging_ / _uat: user acceptance testing_ environment in this case)
1. Click on  _Create pipeline_
1. On the pipeline page, we will enable the _Review Apps_ feature.
1. Click on _Connect to GitHub_
1. In _Search for a repository to connect to_, select the repository name: `instautomation-test`
1. Click on _Search_
1. You will see the repository name: `ely-saucelabs/instautomation-test`
1. Click on Connect
1. In _Review apps_, click on _Enable_
1. Select _Create new review apps for new pull requests automatically_
1. Select _Destroy stale review apps automatically_ (you can leave the default 5 days)
1. Choose a region that is closer to you :)
1. Click on Enable Review Apps

repository: SadiePeregrine/instautomation

branch_name: refs/heads/main

gha_language: Ruby

repo_name: SadiePeregrine/instautomation


text:
# CLI

[![Documentation][godoc-img]][godoc-url]
![License][license-img]
[![Build Status][action-img]][action-url]
[![Coverage][codecov-img]][codecov-url]
[![Go Report Card][report-img]][report-url]

A simple package for building command line applications in Go. The API is
influenced by https://github.com/urfave/cli package, but it is way more
flexible. It provides the following features:

- More extensible flag types such as URL, IP, JSON, YAML and so on. For more information see the [docs][godoc-url]
- Data providers that allow setting the flag's value from different sources such as command line arguments, environment variables and [etc](https://github.com/hairyhenderson/go-fsimpl).
- Data conversion that allow conversion of data to a compatible data type accepted by the declared flag

## Installation

Make sure you have a working Go environment. Go version 1.16.x is supported.

[See the install instructions for Go](http://golang.org/doc/install.html).

To install CLI, simply run:

```
$ go get github.com/phogolabs/cli
```

## Getting Started

```golang
package main

import (
	"fmt"
	"os"
	"syscall"

	"github.com/phogolabs/cli"
)

var flags = []cli.Flag{
	&cli.YAMLFlag{
		Name:     "config",
		Usage:    "Application Config",
		Path:     "/etc/app/default.conf",
		EnvVar:   "APP_CONFIG",
		Value:    &Config{},
		Required: true,
	},
	&cli.StringFlag{
		Name:     "listen-addr",
		Usage:    "Application TCP Listen Address",
		EnvVar:   "APP_LISTEN_ADDR",
		Value:    ":8080",
		Required: true,
	},
}

func main() {
	app := &cli.App{
		Name:      "prana",
		HelpName:  "prana",
		Usage:     "Golang Database Manager",
		UsageText: "prana [global options]",
		Version:   "1.0-beta-04",
		Flags:     flags,
		Action:    run,
		Signals:   []os.Signal{syscall.SIGTERM},
		OnSignal:  signal,
	}

	app.Run(os.Args)
}

// run executes the application
func run(ctx *cli.Context) error {
	fmt.Println("Application started")
	return nil
}

// signal handles OS signal
func signal(ctx *cli.Context, signal os.Signal) error {
	fmt.Println("Application signal", signal)
	return nil
}
```

## Validation

You can set the `Required` field to `true` if you want to make some flags
mandatory. If you need some customized validation, you can create a custom
validator in the following way:

As a struct that has a `Validate` function:

``` golang
type Validator struct{}

func (v *Validator) Validate(ctx *cli.Context, value interface{}) error {
	//TODO: your validation logic
	return nil
}
```

Then you can set the validator like that:

```golang
var flags = []cli.Flag{
	&cli.StringFlag{
		Name:      "name",
		EnvVar:    "APP_NAME",
		Validator: &Validator{},
	},
}
```

## Contributing

We are open for any contributions. Just fork the
[project](https://github.com/phogolabs/cli).

[report-img]: https://goreportcard.com/badge/github.com/phogolabs/cli
[report-url]: https://goreportcard.com/report/github.com/phogolabs/cli
[codecov-url]: https://codecov.io/gh/phogolabs/cli
[codecov-img]: https://codecov.io/gh/phogolabs/cli/branch/master/graph/badge.svg
[action-img]: https://github.com/phogolabs/cli/workflows/main/badge.svg
[action-url]: https://github.com/phogolabs/cli/actions
[godoc-url]: https://godoc.org/github.com/phogolabs/cli
[godoc-img]: https://godoc.org/github.com/phogolabs/cli?status.svg
[license-img]: https://img.shields.io/badge/license-MIT-blue.svg
[software-license-url]: LICENSE

repository: phogolabs/cli

gha_language: Go

repo_name: phogolabs/cli


text:
# Brayn (community version)
Brayn is a B2B product used by SMEs to Visualize, Analyse and also predict their Data. Any customer can use and make use of brayn with no prior knowledge in statistics or technology
https://youtu.be/OluMyfE7muY

This is the  downloadable community version. We are open for contributions, feel free to fork it.

# Main Contribution Credits

Vatsa Prahallada (https://www.linkedin.com/in/shrivatsaprahallada/)

Shrikar Nag (https://www.linkedin.com/in/shrikarnag/)

Lohith Dayananda Ram (https://www.linkedin.com/in/lohith-d-ram-aba55b17/)

Ranjitha Rao (https://www.linkedin.com/in/ranjitha-rao-72927429/)

Vishwanath C (https://www.linkedin.com/in/vishwanath-chennakrishnappa-706063140/)

Vijeth Simha (https://www.linkedin.com/in/vijeth-simha-0aa0a5146/)

Deepashree Abhaya

# How To Run project

step1: git clone https://github.com/Quanscendence/braynai.git

step2: create Virtual environment and activate it.

step3: cd into braynai

step4:CMD pip install -r requirements.txt #To install requirements

sep5: Update  DB,SENDINBLUE_API_KEY,Google Cloud credentials.json in Setting.py

step6:  update razor pay credentials

step7: python manage.py makemigrations

step8: python manage.py migrate

step9: python manage.py runserver

visit http://<IP_ADDRESS>:8000 to visit the site

#contact

mailto<EMAIL_ADDRESS>

repository: Quanscendence/braynai

repo_name: Quanscendence/braynai


text:
//[sdk](../../../index.md)/[com.swedbankpay.mobilesdk](../index.md)/[RiskIndicator](index.md)/[preOrderDate](pre-order-date.md)

# preOrderDate
[androidJvm]
Content
@(value = preOrderDate)

val [preOrderDate](pre-order-date.md): [String](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-string/index.html)?
More info

If this is a pre-order, the expected date that the merchandise will be available on.

Format is YYYYMMDD. You can use [formatPreOrderDate](-companion/format-pre-order-date.md) to format some common local-date types correctly.

repository: SwedbankPay/swedbank-pay-sdk-android

gha_language: Kotlin

repo_name: SwedbankPay/swedbank-pay-sdk-android


text:
## Uploader

Use the WAD Uploader to add files you want to inspect with wadJS. Supported file formats are `.wad`, `.zip`, `.pk3`, and `.json`.

You can upload multiple files from your device.

Alternatively, you can upload one file at a time from the Internet by entering a URL and also specify the name of the file. It is recommended to add the file extension to the file name (e.g., "doom1.wad") for clarity.

Zipped files (including PK3s) must contain only one WAD file to be processed. The handling of compressed files containing more than one WAD file or nested zipped files will be added at a later date.

You can import JSON copies of WAD files that were created via the wadJS export functionality. JSON files are more lightweight than WAD files and they are already parsed. This means that uploading an exported WAD is faster than re-uploading the original binary file. Exporting your WADs as JSON is a great way to back up your work and restore it quickly as needed.

You can upload a file with the same name multiple times. This allows you to compare different versions of a WAD.

Additionally, all the files you upload to wadJS are kept in the memory of your device's browser. This means that you can close the web page or refresh it without having to reupload all your files afterwards.

Please note that it is usually necessary to use an IWAD as a reference when loading a PWAD, especially if the PWAD does not have data concerning the play palettes. If you do not link your PWADs to an IWAD, you might not be able to preview certain resources such as sprites, textures, patches, etc. If you link a PWAD to the incorrect IWAD, the colors of its graphic assets might be weird depending on the play palettes of the IWAD. To remedy to this issue, make sure that you upload the necessary IWAD first, and then select this IWAD when uploading PWADs.

## Uploaded WADs

This list of uploaded WADs allows you to browse between the different WADs you have added to wadJS.

The WADs of the same type (IWADs a.k.a Internal Wads and PWADs a.k.a Patch Wads) are displayed in their own group. This allows for more clarity on your list of uploaded WADs.

Clicking on ![trash](./static/trash.svg) will remove all the uploaded WADs from the list.

Clicking on ![code file](./static/codefile.svg) will export all the uploaded WADs as a JSON file that can be imported to wadJS later.

## WAD Name and Metadata

On this panel, you can see some data about the WAD, including its type (IWAD vs PWAD) and the size of the uploaded binary file.

You can also change the filename to your convenience, but it can not be empty.

Clicking on ![trash](./static/trash.svg) will remove the WAD from your list.

Clicking on ![code file](./static/codefile.svg) will export the WADs as a JSON file that can be imported to wadJS later.

## Lumps

You can select the type of lumps you wish to view within a selected WAD.

Typical categories are "Maps", "Sounds", "Sprites", etc. If you do not find a lump in the expected category, you can always take a look into "Uncategorized", where you will find miscellani lumps along unsupported lump types.

## WAD Lumps

This part of the application shows details about the lumps that belong to a specific type.

If the WAD was provided the right palette, you should be able to view graphics in details.

## Settings

In the settings menu, you can adjust the behavior of wadJS:
* Play music in a loop: Turning this feature ON means that the media player will continue playing music once it reaches the end of a track.

* Play next available track: Turning this feature ON means that the player will cycle through all the music in your uploaded WADs.

repository: yvesgurcan/wadjs

gha_language: JavaScript

repo_name: yvesgurcan/wadjs


text:
# WebravoLab Layers

## Changes Log

### Ver. 1.0.44

* Allow passing override options array to CdnService constructor

### Ver. 1.0.43

* Added function checkImageExists() to CdnService

### Ver. 1.0.42

* Added new functions to CdnService to interact with Google Storage Buckets
    * downloadImageFromCdn
    * createBucket
    * deleteBucket
    * checkBucketExists
* Added HISTORY.md with changes log

### Ver. 1.0.41

* ConfigurationService: override settings through DB table could override also a class, using sintax: class.variable

### Ver. 1.0.40

* Configuration: added method:
    * set - to set/overwrite a value in settings table
    * delete - to delete a value from settings table

### Ver. 1.0.39

* ConfigurationService: added method:
    * setKey - to set/overwrite a value in settings table
    * deleteKey - - to delete a value from settings table

### Ver. 1.0.38

* AbstractValueObject: removed setValue() method to make value objects immutable.

### Ver. 1.0.37

* StackDriverLogger: use RFC3339_EXTENDED format for timestamps, to include milliseconds.

### Ver. 1.0.36

* ConfigurationService: added try/catch to avoid any error in override

### Ver. 1.0.35

* StackDriverLogger: improved parsing more date formats in message

### Ver. 1.0.34

* StackDriverLogger: parse RFC3339 and ISO date formats included in message and use it as timestamp (to ingest external loggers)

### Ver. 1.0.33

* CdnService: handle gzip compression in upload
* CdnService: handle image deleting either with a normal path or google storage standard format /b/.../o/...
* CdnService: handle errors 204/404

### Ver. 1.0.32

* Fixed README.md

### Ver. 1.0.31

* Added config/rabbitmq.php
* Updated README.md

repository: webravolab/layers

repo_name: webravolab/layers


text:
UNMAINTAINED
============
This project is not maintained anymore.
If you want to take over contact us at<EMAIL_ADDRESS>
# websocket-benchmark
Run concurrent WebSocket clients and measure the roundtrip-time.

The server is expected to copy every message it receives back to the client!
```
npm install -g websocket-benchmark
```

```
Usage: node websocket-benchmark -h [host] -n [clients] -c [concurrency] -r [roundtrips] -s [size]

Options:
  -h  Host to connect to (e.g. "ws://<IP_ADDRESS>/echo/websocket")  [required]
  -n  Number of clients to create                                  [default: 1000]
  -c  Number of concurrent clients                                 [default: 1]
  -r  Number of roundtrips to the server each client should do     [default: 5]
  -s  Size of the message to send                                  [default: 30]
```

## Example
```
websocket-benchmark -h 'ws://echo.websocket.org/' -n 1000 -c 10
```

```
Starting 1000 clients doing 5 roundtrips to `ws://echo.websocket.org/`.
Min: 882ms
Mean: 905ms
Max: 921ms
```


text:
## Examples using the mongofs store

Mongofs is a repo store implemented using the mongodb cloud database. It is implemented here.

The mongodb database is not installed by the wizzi factory. You must pass a valid connection uri to the wizzi factory in the configuration parameter.
```javascript
//TODO
```

repository: wizzifactory/wizzi

repo_name: wizzifactory/wizzi


text:
---
layout:     post
categories: 1-recipe-snack
title:      Salmon Pate
---

### Ingredients

_2 servings_

* 240g Tinned Red Salmon
* Juice of half a lemon
* 24ml olive oil
* ½ clove of garlic grated
* 100g cottage cheese or 75g sour cream
* Small handful chopped dill

### Method

For dip: Drain the salmon completely then add all ingredients apart from dill to a food processor and blend until a paste is formed, finish by stirring through the dill.

To serve: Eat dip with 3 wholemeal rice crackers or 3 large salt and vinegar snackajacks.

_Tips: Substitute the salmon for tuna or mackerel._

repository: jonnyburch/recipes

gha_language: HTML

repo_name: jonnyburch/recipes


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

### Description

In PHP through 5.6.33, 7.0.x before 7.0.28, 7.1.x through 7.1.14, and 7.2.x through 7.2.2, there is a stack-based buffer under-read while parsing an HTTP response in the php_stream_url_wrap_http_ex function in ext/standard/http_fopen_wrapper.c. This subsequently results in copying a large string.

### POC

#### Reference
- https://bugs.php.net/bug.php?id=75981
- https://hackerone.com/reports/320222
- https://www.exploit-db.com/exploits/44846/
- https://www.tenable.com/security/tns-2018-03

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

repository: trickest/cve

repo_name: trickest/cve


text:
# Python Developer Documentation

This document explains how to use the Python functions from any calling Singularity (C) process. For the first version we used a client [cli.py](https://github.com/singularityware/singularity/blob/6433ddd67b6abfdf1faa3eaa7b0338aa8fe55b31/libexec/python/cli.py), with optparse, and this strategy made sense given that the python module had a limited functionality to import Docker layers. When the need arose to support more than one uri, and different optional imports, it was decided that a more modular strategy was needed, and one that mirrored how the core Singularity software worked. Specifically:

 - variables are passed around via the environment
 - commands are simple and modular, named intuitively

In the current version, this old client was removed in favor of a modular, environment variable-based approach. The following sections are about the python api endpoints available, including bootstrap modules, and general utilities. For each, the following standards are used for parsing environmental variables (the source of the inputs for the functions):

# Table of Contents
1. [Environment Varialbes](#environment-variables)
2. [Cache](#cache)
3. [Bootstrap API](#bootstrap-modules)
4. [Util Functions API](#utility-modules)
5. [Future Additions](#future-additions)

## Environment Variables
All environmental variables are parsed in [defaults.py](defaults.py), which is a gateway between variables defined at runtime, and defaults. By way of import from the file, variables set at runtime do not change if re-imported. This was done intentionally to prevent changes during the execution, and could be changed if needed. For all variables, the order of operations works as follows:

  1. First preference goes to environment variable set at runtime
  2. Second preference goes to default defined in this file
  3. Then, if neither is found, null is returned except in the case that `required=True`. A `required=True` variable not found will system exit with an error.
  4. Variables that should not be dispayed in debug logger are set with `silent=True`, and are only reported to be defined.

For boolean variables, the following are acceptable for True, with any kind of capitalization or not:

      ("yes", "true", "t", "1","y")

## Cache
The location and usage of the cache is also determined by environment variables.

**SINGULARITY_DISABLE_CACHE**
If the user wants to disable the cache, all this means is that the layers are written to a temporary directory. The python functions do nothing to actually remove images, as they are needed by the calling process. It should be responsibility of the calling process to remove layers given that `SINGULARITY_DISABLE_CACHE` is set to any true/yes value. By default, the cache is not disabled.

**SINGULARITY_CACHE**
Is the base folder for caching layers and singularity hub images. If not defined, it uses default of `$HOME/.singularity`, and subfolders for docker layers are `$HOME` If defined, the defined location is used instead. If `DISABLE_CACHE` is set to True, this value is ignored in favor of a temporary directory. For specific subtypes of things to cache, subdirectories are created (by python), including `$SINGULARITY_CACHE/docker` for docker layers and `$SINGULARITY_CACHE/shub` for Singularity Hub images. If the cache is not created, the Python script creates it.

**SINGULARITY_CONTENT**
The layerfile is important for both docker ADD and IMPORT, as it is the file where .tar.gz layer files are written for the calling process to extract. If `SINGULARITY_CONTENT` is not defined, then it will be generated as
`$SINGULARITY_METADATA_BASE/.layers`.

**SINGULARITY_ENVBASE**
The environment base folder is the folder name within the metadata folder to hold environment variable files to be sourced. If not defined, it defaults to `$SINGULARITY_METADATA_BASE/.env`, and python carries it around in the variable `ENV_BASE`.

**SINGULARITY_LABELBASE**
The label base is akin to the `ENV_BASE`, except it is for labels from the docker image. If not defined, it defaults to `$SINGULARITY_METADATA_BASE/labels`

**SINGULARITY_PULLFOLDER**
By default, images are pulled to the present working directory. The user can change this variable to change that. Currently, the "pull" command is only relevant for Singularity Hub.

## Bootstrap Modules
A boostrap module is a set of functions that allow importing contents, metadata, and environment variables from other containers.

In the current version, the old client was removed, and each module (currently we have support for [shub](shub) and [docker](docker) has a set of functions not exposed for command line use (typically in a `main.py` and `api.py` module, and then a main client (an executable script) that is meant to be called from the command line. For example:

 - `libexec/python/import.py`
 - `libexec/python/pull.py`

For each of the above, the python takes car of parsing the uri, meaning that a uri of `docker://` or `shub://` can be passed to `python/import.py` and it will be directed to the correct module to handle it. This basic structure is meant to put more responsibility on python for parsing and handling uris, with possibility of easily adding other endpoints in the future. This means that the Singularity (calling process), given that required environmental variables are defined, can call a function like:

      eval $SINGULARITY_libexecdir/singularity/python/import.py

and the environment might hold and image uri for `docker://` or `shub://`.

For each, the details of required arguments are detailed in the scripts, and discussed below. First, we will review the environmental variables.

### Defaults
The following variables in [defaults.py](defaults.py) are a combination of static values, and variables that can be customized by the user via environment variables at runtime.

#### Docker

**DOCKER_API_BASE**
Set as `index.docker.io`, which is the name of the registry. In the first version of Singularity we parsed the Registry argument from the build spec file, however now this is removed because it can be obtained directly from the image name (eg, `registry/namespace/repo:tag`). If you don't specify a registry name for your image, this default is used.

**DOCKER_API_VERSION**
Is the version of the Docker Registry API currently being used, by default now is `v2`.

**DOCKER_OS**
This is exposed via the exported environment variable `SINGULARITY_DOCKER_OS` and pertains to images that reveal a version 2 manifest with a [manifest list](https://docs.docker.com/registry/spec/manifest-v2-2/#manifest-list). In the case that the list is present, we must choose an operating system (this variable) and an architecture (below). The default is `linux`.

**DOCKER_ARCHITECTURE**
This is exposed via the exported environment variable `SINGULARITY_DOCKER_ARCHITECTURE` and the same applies as for the `DOCKER_OS` with regards to being used in context of a list of manifests. In the case that the list is present, we must choose an architecture (this variable) and an os (above). The default is `amd64`, and other common ones include `arm`, `arm64`, `ppc64le`, `386`, and `s390x`.

**DOCKER_PREFIX**
Whenever a new Docker container is imported, it brings its environment. This means that we must write the environmental variables to a file where they can be preserved. To keep a record of Docker imports, we generate a file starting with `DOCKER_PREFIX` in the environment metadata folder (see environment variable `ENV_BASE`) (default is `docker`).

**DOCKER_NUMBER**
To support multiple imports, we must number this file (eg, `10-docker.sh`). The `DOCKER_NUMBER` is the starting count for this file, with default `10` to allow more important environment variables to come first. A note of caution to the calling script - this would mean we source them in reverse, otherwise higher numbers (which should be lower priority) overwrite. We probably should import in reverse always, but maintain 1..N as priority ordering so it is intuitive.

**NAMESPACE**
Is the default namespace, `library`.

**RUNSCRIPT_COMMAND**
Is not obtained from the environment, but is a hard coded default (`"/bin/bash"`). This is the fallback command used in the case that the docker image does not have a `CMD` or `ENTRYPOINT`.

**TAG**
Is the default tag, `latest`.

**DISABLE_HTTPS**
If you export the variable `SINGULARITY_NOHTTPS` you can force the software to not use https when interacting with a Docker registry. This use case is typically for use of a local registry.

#### Singularity Hub

**SHUB_PREFIX**
Singularity images are imported in entirety (meaning no environmental data to parse) so we only need the prefix to write metadata for.

**SHUB_API_BASE**
The default base for the Singularity Hub API, which is `https://singularity-hub.org/api`

**SHUB_CONTAINERNAME**
The user is empowered to define a custom name for the singularity image downloaded. The first preference goes to specifying an `SHUB_CONTAINERNAME`. For example:

```bash
export SHUB_CONTAINERNAME="meatballs.img"
singularity pull shub://vsoch/singularity-images
...
Done. Container is at: ./meatballs.img
```

**SHUB_NAMEBYCOMMIT**
Second preference goes to naming the container by commit. If this variable is found in the environment, regardless of the value, it will be done!

```bash
unset SHUB_CONTAINERNAME
export SHUB_NAMEBYCOMMIT=yesplease
singularity pull shub://vsoch/singularity-images
Done. Container is at: ./7a75cd7a32192e5d50f267982e0c30aff794076b.img
```

**SHUB_NAMEBYHASH**
Finally, we can name the container based on the file hash.

```bash
unset SHUB_NAMEBYCOMMIT
export SHUB_NAMEBYHASH=yesplease
singularity pull shub://vsoch/singularity-images
Done. Container is at: ./a989bc72cb154d007aa47a5034978328.img
```

If none of the above are selected, the default is to use the username and reponame

```bash
unset SHUB_NAMEBYHASH
singularity pull shub://vsoch/singularity-images
Done. Container is at: ./vsoch-singularity-images-mongo.img
```

### Formatting
Formatting refers to the user interface for the command line tool.

**SINGULARITY_COLORIZE**
By default, debug messages (and other types) use ascii escape sequences to various commands with colors. This helps to distinguish them, and makes the user interface a bit more pleasant. If the output is not going to a terminal, or if the terminal does not support the ascii escape sequences, this variable is set to False. The user can always override this by setting this variable.

### Plugins
Singularity plugins are custom environment variables that can be set to turn bootstrap (and other building) customizations on and off. Currently, we just have one plugin that will, when turned on, have the Python API backend change permissions for the tarballs.

**SINGULARITY_FIX_PERMS**
If set to `True/true/1/yes`, the Python back end will parse through the tar files from Docker in memory, and fix permissions. This sets the variable `PLUGIN_FIXPERMS` in the script, and is by default False.

### General
**SINGULARITY_PYTHREADS**
The Python modules use threads (workers) to download layer files for Docker, and change permissions. By default, we will use 9 workers, unless the environment variable `SINGULARITY_PYTHREADS` is defined.

**SINGULARITY_COMMAND_ASIS**
By default, we want to make sure the container running process gets passed forward as the current process, so we want to prefix whatever the Docker command or entrypoint is with `exec`. We also want to make sure that following arguments get passed, so we append `"$@"`. Thus, some entrypoint or cmd might look like this:

     /usr/bin/python

and we would parse it into the runscript as:

     exec /usr/bin/python "$@"

However, it might be the case that the user does not want this. For this reason, we have the environmental variable `RUNSCRIPT_COMMAND_ASIS`. If defined as yes/y/1/True/true, etc., then the runscript will remain as `/usr/bin/python`.

**SINGULARITY_METADATA_FOLDER**
Goes into the variable `METADATA_BASE`, and is the directory location to write the metadata file structure. Specifically, this means folders for environmental variable and layers files. The default looks like this:

      `$SINGULARITY_ROOTFS`
           .singularity.d/
               env/
               labels.json

**SINGULARITY_ROOTFS**
This is the root file system location of the container. There are various checks in all calling functions so the script should never get to this point without having it defined.

If the environmental variable `$SINGULARITY_METADATA_FOLDER` is defined, the metadata folder doesn't even need to live in the container. This could be useful if the calling API wants to skip over it's generation, however care should be taken given that the files are some kind of dependency to produce `/environment`. If the variable isn't defined, then the default metadata folder is set to be `$SINGULARITY_ROOTFS/.singularity.d`. The variable is required, an extra precaution, but probably not necessary since a default is provided.

### Example Usage

#### Docker

##### Docker Import
The Docker commands include  `IMPORT`. Import means returning a layerfile with paths (separated by newlines) to a complete list of layers for import, one of those layers being a tarfile with Docker runscript, environment, and labels. For all Docker commands, by way of needing to use the Docker Registry, the user can optionally specifying a username and password for authentication:

    export SINGULARITY_DOCKER_USERNAME='mickeymouse'
    export SINGULARITY_DOCKER_PASSWORD='cheeseftw'

The user and Singularity calling functions also have some control over the cache. Specifically:

 - `SINGULARITY_DISABLE_CACHE`: will write layers to a temporary directory. Note that since the functions aren't actually doing the import, they do not remove the layers (as was done in previous versions)
 - `SINGULARITY_CACHE`: Is a specific path to the cache.

Since we now are also (potentially) parsing a runscript, the user has the choice to use `CMD` instead of `ENTRYPOINT` by way of the variable `SINGULARITY_INCLUDECMD` parsed from `Cmd` in the build spec file, and `SINGULARITY_COMMAND_ASIS` to not include `exec` and `$@`. As with ADD, the user can again specify a `SINGULARITY_DOCKER_USERNAME` and `SINGULARITY_DOCKER_PASSWORD` if authentication is needed.  The required environment exports are:

 - `SINGULARITY_CONTAINER`: (eg, docker://ubuntu:latest)
 - `SINGULARITY_CONTENTS`: the file to write the list of layers to.

The python function previously extracted the layers, but now to support user import without sudo, and consistency across import/shell/bootstrap, the calling function takes care of this. Thus, it is also important that the calling function write metadata to the `labels.json` and any of the user's preferences for the `runscript` after the layers are extracted, in the case that the user wants to overwrite something that came from the Docker dump.

An example use case is the following:

      #!/bin/bash

      # This is an example of the base usage for the docker/add.py command

      # We need, minimally, a docker container and rootfs defined
      export SINGULARITY_CONTAINER="docker://ubuntu:latest"
      export SINGULARITY_CONTENTS=/tmp/hello-kitty.txt

      cd libexec/python/tests
      python ../import.py

After the script runs, the file `/tmp/hello-kitty.txt` will contain the list of layers to import. Something like:

	/home/vanessa/.singularity/docker/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4.tar.gz
	/home/vanessa/.singularity/docker/sha256:2508cbcde94b50cd53356e8730bb508ddb43c76664a35dc29e69bb8b56a0f531.tar.gz
	/home/vanessa/.singularity/docker/sha256:bc7277e579f03a13476b4d2dc6607124f7e67341dbd58f9d1cd6555bec086c04.tar.gz
	/home/vanessa/.singularity/docker/sha256:946d6c48c2a7d60cb2f4d1c4d3a8131086b412d11a9def59d0bcc0892428dde9.tar.gz
	/home/vanessa/.singularity/docker/sha256:695f074e24e392178d364af5ea2405dda7ab0035284001b49939afac5106c187.tar.gz
	/home/vanessa/.singularity/docker/sha256:8aec416115fdbd74102c9090bcfe03bfe8926876642d8846c8b917959ea9b552.tar.gz

The last of the layers will be the tarfile created by the python with the metadata.

#### Singularity Hub
The Singularity Hub python functions include IMPORT, and PULL.

 - PULL: is the most basic of the three, pulling an image from Singularity Hub to the cache (default) or if defined, the `SINGULARITY_PULLFOLDER`. It names the image with the format `username-repo-tag.img.gz`, where the tag is optional. The path to the image is returned to the calling process via the `SINGULARITY_LAYERFILE` environmental variable.
 - IMPORT: is the most robust, doing the same as PULL, but additionally extracting metadata about the image to the `SINGULARITY_LABELDIR` folder.

Examples are included below.

##### PULL
Pull must minimally have a container defined in `SINGULARITY_CONTAINER`

      #!/bin/bash

      cd libexec/python/tests
      # We need, minimally, a singularity hub container, default pulls to cache
      export SINGULARITY_CONTAINER="shub://vsoch/singularity-images"
      python ../pull.py

      # If we specify a different folder, we will specify it
      export SINGULARITY_HUB_PULL_FOLDER=$PWD
      python ../pull.py

## Utility Modules
Included in bootstrap, but not specifically for it, we have a set of utility modules, which do things like:

 - get, add, delete a key from a json file specified
 - get the size of a container

### Size
The size function will return the size of a container. Required environment variables are:

 - `SINGULARITY_CONTAINER`: the path (and uri) to the container (shub:// or docker://)
 - `SINGULARITY_CONTENTS` =  the layerfile to write the size to

Example usage is as follows:

    # Singularity Hub
    export SINGULARITY_CONTAINER=shub://vsoch/singularity-hello-world
    export SINGULARITY_CONTENTS=/tmp/hello-kitty.txt
    # from within tests, for example
    python ../size.py

    # Docker
    export SINGULARITY_CONTAINER=docker://ubuntu:latest
    export SINGULARITY_CONTENTS=/tmp/hello-kitty.txt
    python ../size.py

The size is obtained via reading the (version 2.0) manifest size of each layer, and adding them together. For example, I could use the API internally in Python as follows:

```
cd libexec/python
ipython

from docker.api import DockerApiConnection
client=DockerApiConnection(image='ubuntu')
DEBUG Headers found: Accept,Content-Type
VERBOSE Registry: index.docker.io
VERBOSE Namespace: library
VERBOSE Repo Name: ubuntu
VERBOSE Repo Tag: latest
VERBOSE Version: None
VERBOSE Obtaining tags: https://index.docker.io/v2/library/ubuntu/tags/list
DEBUG GET https://index.docker.io/v2/library/ubuntu/tags/list
DEBUG Http Error with code 401
DEBUG GET https://auth.docker.io/token?service=registry.docker.io&expires_in=9000&scope=repository:library/ubuntu:pull
DEBUG Headers found: Accept,Authorization,Content-Type

client.get_size()
VERBOSE Obtaining manifest: https://index.docker.io/v2/library/ubuntu/manifests/latest
DEBUG GET https://index.docker.io/v2/library/ubuntu/manifests/latest
Out[3]: 46795242
```

Given that the container does not have a version 2.0 manifest (not sure if this is possible, but it could be) or if the manifest is malformed in any way, a size of None is returned.

### Json
The json module serves two functions. First, it writes a key value store of labels specific to a container using supporting functions [add](helpers/json/add.py), [helpers/json/delete.py](helpers/json/delete.py) and [helpers/json/get.py](helpers/json/get.py). Second, it servers to return a [JSON API](http://jsonapi.org/) manifest with one or more metrics of interest.

#### Inspect
Inspect will return (print to the screen, or stdout) a json data structure with the fields asked for by the user, specifically which can be in the set defined in [inspect.help](../cli/inspect.help).

```
-l/--labels      Show the labels associated with the image (default)
-d/--deffile     Show the bootstrap definition file which was used
                 to generate this image
-r/--runscript   Show the runscript for this image
-t/--test        Show the test script for this image
-e/--environment Show the environment settings for this container
```

The bash client handles parsing these command line arguments into the following environment variables that are exported, and found by python:

```
SINGULARITY_MOUNTPOINT
SINGULARITY_INSPECT_LABELS
SINGULARITY_INSPECT_DEFFILE
SINGULARITY_INSPECT_RUNSCRIPT
SINGULARITY_INSPECT_TEST
SINGULARITY_INSPECT_ENVIRONMENT
```

Essentially, if any of the above for `SINGULARITY_INSPECT_*` are found to be defined, this is interpreted as "yes/True." Otherwise, if the environment variable is not defined, python finds it as `None` and doesn't do anything. In this manner, we can call the executable as follows (e.g., from [inspect.sh](../helpers/inspect.sh)).

```
eval_abort "$SINGULARITY_libexecdir/singularity/python/helpers/json/inspect.py"
```
and the python will look for the environmental variables specified above. This is different from the other json functions (below) that expect different parameters to be passed into the script call.

#### Json Functions
The functions `get`, `dump`, and `add` are primarily used to write and read `.json` files in the `SINGULARITY_METADATA/labels` folder, with each file mapping to it's source (eg, docker, shub, etc). Given that the calling (C) function has specified the label file (`SINGULARITY_LABELBASE`) The general use would be the following:

	# Add a key value to labelfile. The key must not exist
	exec $SINGULARITY_libexecdir/singularity/python/utils/json/add.py --key $KEY --value $VALUE --file $LABELFILE

	# If it exists, you can force add
	exec $SINGULARITY_libexecdir/singularity/python/utils/json/add.py --key $KEY --value $VALUE --file $LABELFILE -f

	# Remove a key from labelfile. If the file is empty after, it is removed
	exec $SINGULARITY_libexecdir/singularity/python/utils/json/delete.py --key $KEY --file $LABELFILE

	# Get a stream / list of all labels (in single file, one per line, separated by :)
	exec $SINGULARITY_libexecdir/singularity/python/utils/json/dump.py --file $LABELFILE

	# Get a single key from label file, returns empty and exists if not defined
	exec $SINGULARITY_libexecdir/singularity/python/utils/json/get.py --key $KEY

## Future Additions

#### Python Internal API URIs
The internal python modules, in the case of returning a `SINGULARITY_CONTENTS` file with a list of contents to be parsed by the calling function, will prefix each content (line in the file) with a uri to tell the calling script how to manage it. Currently, we have the following defined:

- URI_IMAGE: img:// - intended for Singularity Hub images, which are downloaded as .img.gz, but returned after decompression.
- URI_TAR: tar:// - for a tar (not compressed)
- URI_TARGZ: targz:// - for a compressed tarball

For each of the above, a path would add an extra slash (e.g. `img:///home/vanessa/image.img.gz`)

repository: edf-hpc/singularity-container

repo_name: edf-hpc/singularity-container


text:
# econophysics
My codes over the econophysics course based on python, numpy and pandas

## Requirement
To work with csv files

`
pip install pandas
`

To download stock prices from internet

`
pip install pandas-datareader
`

For the plotting part.

`
pip install matplotlib
`
# moving average method
![AAPL](images/interactive.png)

repository: nosratullah/econophysics

repo_name: nosratullah/econophysics


text:
# `todo-create`

## Generate the project

The following command was used to generate the library

**` ng g library todo-create --style=scss --prefix=todo`**

## Refactor

I had to explicitly create .scss and .html as both the styles and html were inline

## Test

`ng test todo-create`

gha_language: TypeScript


text:
# `gopass` *gopass-name*

`gopass` returns passwords stored in [gopass](https://www.gopass.pw/) using the
gopass CLI (`gopass`). *gopass-name* is passed to `gopass show --password
$GOPASS_NAME` and the first line of the output of `gopass` is returned with the
trailing newline stripped. The output from `gopass` is cached so calling
`gopass` multiple times with the same *gopass-name* will only invoke `gopass`
once.

!!! example

    ```
    {{ gopass "$PASS_NAME" }}
    ```

repository: twpayne/chezmoi

repo_name: twpayne/chezmoi


text:
# Fancy Text Transformer

Usage :
```
<FancyTextTransformers
  text='github.com/sthobis'
  mask='github'
/>
```

Demo : https://sthobis.github.io/fancy-text-transformers/

repository: sthobis/fancy-text-transformers

repo_name: sthobis/fancy-text-transformers


text:
---
ref: vechev2009experience
title: Experience with Model Checking Linearizability
authors: Martin Vechev, Eran Yahav, Greta Yorsh
year: 2009
venue: SPIN
projects: Research Area 1, Research Area 1
awards:
bibtex: '@inproceedings{vechev2009experience,
  title={Experience with model checking linearizability},
  author={Vechev, Martin and Yahav, Eran and Yorsh, Greta},
  booktitle={International SPIN Workshop on Model Checking of Software},
  pages={261--278},
  year={2009},
  organization={Springer}}'
paper: https://files.sri.inf.ethz.ch/website/papers/spin09.pdf
talk:
slides:
---

Non-blocking concurrent algorithms offer significant performance advantages, but are very difficult to construct and verify. In this paper, we describe our experience in using SPIN to check linearizability of non-blocking concurrent data-structure algorithms that manipulate dynamically allocated memory. In particular, this is the first work that describes a method for checking linearizability with non-fixed linearization points.


text:
---
title: Connect to HubRise
path_override: connect-hubrise
position: 2
layout: documentation
meta:
  title: Connect to HubRise | TastyCloud | HubRise
  description: Instructions on connecting TastyCloud with HubRise for your EPOS to work with other apps as a cohesive whole. Connect apps and synchronise your data.
---

---

**IMPORTANT NOTE:** TastyCloud cannot simultaneously have a connection with HubRise, and a direct connection to an EPOS. Once your TastyCloud website is connected to HubRise, your EPOS will necessarily be connected via HubRise. To see available EPOS solutions on HubRise, check our [Apps](/apps) page.

---

Follow these steps to connect TastyCloud to HubRise:

1. If you have no HubRise Account, create one on the [HubRise Registration page](https://manager.hubrise.com/signup).
1. Give<EMAIL_ADDRESS>permission to access your HubRise Account as **Manager**. For instructions, see [Add a User Permission](/docs/permissions/#add-a-user).
1. Contact your TastyCloud support representative and share your HubRise Location name and unique identifier. For instance, `Fast Pizza London (e34ss-8)`. They will assist you with the connection. You can refer them to the next section of this page if they need more information on the connection process.

At this stage, the connection of a HubRise Location to a TastyCloud website can only be performed by TastyCloud's support team, but users will soon be able to do it autonomously.

## Instructions for TastyCloud support

Here is the process to connect a customer location:

1. Open [the HubRise authorization page for TastyCloud](https://manager.hubrise.com/oauth2/v1/authorize?redirect_uri=urn:ietf:wg:oauth:2.0:oob&client_id=93423377549.clients.hubrise.com&scope=location[orders.write,customer_list.write,all_catalogs.write]). You may check with the development team that the URL is correct.
1. Select the HubRise location to connect, and click **Allow**.
1. Send the displayed code to your development team, and ask them to generate an access token with it.
1. Login to the TastyCloud back office.
1. Select **POS** > **Ajouter un restaurant**.
1. Select the restaurant to connect from a dropdown list.
1. Select **HubRise** from the **Logiciel de caisse** dropdown list.
1. Copy the access token your development team has sent.
1. Save the settings.

repository: HubRise/website

repo_name: HubRise/website


text:
# YOLO Plugin for DeepStream SDK #

### Pre-requisites: ###

- DeepStream 2.0

### Installing Pre-requisites: ###

Download and install DeepStream 2.0

Install GStreamer pre-requisites using:
   `sudo apt-get install libgstreamer-plugins-base1.0-dev libgstreamer1.0-dev`

Update path to TensorRT and DeepStream install directories in makefiles of both
gst-yoloplugin and the yoloplugin_lib
  ```
  TENSORT_INSTALL_DIR:= /path/to/TensorRT-4.0/
  DEEPSTREAM_INTALL_DIR:= /path/to/DeepStream_Release_2.0/
  ```

### Running the DeepStream App ###

Following steps describe how to run the YOLO plugin in the deepstream app

1.  The section below in the config file corresponds to ds-example(yolo) plugin in deepstream.
    The config file is located at `config/deepstream-app_yolo_config.txt`. Make any changes
    to this section if required.

    ```
    [ds-example]
    enable=1
    processing-width=1280
    processing-height=720
    full-frame=1
    unique-id=15
    gpu-id=0
    ```

2.  Update path to the video file source in the URI field under `[source0]` group
    of the config file
    `uri=file://relative/path/to/source/video`

3.  Go to the `sources/gst-yoloplugin/yoloplugin_lib/data` folder and add your yolo .cfg and .weights file.

    For yolo v2,
    Download the config file from the darknet repo located at `https://github.com/pjreddie/darknet/blob/master/cfg/yolov2.cfg`
    Download the weights file by running the command `wget https://pjreddie.com/media/files/yolov2.weights`

    For yolo v3,
    Download the config file from the darknet repo located at `https://github.com/pjreddie/darknet/blob/master/cfg/yolov3.cfg`
    Download the weights file by running the command `wget https://pjreddie.com/media/files/yolov3.weights`

4.  Set the right macro in the `network_config.h` file to choose a model architecture

5.  Update the paths of the .cfg and weights file and other network params in `network_config.cpp` file if required.

7.  Add absolute paths of images to be used for calibration in the `calibrationImages.txt` file within the `sources/gst-yoloplugin/yoloplugin_lib/data` folder.

8.  Go the `sources/gst-yoloplugin` directory and run
    `make && sudo make install`

9.  Go to the root folder of this repo and run
    `deepstream-app -c config/deepstream-app_yolo_config.txt`

repository: bigsnarfdude/deepstream-plugins

repo_name: bigsnarfdude/deepstream-plugins


text:
# npm-install-watch
Watches a directory for changes and auto `npm install`s required dependencies
that are missing.

Currently just a very simple script written for projects using babel ES6.

repository: beijaflor-io/npm-install-watch

repo_name: beijaflor-io/npm-install-watch


text:
> Life is not just a matter of sight, but also poetry and distance.
> There are some things in life that you never try your best to do, You never know how good you are.
> Where there is life, there is learning.

Hi, Everybody, I am Vinter, welcome to my blog.

<!-- ##### Talks -->

<!-- - [Upgrading to Progressive Web Apps][9] · [JSConf China Shanghai 2017](http://2017.jsconf.cn/)
- Building Progressive Web Apps · [CSDI Guangzhou 2017](http://www.csdisummit.com/)
- The State of Progressive Web App · GDG IO Redux Beijing 2017
- PWA Rehashing · Baidu HQ Beijing 2017
- [Service Worker 101][5] · GDG DevFest Beijing 2016
- [Progressive Web Apps][4] · QCon Shanghai 2016
- Progressive Web App in my POV · GDG IO Redux Beijing 2016
- [CSS Still Sucks 2015][2] · 2015
- [JavaScript Modularization Journey][1] · 2015

[1]: //huangxuan.me/2015/07/09/js-module-7day/
[2]: //huangxuan.me/2015/12/28/css-sucks-2015/
[3]: //huangxuan.me/2016/06/05/pwa-in-my-pov/
[4]: //huangxuan.me/2016/10/20/pwa-qcon2016/
[5]: //huangxuan.me/2016/11/20/sw-101-gdgdf/
[6]: https://yanshuo.io/assets/player/?deck=58ac8598b123db0067292f92 "PWA Rehashing"
[7]: https://yanshuo.io/assets/player/?deck=593ad6fbfe88c2006a0a0d6d "The State of PWA"
[8]: https://yanshuo.io/assets/player/?deck=594d673d570c357d0698a950 "Building PWA"
[9]: //huangxuan.me/jsconfcn2017/ -->

<!-- * [Simple and useful canvas library —— Fabric.js][1]
* [introducing SSH][2] -->

![天生我才必有用，千金散尽还复来。](http://vinter.oss-cn-shenzhen.aliyuncs.com/blog/jiangjinjiu.jpg "将进酒")
When we are born, we will be useful.

---

<!-- [1]: //www.vinterx.com/2018/11/18/canvas-fabric/
[2]: //www.vinterx.com/2018/11/05/two-ssh-in-pc-git/ -->


text:
## Getting Started ##
 **Why?**: This was built as a starter theme to bring modern build tools and a modern workflow into Shopify development since Shopfiy Slate has been deprecated.
 This starter theme is as stripped down as much as possible so you can start with a blank canvas.

 **Pre-requisites**: Need to have [Shopify Theme Kit](https://shopify.github.io/themekit/), [Node/NPM](https://nodejs.org/), [Gulp Cli](https://gulpjs.com/docs/en/getting-started/quick-start) installed. This should work for the latest versions of each but for trouble shooting I have the falling versions: npm(7.5.4) | node(v12.16.1) | gulp(CLI version: 2.3.0,Local version: 4.0.2) | ThemeKit (1.1.6 darwin/amd64)

 ### Configuration ###
 If you have all pre-requisites install from above then go ahead and download the latest release. After downloading the release/repo then `cd project-name` and run command `npm install`. This will install all of the development dependencies.

 Go to `dist/` folder and place your *`config.yml`* with the live theme and development theme (live should come after development):
```
#development config
development:
  theme_id: [development_theme_id]
  password: [password]
  store: [store_url]

#staging config
staging:
  theme_id: [staging_theme_id]
  password: [password]
  store: [store_url]

#live/ production
live:
  theme_id: [live_theme_id]
  password: [password]
  store: [store_url]
  read-only: true

```
  Once you have the *`config.yml`* setup you can run `npm run dev` inside the projects root. This will start development on your dev theme by opening a preview link, starting themekit to watch for changes, and also start watching for changes in your *`src/`* folder.

### Commands ###
  List of commands you can use with npm:
 - `npm run dev` opens development theme preview link, start watching src files, and starts theme kit watch
 - `npm run dev:deploy` deploy your development theme
 - `npm run dev:watch` watch development theme,
 - `npm run dev:open` open preview link for development theme
 - `npm run dev:open:pb` open preview link for development theme with preview bar
 - `npm run dev:download` downlaod all development theme files to `/dist`
 - `npm run stage:deploy` deploys to development theme
 - `npm run stage` builds, deploys then opens preview to staging theme
 - `npm run stage:open` opens preview to staging theme
 - `npm run stage:open:pb` opens preview to staging theme but opens with preview bar
 - `npm run stage:deploy` deploys to staging theme
 - `npm run stage:download` downloads all staging files to `/dist`
 - `npm run live:deploy` deploy to live (first must chage read only to fals - in `config.yml`
 - `npm run live:download` download all live theme files to `/dist`
 - `npm run build` generates production ready css and js
 - `npm run build:dev` generates css and js with no minifier etc...
 - `npm run build:staging` generates production ready css and js (same as npm run build)
 - `npm run build:css` generates development css
 - `npm run build:js` generates development js
 - `npm run build:img` compresses images in /src/images and places in assets
 - `npm run watch` alias to **dev:watch**, watches /dist and /src files
 - `npm run watch:src` auto generates development code as you make changes to `/src` scss and js
 - `npm run watch:dist` start theme kit watch on `/dist` files to update theme on shopify
 - `npm run log:purgedCSS` genrates unused css selectors that were purged
 - `npm run open` alias for **dev:open**, opens preview link for development theme
 - `npm run open:pb` alias for **dev:open:pb** open preview link for development theme with preview bar
 - `npm run bs` starts browser-sync which opens a proxy url on your dev theme for auto reloading etc...
 - `npm run autoreload` alias for **bs**, which starts browser-sync for hot reloading

 ### Project Structure ###
 ```
 ├─ node_modules/
 ├─ dist/
 │   ├─ assets/                   - built css and js files  go here
 │   ├─ config.yml                - where shopify's config file gets placed
 │   └─ ...                       - where we edit liquid files
 ├─  src/                         - this src folder where we edit our js and sass files
 │    ├─ images/                  - put images here for compression
 │    │   ├─ placeholder.png
 │    │   └─ ...                  - other images
 │    ├─ js/
 │    │   ├─ modules/             - place to put javascript modules
 │    │   ├─ main.js              - main js files used across site
 │    │   └─ ...                  - other pages of site js go here ie.e cart.js
 │    ├─ sass/
 │    │   ├─ modules/             - place to put scss modules
 │    │   │   └─ _headers.scss    - example of partials starts with _
 │    │   ├─ styles.scss          - main styles used across the site
 │    │   ├─ product.scss         - example of template page sass
 │    │   └─ ...
 │    └─ tmp/                     - used for temp output from gulp, i.e. rejected css
 │        ├─ styles.rejected.css  - shows all selectors that were purged from styles.scss
 │        └─ ...                  - other purged files
 │
 ├─ bs-config.js                  - broswer-sync config, add options to customize your needs
 ├─ gulpfile.js                   - use this to edit build pipelines if needed
 ├─ theme.update                  - used for browser-sync, gets changed on theme kit watch
 └─  ...
 ```

 ### Work Flow & More Structure ###

 **Workflow**: We all know shopify doesn't support local development. This means the usually work flow starts with you going to your shopify store, duplicating the live theme, grabbing the id, then running `theme watch` to start watching your files for changes you make. Some people may watch their live theme directly, but what happens if the wrong branch or code gets uploaded to your live theme? You are screwed.

The intended workflow of this project is to have 3 themes. Live(production), Staging, and Development. Once you have these 3 theme id's you can put them into the config as outlined below.

*The development process*
 1. You have two options either `npm run dev` which will open a preview link, start theme watch on  your *`/dist`* files, and start watching for changes in your *`/src`* files or if you want to get *auto reloading* with Browser Sync, run `npm run watch` to start watching both your *`/src`* and *`/dist`* folders then open a new terminal tab and run `npm run bs` to start Browser Sync to get a link that will allow auto reload your site on file changes (among many other things)

 2. Once your changes look good on development the next step is to run `npm run stage`. This builds your files in production mode and deploys them to your staging theme. Then opens a preview to make sure changes are stable there.

 3. Once you have verified the changes. You can deploy to live by running `npm run live:deploy`, this will confirm you actually want to deploy to live, enter y and watch your changes go live.

 P.S.  You really should never watch live.

**How to handle CSS and Javascript?**
  So first off I should let you know that all built js and css files have `.min` suffix(ex. styles.min.css ). This means when you reference the file in liquid you need to include the suffix. I have two theories on how a project should handle the CSS and Javascript files depending on your needs.

 If you have a lot of different features/styles per page I think this is the best approach. The main idea with Rollup is to have one js file per page. To keep the global scope clear rollup builds your files within an immediately invokedfunction expression. This means we can't stack script tags on top of one another to have access variables and functions in each script.

 The only option is to put all your first-party js into one file. If you have code that's only gonna beused on certain pages and don't want to add it where it isn't needed then you need to make a script per page needed andthen one script that has your js that you share across the site. As an example, let's say you only have custom js for the index, product, and collection page. The rest of your site shares the same code.

  To do this you want to create 4 js files (index.js, collection.js, product.js, main.js) in `/src/js/`, and one module called shared.js in `/src/jsmodules`. You will import the shared.js module in all 4 script files since it will contain the code you need across all pages. You will then go into theme.liquid and write an if statement that imports the script for the page you are on orelse just imports main.js. For example, if the user is on the product page import product.js and nothing else. If the user is on the about us page import main.js and nothing else. This will keep your bundle as small as possible alongw ith Rollup's built-in tree-shaking. This same theory works for CSS though you do get cascading with the CSS so you canhave more than one file per page if you want.

   If you don't have a lot of features and functions you can just import one script and style file for the entire site. This is pretty much already set up in the site with main.js and styles.scss

### Browser Sync ###

[Browser Sync](https://browsersync.io) is enabled by running `npm run bs` (first you willl want to start watching your files using `npm run watch`). This mainly allows us to use a proxy in order to get features such as auto reloading. You can read more about other features in the link above. I currently have a reload delay of 100ms because that's about hot long it seems for changes to be ready on Shopify's servers. This could be different for you and you can change it by editing the *reloadDelay* option in *`bs-config.js`*.

**One thing to note.** Shopify *force redirects* when you have a custom domain which can disconnect you from Browser Sync. This means clicking on any links when using broswer sync will try and redirect you to your site's custom domain. I fixed the issue for relative links (ex. /collections/shop-all) by writing a middleware function in *`bs-config.js`* that appends the don't force flag `_fd=0` on each link. If you need hardcoded links you can choose a [port to run Browser Sync](https://www.browsersync.io/docs/options/#option-port), then in the middleware options write logic that replaces the host with localhost and the port you chose. Make sure to keep the logic that appends the `_fd=0` flag.

### Rollup ###

 [Rollup](https://rollupjs.org/guide/en/) is used to bundle [ES6 javascript modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) within other files and use in the browser. This also performs tree shaking so it's only imports what we use.
 We can import form node_modules but usually tree shaking doesn't work as it used commonJS. You can read the difference [here](https://sazzer.github.io/blog/2015/05/12/Javascript-modules-ES5-vs-ES6/). Rollup also has other plugins we can add as needed.
 Rollup is configured in `*gulpfile.js`*

### PurgeCSS ###

 [PurgeCSS](https://purgecss.com/) looks at the **.liquid** files in the *`/dist`* folder as well as at **.js** files in *`/src/js/`* folder. It will look for any css selectors and not strip those out of the generated css. That means that any css selectors not in the **.js** or **.liquid** files (in their respective directories) will be removed from the css automatically upon each generation of that file. To see what selectors are being stipped we can run `npm run log:purgedCSS`. This will generated the related css files in *`/src/tmp/`*.

 The way PurgeCSS parses js files is by making each word a selector. This is helpfull because it gets all css that needs to stay in stylesheets but sometimes can leave css that isn't being used (though this seems rare).

 **Example:** If we had no paragrpah tags in the .liquid files but had a pragraph as a selector for some styles i.e. ` p { color: red}`. We would want this removed because it isn't in use, but if we have a variable in js all named p (i.e. `var p = 2;`) it may not remove it from the css.

### *Caveats ###

 This one isn't really that big of deal but, at this, I'm not watching the .liquid files with Gulp. This means JS and CSS builds don't get triggered when you only make a change to a *`.liquid`* file. Most of the time this is not an issue. The only issue I have noticed is if a CSS selector or class is purged and then you add it to a .liquid file to use then you have to trigger a CSS rebuild. The other solution is to have gulp rebuild CSS and possibly JS src files upon each *`.liquid`* file change. If you want to do this go to line 118 in *`gulpfile.js`* and change it to this `watch(config.deepSass, config.liquid, series('build:css'));`

### *Note ###
 I got the shopify theme files (*`/dist/`*) from another git repo. I tried to clean up the files and include all the minimum required files that shopify needs.
 You can replaced the entire contents of the *`/dist`* folder with any shopify starter theme. Just make sure it's the same structure(i.e. *`/dist/assets`*, *`/dist/snippets`*,  etc...).Please let me know if I missing any files or base code that is needed.

 P.S. I currently don't have the *`layout/checkout.liquid`* since that's for *Shopify Plus+* only. You can also add this yourself.

repository: princeflight/shopify-bare

repo_name: princeflight/shopify-bare


text:
# Online AB test pattern

## Usecase
- To confirm the a new prediction model works with the production data.
- To verify a new prediction server can load the production access.
- To test business impact of the model in production.
- To test the model will not worsen the impact than the current one.

## Architecture
The online AB test pattern is an architecture to verity multiple prediction models with the production data and load. In this pattern, you will deploy multiple prediction services parallelly, load balance among them, keeping higher load on the current model, and gradually increase the access to the new server. The load balancing will be managed in the proxy server. The proxy will gather the request data and prediction with identity, and record them in a DWH. You may need to trace the client event log to compare the impact of the new model. The load balancing rule may be considered depending on the objective. If your aim is to compare user activity, it might be better to assign users to a constant model. If your aim is to log the prediction result, you may choose to randomly balance or send request to all the predictions.

If it happens to have problem in prediction, latency or availability, it is better to decide eliminating the new model. You need to consider the term of testing. If the service has seasonal effect, you may need to run longer term, while if the service is used everyday in similar manner, the performance can be concluded in a few week. There may be a chance that you may find the result in shorter term. It is important to decide go or no go based on the effect of the new model replacing the current one.

You will let the new model to be online with responding the prediction to the client. It is important to note that it will affect business or user experience.

## Diagram
![diagram](diagram.png)

## Pros
- You can verity the new model performance without affecting the production service.
- It is possible to record multiple predictions.

## Cons
- It may make a negative impact on your business if the model or server is not good.
- Additional cost

## Needs consideration
- Load balancing policy.
- Evaluation and decision policy of go or no go for the new model.

repository: jiyeonseo/ml-system-design-pattern

branch_name: refs/heads/master-ko

repo_name: jiyeonseo/ml-system-design-pattern


text:
---
title: Coconut Cream Pie
category: Dessert
tags: [pie, coconut]
---

# {{ page.title }}

## Based On
Pillsbury
<br>
<https://www.pillsbury.com/recipes/coconut-cream-pie/2ffd5ffb-fcc3-4495-b368-b7fbc30ea1f5>

## Supporting Recipes
* [Graham Cracker Pie Crust](graham-cracker-pie-crust)
* [Pastry Pie Crust](pastry-pie-crust)
* [Toasted Coconut](toasted-coconut)

## Ingredients
* ½ cup + ⅓ cup granulated sugar
* ¼ cup cornstarch
* 2 cups half-and-half
* 4 egg yolks
* 3 tablespoons butter
* 1 cup flaked coconut
* 1 teaspoon + 1½ teaspoons vanilla extract
* 2 cups whipping cream

### Optional
* [Toasted Coconut](toasted-coconut) to top (amount to taste)

## Steps
1.  Prepare the [pastry](pastry-pie-crust) or [graham cracker](graham-cracker-pie-crust) crust. Cool completely.
2.  In a large, heavy saucepan, mix ½ cup sugar and cornstarch.
3.  In small bowl, beat half-and-half and egg yolks with a whisk.
4.  Gradually add egg mixture to sugar mixture and heat to boiling over medium heat, stirring constantly.
5.  Boil 1 minute; remove from heat.
6.  Stir in butter, flaked coconut, and 1 teaspoon of the vanilla.
7.  Cover with plastic wrap, placing plastic wrap directly on custard; let stand 30 minutes.
8.  Spoon custard into cooled baked shell.
9.  Cover and refrigerate 30 minutes or until set.
10. In a medium bowl, beat whipping cream with electric mixer on high speed until foamy.
11. Gradually add ⅓ cup sugar and remaining 1½ teaspoons vanilla, beating until soft peaks form.
12. Spread whipped cream over pie.
13. Sprinkle with [toasted Coconut](toasted-coconut) if desired.
14. Store in refrigerator.


text:
---
uid: headless-service
title: Headless Service
---
# Akka.NET Headless Service

<!-- markdownlint-disable MD033 -->
<iframe width="560" height="315" src="https://www.youtube.com/embed/gpaaCBtKLss" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
<!-- markdownlint-enable MD033 -->

## Headless Actor

[!code-csharp[Main](../../../src/examples/HeadlessService/AkkaHeadlesssService/HeadlessActor.cs?name=headless-actor)]

## Headless Service

[!code-csharp[Main](../../../src/examples/HeadlessService/AkkaHeadlesssService/AkkaService.cs?name=headless-akka-service)]

## Headless Service Host

[!code-csharp[Main](../../../src/examples/HeadlessService/AkkaHeadlesssService/Program.cs?name=headless-service-program)]

## What About Windows Service?

Well, quickly, we have a sample application, [Windows Service](xref:windows-service), to show how `Windows Services` are now being built with `BackgroundService`!

[learn more](https://docs.microsoft.com/en-us/dotnet/core/extensions/windows-service)

branch_name: refs/heads/dev

gha_language: C#

gha_license_id: NOASSERTION


text:
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [2.0.0]

### Breaking Changes

- `podLabels` replaces `deployment.labels`

### Added

- Added `podAnnotations` and `podLabels` to deployment template
- Added `apiVersion` to `Chart.yaml`

### Changed

- Bumped application version to `1.3.2`
- Changed comment in `values.yaml`

## [1.1.0]

### Added

- Ability to add labels to deployments/pods:
  The deployment.labels map is applied to the deployment and the pods

- Ability supply additional command line arguments to pypiserver:
  The pypiserver.extraArgs list is added to the pypiserver startup command

### Changed

- Default appVersion (version of pypiserver) is now 1.3.0

### Removed

## [1.0.1]

### Added

- Bug fix: Setting fsGroup to 1000 in case of enabled persistence
  (due to possibly missing write permissions as volumes are mounted as root owned folder by docker)

### Changed

### Removed


text:
# The openmeter project

TOC:
1. What are we going to build
2. Getting Raspberrypi ready
3. How to install the openmeter solution
4. Connect it to the OpenHab Cloud App
5. Run your app
6. Extra info about:
* InfluxDB

## 1. What are we going to build

## 2. Getting Raspberrypi ready

[See repo openmeter-RPI-get-ready](https://github.com/openmeter/openmeter-RPI-get-ready)

## 3. How to install the openmeter solution

```bash
# ssh into pi
ssh<EMAIL_ADDRESS>
# goto root
cd /

#clone the repository to your pi
sudo git clone https://github.com/openmeter/openmeter.git
sudo chmod 777 -R openmeter
cd /openmeter

# run docker-compose
docker-compose up -d

```

#  4. Connect it to the OpenHab Cloud App

[openhab](OPENHAB.md)

#  5. Run it

#  6. Extra info about:
* [Influxdb](INFLUXDB.md)

repository: openmeter/openmeter

gha_language: Python

repo_name: openmeter/openmeter


text:
---
hrs_structure:
  division: '3'
  volume: '12'
  title: '28'
  chapter: '508'
  section: 508-1
type: hrs_section
tags:
  - Property
  - Family
menu:
  hrs:
    identifier: HRS_0508-0001
    parent: HRS0508
    name: 508-1 Risk of loss
weight: 23005
title: Risk of loss
full_title: 508-1 Risk of loss
---
**§508-1 Risk of loss.** Any contract made in this State after April 25, 1941 for the purchase and sale of realty shall be interpreted as including an agreement that the parties shall have the following rights and duties, unless the contract expressly provides otherwise:

(1) If, when neither the legal title nor the possession of the subject matter of the contract has been transferred, all or a material part thereof is destroyed without fault of the purchaser or is taken by eminent domain, the vendor cannot enforce the contract, and the purchaser is entitled to recover any portion of the price that the purchaser has paid;

(2) If, when either the legal title or the possession of the subject matter of the contract has been transferred, all or any part thereof is destroyed without fault of the vendor or is taken by eminent domain, the purchaser is not thereby relieved from a duty to pay the price, nor is the purchaser entitled to recover any portion thereof that the purchaser has paid. [L 1941, c 109, §1; RL 1945, §9281; RL 1955, §203-1; [HRS §508-1](/title-28/chapter-508/section-508-1/); gen ch 1985]

repository: SamMade/BlueAndKrabby

repo_name: SamMade/BlueAndKrabby


text:
# Substrate Tic Tac Toe

A peer-to-peer electronic tic tac toe game. This blockchain allows users to play many simultaneous games of tic tac toe that cannot be censored or reverted by as long as there are properly incentivized validators running nodes. While the game of tic tac toe itself is just for fun, this project demonstrates many common design principals for building blockchains in general and building blockchains with substrate in particular.

## How to use this
### Build the node

```bash
# Install rust
curl https://sh.rustup.rs -sSf | sh

# Install required tools
./scripts/init.sh

# build project
cargo build --release
```

### Run the node

```bash
# Read the help page
./target/release/tictactoe --help

# Start an instance
./target/release/tictactoe <parameters>
```

### Run the user interface
While you're welcome to interact with the node in any way you see fit #SovereignUIs, a convenient user interface exists at https://github.com/JoshOrndorff/tictactoe-frontend

## Lessons Learned
* Only verify on chain. UI finds the winner, runtime just checks it.
* Help user not submit incorrect transactions. Runtime will check for all sorts of bad conditions, but the UI should help non-malicious users avoid making them. Eg, if you go out of turn, the runtime will handle it, but the UI will only submit transactions for you if it is your turn.
* Don't make the user do extra work. Although claiming a win is a separate extrinsic call, the UI submits it automagically when it detects the current user has won.
* Verify then mutate. Runtime does not make any changes to storage until it is sure those changes will be successful. For example, it does not update the squares until it checks it is the caller's turn and the square is available.

license: Unlicense

repository: JoshOrndorff/TicTacToe

repo_name: JoshOrndorff/TicTacToe


text:
![GitHub Python Version](https://img.shields.io/badge/Python-v3.7-blue) ![GitHub](https://img.shields.io/github/license/No-Death/Gameupdates) [![Build status](https://ci.appveyor.com/api/projects/status/mi7fc9tvop6ew5ri?svg=true)](https://ci.appveyor.com/project/piitchyy/gameupdates-ix091) [![Twitter Follow](https://img.shields.io/twitter/follow/Game_Update_?style=social)](https://twitter.com/Game_Update_)

# GameUpdates Twitter Bot
A python script that will crawl games news pages. It will then post it to a twitter bot account.

## Supported Games
- Battlefield V
- Risk of Rain 2
- Post Scriptum
- Factorio
- My Summer Car

## TODO
- More Games

## How To Use
**What you will need:**
- A twitter dev account and API tokens
- A Bit.ly API secret

**Installation:**

Change the token values in the `config.ini` file to your own.

Type in the command `pip install -r requirements.txt` in the same location that you put the folder.

Run the script with the command `python checker.py`

------
*NOTE: This is just for fun, I have never done something like this and I'm learning as I'm creating this.*

repository: No-Death/gameupdates

repo_name: No-Death/gameupdates


text:
# Lab08

**Jakpat Mingmongkolmitr<PHONE_NUMBER>**

## 4.1 Create trigger (2 points)

> Each insertion of professor information, the data are inserted into not only professor table but also into faculty_insurance table that credit_limit value is calculated from 300% of his/her salary and ins_plan is ”Group Insurance for Instructor”.

### Creating trigger command

```sql
CREATE TRIGGER new_professor_added
AFTER INSERT ON Professor
FOR EACH ROW
    INSERT INTO faculty_insurance (ref_id,
        ins_plan, credit_limit, duedate, s_timestamp, status)
    VALUES (new.pid, "Group Insurance for Instructor”", new.salary * 3,
        DATE_ADD(SYSDATE(),INTERVAL 4 YEAR), SYSDATE(), 'A');
```

### Testing command

```sql
INSERT INTO Professor (pid, pname, salary)
VALUES ('006','Somechai Rakchad','30000');

SELECT * FROM Professor;
SELECT * FROM faculty_insurance
```

![](img/4.1-1.png)
![](img/4.1-2.png)

## 4.2 Create function (2 points)

> Convert the number declared in a numerical data type to other currencies using function named “fn_currency(input_number, exchange_rate, currency_name)” and return the result as string.

### Creating function command

```sql
DELIMITER $$
CREATE FUNCTION fn_currency(input_number decimal,
    exchange_rate decimal, currency_name varchar(30))
RETURNS varchar(50) DETERMINISTIC
BEGIN
    DECLARE fullcurrency varchar(50);
    SET fullcurrency = CONCAT(input_number / exchange_rate, ' ', currency_name);
    RETURN fullcurrency;
END$$
DELIMITER ;
```

### Testing command

```sql
SELECT fn_currency(70, 35.00, 'USD');
```

![](img/4.2-1.png)

## 4.3 Create data stored procedure (6 points)

> Update salaryof all professors who earns salary less than 30,000 up to 10% and update credit limit of insurance up to 400 % of new salary and alsoinsert log into system_log table that stores the old salary, new salary,old credit limit and new credit limit. Finally, the data stored procedure has to print the name, old salary, new salary and credit limit of all professor information that are updated.

### Create data stored procedure command

```sql
DELIMITER $$
CREATE PROCEDURE Proc_cal_professor_upvel()
DETERMINISTIC
BEGIN
    if(SELECT pid FROM Professor WHERE salary < 30000)>0 THEN
        CREATE TEMPORARY TABLE IF NOT EXISTS TMP_PROFESSOR(
            PID varchar(16),
            old_salary int(11) DEFAULT NULL,
            new_salary int(11) DEFAULT NULL,
            old_credit_limit decimal(10,2) DEFAULT NULL,
            new_credit_limit decimal(10,2) DEFAULT NULL
        );
        TRUNCATE TABLE TMP_PROFESSOR;

        INSERT INTO TMP_PROFESSOR (PID, old_salary, new_salary,
            old_credit_limit, new_credit_limit)
        SELECT pid, salary, salary * 1.1, credit_limit, salary * 1.1 * 4
        FROM Professor p
        INNER JOIN faculty_insurance ins ON p.pid = ins.ref_id
        WHERE salary < 30000;

        UPDATE Professor p
        INNER JOIN TMP_PROFESSOR tmp ON p.pid= tmp.PID
        SET salary = tmp.new_salary;

        UPDATE faculty_insurance ins
        INNER JOIN TMP_PROFESSOR tmp ON ins.ref_id= tmp.PID
        SET credit_limit = tmp.new_credit_limit;

        INTO system_log (user_log, remark, timestamp)
        SELECT
            PID,
            CONCAT("old_salary: ", old_salary, ", new_salary: ", new_salary,
                ", old_credit_limit: ", old_credit_limit,
                ", new_credit_limit: ", new_credit_limit) as remark,
            SYSDATE()
        FROM TMP_PROFESSOR;

        SELECT * from Professor WHERE pid in (SELECT PID FROM TMP_PROFESSOR);
    ELSE
        SELECT ' There is no professor those salary less than 30000';
    END IF;
END$$
DELIMITER ;
```

### Testing command

```sql
CALL Proc_cal_professor_upvel();
SELECT * from Professor;
SELECT * from faculty_insurance;
SELECT * from system_log;
```

#### Professor Table

Change from `25000` to `27500`
![](img/4.3-1.png)

#### faculty_insurance Table

Change from `4000.00` to `110000.00`

![](img/4.3-2.png)

#### system_log Table

New system_log record added

![](img/4.3-3.png)


text:
role-eosxd
=========

An ansible role to deploy and configure the eosfusex client on a node

Role Variables
--------------

`role_eosxd_mgmt_alias`: specifies the eos management host (required)

`role_eosxd_eos_upstream`: to use the upstream EOS repos to install eos-fusex (default: true)

`role_eosxd_epel_upstream`: to use the upstream EPEL repos for dependencies (default: true)

`role_eosxd_fstab_state`: /etc/fstab entry for eos (default: "absent", possible values: present, mounted)

`role_eosxd_mount_point`: the mount point for eos when using the systemd (`role_eosxd_fstab`) service (default: /eos)

Example Playbook
----------------

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

    - hosts: cluster
      roles:
        - role: role-eosxd
          role_eosxd_mgmt_alias: eos.example.com

License
-------

BSD

Author Information
------------------

Uemit Seren<EMAIL_ADDRESS>

repository: CLIP-HPC/ansible-role-eosxd

repo_name: CLIP-HPC/ansible-role-eosxd