text:
# Go Bindings for the NVIDIA Management Library (NVML)

## Table of Contents

- [Overview](#overview)
- [Quick Start](#quick-start)
- [How the bindings are generated](#how-the-bindings-are-generated)
- [Code Structure](#code-structure)
  * [Code defining the NVML API](#code-defining-the-nvml-api)
  * [Code to load `libnvidia-ml.so`](#code-to-load--libnvidia-mlso-)
  * [Code to bridge the auto-generated and manual bindings](#code-to-bridge-the-auto-generated-and-manual-bindings)
  * [Manual wrappers around the auto-generated bindings from `c-for-go`](#manual-wrappers-around-the-auto-generated-bindings-from--c-for-go-)
  * [Test code](#test-code)
- [Building and Testing](#building-and-testing)
- [Updating the Code](#updating-the-code)
- [Releasing](#releasing)
- [Contributing](#contributing)

## Overview

This repository provides Go bindings for the [NVIDIA Management Library API
(NVML)](https://docs.nvidia.com/deploy/nvml-api/).

At present, these bindings are only supported on **Linux**.

These bindings are not a reimplementation of NVML in Go, but rather a set of
wrappers around the C API provided by `libnvidia-ml.so`. This library is part
of the standard [NVIDIA driver
distribution](https://www.nvidia.com/Download/index.aspx), and should be
available on any Linux system that has the NVIDIA driver installed.  The API is
designed to be backwards compatible, so the latest bindings should work with
any version of `libnvidia-ml.so` installed on your system.

**Note:** A working NVIDIA driver with `libnvidia-ml.so` is not required to
compile code that imports these bindings. However, you will get a runtime error
if `libnvidia-ml.so` is not available in your library path at runtime.

Please see the following link for documentation on the full NVML Go API:
http://godoc.org/github.com/NVIDIA/go-nvml/pkg/nvml

## Quick Start

All you need is a simple import and a call to `nvml.Init()` to start using
these bindings.

The code below shows an example of using these bindings to query all of the
GPUs on your system and print out their UUIDs.

```
package main

import (
    "fmt"
    "log"

    "github.com/NVIDIA/go-nvml/pkg/nvml"
)

func main() {
    ret := nvml.Init()
    if ret != nvml.SUCCESS {
        log.Fatalf("Unable to initialize NVML: %v", nvml.ErrorString(ret))
    }
    defer func() {
        ret := nvml.Shutdown()
        if ret != nvml.SUCCESS {
            log.Fatalf("Unable to shutdown NVML: %v", nvml.ErrorString(ret))
        }
    }()

    count, ret := nvml.DeviceGetCount()
    if ret != nvml.SUCCESS {
        log.Fatalf("Unable to get device count: %v", nvml.ErrorString(ret))
    }

    for i := 0; i < count; i++ {
        device, ret := nvml.DeviceGetHandleByIndex(i)
        if ret != nvml.SUCCESS {
            log.Fatalf("Unable to get device at index %d: %v", i, nvml.ErrorString(ret))
        }

        uuid, ret := device.GetUUID()
        if ret != nvml.SUCCESS {
            log.Fatalf("Unable to get uuid of device at index %d: %v", i, nvml.ErrorString(ret))
        }

        fmt.Printf("%v\n", uuid)
    }
}
```

On my DGX workstation, this results in the following output:
```
$ go run main.go
GPU-edfee158-11c1-52b8-0517-92f30e7fac88
GPU-f22fb098-d1b3-3806-2655-ba25f02229c1
GPU-f613f823-1032-b3ec-a876-50f2e35e6f9e
GPU-3109fa37-4445-73c7-b695-1b5a4d13f58e
GPU-e28a6529-288c-7ddf-8fea-68c4833cda70
GPU-a27fb382-bad2-c02a-95ba-f6a1da38e76c
GPU-f5bb8d07-ee19-1787-4d9a-a84c4ac6b086
GPU-1ba0ca0e-6d1d-d9db-07d8-c1c5a8c32814
```

## How the bindings are generated

This project leverages two core technologies:
1. Go's builtin support for `cgo` (https://golang.org/cmd/cgo/)
1. A third-party tool called `c-for-go` (https://c.for-go.com/)

Using these tools, we are able to generate a set of Go bindings for NVML, given
nothing more than a specific version of the `nvml.h` header file (which defines
the full NVML API). Most of the process to generate these bindings is
automated, but a few manual steps are required in order to make the generated
bindings more useful from an end user's perspective.

The basic flow to generate the bindings is therefore to:
1. Take the `nvml.h` file and pass it through `c-for-go`
2. Take each of the low-level Go bindings generated by `c-for-go` and wrap them
   in a more user-friendly API

As an example, consider the Go bindings generated for the
`nvmlDeviceGetAccountingPids()` API call below:

Original API in `nvml.h`:
```
nvmlReturn_t nvmlDeviceGetAccountingPids(nvmlDevice_t device, unsigned int *count, unsigned int *pids);
```

Auto-generated Go bindings from `c-for-go`:
```
func nvmlDeviceGetAccountingPids(Device Device, Count *uint32, Pids *uint32) Return {
    cDevice, _ := *(*C.nvmlDevice_t)(unsafe.Pointer(&Device)), cgoAllocsUnknown
    cCount, _ := (*C.uint)(unsafe.Pointer(Count)), cgoAllocsUnknown
    cPids, _ := (*C.uint)(unsafe.Pointer(Pids)), cgoAllocsUnknown
    __ret := C.nvmlDeviceGetAccountingPids(cDevice, cCount, cPids)
    __v := (Return)(__ret)
    return __v
}
```

Manual wrapper around the auto-generated bindings:
```
package nvml

func DeviceGetAccountingPids(Device Device) ([]int, Return) {
    var Count uint32 = 1 // Will be reduced upon returning
    for {
        Pids := make([]uint32, Count)
        ret := nvmlDeviceGetAccountingPids(Device, &Count, &Pids[0])
        if ret == SUCCESS {
            return uint32SliceToIntSlice(Pids[:Count]), ret
        }
        if ret != ERROR_INSUFFICIENT_SIZE {
            return nil, ret
        }
        Count *= 2
    }
}

func (Device Device) GetAccountingPids() ([]int, Return) {
    return DeviceGetAccountingPids(Device)
}

```

This manual wrapper makes it so that users don't have to write the boiler-plate
code of figuring out the correct `count` to pass into the API while at the same
time growing the `Pids` array and turning into a slice. It would be used as
follows:
```
device, _ := nvml.DeviceGetHandleByIndex(0)
pids, _ := device.GetAccountingPids()
...
```

This is actually one of the more complicated examples. Most of the
manual wrappers are very simple and look similar to the following:

Original API in `nvml.h`:
```
nvmlReturn_t nvmlDeviceGetUUID(nvmlDevice_t device, char *uuid, unsigned int length);
```

Auto-generated Go bindings from `c-for-go`:
```
func nvmlDeviceGetUUID(Device Device, Uuid *byte, Length uint32) Return {
    cDevice, _ := *(*C.nvmlDevice_t)(unsafe.Pointer(&Device)), cgoAllocsUnknown
    cUuid, _ := (*C.char)(unsafe.Pointer(Uuid)), cgoAllocsUnknown
    cLength, _ := (C.uint)(Length), cgoAllocsUnknown
    __ret := C.nvmlDeviceGetUUID(cDevice, cUuid, cLength)
    __v := (Return)(__ret)
    return __v
}
```

Manual wrapper around the auto-generated bindings:
```
package nvml

func DeviceGetUUID(Device Device) (string, Return) {
    Uuid := make([]byte, DEVICE_UUID_BUFFER_SIZE)
    ret := nvmlDeviceGetUUID(Device, &Uuid[0], DEVICE_UUID_BUFFER_SIZE)
    return string(Uuid[:clen(Uuid)]), ret
}

func (Device Device) GetUUID() (string, Return) {
    return DeviceGetUUID(Device)
}
```

While it does take some effort to take the auto-generated bindings and manually
wrap them in the more user-friendly API, this only has to be done once per API
call and then never touched again. As such, as new release of NVML come out,
only the new API calls will need to be added.

The following section goes into the details of how the code is structured, and
what each file's purpose is.

## Code Structure

There are two top-level directories in this repository:

* `/gen`
* `/pkg`

The `/gen` directory is used to house any code used in the _generation_ of the
final Go bindings. The `/pkg` directory is used to house any static packages
associated with this project as well as the actual Go bindings once they have
been generated. The one exception is the code used to dynamically load the
`libnvidia-ml.so` code from a host system and attach the go bindings to it. This
package requires no generated code and is housed statically under `pkg/dl`.
Once the code under `gen/nvml` has passed through `c-for-go` and any manual
manual wrappers applied, the final generated bindings are placed under
`pkg/nvml`.

In general, the code used to generate the NVML Go bindings can be broken into 4 logical parts:
1. Code defining the NVML API and how any auto-generated bindings should be produced
1. Code responsible for dynamically loading `libnvidia-ml.so` on a host system and hooking it up to the bindings
1. Code bridging the gap between any auto-generated bindings and the manual wrappers around them
1. The manual wrappers themselves
1. Test code

Each of these parts is discussed in detail below, along with the files associated with them.

### Code defining the NVML API

The following files aid in defining the NVML API and how any auto-generated bindings should be produced from it.

* `gen/nvml/nvml.h`
* `gen/nvml/nvml.yml`

The `nvml.h` file is a direct copy of `nvml.h` from the NVIDIA driver.  Since
the NVML API is guaranteed to be backwards compatible, we should strive to keep
this always up to date with the latest.

**Note:** The make process modifies `nvml.h` in that it translates any opaque
types defined by `nvml.h` into something more recognizable by `cgo`.

For example:
```
-typedef struct nvmlDevice_st* nvmlDevice_t;
+typedef struct
+{
+   struct nvmlDevice_st* handle;
+} nvmlDevice_t;
```

The two statements are semantically equivalent in terms of how they are laid
out in memory, but `cgo` will only generate a unique type for `nvmlDevice_t`
when expressed as the latter. When building the bindings we first update
`nvml.h` using `sed`, and then run `c-for-go` over it.

Finally, the `nvml.yml` file is the input file to `c-for-go` that tells it how
to parse `nvml.h` and auto-generate bindings for it. Please see the [`c-for-go`
wiki](https://github.com/xlab/c-for-go/wiki) for more information about the
contents of this file and how it works.

### Code to load `libnvidia-ml.so`

The code under `pkg/dl` is responsible for dynamically loading the
`libnvidia-ml.so` binary from a host system and connecting the go bindings to
it. This happens under the hood whenever a user makes an `nvml.Init()` call. It
is transparent to the end user, and should work without any further
user-intervention.

Depending on the version of `libnvidia-ml.so` that is found, certain
_versioned_ symbols need to be updated.  At the time of this writing, these
symbols include the following (as defined in `nvml.h`):

```
#ifndef NVML_NO_UNVERSIONED_FUNC_DEFS
    #define nvmlInit                                nvmlInit_v2
    #define nvmlDeviceGetPciInfo                    nvmlDeviceGetPciInfo_v3
    #define nvmlDeviceGetCount                      nvmlDeviceGetCount_v2
    #define nvmlDeviceGetHandleByIndex              nvmlDeviceGetHandleByIndex_v2
    #define nvmlDeviceGetHandleByPciBusId           nvmlDeviceGetHandleByPciBusId_v2
    #define nvmlDeviceGetNvLinkRemotePciInfo        nvmlDeviceGetNvLinkRemotePciInfo_v2
    #define nvmlDeviceRemoveGpu                     nvmlDeviceRemoveGpu_v2
    #define nvmlDeviceGetGridLicensableFeatures     nvmlDeviceGetGridLicensableFeatures_v3
    #define nvmlEventSetWait                        nvmlEventSetWait_v2
    #define nvmlDeviceGetAttributes                 nvmlDeviceGetAttributes_v2
    #define nvmlDeviceGetComputeRunningProcesses    nvmlDeviceGetComputeRunningProcesses_v2
    #define nvmlDeviceGetGraphicsRunningProcesses   nvmlDeviceGetGraphicsRunningProcesses_v2
#endif // #ifndef NVML_NO_UNVERSIONED_FUNC_DEFS
```

The actual versions that these API calls are assigned to will depend on the
version of the NVIDIA driver (and hence the version of `libnvidia-ml.so` that
you have linked in). These updates happen in the `updateVersionedSymbols()`
function of `gen/nvml/init.go` as seen below.

```
// Default all versioned APIs to v1 (to infer the types)
var nvmlInit = nvmlInit_v1
var nvmlDeviceGetPciInfo = nvmlDeviceGetPciInfo_v1
var nvmlDeviceGetCount = nvmlDeviceGetCount_v1
...

// updateVersionedSymbols()
func updateVersionedSymbols() {
	ret := nvml.Lookup("nvmlInit_v2")
	if ret == SUCCESS {
		nvmlInit = nvmlInit_v2
	}
	ret = nvml.Lookup("nvmlDeviceGetPciInfo_v2")
	if ret == SUCCESS {
		nvmlDeviceGetPciInfo = nvmlDeviceGetPciInfo_v2
	}
	ret = nvml.Lookup("nvmlDeviceGetPciInfo_v3")
	if ret == SUCCESS {
		nvmlDeviceGetPciInfo = nvmlDeviceGetPciInfo_v3
	}
	ret = nvml.Lookup("nvmlDeviceGetCount_v2")
	if ret == SUCCESS {
		nvmlDeviceGetCount = nvmlDeviceGetCount_v2
	}
	...
}
```

Whenever a new version of NVML comes out that either (1) adds a new versioned
API call, or (2) bumps the version of an existing API call -- we need to make
sure and update this function appropriately (as well as make the necessary
changes to `nvidia.yml` to ensure all `v1` symbols are imported appropriately).

### Code to bridge the auto-generated and manual bindings

The files below define a set of "glue" code between the auto-generated bindings
from `c-for-go` and the manual wrappers providing a more user-friendly API to
the end user.

* `gen/nvml/cgo_helpers.go`
* `gen/nvml/return.go`

The `cgo_helpers.go` file defines functions that help in dealing with the types
coming out of the C API and turning them into more usable Go types. It is
actually a stripped down version of the auto-generated `cgo_helpers.go` file
from `c-for-go` that we have whittled down to the bare essentials. We also
define a few of our own functions in here as well. For example, doing things
like finding the length of a `NULL` terminated string inside a byte slice
(`clen()`), and converting a `uint32` slice into an `int` slice
(`uint32SliceToIntSlice()`), etc.

The `return.go` file simply wraps the `Return` type created by `c-for-go`
(which is a go-ified version of the `nvmlReturn_t` type from C) and has it
implement the `Error` interface so it can be returned as a normal Go `error`
type if desired. The string returned as part of the error is the result of
calling `nvmlErrorString()` under the hood.

### Manual wrappers around the auto-generated bindings from `c-for-go`

The following files add manual wrappers around all of the auto-generated
bindings from `c-for-go`. Only these manual wrappers are expected as part of
the API for the package -- the auto-generated bindings are only available for
internal use.

* `gen/nvml/init.go`
* `gen/nvml/system.go`
* `gen/nvml/event_set.go`
* `gen/nvml/vgpu.go`
* `gen/nvml/unit.go`
* `gen/nvml/device.go`

These wrappers add boiler-plate code around the auto-generated bindings so that
the end-user doesn't have to do this themselves every time a call is made.

When appropriate, they also bind functions to the top-level `types` that are
defined (e.g. `Unit`, `Device`, `EventSet`, `Vgpu`, etc.) so that functions can
be called directly on instances of these types instead of using a call at the
package scope.

A few examples of a this can be seen below:
```
// nvml.UnitGetDevices()
func UnitGetDevices(Unit Unit) ([]Device, Return) {
	var DeviceCount uint32 = 1 // Will be reduced upon returning
	for {
		Devices := make([]Device, DeviceCount)
		ret := nvmlUnitGetDevices(Unit, &DeviceCount, &Devices[0])
		if ret == SUCCESS {
			return Devices[:DeviceCount], ret
		}
		if ret != ERROR_INSUFFICIENT_SIZE {
			return nil, ret
		}
		DeviceCount *= 2
	}
}

func (Unit Unit) GetDevices() ([]Device, Return) {
	return UnitGetDevices(Unit)
}

// nvml.DeviceGetUUID()
func DeviceGetUUID(Device Device) (string, Return) {
	Uuid := make([]byte, DEVICE_UUID_BUFFER_SIZE)
	ret := nvmlDeviceGetUUID(Device, &Uuid[0], DEVICE_UUID_BUFFER_SIZE)
	return string(Uuid[:clen(Uuid)]), ret
}

func (Device Device) GetUUID() (string, Return) {
	return DeviceGetUUID(Device)
}

// nvml.EventSetWait()
func EventSetWait(Set EventSet, Timeoutms uint32) (EventData, Return) {
	var Data EventData
	ret := nvmlEventSetWait(Set, &Data, Timeoutms)
	return Data, ret
}

func (Set EventSet) Wait(Timeoutms uint32) (EventData, Return) {
	return EventSetWait(Set, Timeoutms)
}

// nvml.VgpuInstanceGetUUID()
func VgpuInstanceGetUUID(VgpuInstance VgpuInstance) (string, Return) {
	Uuid := make([]byte, DEVICE_UUID_BUFFER_SIZE)
	ret := nvmlVgpuInstanceGetUUID(VgpuInstance, &Uuid[0], DEVICE_UUID_BUFFER_SIZE)
	return string(Uuid[:clen(Uuid)]), ret
}

func (VgpuInstance VgpuInstance) GetUUID() (string, Return) {
	return VgpuInstanceGetUUID(VgpuInstance)
}

```

Whenever a new version of NVML comes out that adds new API calls, a new set of
manual wrappers will need to be added to keep the API up-to-date. Adding the
initial set of wrappers was very time consuming, but adding additional wrappers
should be straightforward so long as we keep good pace with each new release.

### Test code

At present, all test code is under the following file:
* `gen/nvml/nvml_test.go`

The test coverage is fairly sparse and could be greatly improved.

## Building and Testing

Building and testing the bindings is fairly straight-forward. The only
prerequisite is a working installation of `c-for-go` from
https://github.com/xlab/c-for-go.

**Note**: Please check the `Makefile` for the specific version of `c-for-go` used.

Once this is available, just run the sequence below to build and test these
NVML Go bindings. The generated bindings will be placed under `go-nvml/pkg/nvml`.
```
$ make
c-for-go -out pkg gen/nvml/nvml.yml
  processing gen/nvml/nvml.yml done.
cp gen/nvml/*.go pkg/nvml
cd pkg/nvml; \
	go tool cgo -godefs types.go > types_gen.go; \
	go fmt types_gen.go; \
cd -> /dev/null
types_gen.go
rm -rf pkg/nvml/types.go pkg/nvml/_obj

$ make test
cd pkg/nvml; \
	go test -v .; \
cd -> /dev/null
=== RUN   TestInit
    TestInit: nvml_test.go:26: Init: Success
    TestInit: nvml_test.go:33: Shutdown: Success
--- PASS: TestInit (0.06s)
=== RUN   TestSystem
    TestSystem: nvml_test.go:45: SystemGetDriverVersion: Success
    TestSystem: nvml_test.go:46:   version: 410.104
    TestSystem: nvml_test.go:53: SystemGetNVMLVersion: Success
    TestSystem: nvml_test.go:54:   version: 10.410.104
    TestSystem: nvml_test.go:61: SystemGetCudaDriverVersion: Success
    TestSystem: nvml_test.go:62:   version: 10000
    TestSystem: nvml_test.go:69: SystemGetCudaDriverVersion_v2: Success
    TestSystem: nvml_test.go:70:   version: 10000
    TestSystem: nvml_test.go:77: SystemGetProcessName: Success
    TestSystem: nvml_test.go:78:   name: /lib/systemd/s
    TestSystem: nvml_test.go:85: SystemGetHicVersion: Success
    TestSystem: nvml_test.go:86:   count: 0
    TestSystem: nvml_test.go:96: SystemGetTopologyGpuSet: Success
    TestSystem: nvml_test.go:97:   count: 4
    TestSystem: nvml_test.go:99:   device[0]: {0x7f5875284408}
    TestSystem: nvml_test.go:99:   device[1]: {0x7f5875298e90}
    TestSystem: nvml_test.go:99:   device[2]: {0x7f58752ad918}
    TestSystem: nvml_test.go:99:   device[3]: {0x7f58752c23a0}
--- PASS: TestSystem (0.10s)
=== RUN   TestUnit
    TestUnit: nvml_test.go:112: UnitGetCount: Success
    TestUnit: nvml_test.go:113:   count: 0
    TestUnit: nvml_test.go:117: Skipping test with no Units.
--- SKIP: TestUnit (0.06s)
=== RUN   TestEventSet
    TestEventSet: nvml_test.go:253: EventSetCreate: Success
    TestEventSet: nvml_test.go:254:   set: {0x2122f10}
    TestEventSet: nvml_test.go:261: EventSetWait: Timeout
    TestEventSet: nvml_test.go:262:   data: {{<nil>} 0 0 0 0}
    TestEventSet: nvml_test.go:269: EventSet.Wait: Timeout
    TestEventSet: nvml_test.go:270:   data: {{<nil>} 0 0 0 0}
    TestEventSet: nvml_test.go:277: EventSetFree: Success
    TestEventSet: nvml_test.go:285: EventSet.Free: Success
--- PASS: TestEventSet (0.06s)
PASS
ok  	github.com/NVIDIA/go-nvml/pkg/nvml	0.283s
```

**Note:** A working NVIDIA driver with `libnvidia-ml.so` is not required to
compile code that imports these bindings. However, you will get a runtime error
if `libnvidia-ml.so` is not available in your library path at runtime.

## Updating the Code

The general steps to update the bindings to a newer version of the NVML API are as follows:

### Update `nvml.h`

Pull down the `nvml.h` containing the updated API and commit it back to `gen/nvml/nvml.h`. The `Makefile` contains a command:
```bash
make CUDA_VERSION=11.1 update-nvml-h
```
that copies the file from the specified NVIDIA CUDA development image (version 11.1 in this case). The command will fail if no `CUDA_VERSION` is specified.

Since `gen/nvml/nvml.h` is under version control, running:
```
git diff -w
```
(ignoring whitspace) will show us which new API calls there are.

### Add new versioned APIs
If there are changes to the versioned APIs (defined as in the `#ifndef NVML_NO_UNVERSIONED_FUNC_DEFS` block in `gen/nvml/nvml.h`) `nvml.yml` and `init.go` must be updated accordingly.

The modified versioned calls can be found bu running:
```
git diff -w gen/nvml/nvml.h | grep -E "^\+\s*#define.*?_v[^1]"
```

### Add manual wrappers
Write a set of manual wappers around any new calls as described in one of the previous sections above.

The following command should show the API calls added in the update:
```
git diff -w gen/nvml/nvml.h | grep "+nvmlReturn_t DECLDIR nvml"
```
Note that these includes the new versions of existing calls -- which should already have been handled in the previous section. To exclude these run:
```
git diff -w gen/nvml/nvml.h | grep "+nvmlReturn_t DECLDIR nvml" | grep -vE "_v\d+\("
```

Of course this is just the general flow, and there may be more work to do if
new types are added, or a new API is created that does something outside the
scope of what has been done so far. These guidelines should be good a starting
point though.

Keep in mind, that all updates to the NVML bindings code should be made in the
`gen/` directory of the repository. Only when releasing new bindings will this
code be processed and pushed to the `pkg/` directory for release.

## Releasing
Once the code in `gen/` has been fully updated to support a particular version of NVML, a new release should be created.

As part of the release, two things need to happen:
1. A new set of bindings needs to be generated from the code under `gen/` and committed into `pkg/`
2. A tag with the appropriate NVML release needs to be added to the repo and pushed upstream.

An example of this workflow for the 11.0 release of NVML can be seen below:
```
# Commit the generated bindings back to master
git checkout master
make
git add -f pkg/
git commit -m "Add bindings for v11.0 of the NVML API"
git push origin

# Tag the repo with the version number and push it upstream
git tag v11.0
git push origin v11.0
```

If updates need to be made against a particular version (due to bugs in the
bindings code, for example), then we append a `-<revision>` number to the
version tag we push.

For example:
```
git checkout v11.0
git checkout -b bug-fixes-for-v11.0
... fix bugs and commit
git tag v11.0-1
git push v11.0-1
```

Since the NVML API is designed to be backwards compatible, we envision it being
rare to require such backports (because people can just use the latest bindings
instead of relying on a particular version). However, we may perform such
backports from time-to-time as deemed necessary (or upon request).

## Contributing

Please see the file [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to
contribute to this project.

repository: suchiagicha/go-nvml

repo_name: suchiagicha/go-nvml


text:
# trainset
A lathe gear change set calculator for lathes with an M/N * A/B * C/D style gearbox.

# How to Run:

These instructions are for Linux, but running on OS X will be identical. Running on Windows should be very similar.

Linux:
```
$ ./trainset
Usage: ./trainset <gear library> <output file> <M gear> <N gear> <pitch>
$
```

Windows:
` C:\Users\My Username\trainset.exe> <gear library> <output file> <M gear> <N gear> <pitch>`

# Explanation:
* ./trainset is the name of the command
* `<gear library>` is a file containing one number for each gear you have. In my library, I have 2x 32T gears, so I include the number 32 twice. The order is not important.
* `<output file>` is the name of a text file you want the trainset to save its output as.
* `<M gear>` The M gear.
* `<N gear>` The N gear. If you don't have M/N gears, just enter 1 and 1.
* `<pitch>` The pitch of your leadscrew in mm.

Example - My lathe is an L141 from Hare and Forbes in Australia. I created a gear library file for the ABCD gears (MN gears need to be treated separately for the moment), and the lathe has a 3mm pitch on the leadscrew.

`./trainset L141.lib.txt L141.28.35.out.txt 28 35 3`

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
This is an Atlas plugin that will let you edit and run Processing sketches using [codemirror](http://codemirror.net/) and [processingjs](http://processingjs.org/).  See the [project page](http://odewahn.github.io/orm-coderunner-processingjs/) for details and examples.

MIT Licensed.

license: MIT

repository: odewahn/orm-coderunner-processingjs

repo_name: odewahn/orm-coderunner-processingjs


text:
# InvoiceCreationResponse

## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**invoiceData** | [**InvoiceCreationDataResponse**](InvoiceCreationDataResponse.md) | Structure of invoice data |  [optional]
**invoiceUrl** | **String** | Invoice URL |  [optional]

gha_language: Java

gha_license_id: MIT


text:
---
layout: default
---

# 1995-08-11 - Re:  More "S-1" foolishness

## Header Data

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

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1995-08-11 08:55:14 UTC

Raw Date: Fri, 11 Aug 95 01:55:14 PDT

## Raw message

```
{% raw  %}From: Hal<EMAIL_ADDRESS>Date: Fri, 11 Aug 95 01:55:14 PDT
To<EMAIL_ADDRESS>Subject: Re:  More "S-1" foolishness
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

The other thing I noticed that really makes me question this is that G1
only uses 4 of its 8 input bits.  As I wrote, it is equivalent to
parity(i&0x17).  A bit is a terrible thing to waste, and it is hard to
imagine why it would do this intentionally.  G1 may not be that important
an element of the cipher but why throw away four bits?

It is possible I suppose that the F and G boxes are not the ones used
in the "real" version of whatever cipher this is, so this apparent
weakness and the ones which Matt has pointed out may not be that
significant.

Hal

{% endraw %}
```

## Thread

+ Return to [August 1995](/archive/1995/08)

+ Return to "[Hal <hfinney@shell.portal.com>](/authors/hal_hfinney_at_shell_portal_com_)"
+ Return to "[Jim Gillogly <jim@acm.org>](/authors/jim_gillogly_jim_at_acm_org_)"
+ Return to "[Matt Blaze <mab@crypto.com>](/authors/matt_blaze_mab_at_crypto_com_)"

+ 1995-08-11 (Fri, 11 Aug 95 01:55:14 PDT) - Re:  More "S-1" foolishness - _Hal<EMAIL_ADDRESS>  + 1995-08-11 (Fri, 11 Aug 95 02:14:55 PDT) - [Re: More "S-1" foolishness](/archive/1995/08/3ae3ef3d57e7e6fbd0e9450516548ef64974928842dc968bc355a1746b31dbff) - _Jim Gillogly<EMAIL_ADDRESS>  + 1995-08-11 (Fri, 11 Aug 95 04:35:03 PDT) - [Re: More "S-1" foolishness](/archive/1995/08/54bcc02138a0ffeddd92b76a547c137551a9ed3fc1ca54a54d137668fd2f788c) - _Matt Blaze<EMAIL_ADDRESS>


text:
18 Exercises: JavaServer Faces
==============================

---
---

Problems for exercises and homework for the [“Java Web Development Basics”
course \@
SoftUni](https://softuni.bg/trainings/1844/java-web-development-basics-january-2018/internal).
Submit your solutions on the **course page** of the **current instance**.

18.01 Employee Register
-----------------------

You have been tasked to create a simple page using JSF, for a big company. The
page should support displaying, creating and deleting data about employees. The
page should also present aggregated data in the form of sums and averages.

Start by creating the **Employee** class. It should have the following
properties:

-   **First Name**

-   **Last Name**

-   **Position**

-   **Salary**

-   **Age**

### Displaying Employees

Add some employees from the code (in a static collection or just any way you
want) and display them like this.

**NOTE**: Use the **given HTML** resources to construct the JSF exactly like the
screenshot above.

### Deleting Employees

Implement functionality for **removing employees**. By clicking on the
[**Remove**] button, the corresponding employee should be **deleted** .

### Creating Employees

Creating Employees is simple. Implement a form on the page (again, using the
given HTML resources), for Employee creation. It should have fields for **First
Name**, **Last Name**, **Position**, **Salary** and **Age**.

The **Salary** and **Age** should be **number-type** inputs.

You don’t need an additional page. Everything from this task will be done on
this page.

The form should look like this:

**Submitting** the **form** (clicking on the [**Register**] button) should
**initialize** an **Employee object,** with the data from the **input fields**.
If there is an **empty field**, **NOTHING** should happen, and **NO** Employee
should be added.

### Aggregating Employees

Finally, implement a simple aggregated data about the **Total Salary** needed to
pay all **Employees**, and the **Average Employee Salary** given.

This data should depend only on the existent **Employees**. **Deleted
Employees** do **not figurate** in this data.

It should look like this:

### Expected Result

Now, if you have implemented everything correctly, you should have a fully
functional Employee Register Page, which looks like this:

### Solution: Employee Register

---

url: https://raw.githubusercontent.com/TsvetanNikolov123/JAVA---Java-Web-Development-Basics/0513097dc9443520c987a2b7be32cd14d0476610/18 EXERCISE JAVA EE JAVASERVER FACES/README.md


text:
# sonic-pas-config-s6000
This repo holds the configuration files for the SONiC PAS component.

## Description
The sonic PAS component will read the configuration files to determine how to initialize the system and understand which devices are expected to be present and should be tracked.

Additionally this repo has python services using the PAS to monitor startup and optionally events.

A good example of using the object-library interfaces to communicate with the pas can be found in the cfg/bin directory.

Building
--------
Please see the instructions in the sonic-nas-manifest repo for more details on the common build tools.  [Sonic-nas-manifest](https://github.com/Azure/sonic-nas-manifest)

BUILD CMD: sonic_build -- clean binary

(c) Dell 2016


text:
Open-PDKs (open_pdks)
-----------------------------------------

Summary:

Automatic setup of PDKs for open-source tools from foundry sources.

Builds out and populates a new set of directories and subdirectories in
the efabless format, with the efabless name for the PDK at the top,
followed by categories "libs.ref" (IP) and "libs.tech" (EDA tool setup),
each with subcategories corresponding to layout, abstract views,
netlists, etc. for the IP;  and magic, netgen, qflow, etc., for the
EDA tool setup.

The populated PDK directories can contain either copies of files from
the foundry sources, links to the foundry sources, or links back to
another PDK.

Generates magic layout views for all vendor IP for which either a GDS
view or a LEF view exists.  Annotates the views as needed to handle
ports, bounding boxes, etc.

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

This distribution contains sources for building out the SkyWater s8
130nm process.  Sources for the foundry process data must be obtained
separately.  Read the README file in subdirectory s8/ for instructions
on obtaining and building the SkyWater s8 PDK.

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

License:

Open_PDKs is open-source software distributed under the Apache-2.0 license.
See file LICENSE for the complete license text.

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

Instructions:

There is a top-level Makefile but generally it is recommended to cd
to the directory for the target foundry process and follow the instructions
in the README file there.

Also see the website at http://opencircuitdesign.com/open_pdks


text:
[![Code Climate](https://codeclimate.com/github/slopy/pc_rails_code_quality/badges/gpa.svg)](https://codeclimate.com/github/slopy/pc_rails_code_quality)
[![Test Coverage](https://codeclimate.com/github/slopy/pc_rails_code_quality/badges/coverage.svg)](https://codeclimate.com/github/slopy/pc_rails_code_quality/coverage)
[![Issue Count](https://codeclimate.com/github/slopy/pc_rails_code_quality/badges/issue_count.svg)](https://codeclimate.com/github/slopy/pc_rails_code_quality)
[![Build Status](https://travis-ci.org/slopy/pc_rails_code_quality.svg?branch=master)](https://travis-ci.org/slopy/pc_rails_code_quality)

# PcRailsCodeQuality
This gem is a compilation of usefull rails gems:
- rubocop
- rubycritic
- simplecov
- rails_best_practices
- brakeman

## Usage
How to use my plugin.

## Installation
Add this line to your application's Gemfile:

```ruby
group :development, :test do
  gem 'pc_rails_code_quality', :git => 'https://github.com/slopy/pc_rails_code_quality'
end
```

And then execute:
```bash
$ bundle
```

## Generating reports

```bash
$ rake pc_reports:html
```

## Web UI

Add to you routes.rb
```ruby
mount PcRailsCodeQuality::Engine => "/"
```

To show menu on other pages

In ApplicationController
```ruby
  helper PcRailsCodeQuality::ApplicationHelper
```

In layout file
```erb
  <%= stylesheet_link_tag "pc_rails_code_quality/application.css" %>
  <%= code_quality_fixed_menu %>
```

Then you can access the reports:
* **rubocop** /dev/reports/rubocop
* **rubycritic** /dev/reports/rubycritic
* **tests** /dev/reports/tests
* **simplecov** /dev/reports/simplecov
* **rails_best_practices** /dev/reports/rails_best_practices
* **brakeman** /dev/reports/brakeman

## Test reports
add
```ruby
require "pc_rails_code_quality/tests"
```
to your **test_helper or spec_helper**

## Contributing
Contact<EMAIL_ADDRESS>
## License
The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).

gha_language: Ruby


text:
# Pinning

To poll futures, they must be pinned using a special type called
`Pin<T>`. If you read the explanation of [the `Future` trait] in the
previous section ["Executing `Future`s and Tasks"], you'll recognize
`Pin` from the `self: Pin<&mut Self>` in the `Future::poll` method's definition.
But what does it mean, and why do we need it?

## Why Pinning

`Pin` works in tandem with the `Unpin` marker. Pinning makes it possible
to guarantee that an object implementing `!Unpin` won't ever be moved. To understand
why this is necessary, we need to remember how `async`/`.await` works. Consider
the following code:

```rust,edition2018,ignore
let fut_one = /* ... */;
let fut_two = /* ... */;
async move {
    fut_one.await;
    fut_two.await;
}
```

Under the hood, this creates an anonymous type that implements `Future`,
providing a `poll` method that looks something like this:

```rust,ignore
// The `Future` type generated by our `async { ... }` block
struct AsyncFuture {
    fut_one: FutOne,
    fut_two: FutTwo,
    state: State,
}

// List of states our `async` block can be in
enum State {
    AwaitingFutOne,
    AwaitingFutTwo,
    Done,
}

impl Future for AsyncFuture {
    type Output = ();

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
        loop {
            match self.state {
                State::AwaitingFutOne => match self.fut_one.poll(..) {
                    Poll::Ready(()) => self.state = State::AwaitingFutTwo,
                    Poll::Pending => return Poll::Pending,
                }
                State::AwaitingFutTwo => match self.fut_two.poll(..) {
                    Poll::Ready(()) => self.state = State::Done,
                    Poll::Pending => return Poll::Pending,
                }
                State::Done => return Poll::Ready(()),
            }
        }
    }
}
```

When `poll` is first called, it will poll `fut_one`. If `fut_one` can't
complete, `AsyncFuture::poll` will return. Future calls to `poll` will pick
up where the previous one left off. This process continues until the future
is able to successfully complete.

However, what happens if we have an `async` block that uses references?
For example:

```rust,edition2018,ignore
async {
    let mut x = [0; 128];
    let read_into_buf_fut = read_into_buf(&mut x);
    read_into_buf_fut.await;
    println!("{:?}", x);
}
```

What struct does this compile down to?

```rust,ignore
struct ReadIntoBuf<'a> {
    buf: &'a mut [u8], // points to `x` below
}

struct AsyncFuture {
    x: [u8; 128],
    read_into_buf_fut: ReadIntoBuf<'what_lifetime?>,
}
```

Here, the `ReadIntoBuf` future holds a reference into the other field of our
structure, `x`. However, if `AsyncFuture` is moved, the location of `x` will
move as well, invalidating the pointer stored in `read_into_buf_fut.buf`.

Pinning futures to a particular spot in memory prevents this problem, making
it safe to create references to values inside an `async` block.

## Pinning in Detail

Let's try to understand pinning by using an slightly simpler example. The problem we encounter
above is a problem that ultimately boils down to how we handle references in self-referential
types in Rust.

For now our example will look like this:

```rust, ignore
#[derive(Debug)]
struct Test {
    a: String,
    b: *const String,
}

impl Test {
    fn new(txt: &str) -> Self {
        Test {
            a: String::from(txt),
            b: std::ptr::null(),
        }
    }

    fn init(&mut self) {
        let self_ref: *const String = &self.a;
        self.b = self_ref;
    }

    fn a(&self) -> &str {
        &self.a
    }

    fn b(&self) -> &String {
        assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
        unsafe { &*(self.b) }
    }
}
```

`Test` provides methods to get a reference to the value of the fields `a` and `b`. Since `b` is a
reference to `a` we store it as a pointer since the borrowing rules of Rust doesn't allow us to
define this lifetime. We now have what we call a self-referential struct.

Our example works fine if we don't move any of our data around as you can observe by running
this example:

```rust
fn main() {
    let mut test1 = Test::new("test1");
    test1.init();
    let mut test2 = Test::new("test2");
    test2.init();

    println!("a: {}, b: {}", test1.a(), test1.b());
    println!("a: {}, b: {}", test2.a(), test2.b());

}
# #[derive(Debug)]
# struct Test {
#     a: String,
#     b: *const String,
# }
#
# impl Test {
#     fn new(txt: &str) -> Self {
#         Test {
#             a: String::from(txt),
#             b: std::ptr::null(),
#         }
#     }
#
#     // We need an `init` method to actually set our self-reference
#     fn init(&mut self) {
#         let self_ref: *const String = &self.a;
#         self.b = self_ref;
#     }
#
#     fn a(&self) -> &str {
#         &self.a
#     }
#
#     fn b(&self) -> &String {
#         assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
#         unsafe { &*(self.b) }
#     }
# }
```
We get what we'd expect:

```rust, ignore
a: test1, b: test1
a: test2, b: test2
```

Let's see what happens if we swap `test1` with `test2` and thereby move the data:

```rust
fn main() {
    let mut test1 = Test::new("test1");
    test1.init();
    let mut test2 = Test::new("test2");
    test2.init();

    println!("a: {}, b: {}", test1.a(), test1.b());
    std::mem::swap(&mut test1, &mut test2);
    println!("a: {}, b: {}", test2.a(), test2.b());

}
# #[derive(Debug)]
# struct Test {
#     a: String,
#     b: *const String,
# }
#
# impl Test {
#     fn new(txt: &str) -> Self {
#         Test {
#             a: String::from(txt),
#             b: std::ptr::null(),
#         }
#     }
#
#     fn init(&mut self) {
#         let self_ref: *const String = &self.a;
#         self.b = self_ref;
#     }
#
#     fn a(&self) -> &str {
#         &self.a
#     }
#
#     fn b(&self) -> &String {
#         assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
#         unsafe { &*(self.b) }
#     }
# }
```

Naively, we could think that what we should get a debug print of `test1` two times like this:

```rust, ignore
a: test1, b: test1
a: test1, b: test1
```

But instead we get:

```rust, ignore
a: test1, b: test1
a: test1, b: test2
```

The pointer to `test2.b` still points to the old location which is inside `test1`
now. The struct is not self-referential anymore, it holds a pointer to a field
in a different object. That means we can't rely on the lifetime of `test2.b` to
be tied to the lifetime of `test2` anymore.

If you're still not convinced, this should at least convince you:

```rust
fn main() {
    let mut test1 = Test::new("test1");
    test1.init();
    let mut test2 = Test::new("test2");
    test2.init();

    println!("a: {}, b: {}", test1.a(), test1.b());
    std::mem::swap(&mut test1, &mut test2);
    test1.a = "I've totally changed now!".to_string();
    println!("a: {}, b: {}", test2.a(), test2.b());

}
# #[derive(Debug)]
# struct Test {
#     a: String,
#     b: *const String,
# }
#
# impl Test {
#     fn new(txt: &str) -> Self {
#         Test {
#             a: String::from(txt),
#             b: std::ptr::null(),
#         }
#     }
#
#     fn init(&mut self) {
#         let self_ref: *const String = &self.a;
#         self.b = self_ref;
#     }
#
#     fn a(&self) -> &str {
#         &self.a
#     }
#
#     fn b(&self) -> &String {
#         assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
#         unsafe { &*(self.b) }
#     }
# }
```

The diagram below can help visualize what's going on:

**Fig 1: Before and after swap**
![swap_problem](../assets/swap_problem.jpg)

It's easy to get this to show undefined behavior and fail in other spectacular ways as well.

## Pinning in Practice

Let's see how pinning and the `Pin` type can help us solve this problem.

The `Pin` type wraps pointer types, guaranteeing that the values behind the
pointer won't be moved if it is not implementing `Unpin`. For example, `Pin<&mut
T>`, `Pin<&T>`, `Pin<Box<T>>` all guarantee that `T` won't be moved if `T:
!Unpin`.

Most types don't have a problem being moved. These types implement a trait
called `Unpin`. Pointers to `Unpin` types can be freely placed into or taken
out of `Pin`. For example, `u8` is `Unpin`, so `Pin<&mut u8>` behaves just like
a normal `&mut u8`.

However, types that can't be moved after they're pinned have a marker called
`!Unpin`. Futures created by async/await is an example of this.

### Pinning to the Stack

Back to our example. We can solve our problem by using `Pin`. Let's take a look at what
our example would look like if we required a pinned pointer instead:

```rust, ignore
use std::pin::Pin;
use std::marker::PhantomPinned;

#[derive(Debug)]
struct Test {
    a: String,
    b: *const String,
    _marker: PhantomPinned,
}

impl Test {
    fn new(txt: &str) -> Self {
        Test {
            a: String::from(txt),
            b: std::ptr::null(),
            _marker: PhantomPinned, // This makes our type `!Unpin`
        }
    }

    fn init(self: Pin<&mut Self>) {
        let self_ptr: *const String = &self.a;
        let this = unsafe { self.get_unchecked_mut() };
        this.b = self_ptr;
    }

    fn a(self: Pin<&Self>) -> &str {
        &self.get_ref().a
    }

    fn b(self: Pin<&Self>) -> &String {
        assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
        unsafe { &*(self.b) }
    }
}
```

Pinning an object to the stack will always be `unsafe` if our type implements
`!Unpin`. You can use a crate like [`pin_utils`][pin_utils] to avoid writing
our own `unsafe` code when pinning to the stack.

Below, we pin the objects `test1` and `test2` to the stack:

```rust
pub fn main() {
    // test1 is safe to move before we initialize it
    let mut test1 = Test::new("test1");
    // Notice how we shadow `test1` to prevent it from being accessed again
    let mut test1 = unsafe { Pin::new_unchecked(&mut test1) };
    Test::init(test1.as_mut());

    let mut test2 = Test::new("test2");
    let mut test2 = unsafe { Pin::new_unchecked(&mut test2) };
    Test::init(test2.as_mut());

    println!("a: {}, b: {}", Test::a(test1.as_ref()), Test::b(test1.as_ref()));
    println!("a: {}, b: {}", Test::a(test2.as_ref()), Test::b(test2.as_ref()));
}
# use std::pin::Pin;
# use std::marker::PhantomPinned;
#
# #[derive(Debug)]
# struct Test {
#     a: String,
#     b: *const String,
#     _marker: PhantomPinned,
# }
#
#
# impl Test {
#     fn new(txt: &str) -> Self {
#         Test {
#             a: String::from(txt),
#             b: std::ptr::null(),
#             // This makes our type `!Unpin`
#             _marker: PhantomPinned,
#         }
#     }
#
#     fn init(self: Pin<&mut Self>) {
#         let self_ptr: *const String = &self.a;
#         let this = unsafe { self.get_unchecked_mut() };
#         this.b = self_ptr;
#     }
#
#     fn a(self: Pin<&Self>) -> &str {
#         &self.get_ref().a
#     }
#
#     fn b(self: Pin<&Self>) -> &String {
#         assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
#         unsafe { &*(self.b) }
#     }
# }
```

Now, if we try to move our data now we get a compilation error:

```rust, compile_fail
pub fn main() {
    let mut test1 = Test::new("test1");
    let mut test1 = unsafe { Pin::new_unchecked(&mut test1) };
    Test::init(test1.as_mut());

    let mut test2 = Test::new("test2");
    let mut test2 = unsafe { Pin::new_unchecked(&mut test2) };
    Test::init(test2.as_mut());

    println!("a: {}, b: {}", Test::a(test1.as_ref()), Test::b(test1.as_ref()));
    std::mem::swap(test1.get_mut(), test2.get_mut());
    println!("a: {}, b: {}", Test::a(test2.as_ref()), Test::b(test2.as_ref()));
}
# use std::pin::Pin;
# use std::marker::PhantomPinned;
#
# #[derive(Debug)]
# struct Test {
#     a: String,
#     b: *const String,
#     _marker: PhantomPinned,
# }
#
#
# impl Test {
#     fn new(txt: &str) -> Self {
#         Test {
#             a: String::from(txt),
#             b: std::ptr::null(),
#             _marker: PhantomPinned, // This makes our type `!Unpin`
#         }
#     }
#
#     fn init(self: Pin<&mut Self>) {
#         let self_ptr: *const String = &self.a;
#         let this = unsafe { self.get_unchecked_mut() };
#         this.b = self_ptr;
#     }
#
#     fn a(self: Pin<&Self>) -> &str {
#         &self.get_ref().a
#     }
#
#     fn b(self: Pin<&Self>) -> &String {
#         assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
#         unsafe { &*(self.b) }
#     }
# }
```

The type system prevents us from moving the data, as follows:

```
error[E0277]: `PhantomPinned` cannot be unpinned
   --> src\test.rs:56:30
    |
56  |         std::mem::swap(test1.get_mut(), test2.get_mut());
    |                              ^^^^^^^ within `test1::Test`, the trait `Unpin` is not implemented for `PhantomPinned`
    |
    = note: consider using `Box::pin`
note: required because it appears within the type `test1::Test`
   --> src\test.rs:7:8
    |
7   | struct Test {
    |        ^^^^
note: required by a bound in `std::pin::Pin::<&'a mut T>::get_mut`
   --> <...>rustlib/src/rust\library\core\src\pin.rs:748:12
    |
748 |         T: Unpin,
    |            ^^^^^ required by this bound in `std::pin::Pin::<&'a mut T>::get_mut`
```

> It's important to note that stack pinning will always rely on guarantees
> you give when writing `unsafe`. While we know that the _pointee_ of `&'a mut T`
> is pinned for the lifetime of `'a` we can't know if the data `&'a mut T`
> points to isn't moved after `'a` ends. If it does it will violate the Pin
> contract.
>
> A mistake that is easy to make is forgetting to shadow the original variable
> since you could drop the `Pin` and move the data after `&'a mut T`
> like shown below (which violates the Pin contract):
>
> ```rust
> fn main() {
>    let mut test1 = Test::new("test1");
>    let mut test1_pin = unsafe { Pin::new_unchecked(&mut test1) };
>    Test::init(test1_pin.as_mut());
>
>    drop(test1_pin);
>    println!(r#"test1.b points to "test1": {:?}..."#, test1.b);
>
>    let mut test2 = Test::new("test2");
>    mem::swap(&mut test1, &mut test2);
>    println!("... and now it points nowhere: {:?}", test1.b);
> }
> # use std::pin::Pin;
> # use std::marker::PhantomPinned;
> # use std::mem;
> #
> # #[derive(Debug)]
> # struct Test {
> #     a: String,
> #     b: *const String,
> #     _marker: PhantomPinned,
> # }
> #
> #
> # impl Test {
> #     fn new(txt: &str) -> Self {
> #         Test {
> #             a: String::from(txt),
> #             b: std::ptr::null(),
> #             // This makes our type `!Unpin`
> #             _marker: PhantomPinned,
> #         }
> #     }
> #
> #     fn init<'a>(self: Pin<&'a mut Self>) {
> #         let self_ptr: *const String = &self.a;
> #         let this = unsafe { self.get_unchecked_mut() };
> #         this.b = self_ptr;
> #     }
> #
> #     fn a<'a>(self: Pin<&'a Self>) -> &'a str {
> #         &self.get_ref().a
> #     }
> #
> #     fn b<'a>(self: Pin<&'a Self>) -> &'a String {
> #         assert!(!self.b.is_null(), "Test::b called without Test::init being called first");
> #         unsafe { &*(self.b) }
> #     }
> # }
> ```

### Pinning to the Heap

Pinning an `!Unpin` type to the heap gives our data a stable address so we know
that the data we point to can't move after it's pinned. In contrast to stack
pinning, we know that the data will be pinned for the lifetime of the object.

```rust, edition2018
use std::pin::Pin;
use std::marker::PhantomPinned;

#[derive(Debug)]
struct Test {
    a: String,
    b: *const String,
    _marker: PhantomPinned,
}

impl Test {
    fn new(txt: &str) -> Pin<Box<Self>> {
        let t = Test {
            a: String::from(txt),
            b: std::ptr::null(),
            _marker: PhantomPinned,
        };
        let mut boxed = Box::pin(t);
        let self_ptr: *const String = &boxed.a;
        unsafe { boxed.as_mut().get_unchecked_mut().b = self_ptr };

        boxed
    }

    fn a(self: Pin<&Self>) -> &str {
        &self.get_ref().a
    }

    fn b(self: Pin<&Self>) -> &String {
        unsafe { &*(self.b) }
    }
}

pub fn main() {
    let test1 = Test::new("test1");
    let test2 = Test::new("test2");

    println!("a: {}, b: {}",test1.as_ref().a(), test1.as_ref().b());
    println!("a: {}, b: {}",test2.as_ref().a(), test2.as_ref().b());
}
```

Some functions require the futures they work with to be `Unpin`. To use a
`Future` or `Stream` that isn't `Unpin` with a function that requires
`Unpin` types, you'll first have to pin the value using either
`Box::pin` (to create a `Pin<Box<T>>`) or the `pin_utils::pin_mut!` macro
(to create a `Pin<&mut T>`). `Pin<Box<Fut>>` and `Pin<&mut Fut>` can both be
used as futures, and both implement `Unpin`.

For example:

```rust,edition2018,ignore
use pin_utils::pin_mut; // `pin_utils` is a handy crate available on crates.io

// A function which takes a `Future` that implements `Unpin`.
fn execute_unpin_future(x: impl Future<Output = ()> + Unpin) { /* ... */ }

let fut = async { /* ... */ };
execute_unpin_future(fut); // Error: `fut` does not implement `Unpin` trait

// Pinning with `Box`:
let fut = async { /* ... */ };
let fut = Box::pin(fut);
execute_unpin_future(fut); // OK

// Pinning with `pin_mut!`:
let fut = async { /* ... */ };
pin_mut!(fut);
execute_unpin_future(fut); // OK
```

## Summary

1. If `T: Unpin` (which is the default), then `Pin<'a, T>` is entirely
equivalent to `&'a mut T`. in other words: `Unpin` means it's OK for this type
to be moved even when pinned, so `Pin` will have no effect on such a type.

2. Getting a `&mut T` to a pinned T requires unsafe if `T: !Unpin`.

3. Most standard library types implement `Unpin`. The same goes for most
"normal" types you encounter in Rust. A `Future` generated by async/await is an exception to this rule.

4. You can add a `!Unpin` bound on a type on nightly with a feature flag, or
by adding `std::marker::PhantomPinned` to your type on stable.

5. You can either pin data to the stack or to the heap.

6. Pinning a `!Unpin` object to the stack requires `unsafe`

7. Pinning a `!Unpin` object to the heap does not require `unsafe`. There is a shortcut for doing this using `Box::pin`.

8. For pinned data where `T: !Unpin` you have to maintain the invariant that its memory will not
get invalidated or repurposed _from the moment it gets pinned until when drop_ is called. This is
an important part of the _pin contract_.

["Executing `Future`s and Tasks"]: ../02_execution/01_chapter.md
[the `Future` trait]: ../02_execution/02_future.md
[pin_utils]: https://docs.rs/pin-utils/

repository: rust-lang/async-book

gha_language: Shell

repo_name: rust-lang/async-book


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).

## [10.0.0] - 2020-01-10
### Breaking
- Remove support for the ENABLE_LAMBDA_LOGGING environment variable. Instead you can set DEBUG=lambda-tools:lambda

## [8.0.0] - 2019-06-07
### Breaking
- Upgraded ava to 2.0
- Drop support for node 6

## [7.2.0] - 2019-02-27
### New
- A new `-t` options for the webpack build CLI that allows providing a
  `tsconfig.json` file for TypeScript compilation

## [7.1.0] - 2019-02-27
### New
- A new `mountpointParent` option on `useNewContainer` to was added to control
  where `zipfile` arguments are unzippped. This new option can be used when
  trying to align paths both inside and outside docker which is needed when
  using `zipfile` from inside a compose environment.

## [7.0.0] - 2019-02-26
### New
- A new `zipfile` option on `useNewContainer` to build containers straight from
  zip files. Testing from zip files can help validate final packaging.

### Breaking
- Dependent projects will need to make sure that MockServer 5.5 is used in
  docker-compose environments and npm dependencies
- Dependnet projects need to upgrade to Ava 1.x

repository: jagoda/lambda-tools

repo_name: jagoda/lambda-tools


text:
# Dynamic Form Registration

## Demo

[DEMO LINK](https://dynamic-form-registration.vercel.app/)

## Description

React.js Dynamic multi-page application form

- Check `src/common/form-schema.ts` to define form fields
- _Note:_ select type option still not defined yet, only `"text" , "email", "number", "radio"`

## Screenshot

![List](./assets/dynamic-form-builder.gif)

## Prerequisites

[npm](https://www.npmjs.com/get-npm) or [yarn](https://yarnpkg.com/en/docs/install) installed
[Vercel](https://vercel.com) installed is optional, it's only for deployment

## Getting Started

1. Clone the repository
   `git clone git@github.com:AlaeddineMessadi/dynamic-form-registration.git`

2. Run `yarn` or `npm install`

## Run the project locally

1. run `yarn start`

## Testing

To run the test on the browser use

- `yarn cypress:open`

To run the test on terminal

- Run `yarn cypress:run`

## Deploy

Run `yarn deploy` OR `yarn deploy:prod` for production

### Notes

> #### TODO
>
> - more tests.
> - Style enhancements.

## Contribution
All PR's are welcome :)

## Built With

- [React.js](https://reactjs.org/) - JavaScript library for building user interfaces
- [Redux](https://redux.js.org/) - State Management
- [Cypress](https://www.cypress.io/) - End to End testing Framework
- [typescript](https://www.typescriptlang.org/) - Typescript
- [vercel](https://vercel.com/) - Deployment server
- [Yarn](https://yarnpkg.com/) - Dependency Management
- [React Router](https://reactrouter.com/) - Declarative ROuting for Reactjs
- [Formik](https://formik.org/) - Formik
- [Create-React-App](https://reactjs.org/docs/create-a-new-react-app.html) - Boilerplate

## License

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

gha_language: TypeScript


text:
## CLI

The package can be used from the CLI.

```sh
package-rank PACKAGE_NAME -s SEARCH_QUERY
```

For example, to find out how the [_Documentary_](https://github.com/artdecocode/documentary) package ranks for the `documentation` keyword, the following command is used:

```sh
package-rank documentary -s documentation
```

%FORK package-rank documentary -s documentation%

### `--help`, `-h`

%FORK package-rank -h%

%~%

repository: artdecocode/package-rank

repo_name: artdecocode/package-rank


text:
# tachistoscope

Perform tests showing different words for short period of time. Tests are defined in tests.js file. You can set a list of words, a delay between mouse click and word presentation and presentation time in milliseconds.

repository: nikolaynag/tachistoscope

repo_name: nikolaynag/tachistoscope


text:
# brew tap
The `brew tap` command is powerful, but has a few subtleties worth describing.

**tl;dr** `brew tap` allows you to add more Github repos to the list of formulae that `brew` tracks, updates and installs from. When naming tap repos and formulas, however, there are a few gotchas to beware of.

## The command

*   If you run `brew tap` with no arguments, it will list the currently
    tapped repositories. Example:

```bash
$ brew tap
homebrew/dupes
telemachus/desc
telemachus/vim
```

*   If you run `brew tap` with a single argument, `brew` will attempt to
    parse the argument into a valid 'username/repo' combination. If the argument is a valid name, then `brew tap` will attempt to clone the repository and symlink all its formulae. (See below for what it means to be a 'valid name'.) After that, `brew` will be able to work on those formulae as if there were in Homebrew's canonical repository. You can install and uninstall them with `brew [un]install`, and the formulae are automatically updated when you run `brew update`. (See below for a few exceptions on names and installation.)

*   You can remove a tapped repository using the `brew untap` command.

## Naming conventions and limitations

`brew tap username/repo` employs some shortcuts and has some limitations.

*   On Github, your repository must be named `homebrew-something`.
    The prefix 'homebrew-' is not optional.

*   When you use `brew tap` on the command line, you can leave out the
    'homebrew-' prefix in commands.

    That is, `brew tap username/foobar` can be used as a shortcut for the long version: `brew tap username/homebrew-foobar`. The command will automatically add back the 'homebrew-' prefix.

## Formula duplicate names
If your tap contains a formula that is also present in master, that's fine, but it means that you must install it explicitly.

For example, you can create a tap for an alternative `vim` formula, but in that case when you install from there you must run the command with a more explicit installation target:

```bash
brew install vim                 # installs from Homebrew/homebrew
brew install username/repo/vim   # installs from your custom repo
```

repository: snarfed/homebrew

gha_license_id: NOASSERTION

repo_name: snarfed/homebrew


text:
# Get all Google Fonts

A Python script/CLI that downloads all the fonts from Google Fonts using the API. You will need to provide an API key, get one [here](https://developers.google.com/fonts/docs/developer_api). The script is borrowing a lot from [this FontBakery script](https://github.com/googlefonts/fontbakery/blob/master/fontbakery-metadata-vs-api.py).

Usage:

In Terminal, in the folder with the script you can do, for example:

`python get_all_google_fonts.py --apikey <your API key>` downloads all fonts to a subfolder of the current folder. Takes a few minutes (currently it is about 320 MB of fonts)

`python get_all_google_fonts.py --apikey <your API key> --subsets latin,gujarati` downloads only fonts that include `latin` and `gujarati` subsets. See the API docs for more subset options.

`python get_all_google_fonts.py --apikey <your API key> --out Darkfold` downloads all fonts to a folder `Darkhold`.

For other options, see the script’s own help.

Alternatively, if you did not need the most recent fonts, you could download [this archive](https://github.com/google/fonts/archive/master.zip). Note, however, that as of 3 March 2017, it has not been updated for a while and some nice new families are missing.

## Feedback

These scripts are provided as is. Feel free to submit an issue, but we might not have the time to fix it.

repository: rosettatype/random-scripts

repo_name: rosettatype/random-scripts


text:
https://github.com/CalculatedContent/WeightWatcher

Weight Watcher analyzes the Fat Tails in the weight matrices of Deep Neural Networks (DNNs).

well trained neural networks weights are not random (of course).
The weights are correlated.
By analyzing the eigenvalue distributions of weight matrices, there are things you can say about how well the model generalizes.

https://openreview.net/forum?id=SJeFNoRcFQ

Charles H. Martin, Michael W. Mahoney
Traditional and Heavy Tailed Self Regularization in Neural Network Models

repository: sanjosh/csdocs

repo_name: sanjosh/csdocs


text:
---
title: Check Heater Relay Overheating
date: Last Modified
tags:
  - electrical
  - overheating
  - "heater relay"
problemCode:
resolutionCode: 303
nextStepURL: "/heating/check-tank-element-overheating/"
---
## Possible Cause

- Heater Relay.

## What to Check - Field

- Contact points are fused together. (unseen from exterior)

## Action Needed - Field

1) Disconnect power, remove red & black wires from relay. Reconnect power. Volt meter should NOT read 9-12VDC. If it does the main control board needs to be changed. If there is not a reading of 9-12VDC replace the heating relay.

## Caution

repository: ecrosstexas/teazzers-spacebook

branch_name: refs/heads/main

repo_name: ecrosstexas/teazzers-spacebook


text:
## 452 Minimum Number of Arrows to Burst Balloons

#### Description

[link](https://leetcode.com/problems/minimum-number-of-arrows-to-burst-balloons/)

---

#### Solution

传统滑动窗口可以解决问题，看代码

---

#### Code

O(nlogn)

```python
class Solution:
    def findMinArrowShots(self, points: List[List[int]]) -> int:
        points.sort()
        low = 0
        high = 0
        count = 0
        if (points):
            low = points[0][0]
            high = points[0][1]
        else:
            return 0
        for point in points:
            if (point[0] > high):
                count += 1
                low = point[0]
                high = point[1]

            elif (point[1] < high and point[0] > low):
                high = point[1]
        return count+1
```

repository: ProHiryu/leetcode

repo_name: ProHiryu/leetcode


text:
python--setuptools
==================

Parent: [build-locally](../../README.md)

Builds the setuptools package into the locally built Python installation. See [setuptools home page](https://pypi.python.org/pypi/setuptools)

repository: bgoodr/build-locally

repo_name: bgoodr/build-locally


text:
---
title: Nearly Nine Chosen as First Mash Stories Winner
tags:
    - post
    - nearly-nine
    - digital
    - win
    - mash-stories
---
"Nearly Nine" is a short story I wrote for a contest on MashStories.com. I was fortunate enough to get short listed, and I was even more fortunate to win.

A big thank you, and much credit, has to go to the people who shared, commented, and voted on my story. The feedback was encouraging, and it was fun to hear people's reactions. The win is encouraging for my future creative writing endeavors.

If you're interested, you can read "Nearly Nine" on MashStories.com. Second place went to "Lost Balls" by Ross Baxter, and third place was awarded to Carrie Guss for "Tina, Trapped and Released". Excellent stories, all.

Now, if you'll excuse me, I have to buy $100 worth of hipster writing glasses and typewriters. I've arrived, baby.

gha_language: HTML


text:
# Trusted Web Activity navigations must succeed or be handled by the ServiceWorker. Your app may crash in the future.

Dead link (404) or 5xx status code encountered when navigating within the verified origin.

In order to provide a seamless experience on par with Android apps, it is important for navigations within the verified origin in a Trusted Web Activity not result in broken links or internal errors.

⚠ In the future, your app may crash if the user navigates to a page and gets a 404 or 50x error. Ensure that all links on your origin are correct, or use a service worker to handle these errors gracefully.

Please make sure your app doesn’t have 404 or 5xx errors, or use a service worker fetch event fallback response to handle the errors.

repository: DOSYCORPS/devtools-frontend

repo_name: DOSYCORPS/devtools-frontend


text:
---
title: FAQs
menu:
  main:
    weight: 80

draft: false
---

## General

### What is the DevFest?
The DevFests are major community events throughout the world, following the tradition of Google Developer Days and organized by local user groups. They constitute a unique opportunity to share and network around the World of Web and cloud technologies! This event will be followed by an after-event party to discuss and network!

### Who is organizing this event?
The DevFest Nantes in 2019 is organized by GDG Nantes. More information on the [team](../team/) page.

### How to become a sponsor or partner?
Simply by visiting our partnership proposition, or by contacting us by mail at <a<EMAIL_ADDRESS>of GDG Nantes.

## Conference

### When and Where is the event?
The conference takes place on 21th and 22th October 2019 at the Cité des Congrès in Nantes.

### Where can I leave my luggage?
Although the event is over several days, we do not allow participants to leave their luggage at the event. Cloakroom service is available free during the 2 days to deposit backpacks and jackets.

### How to get there?
All information relating to the arrival in DevFest is available on the [attending](../attending/) page.

### Is there discounted tickets?
The discounted rate is applicable only in the following categories:

 - Students
 - Teachers
 - In-between jobs
 - Unemployed

In all cases, access to the discounted rate will be available only on providing justification proof. Without justification proof, the participant can not to attend the event. No refund will be provided.

### How will the DevFest be organised?
This 2-days event will include three types of sessions: Conferences (50 minutes), Quickies events (20 minutes) and Codelabs (2 hours).

Conferences and Quickies talks will be presentations by renowned speakers or Googlers evoking their favorite technologies.

The Codelabs are more informal and will be an opportunity to put your hands (and feet) to work on code in the company of a technology expert in the field.

### What are the topics?
This year you will find topics around the : Web, Mobile, IoT, Backend, Cloud, Big Data, Machine Learning, DevOps, Discovery ...

### How to register and how much does it cost?
Registration for DevFest Nantes can be done directly from this site by clicking the link on the home page. Admission is € 78 for the 2-day pass until June 30th 2019 then € 99 past this date, and € 20 for the discounted rate.

### If I register and am not able to attend, can I get a refund?
Our entire ticketing is handled by a service provider, so you can cancel your tickets under the conditions defined by this one. After the date of the event, no refund will be made.

### I have registered but am unable to attend, can I give it to a friend?
We can accept registration transfers. If you are aware of the change two weeks before the event, you can make the modification directly by clicking on the link "manage my order" at the bottom of your order confirmation email. If you are unable to inform us 2 weeks prior to the event (and are unable to make it), your "friend" must show up with your ticket and he/she will wear the badge registered in your name.

### Are presentations recorded?
All sessions except Codelabs will be recorded and made available on the Youtube channel GDG France

### Are talks in English or French?
The sessions can be both in English and in French, depending on the speakers chosen. As many speakers are from abroad, some sessions will be in English. These sessions will be indicated with a special icon.

### How many presentations are held at the same time?
There will be all day 6 parallel sessions (one session per subject and 2 codelab)

### About the image rights?
When participating in DevFest Nantes as a speaker or attendee, you agree to be recorded and photographed and potentially livestreamed.

You agree to use only royalty-free content or for which you have purchased the necessary licenses (images, music).

You agree that your presentation may be freely broadcast on Youtube.

### I have registered but am unable to attend, can I give it to a friend?
Yes it's possible, for that you must make the change yourself on your command management interface. It is accessible on the link "Manage my order" at the bottom of the purchase confirmation email.

### I am organizing a User Group, how can I help you?
As a User Group, you can help us in several aspects:

 - By helping us find speakers
 - By broadcasting the event on your network. To facilitate this, we have several elements in the press section for distributing posters and banners at your disposal.

## CFP: Call for Paper

### How long does the CFP?
The Registration will open on May 1st 2019 and will close on June 30th 2019 at 23:59

### My presentation has been accepted, do I still need to buy an Entry ticket/ pass for the conference?
Each speaker/ team of speakers is given a Free pass. It is therefore not necessary to buy a ticket. (Whether you are alone or several to present).

### My presentation has not been accepted as yet, should I buy my Pass, just in case?
We will contact all presenters and we will propose more presentation slots if necessary to faclitate registration.

### As a speaker, am I free to use what I want?
You agree to use only copyright-free content or for which you have made the necessary licenses purchases (images, music).

## Other

### Other questions?
Contact us by mail to the address <a href="mailto:bureau<EMAIL_ADDRESS>

branch_name: refs/heads/nantes

gha_language: JavaScript


text:
Gareth Vagrant
==============
**Gareth Vagrant** provides a Vagrant based development environment for the [Gareth][] code review system.

All of Gareth's dependencies reside in a VM letting you get quickly setup with the STOMP Server, Database server, gevent, gunicorn server, and other dependencies Gareth needs without needing to install and configure them on your host computer.

## Prerequisites
You'll need to install [Vagrant][] and [VirtualBox][] (>= 4.1).

**IMPORTANT**: You must enable hardware virtualization (VT-x or AMD-V).  This is often a BIOS setting. If you don't do that, you'll probably get an error in the last step of the installation, 'vagrant up'. You can verify this by trying to launch the VM from the VirtualBox GUI. If an error message appears that says something about "VT-X", you need to reboot the host machine and enable the BIOS setting that allows hardware virtualization.

## Installation
```bash
git clone https://github.com/dantman/gareth-vagrant.git
cd ./gareth-vagrant
vagrant up
```

It'll take some time, because it'll need to fetch the base precise64 box if you don't already have it. Once it's done, you should be able to browse to [http://localhost:8080/](http://localhost:8080/) and see a Gareth install, served by the guest VM, which is running Ubuntu Precise 64-bit.

The Gareth credentials are:

* Username: admin
* Password: vagrant

The MySQL root credentials are:

* Username: root
* Password: vagrant

To SSH into your VM, simply type `vagrant ssh`.

## Commands within the vm
`mysql` can be used to interact directly with the database without needing any extra args.

If you `cd /var/lib/gareth/core` Gareth's `./manage.py` commands will be available.

`sudo supervisorctl` will let you interact with supervisord afnd allow you to start, stop, restart, and tail the Apollo STOMP server, Gunicorn webserver running Gareth, and Gareth's taskrunner.

`sass` is also available so from within `/var/lib/gareth/core` you can run `sass --watch garethweb/public --poll` to begin polling for .scss changes.

## License
The Gareth Vagrant repo is licensed under the [MIT License][], please see the `LICENSE` file.

This repo contains a few files that come from other codebases made by other developers. Currently these files are all also MIT licensed but the copyright is owned by others. The copyright owner and license for these will be noted inside of the individual file.

Please also remember that the Gareth repository automatically cloned when running `vagrant up` is under completely different license terms.

  [Gareth]: http://gareth-review.com
  [Vagrant]: http://vagrantup.com/v1/docs/getting-started/index.html
  [VirtualBox]: https://www.virtualbox.org/wiki/Downloads
  [MIT License]: http://opensource.org/licenses/MIT

repository: dantman/gareth-vagrant

repo_name: dantman/gareth-vagrant


text:
crysh shell

> A Linux shell written in Crystal.

## Installation

Crysh needs to be built from source for now. To do that, you must install [Crystal](https://crystal-lang.org/).

1. Clone this repo: `git clone https://github.com/Sevensidedmarble/crysh.git && cd crysh`

2. Install dependencies: run: `shards install` (`shards` might be a seperate package in your package manager. Make sure you have it. You could try `crystal deps install` as well.)

3. Build: `crystal build src/crysh.cr --release`.

4. You can run crysh right from this directory with `./crysh`

5. You can now symlink to your bin folder (make sure /usr/local/bin is on your path, or use /usr/bin):

* In bash/zsh: `sudo ln -sf $(pwd)/crysh /usr/local/bin/crysh`

* In fish: `sudo ln -sf (pwd)/crysh /usr/local/bin/crysh`

## Usage

Follow the instructions above. Crysh can be used like any other unix shell. It does not aim to be 100% POSIX complete, but it should be as POSIX complete as fish when 1.0 is released.

## Development

I've collected some very helpful resources about programming shells in the wiki, [available here.](https://github.com/Sevensidedmarble/crysh/wiki/Important-Links-for-Making-Shells)

## Contributing

1. Fork it ( https://github.com/Sevensidedmarble/crysh/fork )
2. Open a PR
3. Profit


text:
# To be or what to be, that is the question
This is a solution to the [problem](https://www.hackerrank.com/challenges/to-be-what/problem) listed on HackerRank.

This solution uses encoder decoder LSTM neural networks implemented using IBM's pytorch implemation for [seq2seq](https://github.com/IBM/pytorch-seq2seq).

Main libraries used:
* [pytorch-seq2seq](https://github.com/IBM/pytorch-seq2seq) for encoder decoder LSTM implementation
* [torchtext](https://github.com/pytorch/text) for data loading, batching and vocabulary labeling
* [pytorch](https://github.com/pytorch/pytorch) for tensor computation with GPU acceleration and deep neural network.
* [nltk](https://www.nltk.org) for training data pre-processing.

##  Using beOrNotToBe-predictor.py to predict the correct form of verb "be" in a given text

1. Add your text inside text-to-predict.txt or specify the path to your own text when running beOrNotToBe-predictor.py.
2. Run beOrNotToBe-predictor.py
    * Use --text-path your/path/here (to override the default path: ./text-to-predict.txt)

The input text has contain two lines. The first line will contain only one integer N, which will equal the number of blanks in the text. The second line contains one paragraph of text. Several occurrences of the words mentioned previously have been blanked out and replaced by four consecutive hyphens (----). These are the blanks which you need to fill up with one of the following words: 'am','are','were','was','is','been','being','be'

##  Using beOrNotToBe-preprocessor.py to pre-process your data for training

1. Add your text files to the directory path ./ToBeOrWhatToBe/dataset/original_data (one or many files containing text)
2. Run beOrNotToBe-preprocessor.py
    * Output will be generated in the following directory path ./ToBeOrWhatToBe/dataset/pre_processed_data.

##  Using beOrNotToBe-trainer.py to train the model
1. Make sure you your pre-process your training data using beOrNotToBe-preprocessor.py first.
2. Run beOrNotToBe-trainer.py
    * Add argument --resume to resume from last the checkpoint should the training get interrupted.
    * Add argument --load_checkpoint 2018_09_08_18_34_58 to reach a prompt that will allow you to input text and get a prediction
       from the trained model loaded from the specified checkpoint.


text:
# grunt-documentation

[![Circle CI](https://circleci.com/gh/documentationjs/grunt-documentation/tree/master.svg?style=shield)](https://circleci.com/gh/documentationjs/grunt-documentation/tree/master)
[![Greenkeeper badge](https://badges.greenkeeper.io/documentationjs/grunt-documentation.svg)](https://greenkeeper.io/)

Use [Grunt](http://gruntjs.com/) with
[documentation](https://github.com/documentationjs/documentation)
to generate great documentation for your JavaScript projects.

## Getting Started
This plugin requires Grunt `>=0.4.0`

If you haven't used [Grunt](http://gruntjs.com/) before, be sure to check out the [Getting Started](http://gruntjs.com/getting-started) guide, as it explains how to create a [Gruntfile](http://gruntjs.com/sample-gruntfile) as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

```shell
npm install grunt-documentation --save-dev
```

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

```js
grunt.loadNpmTasks('grunt-documentation');
```

## The "documentation" task

### Overview
In your project's Gruntfile, add a section named `documentation` to the data object passed into `grunt.initConfig()`.

```js
grunt.initConfig({
    documentation: {
        default: {
            files: [{
                "expand": true,
                "cwd": "src",
                "src": ["**/*.js"]
            }],
            options: {
                destination: "docs"
            }
        },
    }
});
```

### Options

#### options.destination
Type: `String`

The destination folder for the generated docs.

#### options.format
Type: `String`
Default value: `'html'`

Either `'html'`, `'md'`, `'json'`, or `'docset'`.

#### options.filename
Type: `String`

Custom filename for md or json output.

#### options.access
Type: `Array`
Default value: `['protected', 'public', 'undefined']`

Include only comments with a given access level, out of `private`, `protected`, `public` and `undefined`. By default, `public`, `protected` and `undefined` access levels are included.

#### options.order
Type: `Array`
Default value: `[]`

An array defining explicit sort order.

#### options.theme
Type: `String`

Path to a custom theme.

#### options.name
Type: `String`

A custom project name to display in the generated documentation.

#### options.version
Type: `String`

A custom version string to display in the generated documentation.

## Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint your code using [Grunt](http://gruntjs.com/).

## Release History

**v1.2.0**
* new options: theme, name and version
* now compatible with both 3.x and 4.x version of documentation
* new theming demo

**v1.1.2**
* always use latest NPM packages

**v1.1.1**
* support Grunt 1.0

**v1.1.0**
* new feature: `access` option to only include comments with a given access level, out of `private`, `protected`, `public` and `undefined`
* new feature: `order` option to include user-defined sorting

**v1.0.1**
* store `md` format at right destination; fixes [issue #3](https://github.com/documentationjs/grunt-documentation/issues/3)

**v1.0.0**
* Transfered to documentationjs

repository: captbaritone/grunt-documentation

repo_name: captbaritone/grunt-documentation


text:
liferay-push-windowsphone
======================

Service for Liferay SDK Windows Phone for Push Notifications. It's an extension for [Ithildir](https://github.com/Ithildir/liferay-sdk-builder-windows) and [Bruno Farache IOS Service] (https://github.com/brunofarache/liferay-push-ios)

If you find any bug, please create a Issue.

## Installation
```
Copy the folder Notification and paste in Liferay Services project or folder.
```

### Methods

- AddPushNotificationsDeviceAsync(string token, string platform)
- DeletePushNotificationsDeviceAsync(string token)
- SendPushNotificationWithToUserIdsAsync(IEnumerable<int> toUserIds, string payload)
- SendPushNotificationWithPlatformAsync(string platform, IEnumerable<string> tokens, string payload)

##More info:

For more information read [Bruno Farache IOS Service] (https://github.com/brunofarache/liferay-push-ios)

repository: salvatejero/liferay-push-windowsphone

repo_name: salvatejero/liferay-push-windowsphone


text:
# Task to complete 20/04

<input type="checkbox" checked>Insert new traces on the backend</input>

<input type="checkbox" checked>Do some tests on new traces and test Giulio's constraints
</input>

<input type="checkbox" checked>Write down what's wrong with the new tests</input>

<input type="checkbox">Create a new interface, to navigate trough traces: </input>

<input type="checkbox">Create a class Result, in which rule synthetized, anomalies, and plots dataset are saved. </input>

<input type="checkbox">After the rule has been sent, create and display the blox which navigates trough the results</input>

repository: gbagolin/explainable-ai-gatsby-version

repo_name: gbagolin/explainable-ai-gatsby-version


text:
---
title: Privacy Enhancements
description: Privacy Enhancements feature prevents nodes from modifying contracts they are not party with.
---

# Privacy Enhancements

From GoQuorum v20.10.0, two privacy enhancements are included to prevent state divergence:

* Counter party protection
* Private state validation

## Counter party protection

Counter party protection prevents non-participants sending a transaction to a
private contract. For example, a private contract is deployed between node 1 and 2. Without counter
party protection, if node 3 discovers the private contract address, node 3 can send a transaction with
`privateFor` set to node 2. The transaction is not applied on node 3 because it is not a participant
in the private transaction. The transaction submitted by non-participating node 3 is applied to the
private state on node 2.

Use the counter party protection instead of access controls on private contract implementations to protect
against other network participants from updating the state. Counter party protection prevents non-participants
from interacting with the private contract without additional access controls.

## Private state validation

Private state validation prevents state divergence by ensuring that any private transaction
for the contract is always sent to all participants. For example, a private contract is deployed between node 1 and 2.
Without private state validation, node 1 can send a transaction to the private contract with a `privateFor`
of `[]`. The transaction changes the private state of node 1 but not node 2 and the private states of
1 and 2 no longer match. With private state validation, a transaction from node 1 with a `privateFor`
of `[]` is rejected and the transaction is processed only when `privateFor` contains both 1 and 2

When using private state validation, the full participant list is shared among all participants and
validated against all subsequent transactions. Transactions sent to a subset of participants fail.

In standard privacy or when only using counter party protection, only the sending node knows
the full participant list.

## Affected Contract Original Transaction Payload Hash

Counter party protection and private state validation are implemented using the Affected Contract
Original Transaction Payload Hash (`ACOTH`). To transact with a private contract, a node must prove
it has access (that is, it has the encrypted payload and the ability to decrypt it) to the originating
transaction for the contract.

## Key Enhancements

### Privacy Flag

A new parameter `PrivacyFlag` has been added to all GoQuorum
[`send` API methods](../../Reference/API-Methods.md#privacy-methods), being passed from the client to enable the privacy
enhancements feature.
This flag is an unsigned integer set to 1 for PP and 3 for PSV transactions.
If the flag is missing or zero, the transaction is assumed to be a "non-privacy enhanced" SP transaction.

### Privacy Metadata and Privacy Metadata Trie

Privacy Metadata is a new structure introduced in GoQuorum. It is stored in the GoQuorum DB in the privacy
metadata trie (which is linked to the private state via root hash mappings). The Privacy Metadata contains
the ACOTH and privacyFlag.

Privacy Metadata Trie is a parallel trie that stores the privacy metadata (and whatever extra data we
may need) for the private contracts and is linked to the private state by root hash mappings. The records
in the trie are keyed by the contract address (similarly to how the contract/accounts data is stored
in the state trie).

Each contract(account) that is created as the result of a PP or PSV transaction would have such a structure
attached to the privacy metadata trie as it is essential in performing checks on future transactions
affecting those contracts.

### Transaction simulation

In order to discover what ACOTH(s) to attach to a transaction the GoQuorum node simulates the execution
of the proposed transaction. The result of the simulation relies on the current state of the chain.
The Ethereum VM has been enhanced to track the contracts involved in the simulated transaction.
At the end of the simulation the EVM can report all the created/invoked contract addresses.
Coupled with the privacy metadata described above it is easy to translate contract addresses to ACOTHs
and attach them to the proposed transaction.

#### Limitations

Depending on the complexity of the contracts and the throughput of the network it may happen that the
state at simulation time may differ from the chain state at the time the proposed transaction is minted.
If the state at minting time is sufficiently altered to determine different contract interactions the
corresponding PP/PSV transactions would be marked as failed on all the participants.
Furthermore, since state divergence is expected in PP contracts, it is possible (depending on contract design)
for PP transactions to fail on some of the participants.

Concurrency may also present a problem for PSV contracts. The execution hash calculation is based on
the chain state at simulation time. Submitting multiple transactions to the same PSV contract from multiple
nodes concurrently is likely to result in most of the transactions failing.

Considering the above we expect users to choose PP and PSV contracts/transactions **only** when th
enhanced privacy is necessary (and the extra privacy benefits outweigh the potential shortfalls).

### Contract/Transaction interactions

No interactions are allowed between the different types of private contracts/transactions. The only type
of allowed interaction is for private contracts (SP/PP/PSV) to read from public contracts.

![Contract interaction matrix](../../images/PrivacyEnhancements_Contract_Interaction_Matrix.png)

The privacy enhancements feature only performs it’s checks on submitted/minted transactions.
None of the above limitations apply to calls (read only transactions). In this context calls are contract
method invocations that are executed locally and do not result in minted transactions.

## Configuration Changes

### GoQuorum

`genesis.json` file has been modified to include `privacyEnhancementsBlock`. The values for this should
be set to an appropriate value in the future (and should be initialised with same value across all the nodes
in the network) by when the entire network would be ready to transact with privacy enhanced contracts/transactions.

### Tessera

New flag `enablePrivacyEnhancements` has been added to Tessera config defaulting to `FALSE`, and can
be enabled by adding the property to the config file the same way as other features.
Refer sample configuration for further details.

## Enabling Privacy Enhancements in the GoQuorum Network

For any given node the privacy manager (Tessera) is started first and for that reason we allow the Tessera
node to be upgraded with privacy enhancements support ahead of GoQuorum upgrade. But when GoQuorum node
is upgraded and `geth` is reinitialized with `privacyEnhancementsBlock`, GoQuorum node will validate the
version of Tessera running and will fail to start if Tessera is not running an upgraded version. The
GoQuorum node reports an appropriate error message in the console suggesting users to upgrade Tessera first.

If a node wants to upgrade it's Tessera to privacy enhancements release (or further) to avail other
features and fixes but not ready to upgrade GoQuorum, it can do so by not enabling `enablePrivacyEnhancements`
in Tessera config. This will allow the node to reject PP and PSV transactions from other nodes until
the node is ready to support privacy enhanced contracts/transactions.

## Backward compatability

### GoQuorum

An upgraded GoQuorum node can coexist on a network where other nodes are running on lower version of
GoQuorum and thus supports node by node upgrade. But it cannot support privacy enhanced contracts until
all interested nodes are upgraded and privacy is enabled.
If an upgraded but privacy not "enabled" node receives a PSV or PP transaction the node would log a
`BAD BLOCK` error with “Privacy enhanced transaction received while privacy enhancements are disabled.
Please check your node configuration.” error message. If the consensus algorithm is Raft, the node would stop.
For Istanbul, the node would keep trying to append the problematic block and reprint the above errors and
it won't catch up with rest of nodes until restarted and reinitialized with the correct `privacyEnhancementsBlock`.

### Tessera

On any given node, Tessera can be upgraded to privacy enhanced release at anytime.
Take care when you enable `enablePrivacyEnhancements` flag in Tessera config as it will accept PSV and
PP transactions and can cause the node to crash if GoQuorum node is not privacy enabled.
The upgraded node can continue to communicate on Tessera nodes running on previous versions using SP transactions.
API versioning <!-- TODO: add hyperlink later --> (that will be introduced along with privacy enhancements)
enables the upgraded node to determine if the receiving node supports privacy enhancements and fail the transaction if not.

## Tessera P2P communication changes

Refer [here](PrivateTransactionLifecycle.md) to refresh about Tessera P2P communication.

### Party Protection changes

To prevent a non-party node from interacting with PP contracts new transactions must be submitted with
`ACOTHs` and `PrivacyFlag` from GoQuorum to Tessera. The Tessera node would then generate proofs
(a hash using new transaction ciphertext, original transaction ciphertext and original transaction master key)
for each ACOTH and include a) `PrivacyFlag`, b) ACOTHs and c) ACOTH proofs (secure hashes) in the transaction
payload shared between Tessera nodes.

### Private State Validation changes

Besides the ACOTH, a PSV transaction has an execution hash (Merkle root) calculated from all the affected
contract(s) resulting from the transaction simulation (at the time of submission) included from GoQuorum
to Tessera. The d) execution hash and e) list of participants are also shared between Tessera nodes.

## Privacy Enhanced Transaction End to End Flow

Refer [to the private transaction livecycle](PrivateTransactionLifecycle.md) documentation for end to end flow of SP transaction.

![Privacy enhanced transaction end to end flow](../../images/PrivacyEnhancements.png)

In this example we walk through the flow of a private transaction on a "privacy enhanced contract" between Nodes A & B.

1. User pushing a private transaction from Node A private for Node B

    * The transaction payload will include the `PrivacyFlag` with value `1` for PP and `3` for PSV contract

1. Node A GoQuorum reading the `PrivacyFlag` runs an EVM transaction simulation to gather all the affected
contracts and the ACOTH(s) associated to contract accounts. For PSV transactions, it also calculates
an execution hash (Merkle root) from all the affected contracts resulting from the transaction simulation.

1. Node A GoQuorum pushes the transaction payload, `PrivacyFlag`, ACOTHs (& the Merkle root for PSV) to Node A Tessera.

1. Node A Tessera generates proofs (secure hashes) for the ACOTHs and use them to validate that the
originating party has access to all relevant transactions.
In addition for PSV it would also verify the participants list against the list in each of the ACOTH
transactions (as in PSV transactions the recipient list is shared across all nodes party to the transaction).
If the list doesn't match it will return failure on `/send` to Node A GoQuorum.

1. Node A Tessera pushes to Node B Tessera the encrypted payload, ACOTH <-> proofs (secure hash) mappings
(for PSV transaction it will also push the `privateFor` list and Merkle root).

1. Node B Tessera computes and compares proofs (secure hash) from Node A Tessera (for PSV it also verifies
participants list of ACOTHs against the `privateFor` list).

1. Node B Tessera returns a SUCCESS response to Node A Tessera - even if the compute and compare mismatched
(in order to prevent Node A finding out the recipient list of a contract/transaction) but it will not
store the payload/ACOTH <--> Securehash mapping based on the outcome.

1. Node A Tessera returns the hash for the encrypted transaction payload to Node A GoQuorum

1. Node A mines the transaction across the network.

1. Node A & Node B being party to the contract will `/receive` decrypted payload, ACOTHs (for PSV also
Merkle root) from the respective Tessera Nodes.

1. Both Nodes execute the transaction and compare the ACOTHs (and execution hash for PSV) and update
the transaction receipt accordingly to mark transaction execution completion.

!!! note
    If the EVM simulation impacts more than one contract, all contracts should have the same `PrivacyFlag`,
    otherwise the transaction is rejected.
    All contracts ACOTHs are included in the transmission and the Tessera node will create individual
    proofs (secure hash) for each ACOTH.**

*[PP]: Counter Party Protection
*[PSV]: Private State Validation
*[ACOTH]: Affected Contract's Original Transaction's encrypted payload Hash
*[SP]: Standard Private
*[EVM]: Ethereum Virtual Machine
*[P2P]: Peer to peer