text:
PAML Specifications
--------------------------------------

PAML (Pixel Art Markup Language) is a pseudo-XML compliant form of structured data. The are some variations from traditional XML that are non-breaking allowing PAML to be parsed by modern XML parsers. This means PAML is still subject to some XML rules, such as correctly using the ampersand escape entities, etc. That said, there are some similarities with the INI configuration file format.

## Tags
There are 4 required tags:
- `<paml>`
- `<info>`
- `<defcolor>`
- `<drawpixels>`

The `<paml>` tag is used to enclose the all other tags and their associated information. It delimits when the PAML file starts and when it ends (`</paml>`).

The `<info>` tag is used to define metadata, options and the required information to correctly draw out the pixels later on. The properties are (defined in "INI" style with a `=` between the key and the value):
- `author`: optional, used for name of author, attribution or copyright holder(s) of the artwork.
- `title`: (? to be added)
- `dateofcreation`: optional, a date as to when the artwork was created or copyright years, etc.
- `license`: optional, required if some artwork is copyrighted or trademarked.
- `xpixels`: required, specifies the width (in pixels) of the artwork
- `ypixels`: required, specifies the height (in pixels) of the artwork
- `sizexpixels`: optional, define the width (in pixels) of artwork's pixel, used for scaling, default is 1px
- `sizeypixels`: optional, define the height (in pixels) of artwork's pixel, used for scaling, default is 1px
- `bgcolor`: optional, defines the background color of the image, when each transparent pixel will be replaced with

The `<defcolor>` tag is used to define the symbols and associated colors used in the `<drawpixels>` tag.

The `<drawpixels>` tag ...
a predefined color is ' ' for transparent which is replace by `bgcolor` is specified.

## Comments
PAML allows for line comments using `;`. PAML files are preprocess before being parsed by an xml parser allowing for things like `&` to be used when commenting. That said XML-style comments (`<!-- XML comment -->`) should also be valid but are not explicitly supported.

## Miscellaneous, Whitespace, Encoding
All leading and trailing whitespaces are trimmed. New lines are important, `CR`, `LF`, `CR+LF` should all be explicitly supported. Unless the XML parser allows for a BOM, this is not needed or explicitly supported. Character encoding should be as per XML specifications. It is recommended UTF-8 or ASCII when possible. Other encodings are not recommended.

repository: tajmone/PixelArtMarkupLanguage

repo_name: tajmone/PixelArtMarkupLanguage


text:
##Angular Calculator
You can find working application here:
http://webpage.win/calculator/
or here:
https://javascript-calculator.herokuapp.com/
(*heroku server can sleep after some time of inactivity, so just wait several seconds before it wakes up and web page will be available.*)

![Screenshot](/../screenshots/screenshot.png?raw=true)
![Screenshot](/../screenshots/screenshot2.png?raw=true)

* Looks great in both desktop and mobile devices.
* Looks fine in both portrait and landscape modes.
* You can use hardware keayboard as well as software screen keyboard via mouse or touchscreen of your smartphone.

###Install
You should install [**node.js**](https://nodejs.org/en/) and [**git**](https://git-scm.com/).

If you want to run local http-server install npm dependencies:
```
npm i
```
Then run local http-server:
```
npm start
```
Then type in your browser URL http://<IP_ADDRESS>:8080/

Алгоритм и исходный код для вычисления выражения взят с [habrahabr](https://habrahabr.ru/post/50196/) и переписан мной с C# в javascript.

The MIT License (MIT)

Copyright (c) 2016 Nikolai Adamovich<EMAIL_ADDRESS>

license: MIT

repository: Nikolai-Adamovich/Calculator

branch_name: refs/heads/master

extension: md

gha_language: JavaScript

license_type: permissive

repo_name: Nikolai-Adamovich/Calculator


text:
# Pnums

[![Build Status](https://travis-ci.org/jwmerrill/Pnums.jl.svg?branch=master)](https://travis-ci.org/jwmerrill/Pnums.jl)

Pnums are a prototype Julia implementation of Gustafson's [Unums 2.0 [PDF]](http://www.johngustafson.net/presentations/Unums2.0.pdf).

The "P" in Pnums stands either for "prototype" or "projective," I haven't totally decided yet. There are currently several [limitations and differences](#current-limitations) from the Unums 2.0 proposal, which is part of the reason for the "P" in the name.

See the [tutorial introduction](/example/Tutorial.ipynb) for a tutorial; the remainder of the README is closer to reference documentation.

### Installation

This package isn't registered with METADATA yet, but if you want to try it out, you can manually add it with `Pkg.clone`:

```julia
Pkg.clone("https://github.com/jwmerrill/Pnums.jl")
```

### Unums 2.0 background

Unums are an alternative to floating point numbers that allow representing and computing with entire subsets of the real line at once, instead of doing rounded computations on point values. Unlike floating point arithmetic, they explicitly track bounds on numerical error throughout a computation. In this way, they are similar to other forms of [Interval Arithmetic](https://en.wikipedia.org/wiki/Interval_arithmetic), but there are also some important differences:

1. Explicit representation of open/closed endpoints. This enables proper set operations like complement and intersection.
2. A single "projective" infinite value is included (floating point arithmetic includes separate +∞ and -∞ values). This means that the reciprocal (1/x) of intervals that span 0 can be explicitly represented as single intervals that span infinity.
3. The reciprocal of every exact value is also included as an exact value. This means that division can be easily implemented as multiplication by a reciprocal.
4. A nicer set of "exceptional" numbers: a single ∞, "everything" (the whole real line plus ∞), and "empty" (the empty set). There is no -0, no NaN, and no subnormal numbers.
5. (Not implemented here) Unums 2.0 encourages working with arbitrary subsets of the real line (or R^n), not just contiguous intervals.
6. (Not implemented here) When a variable shows up in multiple parts of a computation, Unums 2.0 encourages (requires?) splitting intervals into pieces (individual Unums), doing computations on the pieces separately, and forming the union of the results at the end. This is a strategy for combatting overly pessimistic bounds that commonly occur in interval arithmetic ([the dependency problem](https://en.wikipedia.org/wiki/Interval_arithmetic#Dependency_problem)).

## Usage:

The basic unit of computation is the Pnum. Each Pnum represents either an exact value, or the open subset between neighboring exact values. Several different precisions are implemented here:

| Type    | Literal  |
|---------|----------|
| `Pnum3` | `pn3"1"` |
| `Pnum4` | `pn4"1"` |
| `Pnum8` | `pn8"1"` |
| `Pnum16`| `pn16"1"`|

This is analogous to the different precisions of integers or floating point numbers, like `Int8`, `Int32`, `Float16`, or `Float64`. The lowest precision Pnum, the 3-bit `Pnum3`, can represent -1, 0, 1, /0, and the open subsets between these values (/0 is Gustafson's notation for projective ∞; the notation means "reciprocal of 0"). `Pnum4` adds ±2 and ±1/2. `Pnum8` has enough exact values for 1/4 of a decimal of precision between 10^-3 and 224. `Pnum16` has 2-3 decimal digits of precision between 10^-9 and 10^9.

Note, the exact values used here don't precisely match Gustafson's proposal (I haven't tried to include simple decimals in the exact values), but it's reasonably easy to create new types using whatever exact values you want.

Open or closed intervals are represented by Pbounds composed of a pair Pnum endpoints (inexact or exact for open or closed endpoints, respectively), plus a flag to indicate whether the bound is empty. Pbounds are parametrized by the Pnum type of their endpoints, with aliases for the existing types:

| Type           | Alias      | Literal       |
|----------------|------------|---------------|
|`Pbound{Pnum3}` | `Pbound3`  | `pb3"(0, 1]"` |
|`Pbound{Pnum4}` | `Pbound4`  | `pb4"(0, 1]"` |
|`Pbound{Pnum8}` | `Pbound8`  | `pb8"(0, 1]"` |
|`Pbound{Pnum16}`| `Pbound16` | `pb16"(0, 1]"`|

Pbounds represent all values on the projective circle between their first and second endpoints, always moving clockwise. The distinction is relevant for bounds that span infinity.

For example, `pb8"(-1, 1)"` represents all reals with magnitude strictly less than 1, but `pb8"(1, -1)"` represents all reals with magnitude strictly larger than 1 (and infinity).

### Construction

Pnums are created by calling the type constructor on other numerical values, or using the `pn*""` string macro literals. The constructor rounds as necessary, but literals must be written exactly and do no rounding.

Similarly, Pbounds can be created by calling the type constructor with one or two other numerical values (which rounds as necessary), or using the `pb*""` string macro literals for exact values.

### Special Pbound values:

| Type           | Example Literal       |
|----------------|-----------------------|
|`/0` (Infinity) | `pb8"/0"`             |
|`everything`    | `pb8"everything"`     |
|`empty`         | `pb8"empty"`          |

### Arithmetic

Arithmetic (`+`, `-`, `*`, `/`) on Pnums produces Pbound outputs. Pbounds are closed under arithmetic.

### Other Implemented functions

* `^` (Integer powers only)
* `exp`
* `sqrt`

### Iteration

* `eachpnum(x::Pbound)`
* `nextpnum(x::AbstractPnum)`
* `prevpnum(x::AbstractPnum)`

You can iterate through all the Pnums contained in a Pbound using eachpnum. For example:

```julia
collect(eachpnum(pb4"[0, /0)"))
# 8-element Array{Pnums.Pnum4,1}:
#        pn4"0"
#  pn4"(0, /2)"
#       pn4"/2"
#  pn4"(/2, 1)"
#        pn4"1"
#   pn4"(1, 2)"
#        pn4"2"
#  pn4"(2, /0)"
```

Given a Pnum, you can find the neighboring Pnums with `nextpnum` (counterclockwise) and `prevpnum` (clockwise). For example:

```julia
nextpnum(pn8"0")  # pn8"(0, /224)"
prevpnum(pn8"/0") # pn8"(224, /0)"
nextpnum(pn8"/0") # pn8"(/0, -224)"

nextpnum(nextpnum(pn4"1")) # pn4"2"
```

The neighbors of exact values are always inexact, and vice versa.

### Combining Pbounds

* `shortestcover(x::Pbound, y::Pbound)`

`shortestcover` returns the smallest Pbound that contains all the Pnums in both of its inputs.

### Root and maximum finding

* `findroots(fn::Function, rng::Pbound)`
* `findmaximum(fn::Function, rng::Pbound)`

Root finding and optimization (1D only) are implemented through `findroots` and `findmaximum`. Both of these are global methods.

`findroots` returns an array of disjoint Pbounds; all the roots of the function within the input range are guaranteed to lie within one of the returned Pbounds (but there is no guarantee of how many roots (if any) each interval actually contains). For example:

```julia
findroots(x->x*(x*x - 1), pb3"everything")
# 3-element Array{Pnums.Pbound{Pnums.Pnum3},1}:
#  pb3"-1"
#   pb3"0"
#   pb3"1"
```

`findmaximum` returns an array of disjoint Pbounds; the global maximum of the function within the input range is guaranteed to lie within one of the returned Pbounds. For example:

```julia
findmaximum(x->-(x-4)^2 + 3, pb8"everything")
# 1-element Array{Pnums.Pbound{Pnums.Pnum8},1}:
#  pb8"4"
```

The results of root finding and maximization aren't always as clean as the above examples. The [dependency problem](https://en.wikipedia.org/wiki/Interval_arithmetic#Dependency_problem) may make it impossible to eliminate some ranges that contain no actual solutions:

```julia
findmaximum(x->x-exp(x), pb8"everything")
# 7-element Array{Pnums.Pbound{Pnums.Pnum8},1}:
#  pb8"(-1/2, -2/5)"
#  pb8"(-1/3, -1/5)"
#    pb8"(-1/5, /4)"
#      pb8"(/4, /2)"
#     pb8"(/2, 4/7)"
#    pb8"(2/3, 4/5)"
#     pb8"(192, /0]"
```

The actual solution is `0`, but this algorithm fails to eliminate some regions that don't include `0`, and a region that contains infinity.

### Current Limitations

##### Missing arbitrary sets of Pnums (partially implemented)

The Unums 2.0 proposal suggests doing most computations on arbitrary sets of Unums, and not just contiguous intervals. These sets are called SORNs for "Sets Of Real Numbers".

This library contains an unexported type, `Pnums.Sopn` that implements a dense representation of sets of Pnums (backed by Julia's `IntSet`). It is currently used internally for testing, but I haven't built a lot of conveniences for it yet (like nice display and convenient constructors).

I have chosen to focus on contiguous intervals (Pbounds), because it seems that dense representations won't be able to scale well to higher precisions and multiple dimensions. For example, a dense bitset for 32-bit Pnums would require 2^32 bits ≈ 500MB to represent a single set. The storage requirements for a dense 2D set over 16-bit Pnums would be the same.

Contiguous intervals should be a useful building block for *sparse* represetations of sets; indeed, the results returned by `findroots` and `findmaximum` are exactly this kind of sparse representation.

##### No lookup tables
My implementation strategy means performance can't be competitive with floats or traditional intervals.

Gustafson suggests implementing arithmetic and functions using lookup tables. I have not implemented lookup tables; instead, operations are done internally on higher precision representations and then the results are looked up in the table of exact values dynamically using binary search.

Lookup tables would be trivial to implement, and would probably improve the performance of 3-, 4-, and 8-bit Pnums, but a lookup table for multiplication of 16-bit Pnums would require (`2^16*2^16*32/2` bits ≈ 8.5 GB) of storage. Doing a lookup into a table that large for every arithmetic operation does not seem practical for a software implementation.

If the exact Pnum values were all representable as floating point numbers, then lookup tables would not be necessary; however, this would require abandoning reciprocal closure (the property that the reciprocal of every exact value is also an exact value). My personal conclusion is that reciprocal closure is not worth this cost (unless some alternative way of doing fast arithmetic without lookup tables can be found).

##### No automatic subdivision
The Unums 2.0 proposal suggests a way to partially address the dependency problem: when an interval-valued (or set-valued) variable shows up more than once in a computation, run the computation separately on each individual Unum contained in the interval/set, and then form the union of the results at the end. I have not implemented this as an automated strategy, but you can simulate it manually using `eachpnum` and `shortestcover`

For example:

```julia
f(x) = x - x

# Ideally, we'd like f to return 0 for any finite input,
# but Pbounds don't automatically track dependencies
# between different uses of the same variable.
f(pb8"[1, 2]")
# pb8"[-1, 1]"

# You can manually address the problem using a split-apply-combine
# strategy. Notice that the bound is tighter, but not perfectly
# tight.
let out = pb8"empty"
  for x in eachpnum(pb8"[1,2]")
    out = shortestcover(out, f(x))
  end
  out
end
# pb8"(-1/4, /4)"

# Same thing as a one-liner
mapreduce(f, shortestcover, eachpnum(pb8"[1, 2]"))
# pb8"(-1/4, /4)"
```

Again, it may make sense to apply this strategy automatically to 3-, 4-, or 8-bit Pnums, but for higher precision arithmetic, I believe it will be necessary to have more control over when intervals are and aren't split.

### Other relevant work

Julia implementations of Unums 1.0:

* [JuliaComputing/Unums.jl](https://github.com/JuliaComputing/Unums.jl)
* [tbreloff/Unums.jl](https://github.com/tbreloff/Unums.jl)
* [REX-Computing/unumjl](https://github.com/REX-Computing/unumjl)
* [dpsanders/SimpleUnums.jl](https://github.com/dpsanders/SimpleUnums.jl)

Julia implementations of traditional interval arithmetic:

* https://github.com/dpsanders/ValidatedNumerics.jl
* https://github.com/andrioni/MPFI.jl
* https://github.com/andrioni/Intervals.jl

Unums Resources:
* [Book](https://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868) (covers Unums 1.0 only)
* [Gustafson's Presentations](http://www.johngustafson.net/unums.html) (I recommend downloading the powerpoint versions and looking at the presenters' notes).
* [Unum Computing Mailing list](https://groups.google.com/forum/#!forum/unum-computing)

gha_language: Julia


text:
# Ratibor

This app plows data via several ways(syslog, api, client) and exposes metrics based on this data readable for Prometheus. Metrics are configurable via config file flexibly, see examples below.

## Config

The example of config:

```yaml
input:
  api:
  - name: "some_api_input"
    listenAddr: 9999
    path: /some/api
template:
  type: plain
  pattern: "{{.http_code}} | {{.duration}} | {{.request}} | {{.method}}"
  delimiter: "|"
metrics:
- name: requests_total
  type: counter
  help: "Total requests"
  expr: '{{if ne .http_code "1"}}12{{else}}{{end}}'
  value: "1"
  labels:
  - name: "http_code"
    value: {{.http_code}}
  - name: "method"
    value: {{.method}}
- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}1{{end}}'
  value: "1"
- name: response_time_milliseconds
  type: summary
  value: "{{.duration}}"
```

### Supported types

Ratibor supports the following types of templates:
 - `plain`: is a one line data, the values in which are separated by delimiter. For example: `value 1 | value 2 | value 3`. The delimiter is `|`.

### Metric value evaluation

To evaluate metric value the two fields are used: `expr` and `value`. There are 3 cases of using this fields:

1. `expr` and `value` are not empty. In this case if evaluated expr is not empty, then if `value` can be considered as float64 value, it will be as metric value, else if `value` is not empty(i.e. it is some string), it will be as `float(1)` as metric value, else `float(0)`:

Examples:

```yaml
# http_code=200

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}1{{end}}'
  value: "1"

# nothing will be used as metric value
```

```yaml
# http_code=100

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}1{{end}}'
  value: "1"

# float64(1) will be used as metric value
```

```yaml
# http_code=100, page=/search

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}1{{end}}'
  value: "{{if eq .page "/page"}}2{{else}}3{{end}}"

# float64(2) will be used as metric value
```

```yaml
# http_code=100, page=/product

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}1{{end}}'
  value: "{{if eq .page "/page"}}2{{else}}3{{end}}"

# float64(3) will be used as metric value
```

```yaml
# http_code=100, page=/product

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}1{{end}}'
  value: "{{if eq .page "/page"}}some_value{{else}}another_value{{end}}"

# float64(1) will be used as metric value
```

2. `expr` is not empty, but `value` is empty, then if `expr` can be considered as float64, it will be as metric value, else if `expr` is not empty(i.e. some string), then `float64(1)` value will be as metric value, else nothing will be exposed.

```yaml
# http_code=100

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}2{{end}}'

# float64(2) will be used as metric value
```

```yaml
# http_code=100

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}yes{{end}}'

# float64(1) will be used as metric value
```

```yaml
# http_code=200

- name: errors_total
  type: counter
  help: "Total Errors"
  expr: '{{if ne .http_code "200"}}yes{{end}}'

# nothing will be used as metric value
```

3. `expr` is empty, but `value` is not empty, then if `value` can be considered as float64, it will be as metric value, else if `value` is not empty, `float64(1)` will be exposed as metric value else `float64(0)` will be exposed.

```yaml
# page=/page

- name: errors_total
  type: counter
  help: "Total Errors"
  value: "{{if eq .page "/page"}}2{{else}}3{{end}}"

# float64(2) will be used as metric value
```

```yaml
# page=/product

- name: errors_total
  type: counter
  help: "Total Errors"
  value: "{{if eq .page "/page"}}3{{end}}"

# float64(0) will be used as metric value
```

```yaml
# page=/page

- name: errors_total
  type: counter
  help: "Total Errors"
  value: "{{if eq .page "/page"}}yes{{end}}"

# float64(1) will be used as metric value
```

### Label value evaluation

```yaml
- name: handler_total_requests
  type: counterVec
  help: "Total requests by handler"
  value: 1
  labels:
  - name: "status"
    value: "{{.status}}"
  - name: "handler"
    values:
    - expr: "{{if contains .request `blog`}}1{{end}}"
      value: "{{ extractRegExp `\\/blog\\/[a-zA-Z-_\\/]+` .request }}"
    - expr: "{{if eq .request `/`}}1{{end}}"
      value: "home"
    - value: "{{if contains .request `forum`}}{{ extractRegExp `\\/forum\\/[a-zA-Z-_\\/]+` .request }}{{end}}"
```

### Inputs

Input is a source of data. There are several types of inputs.

#### Syslog

To set up syslog input add the following settings into configuration:

```yaml
input:
  syslog:
    - name: "some_syslog_input"
      listenAddr: ":9876"
```

#### API

To receive data via API it is needed to add the following configuration:

```yaml
input:
  api:
    - name: "some_api_input"
      listenAddr: ":9999"
      path: "/my_input"
```

repository: vlamug/ratibor

repo_name: vlamug/ratibor


text:
# [About Files and The File System](https://tldp.org/LDP/intro-linux/html/sect_03_01.html)

* On a UNIX system, everything is a file; if something is not a file, it is a process
* Input and output devices (and all devices) are considered to be files
* `ls -F` suffixes file names with a character to indicate file type

## About Partitioning

* By dividing the hard disk into partitions, data can be grouped and separated
* When an accident occurs, only the data in the partition that got the hit will be damaged, while the data on the other partitions will most likely survive
  * If a user creates a script that starts filling up the disk, and the disk only contains one big partition, the entire system will stop functioning if the disk is full
  * If the user stores the data on a separate partition, then only that data will be affected and other system partitions / data partitions will keep functioning
* There are two kinds of major partitions on a Linux system
  * Data partition, which is the normal Linux system data, including the root partition, which contains all the data to start up and run the system

## Mount Points

* All partitions are attached to the file system via a mount point
  * Mount point defines place of a particular data set in the file system
* Given a partition with directories, if we wanted to attach this partition to the filesystem at `/opt/media` would need to ensure that the directory exists on the system
* During system start up, many partitions are mounted (see in `/etc/fstab` file)
* Information about partitions and their mount points can be displayed using the `df` command (`disk full` / `disk free`)

## The File System In Reality

* Every partition has its own file system
  * In a file system, a file is represented by an `inod`, a kind of serial number containing information about the actual data that makes up the file
  * Every partition has its set of `inodes` - throughout a system with multiple partitions, files with the same inode number can exist

repository: jaebradley/notes

branch_name: refs/heads/main

gha_license_id: MIT

repo_name: jaebradley/notes


text:
# Patient

In ERPNext Healthcare, the Patient document corresponds any individual who is the recipient of healthcare services you provide. For every document ERPNext Healthcare, it is important to have a Patient associated with it. You can create a new Patient from

`Healthcare > Masters > Patient > New Patient`

The Patient document holds most details that are required to identify and qualify a patient. You can enter as much information available while creating the Patient. All information in the patient document is presented on the Consultation screen for easy lookup and you can always update this information. Other data like observations, vital signs etc. are all linked to the Patient document. These could be recorded during patient encounters and will be available as part of the Patient Medical History.

The Patient document holds the Patient barcode and can be used in any the default print formats or any [Custom Print Formats](docs/user/manual/en/customize-erpnext/print-format) that you create for printing patient identification tags.

### Patient as a Customer

ERPNext, especially the Accounts module, makes use of **Customer** document for booking all transactions. So, you may want to associate every Patient to be associated with a Customer in ERPNext. By default, ERPNext Healthcare creates a Customer alongside a Patient and links to it - every transaction against a Patient is booked against the associated Customer. If, for some reason you do not intend to use the ERPNext Accounts module you can turn this behavior off by unchecking this flag

`Healthcare > Setup > Healthcare Settings > Manage Customer`

In many cases, you may want to associate multiple Patients to a single Customer against whom you want to book the transactions. For instance, a Veterinarian would require the care services provided to different pets of an individual invoiced against a single Customer.

### Registration Fee
Many clinical facilities collect a registration fee during Registration. You can turn this feature on and set the registration fee amount by checking this flag

`Healthcare > Setup > Healthcare Settings > Collect Fee for Patient Registration`

If you have this option enabled, all new Patients you create will be in _Disabled_ mode by default and will only be enabled after Invoicing the Registration Fee. To create Invoice and record the payment receipt, you can use the `Invoice Patient Registration` button in the Patient document.

> Note: "Disabled" Patients are filtered out in all ERPNext Healthcare documents.

### Grant access to Patient Portal
ERPNext Healthcare allows you to create a portal user associated with a Patient by simply entering the user email id. A welcome email will be sent to the Patient email address to "Complete" registration.

### Actions
You can use the document links in the dashboard to traverse the linked document list with Patient filter applied, or use the + icons to create new records. Apart from this, the Patient document allows you to,

* Jump to the Patient's Health History, using `View > Medical Record` button.

* `Create > Vital Signs` to record the vitals of the Patient.

* Manually add data to a Patient's Medical Record, for instance a scanned copy of a Lab Test performed in an external Laboratory or a quick note on the Patient's condition, using `Create > Medical Record` button.

* Record the details of an encounter by using `Create > Patient Encounter` button

> Note: User should have appropriate privileges (User Role) to view the buttons

{next}

gha_license_id: NOASSERTION


text:
# Imbo - Image box
Imbo is an image "server" that can be used to add/get/delete images using a REST interface. There is also support for adding meta data to an image. The main idea behind Imbo is to have a place to store high quality original images and to use the REST interface to fetch variations of those images. Imbo will resize, rotate, crop (amongst other features) on the fly so you won't have to store all the different variations.

[![Current build Status](https://secure.travis-ci.org/imbo/imbo.png)](http://travis-ci.org/imbo/imbo)

## Documentation
End-user docs can be found [here](http://docs.imbo-project.org/en/latest/).

## Community
Feel free to join `#imbo` on the Freenode IRC network (`chat.freenode.net`) if you have any questions.

## Developer/Contributer notes
Here you will find some notes about how Imbo works internally along with information on what is needed to develop Imbo.

* [Jenkins job](http://ci.starzinger.net/job/Imbo/)
* [API Documentation](http://ci.starzinger.net/job/Imbo/API_Documentation/)
* [Code Coverage](http://ci.starzinger.net/job/Imbo/Code_Coverage/)
* [Code Browser](http://ci.starzinger.net/job/Imbo/Code_Browser/)

### Get started
First you must make sure you have both [PHPUnit](http://phpunit.de) and the [Imagick extension](http://pecl.php.net/package/imagick) installed. If not, you can install them using the following commands:

    sudo pear config-set audo_discover 1
    sudo pear install --alldeps pear.phpunit.de/PHPUnit
    sudo apt-get install php5-imagick

Now click the fork button on github and then clone your fork:

    git clone git@github.com:<username>/imbo.git

Enter the newly created directory and initialize the project using [composer](http://getcomposer.org):

    cd imbo
    curl -s https://getcomposer.org/installer | php
    php composer.phar --dev install

And lastly, execute the test suite:

    phpunit

Some tests will probably be skipped unless you have already installed all optional dependencies, like [APC](http://pecl.php.net/package/apc), [Memcached](http://pecl.php.net/package/memcached) and [Doctrine](http://www.doctrine-project.org).

If you send me a pull request I would appreciate it if you include tests for all new code, and make sure that the test suite passes. I also require you to use "feature branches", also for minor fixes like typos in comments.

repository: vstene/imbo

extension: markdown

repo_name: vstene/imbo


text:
---
layout: post
title: "A System for Email"
category: articles
tags: ["other"]
image:
  feature: 'email.jpg'
  feature_credit:
    author: John Schnobrich
    title: Person Using Silver Laptop
    link: https://unsplash.com/photos/yFbyvpEGHFQ
---

For many years at Square, then later at Bradfield CS, I ran a class for new
hires and managers about managing email.  This is basically an _Inbox Zero_
approach, but I deliberately avoid the label because _Inbox Zero_ is a thing
people often misunderstand. It's not about how many emails you have.  My
mantra: I don't care what your system is, so long as you have one. Your inbox
should not be a source of stress.

I don't expect many to follow this process to the letter (I barely do...), but
it does a decent job of encouraging people to reflect on their own process and
come up with something that works better for them. For me these principles
scaled to a couple of hundred emails a day to my inbox, with many more filtered
out, without requiring too much dedicated effort.

Changing how you handle email, particularly in such a seemingly radical way can
be scary and require a lot of support and coaxing. Probably more than a blog
post can provide, but I'll do my best. If this seems scary to you, still at
least try it for a couple of days to see how you feel once you have the process
under your fingers.

This is really a collection of notes, rather than a considered way of
introducing the material. It also doesn't address instant messaging, nor
effective ways of actually writing email. If anyone wants to remix this
material (alternate presentation, videos, training for your team, whatever)
please feel free, it is unlikely I'm going to.

 It is not a calendar. It is not a passive
information source. It is good for one thing and one thing only: triage. Triage
queues trend to zero, so when your inbox is empty you know you are done
processing. A previously unnoticed weight lifts off your shoulders, as the
nagging doubt that you're missing something important dissolves away.

### Buckets

Every email falls in to one of four buckets, each mapping to an action:

1. *No action.* There is nothing to do as a result of this email.
2. *Immediate action.* For tasks that take less than a minute, such as a quick
   reply. Do the task.
3. *Today.* Action needs to be taken in a timely manner, but will take too long
   to be part of the triage process. Add to your to-do list.
3. *Future.* No immediate action is required. Schedule something on your calendar.

After performing the associated action, you are done triaging that email, so
therefore it no longer belongs in your inbox. Archive it and move on to the
next one. This may make you uncomfortable for emails on your to-do list, since
you haven't done them yet but are removing them from your inbox. You won't
forget about them since they're written down on your to-do list, and you can
easily find them again using search (see below).

This *does not* imply that you respond to every email, which is a common
misunderstanding of this kind of process. Your inbox being empty means only
that you have seen everything that came in and decided what you are going to do
about it.

## Technique

To effectively triage email, you need to be able to move fast. Most emails
should take less than a second or two to handle.

[Enable keyboard shortcuts in
GMail.](https://support.google.com/mail/answer/6594?hl=en) There is only one
shortcut you absolutely have to know: shift+{. This will archive
the current message, and move to the next one in your inbox.

Open the first email in your inbox. Don't pick and choose! Open the first one.
Which bucket does it fall into? Do nothing, reply, add to your to-do list, or
add to your calendar. Now press shift+{, and the next message
appears. Rinse and repeat. With practice, you will be able to do this very
quickly. If you are doing this for the first time, after you have triaged back
a day or two, select all of the remaining messages and archive them. It's
probably not worth it to triage anything older than that, and there is a large
benefit to having your queue empty: you know when you're done and can close
your email client.

## To-do List

Your to-do list contains useful things you plan to do today. Things that might
be nice to do someday do not belong here. Put them on a different list. Your
to-do list must trend towards zero, otherwise you are committing to too much
work.

Each day, *start a new list.* I use a pen and paper, but you could use an
electronic list. Cross off everything that didn't get done yesterday. If it
is still worth doing, write it out again for today. Yes, this is redundant work!
By writing out your list each day, you ensure that your list doesn't get too
big, and nothing will be forgotten. You commit each day afresh to what you are
going to do. It makes it obvious which work empirically isn't getting done so
that you can explicitly handle that (de-commit, ask for help) rather than
giving the impression you forgot.

Everything on your list should be actionable. If a task hangs around for a few
days, maybe it isn't actionable enough? Can you break it down into smaller
chunks? Make it harder to procrastinate on? Set a calendar reminder next week
to follow up?

Keeping an effective to-do list is probably the most important technique in
this entire post.

## Passive Information Sources

Some types of emails — interesting or informational lists — are useful to keep
an eye on, but don't need to be part of the triage process. Have them skip your
inbox, then you can review at your leisure by searching for
<EMAIL_ADDRESS>Alternatively, you can apply an
_Interesting_ label which acts as a saved search. Consider automatically
marking these emails as read, so you are not distracted by an _unread_ count in
your sidebar.

## Example

Alice emails a short status report. I fire off a quick clarification on one
point (bucket #2).

Bob is asking for feedback on a new proposal. I want to collect my thoughts, so
add an item to my to-do list: "Reply to Bob" (bucket #3). Later when I get to
this item, I can easily retrieve Bob's email by searching for
from:bob.

Charles sends an interesting looking article to a mailing list I'm on. Reading
a blog post takes longer than a minute, and is too distracting from triage, so
I open it in a background tab to scan when I am done with triage (bucket #3,
implicit to-do list). After triage (there are no emails left in my inbox), on
scanning the article it is really long but seems interesting, so I add it to my
proper to-do list. Tomorrow when creating my to-do list, I notice I never got
around to reading the article (as I'm crossing it out) and feel like I'm
probably too busy, so don't bring it forward.

I receive some alerts for a service my team operates, but I already know our
oncall is taking care of it so I skip it (bucket #1). I already filter the
general oncall list to *Skip Inbox* when I am not oncall (passive information
source).

A friend replies confirming a new lunch time for later in the week, I ensure it
is in my calendar (bucket #4).

Having no further emails in my inbox, I close my email client and turn to my
to-do list. I am confident it is a complete list of the tasks I need to
prioritize.

## Common mistakes

### Categories/Hierarchies

Explicitly categorizing email — usually by manually applying labels — adds too
much cognitive overhead to the triage, and provides negligible benefit. Search
is good enough that you will always be able to find what you are looking for
without a predefined taxonomy. (Though a taxonomy doesn't generally help you
find emails anyway...)

### Priority Inbox

GMail's priority inbox tries to do some of the triage work for you, but it
provides no benefit if you are triaging properly. Triage is fast and always
trends to zero, there is no need for a "triage this first" concept.

### Preemptive Filtering

Filters should only be created as a reaction to repeated triage. When you
notice yourself triaging the same class of email with a repeatable action, that
is the time to create a filter to automate that action.

* *Filter to trash.* My favorite. Some email just doesn't need to be read.
* *Skip inbox.* Useful for passive information sources.

Do not use filters to solely apply labels unless it helps you triage faster.

The first step I do with people when training in this method is have them
delete all of their filters. They can contribute to a sense of "not being on
top of everything" and rebuilding them from scratch using the above principle
(response to repeated triage) is the best way to address.

### Leaving to-do items in your inbox

It is tempting to leave email that you need to reference or reply to in your
inbox. Don't. It clutters your space, and clutters your mind. Search is a much
more efficient way of bringing back email. See the example above for how to do
this.

### Continuous triage

Don't keep your email open. Triage, then close it. Set an expectation that if
someone needs your attention urgently, they should call you.

Nothing should notify you when an email arrives. Triage on your terms.  Triage
is busy work and isn't the useful thing you should be doing. I'll usually
triage a couple of times a day, or more if I have a couple of minutes between
meetings and no one to talk to.

Don't triage email outside of work hours. Don't put work email on your personal
phone that might tempt you to check it.

## Bonus Techniques

### Follow up label

If you need to follow up on a lot of email that you send, it can be too much
overhead to add all of them to your to-do list or calendar. Instead, keep a
"followup" label separate from your inbox that you can scan once a day.
Keeping these in your inbox means you have to "re-triage" them every time,
which is wasted effort.

### Skip email

For tasks you are going to do either do immediately post-triage or add to your
to-do list you can skip over them without archiving (keyboard shortcut
j), then do a second pass. It is equivalent to using your inbox as
a hyper-short-term to-do list. This is a dangerous technique if you are not
already adept at clearing your inbox to zero, since by divorcing bucketing and
action it subtly encourages you to be sloppy in your categorization and clean
up.

## Putting it together

Try this system for a week. Don't cheat. This should be enough time to cement
the process into your subconscious. If you don't feel like you can function
without your inbox being regularly empty, you've made it. Now is the time to
cheat, cut corners, or optimize for your personality. Good luck!

repository: xaviershay/blog

gha_language: SCSS

repo_name: xaviershay/blog


text:
```
title: Community
layout: page
pageOrder: 4
```

### Google Groups
Get help using SociaLite on our Google Groups:
* [SociaLite Users Group](https://groups.google.com/forum/#!forum/socialite-users) for usage questions.
* [SociaLite Dev Group](https://groups.google.com/forum/#!forum/socialite-dev) for discussions on SociaLite development.

### Issues

File a bug in the following issue tracker:
* [GitHub Issue Tracker](https://github.com/socialite-lang/socialite/issues)

repository: socialite-lang/homepage-src

repo_name: socialite-lang/homepage-src


text:
# node-japan-vat-offline

Supply a well known copy of Japanese consumption tax table.

```js
const japanVat = require('node-japan-vat-offline');

console.log(japanVat.table());
```

Sample output:

```txt
[ { since: '2019-10-01', percent: 10 },
  { since: '2014-04-01', percent: 8 },
  { since: '1997-04-01', percent: 5 },
  { since: '1989-04-01', percent: 3 } ]
```

repository: kenjiuno/node-japan-vat-offline

repo_name: kenjiuno/node-japan-vat-offline


text:
# RFC-0172/PeerToPeerMessaging

## Peer to Peer Messaging Protocol

![status: draft](theme/images/status-draft.svg)

**Maintainer(s)**: [Stanley Bondi](https://github.com/sdbondi), [Cayle Sharrock](https://github.com/CjS77) and [Yuko Roodt](https://github.com/neonknight64)

# Licence

[ The 3-Clause BSD Licence](https://opensource.org/licenses/BSD-3-Clause).

Copyright 2019 The Tari Development Community

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

1. Redistributions of this document must retain the above copyright notice, this list of conditions and the following
   disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
   disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products
   derived from this software without specific prior written permission.

## Language

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in
[BCP 14](https://tools.ietf.org/html/bcp14) (covering RFC2119 and RFC8174) when, and only when, they appear in all capitals, as
shown here.

## Disclaimer

This document and its content are intended for information purposes only and may be subject to change or update
without notice.

This document may include preliminary concepts that may or may not be in the process of being developed by the Tari
community. The release of this document is intended solely for review and discussion by the community of the
technological merits of the potential system outlined herein.

## Goals

The aim of this Request for Comment (RFC) is to describe the peer-to-peer messaging protocol for [communication node]s
and [communication client]s on the Tari network.

## Related Requests for Comment

- [RFC-0170: NetworkCommunicationProtocol](rfc-0170_NetworkCommunicationProtocol.md)
- [RFC-0171: MessageSerialization](RFC-0171_MessageSerialisation.md)

## Description

### Assumptions

- Either every [communication node] or [communication client] has access to a Tor/I2P proxy, or a native Tor/I2P implementation
  exists, which allows communication across the Tor network.
- All messages are de/serialized as per [RFC-0171: Message Serialisation].

### Broad Requirements

Tari network peer communication must facilitate secure, private and efficient communication
between peers. Broadly, a [communication node] or [communication client] MUST be capable of:

- bidirectional communication between multiple connected peers;
- private and secure over-the-wire communication;
- understanding and constructing Tari messages;
- encrypting and decrypting message payloads;
- gracefully reestablishing dropped connections; and (optionally)
- communicating to a SOCKS5 proxy (for connections over Tor and I2P).

Additionally, communication nodes MUST be capable of performing the following tasks:

- opening a control port for establishing secure peer channels;
- maintaining a list of known peers in the form of a routing table;
- forwarding directed messages to neighbouring peers; and
- broadcasting messages to neighbouring peers.

### Overall Architectural Design

The Tari communication layer has a modular design to allow for the various communicating nodes and clients to
use the same infrastructure code.

The design is influenced by an open-source library called [ZeroMQ] and the ZeroMQ C bindings are a dependency of
the project. ZeroMQ's over-the-wire protocol is relatively simple, and replicating ZeroMQ framing in a custom
implementation should not be prohibitively difficult. However, ZeroMQ offers many valuable features, which would be a
significantly larger undertaking to reproduce. Fortunately, bindings or native ports are available in numerous languages.

To learn more about ZeroMQ, read [the guide](http://zguide.zeromq.org/page:all). It's an enjoyable and worthwhile read.

A quick overview of what ZeroMQ provides:

- A simple socket Application Programming Interface (API).
- Some well-defined patterns to connect sockets together.
- Sockets that are tiny asynchronous message queues, which:
  - abstract away complexity around the underlying socket;
  - are transport agnostic, meaning you can choose between Transmission Control Protocol (TCP), Pragmatic General
  Multicast (PGM), Inter-process Communication (IPC) and in-process (inproc) transports with little or no changes to code;
  and
  - transparently reconnect when connections are dropped.
- The `inproc` transport for message passing between threads without mutex locks.
- Built-in protocol for asymmetric encryption over the wire using Curve25519.
- Ability to send and receive multipart messages using a simple framing scheme. More info [here](http://zguide.zeromq.org/php:chapter2#toc11).
- Support for Secure Socket (SOCKS) proxies.

This document will refer to several [ZeroMQ socket]s. These are referred to by prepending `ZMQ_` and the name
of the socket in capitals. For example, `ZMQ_ROUTER`.

**Note about ZeroMQ frames and multipart messages:**

ZeroMQ frames are length-specified blocks of binary data and can be strung together to make multipart messages.

```text
|5|H|E|L|L|O|*|0|*|3|F|O|O|+|
* = more flag
+ = no more flag
```

_A multipart message consisting of three frames "HELLO", a zero-length frame and "FOO"_

When this RFC mentions 'multipart messages', this is what it's referring to.

#### Establishing a Connection

Every participating [communication node] SHOULD open a control socket (refer to [ControlService]) to allow peers to negotiate and
establish a peer connection. The [NetAddress] of the control socket is what is stored in peers' routing tables and will
be used to establish new ephemeral [PeerConnection]s. Any peer that wants to connect MUST establish a connection
to the control socket of the destination peer to negotiate a new encrypted PeerConnection.

Once a connection is established, messages can be sent and received directly to or from the [Peer].

Incoming messages are validated, deserialized and handled as appropriate.

#### Encryption

Two forms of encryption are used:

- Over-the-wire encryption, in which traffic between nodes is encrypted using ZMQ's [CURVE](http://curvezmq.org/page:read-the-docs)
  implementation.
- Payload encryption, in which the [MessageEnvelopeBody] is encrypted in such a way that it can only be decrypted by the
destination recipient.

 This format consists of four frames of a multipart message.

A MessageEnvelope  represents a message that has either just come off or is about to go on to the wire. and consists of
the following:

| Name     | Frame | Length (Octets) | Type      | Description                                                                                |
| -------- | ----- | --------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| identity | 0     | 8               | `[u8;8]`  | The identifier that a `ZMQ_ROUTER` socket expects so that it knows the intended destination of the message. This can be thought of as a session token. |
| version  | 1     | 1               | `u8`      | The wire protocol version.                                                                                |
| header   | 2     | Varies          | `Vec<u8>` | Serialized bytes of data containing an unencrypted [MessageEnvelopeHeader].                                                                                |
| body     | 3     | Varies          | `Vec<u8>` | Serialized bytes of data containing an unencrypted or encrypted [MessageEnvelopeBody].                                                                      |

The header and decrypted body MUST be deserializable as per [RFC-0171: MessageSerialization](RFC-0171_MessageSerialisation.md).

#### MessageEnvelopeHeader

Every MessageEnvelope MUST have an unencrypted header containing the following fields:

| Name      | Type                      | Description                                                                                |
| --------- | ------------------------- | -------------------------------------------------------------------------------------------------- |
| version   | `u8`                      | Message protocol version.                                                                      |
| source    | `PublicKey`               | Source public key.                                                                             |
| dest      | `Option<NodeDestination>` | Destination [node ID] or public key. A destination is optional.                                |
| signature | `[u8]`                    | Signature of the message header and body, signed with the private key of the source.               |
| flags     | `u8`                      |

bit 0: 1 indicates that the message body is encrypted

bits 1-7: reserved

. |

A [communication node] and [communication client]:

- MUST validate the signature of the message using the source's public key.
- MUST reject the message if the signature verification fails.
- If the encryption bit flag is set:
  - MUST attempt to decrypt the [MessageEnvelopeBody]; or failing that
  - MUST forward the message to a subset of peers using the `Closest` [BroadcastStrategy].
  - MUST discard the message if the body is not encrypted.

#### MessageEnvelopeBody

A MessageEnvelopeBody is the payload of the [MessageEnvelope]. A [MessageEnvelopeBody] may be encrypted as required.

It consists of a [MessageHeader] and [Message] of a particular predefined [MessageType].

#### MessageType

An enumeration of the messages that are part of the Tari network. MessageTypes are represented
as an unsigned eight-bit integer and each value must be mapped to a corresponding Message struct.

All MessageTypes fall within a particular numerical range according to the message's concern:

| Category     | Range   | # Message Types | Description                                                  |
| ------------ | ------- | --------------- | ------------------------------------------------------------ |
| `reserved`     | 0       | 1               | Reserved for control messages such as `Ack`.                  |
| `net`        | 1-32    | 32              | Network-related messages such as `join` and `discover`.       |
| `peer`       | 33-64   | 32              | Peer connection messages, such as `establish connection`.     |
| `blockchain` | 65-96   | 32              | Messages related to the blockchain, such as `add block`.      |
| `vn`         | 97-224  | 128             | Messages related to the validator nodes, such as `execute instruction`. |
| `extended`   | 225-255 | 30              | Reserved for future use.                                      |

In documentation, MessageTypes can be referred to by the category and name. For example, `peer::EstablishConnection` and
`net::Discover`.

#### MessageHeader

Every Tari message MUST have a header containing the following fields:

| Name         | Type | Description                                                        |
| ------------ | ---- | ------------------------------------------------------------------ |
| version      | `u8` | The message version.                                               |
| message_type | `u8` | An enumeration of the message type of the body. Refer to [MessageType]. |

As this is part of the [MessageEnvelopeBody], it can be encrypted along with the rest of the message,
which keeps the type of message private.

 MessageType names should thus be a verb such as `net::Join` or `blockchain::AddBlock`.

All messages can be categorized as follows; each categorization has rules for how they should be handled:

- A propagation message
  - SHOULD NOT have a destination in the MessageHeader;
  - MUST be forwarded;
  - SHOULD use the `Random` BroadcastStrategy;
  - SHOULD discard a message that it has seen within the [DuplicateMessageWindow].
- A direct message
  - MUST have a destination in the MessageHeader;
  - SHOULD be discarded if it does not have a destination;
  - SHOULD discard a message that it has seen before;
  - MUST use the `Direct` BroadcastStrategy if a destination peer is known;
  - SHOULD use the `Closest` BroadcastStrategy if a destination peer is not known.
- An encrypted message
  - MUST undergo an attempt to be decrypted by all recipients;
  - MUST be forwarded by recipients if it cannot be decrypted;
  - SHOULD discard a message that it has seen before.

The [MessageType] in the header MUST be used to determine the type of the message deserialized.
If the deserialization fails, the message SHOULD be discarded.

#### DuplicateMessageWindow

A configurable length of time for which message signatures should be tracked in order to eliminate duplicate messages.
This should be long enough to make it highly unlikely that a particular message will be processed again
and short enough to not be a burden on the node.

#### InboundConnection

A thin wrapper around a `ZMQ_ROUTER` socket, which binds to a [NetAddress] and accepts incoming multipart messages.
This connection blocks until there is data to read, or a timeout is reached. In both cases, the `receive` method
can be called again (i.e. in a loop) to continue listening for messages. Client code should run this loop in its own thread.
`send` is only called (if at all) in response to an incoming message.

Fields may include

- a NetAddress;
- a timeout;
- underlying [ZeroMQ socket].

Methods may include:

- `receive()`
- `send(data)`
- `set_encryption(secret_key)`
- `set_socks_proxy(address)`
- `set_hwm(v)`

An InboundConnection:

- MUST perform the "server-side" [CurveZMQ](http://curvezmq.org/page:read-the-docs) encryption protocol if encryption is set.
  - Using [ZeroMQ]. this means setting the socketopts `ZMQ_CURVE_SERVER` to 1 and `ZMQ_CURVE_SECRETKEY` to the secret key before binding.
- MUST listen for and accept TCP connections.
  - For an IP NetAddress, bind on the given host IP and port.
  - For an Onion NetAddress, bind on <IP_ADDRESS> and the given port.
  - For an I2P NetAddress, as yet undetermined.
- MUST read multipart messages and return them to the caller.
  - If the timeout is reached, return an error to be handled by the calling code.

#### OutboundConnection

A thin wrapper around a `ZMQ_DEALER` socket, which connects to a [NetAddress] and sends outbound multipart messages.
This connection blocks until data can be written, or a timeout is reached. The timeout should never be reached, as
[ZeroMQ] internally queues messages to be sent.

Fields may include:

- a NetAddress;
- underlying [ZeroMQ socket].

Methods may include:

- `send(msg)`
- `receive()`
- `disconnect()`
- `set_encryption(server_pk, client_pk, client_sk)`
- `set_socks_proxy(address)`
- `set_hwm(v)`

An OutboundConnection:

- MUST perform the "client-side" [CurveZMQ](http://curvezmq.org/page:read-the-docs) encryption protocol if encryption is set.
  - Using ZeroMQ, this means setting the socketopts `ZMQ_CURVE_SERVERKEY`, `ZMQ_CURVE_SECRETKEY` and `ZMQ_CURVE_PUBLICKEY`.
- MUST connect to a TCP endpoint.
  - For an IP NetAddress, connect to the given host IP and port.
  - For an Onion NetAddress, connect to the onion address using the TCP, e.g. `tcp://xyz...123.onion:1234`.
  - For an I2P NetAddress, as yet undetermined.
- MUST write the parts of the given MessageEnvelope to the socket as a multipart message consisting of, in order:
  - identity;
  - version;
  - header;
  - body.
- If specified, MUST set a High Water Mark (HWM) on the underlying ZeroMQ socket.
- If the HWM is reached, a call to `send` MUST return an error and any messages received SHOULD be discarded.

#### Peer

A single peer that can communicate on the Tari network.

Fields may include:

- `addresses` - a list of [NetAddress]es associated with the peer, perhaps accompanied by some bookkeeping metadata, such
as preferred address;
- `node_type` - the type of node or client, i.e. [BaseNode], [ValidatorNode], [Wallet] or [TokenWallet]);
- `last_seen` - a timestamp of the last time a message has been sent/received from this peer;
- `flags` - 8-bit flag;
  - bit 0: is_banned,
  - bit 1-7: reserved.

A peer may also contain reputation metrics (e.g. rejected_message_count, avg_latency) to be used to decide
if a peer should be banned. This mechanism is yet to be decided.

#### PeerConnection

Represents direct bidirectional connection to another node or client. As connections are bidirectional,
the PeerConnection need only hold a single [InboundConnection] or [OutboundConnection], depending on if the
node requested a peer connect to it or if it is connecting to a peer.

PeerConnection will send messages to the peer in a non-blocking, asynchronous manner as long as the connection
is maintained.

It has a few important functions:

- managing the underlying network connections, with automatic reconnection if necessary;
- forwarding incoming messages onto the given handler socket; and
- sending outgoing messages.

Unlike InboundConnection and OutboundConnection, which are essentially stateless,
`PeerConnection` maintains a particular `ConnectionState`.

- `Idle` - the connection has not been established.
- `Connecting` - the connection is in progress.
- `Connected` - the connection has been established.
- `Suspended` - the connection has been suspended. Incoming messages will be discarded, calls to `send()` will error.
- `Dead` - the connection is no longer active because the connection was dropped.
- `Shutdown` - the connection is no longer active because it was shut down.

Fields may include:

- a connection state;
- a control socket;
- a peer connection `NetAddress`;
- a direction (either `Inbound` or `Outbound`);
- a public key obtained from the connection negotiation;
- (optional) SOCKS proxy.

Methods may include:

- `establish()`
- `shutdown()`
- `suspend()`
- `resume()`
- `send(msg)`

A `PeerConnection`:

- MUST listen for data on the given [NetAddress] using an InboundConnection;
- MUST sequentially try to connect to one of the peer's NetAddresses until one succeeds or all fail using an OutboundConnection;
- MUST immediately reject and dispose of a multipart message not consisting of four parts, as detailed in MessageEnvelope;
- MUST construct a MessageEnvelope from the multiple parts;
- MUST pass the constructed MessageEnvelope to the message handler;
- MUST transition to `Connecting` state and retry the connection, should a connection drop;
- MUST send a `net::Disconnect` message and drop the connection when a shutdown signal is received.

#### ConnectionManager

The ConnectionManager manages a set of live PeerConnections. It provides an abstraction for other components
to initiate and use PeerConnections without having to worry about attaching the new PeerConnection to message handlers.

It consists of a list of active peer connections and an `inproc` message handler socket. This socket is 'written to' whenever
a message is received from any active [PeerConnection] for other components to act on.

Methods may include:

- `establish_connection(Peer)` - create and return a new PeerConnection;
- `disconnect(peer)` - disconnect a particular peer;
- `suspend()` - temporarily suspend connections;
- `resume()` - temporarily suspend connections;
- `shutdown` - cleanly shut down all PeerConnections.

The `ConnectionManager`:

- MUST call `suspend` on every PeerConnection if its `suspend` method is called;
- MUST call `resume` on every PeerConnection if its `resume` method is called;
- MUST call `shutdown` on every PeerConnection if its `shutdown` method is called
- MUST create a new PeerConnection with the given Peer and NetAddress, when `establish_connection` is called;
- MUST call `shutdown` on the PeerConnection and remove the connection for the given peer, when `disconnect(peer)` is called;
- MAY disconnect peers if the connection has not been used for an extended period;
- SHOULD disconnect the least recently used peer if the connection pool is greater than `max connections`

#### ControlService

The purpose of this service is to negotiate a new secure PeerConnection.

The control service accepts a single message:

- `peer::EstablishConnection(pk, curve_pk, net_address)`.

A ControlService:

- MUST listen for connections on a predefined CONTROL PORT;
- SHOULD deny connections from banned peers.

The steps to establish a peer connection are as follows:

Alice wants to connect to Bob

1. Alice creates a `PeerConnection` to which Bob can connect.
   - A new CURVE key pair is generated.
2. Alice connects to Bob's control server and Bob accepts the connection.
3. Alice sends a `peer::establish_connection` message, with:
   - the CURVE public key for the socket connection;
   - the node's public key corresponding to its [Node ID]; and
   - the [NetAddress] of the new PeerConnection.
4. Bob accepts this request and opens a new `PeerConnnection` socket using Alice's CURVE public key.
5. Bob connects to the given NetAddress and sends a `peer::establish_connection` message.
6. If Alice accepts the connection, they can begin sending messages. If not, both sides terminate the connection.

#### PeerManager

The PeerManager is responsible for managing the list of peers with which the node has previously interacted.
This list is called a routing table and is made up of [Peer]s.

The PeerManager can

- add a peer to the routing table;
- search for a peer given a node ID, public key or [NetAddress];
- delete a peer from the list;
- persist the peer list using a storage backend;
- restore the peer list from the storage backend;
- maintain lightweight views of peers, using a filter criterion, e.g. a list of peers that have been banned, i.e. a denylist; and
- prune the routing table based on a filter criterion, e.g. last date seen.

#### MessageDispatcher

The MessageContext contains:

- the requesting PeerConnection;
- the MessageHeader;
- the deserialized message;
- the OutboundMessageService.

Basically, all the tools the handler needs to interact with the network.

A MessageDispatcher is responsible for:

- constructing the MessageContext;
- finding the message handler that is associated with the MessageType;
- passing the MessageContext to the handler; and
- ignoring the message if the handler cannot be found.

An example API may be:

```rust,compile_fail
let dispatcher = MessageDispatcher::<MessageType>::new()
    .middleware(logger)
    .route(BlockchainMessageType::NewBlock, BlockHandlers::store_and_broadcast)
    ...
    .route(NetMessageType::Ping, send_pong);

inbound_msg_service.set_handler(dispatcher.handler);
```

#### InboundMessageService

InboundMessageService is a service that receives messages over a non-blocking asynchronous socket and
determines what to do with it. There are three options: handle, forward and discard.

A pool of worker threads (with a configurable size) is started and each one listens for messages on its $1:n$ `inproc` message
socket. A `ZMQ_DEALER` socket is suggested for fair-queueing work amongst workers, who listen for work with a `ZMQ_REP`.
The workers read off this socket and process the messages.

An InboundMessageService:

- MUST receive messages from all PeerConnections; and
- MUST write the message to the worker socket.

A worker:

- MUST deserialize the MessageHeader.
  - If unable to deserialize, MUST discard the message.
- MUST check the message signature.
  - MUST discard the message if the signature is invalid.
  - MUST discard the message if the signature has been processed within the [DuplicateMessageWindow].
- If the encryption flag is set:
  - MUST attempt to decrypt the message.
    - If successful, process and handle the message.
    - Otherwise, MUST forward the message using the `Random` BroadcastStrategy.
    - If the message is not encrypted, MUST discard it.
- If the destination [node ID] is set:
  - If the destination matches this node's ID - process and handle the message.
  - If the destination does not match this node's ID - MUST forward the message using the `Closest` BroadcastStrategy.
- If the destination is not set
  - If the MessageType is a kind of propagation message:
    - MUST handle the message;
    - MUST forward the message using the `Random` BroadcastStrategy.
  - If the MessageType is a kind of encrypted message:
    - MUST attempt to decrypt and handle the message;
    - if successful, MUST handle the message;
    - if unsuccessful, MUST forward the message using the `Random` or `Flood` BroadcastStrategy,

#### OutboundMessageService

OutboundMessageService is responsible for using the connection and peer infrastructure to
send messages to the rest of the network.

In particular, it is responsible for:

- serializing the message body;
- constructing the MessageEnvelope;
- executing the required BroadcastStrategy; and
- sending messages using the [ConnectionManager].

The actual sending of messages can be requested via the public `send_message` method, which takes a
MessageHeader, MessageBody and BroadcastStrategy as parameters.

`send_message` then selects an appropriate peer(s) from the ConnectionManager according to the
BroadcastStrategy and sends the message to each of the selected peers.

BroadcastStrategy determines how a set of peer nodes will be selected and can be:

- `Direct` - send to a particular peer matching the given [node ID];
- `Flood` - send to all known peers who are not [communication clients];
- `Closest` - send to $n$ closest peers who are not [communication clients]; or
- `Random` - send to a random set of peers of size $n$ who are not [communication clients].

### Privacy Features

The following privacy features are proposed:

- A [communication node] or [communication client] MAY communicate solely over the Tor/I2P networks.
- All traffic (with the exception of the control service) MUST be encrypted.
- Messages MAY encrypt the body of a MessageEnvelope, which only a particular recipient can decrypt.
- The `destination` header field can be omitted when used in conjunction with body encryption; the destination is
  completely unknown to the rest of the network.

### Store and Forward Strategy

Sometimes it may be desirable for messages to be sent without a destination node/client being online. This
is especially important for a modern chat/messaging application.

The mechanism for this is proposed as follows:

Each [communication node] MUST allocate some disk space for storage of messages for offline recipients.
Only some allowlisted MessageTypes are permitted to be stored. A sender sends a message destined for a particular
[node ID] to its closest peers, which forward the message to their closest peers, and so on.

Eventually, the message will reach nodes that either know the destination or are very close to the destination.
These nodes MUST store the message in some pending message bucket for the destination. The maximum number of
buckets and the size of each bucket SHOULD be sufficiently large as to be unlikely to overflow, but not so
large as to approach disk space problems. Individual messages should be small and responsibilities for
storage spread over the entire network.

A communication node

- MUST store messages for later retransmission, if all of the following conditions are true:
  - the MessageType is permitted to be stored;
  - there are fewer than $n$ closer online peers to the destination.
- MUST retransmit pending messages when a closer peer comes online or is added to the routing table.
- MAY remove a bucket, in any of the following conditions:
  - The bucket is empty;
  - A configured maximum number of buckets has been reached. Discard the bucket with the earliest creation timestamp.
  - The number of closer online peers to the destination is equal to or has exceeded $n$.
- MAY expire individual messages after a sufficiently long Time to Live (TTL)

This approach has the following benefits:

- When a destination comes online, it will receive pending messages without having to query them.
- The "closer within a threshold" metric is simple.
- Messages are stored on multiple peers, which makes it less likely for messages to disappear as nodes come and go
  (depending on threshold $n$).

### Queue Overflow Strategy

Inbound/OutboundConnections (and therefore PeerConnection) have an HWM set.

If the HWM is hit:

- any call to `send()` should return an error; and
- incoming messages should be silently discarded.

### Outstanding Items

- A PeerConnection will probably need to implement a heartbeat to detect if a peer has gone offline.
- InboundConnection(Service) may want to send small replies (such as OK, ERR) when the message has been accepted or rejected.
- OutboundConnection(Service) may want to receive and handle small replies.
- Encrypted communication for the [ControlService] would be better privacy, but since ZMQ requires a CURVE public key before
  the connection is bound, a dedicated "secure connection negotiation socket" would be needed.
- Details of distributed message storage.
- Which [NetAddress] to use if a peer has many.

[basenode]: Glossary.md#base-node
[broadcaststrategy]: #outboundmessageservice
[communication client]: Glossary.md#communication-client
[communication node]: Glossary.md#communication-node
[connectioncontext]: #connectioncontext
[controlservice]: #controlservice
[duplicatemessagewindow]: #duplicatemessagewindow
[inboundconnection]: #inboundconnection
[message]: #message
[MessageEnvelopeBody]: #messageenvelopebody
[MessageEnvelopeHeader]: #messageenvelopeheader
[messageheader]: #messageheader
[messagetype]: #messagetype
[netaddress]: #netaddress
[node id]: Glossary.md#node-id
[outboundconnection]: #outboundconnection
[peer]: #peer
[peerconnection]: #peerconnection
[rfc-0171: message serialisation]: RFC-0171_MessageSerialisation.md
[tokenwallet]: Glossary.md#token-wallet
[validatornode]: Glossary.md#validator-node
[wallet]: Glossary.md#wallet
[zeromq socket]: http://api.zeromq.org/2-1:zmq-socket
[zeromq]: http://zeromq.org/

repository: philipr-za/tari

branch_name: refs/heads/development

gha_language: Rust

repo_name: philipr-za/tari


text:
# Study OnsenUI and UI Router

This is an example application of [Onsen UI](http://onsen.io) using [ui-router](http://angular-ui.github.io/ui-router/).

original source is here
http://frankdiox.github.io/OnsenUI-router

repository: strozw/study-onsenui-router

repo_name: strozw/study-onsenui-router


text:
| Supported Targets | ESP32 | ESP32-S2 |
| ----------------- | ----- | -------- |

# DAC Constant Example

(See the README.md file in the upper level 'examples' directory for more information about examples.)

## Overview

This example shows the basic usage of outputting continuous voltage by the DAC driver. There are two ways to realize continuous output, one is outputting by DMA transmission and another is by timer interrupt.

### Timer Interrupt

While using timer interrupt to output the waves, it actually sets the voltage by `oneshot` API in every timer interrupt callback. Which means the conversion frequency is equal to the timer interrupt frequency. Obviously, the conversion frequency is limited by the interrupt, which relies on the CPU scheduling, thus it can't reach a high frequency in this mode. But it can be used as a supplementary way while the conversion frequency is too low to use DMA mode.

### DMA transmission

While using DMA to transmit the wave buffers, the digital values are put into a DMA buffer waiting for transmission and conversion, that means the conversion frequency is equal to the frequency that DMA transmitting the data. We can set the DMA frequency directly, and the digital data in the buffer will be sent automatically when the buffer has been loaded into the DMA. So the conversion frequency can reach even several MHz while using DMA mode. But the wave can be distorted if the frequency is too high.

## How to use the Example

### Hardware Required

* A development board with ESP32 or ESP32-S2 SoC
    - Note that some ESP32-S2 DevKits have LED on it which is connected to GPIO18 (same pin as DAC channel1), so the output voltage of DAC channel 1 can't go down due the this LED.
* (Optional) An oscilloscope to monitor the output wave

### Configure the Project

You can switch the output method by setting the macro `EXAMPLE_DAC_CONTINUOUS_MODE` to `EXAMPLE_DAC_CONTINUOUS_BY_TIMER` or `EXAMPLE_DAC_CONTINUOUS_BY_DMA`.

There are four waves: sine, triangle, saw tooth and square. These waves are stored in corresponding buffers, and each wave has 400 points as default, which can be modified by `EXAMPLE_ARRAY_LEN`, reduce the point number can increase the wave frequency.

### Build and Flash

Note that as we use the ADC to monitor the output data, we need to set false to `CONFIG_ADC_DISABLE_DAC_OUTPUT` in the menuconfig, otherwise the ADC will shutdown the DAC power to guarantee it won't be affect by DAC.

Build the project and flash it to the board, then run monitor tool to view serial output:

```
idf.py -p PORT flash monitor
```

(Replace PORT with the name of the serial port to use.)

(To exit the serial monitor, type ``Ctrl-]``.)

See the Getting Started Guide for full steps to configure and use ESP-IDF to build projects.

## Example Output

This example can output sine wave, triangle wave, saw tooth wave and square wave periodically, each wave will last for 3 seconds.

The DAC channels can be read by ADC channels internally. The ADC read period is 500 ms, the following log is the raw ADC value read from the DAC channels. But since the ADC sample-rate is lower than the DAC output-rate, the sampling value can only indicate that the voltage is changing.

### Timer Triggered Output

You can see sine wave, triangle wave, saw tooth wave and square wave at 50 Hz on the oscilloscope.

```
I (333) dac continuous: --------------------------------------------------
I (343) dac continuous: DAC continuous output by Timer
I (343) dac continuous: DAC channel 0 io: GPIO_NUM_25
I (353) dac continuous: DAC channel 1 io: GPIO_NUM_26
I (353) dac continuous: Waveform: SINE -> TRIANGLE -> SAWTOOTH -> SQUARE
I (363) dac continuous: DAC conversion frequency (Hz): 20000
I (373) dac continuous: DAC wave frequency (Hz): 50
I (373) dac continuous: --------------------------------------------------
DAC channel 0 value: 2291       DAC channel 1 value: 2331
DAC channel 0 value:   43       DAC channel 1 value:    3
DAC channel 0 value:   55       DAC channel 1 value:   32
DAC channel 0 value:   57       DAC channel 1 value:   33
DAC channel 0 value:   56       DAC channel 1 value:   34
DAC channel 0 value:   59       DAC channel 1 value:   34
DAC channel 0 value:   56       DAC channel 1 value:   33
I (3393) dac continuous(timer): triangle wave start
DAC channel 0 value: 2258       DAC channel 1 value: 2243
DAC channel 0 value: 2257       DAC channel 1 value: 2242
DAC channel 0 value: 2259       DAC channel 1 value: 2242
DAC channel 0 value: 2257       DAC channel 1 value: 2245
DAC channel 0 value: 2257       DAC channel 1 value: 2243
DAC channel 0 value: 2258       DAC channel 1 value: 2240
I (6393) dac continuous(timer): sawtooth wave start
DAC channel 0 value: 2704       DAC channel 1 value: 2735
DAC channel 0 value: 2704       DAC channel 1 value: 2735
DAC channel 0 value: 2704       DAC channel 1 value: 2736
DAC channel 0 value: 2704       DAC channel 1 value: 2717
DAC channel 0 value: 2704       DAC channel 1 value: 2734
DAC channel 0 value: 2704       DAC channel 1 value: 2736
I (9393) dac continuous(timer): square wave start
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
I (12393) dac continuous(timer): sine wave start
DAC channel 0 value:   82       DAC channel 1 value:   62
DAC channel 0 value:   83       DAC channel 1 value:   62
DAC channel 0 value:   82       DAC channel 1 value:   62
DAC channel 0 value:   87       DAC channel 1 value:   62
DAC channel 0 value:   84       DAC channel 1 value:   63
DAC channel 0 value:   83       DAC channel 1 value:   64
...
```

### DMA Output

You can see sine wave, triangle wave, saw tooth wave and square wave at 2 KHz on the oscilloscope.

```
I (335) dac continuous: --------------------------------------------------
I (345) dac continuous: DAC continuous output by DMA
I (345) dac continuous: DAC channel 0 io: GPIO_NUM_25
I (355) dac continuous: DAC channel 1 io: GPIO_NUM_26
I (355) dac continuous: Waveform: SINE -> TRIANGLE -> SAWTOOTH -> SQUARE
I (365) dac continuous: DAC conversion frequency (Hz): 800000
I (375) dac continuous: DAC wave frequency (Hz): 2000
I (375) dac continuous: --------------------------------------------------
DAC channel 0 value: 3131       DAC channel 1 value: 1634
DAC channel 0 value: 1712       DAC channel 1 value: 2531
DAC channel 0 value: 1716       DAC channel 1 value: 2535
DAC channel 0 value: 1715       DAC channel 1 value: 2544
DAC channel 0 value: 1715       DAC channel 1 value: 2533
DAC channel 0 value: 1712       DAC channel 1 value: 2539
I (3395) dac continuous(DMA): triangle wave start
DAC channel 0 value:  592       DAC channel 1 value: 1190
DAC channel 0 value: 4095       DAC channel 1 value: 3518
DAC channel 0 value: 4095       DAC channel 1 value: 3515
DAC channel 0 value: 4095       DAC channel 1 value: 3516
DAC channel 0 value: 4095       DAC channel 1 value: 3514
DAC channel 0 value: 4095       DAC channel 1 value: 3515
I (6395) dac continuous(DMA): sawtooth wave start
DAC channel 0 value:  294       DAC channel 1 value:  560
DAC channel 0 value: 2861       DAC channel 1 value: 3227
DAC channel 0 value: 2860       DAC channel 1 value: 3216
DAC channel 0 value: 2861       DAC channel 1 value: 3227
DAC channel 0 value: 2861       DAC channel 1 value: 3216
DAC channel 0 value: 2859       DAC channel 1 value: 3183
I (9395) dac continuous(DMA): square wave start
DAC channel 0 value: 4095       DAC channel 1 value: 4095
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
DAC channel 0 value:    0       DAC channel 1 value:    0
I (12395) dac continuous(DMA): sine wave start
DAC channel 0 value: 2864       DAC channel 1 value: 3691
DAC channel 0 value:    0       DAC channel 1 value:  204
DAC channel 0 value:    0       DAC channel 1 value:  202
DAC channel 0 value:    0       DAC channel 1 value:  193
DAC channel 0 value:    0       DAC channel 1 value:  181
DAC channel 0 value:    0       DAC channel 1 value:  194
...
```

repository: KollarRichard/esp-idf

repo_name: KollarRichard/esp-idf


text:
leiningen
=========

Base [leiningen](https://github.com/technomancy/leiningen) container for octohost.

To use an already built container:

`docker pull octohost/leiningen`

Or you can build it from this source:

`docker build -t your-organization/leiningen`

repository: octohost/leiningen

repo_name: octohost/leiningen


text:
# High Availability Manager #
This service sets up the high availability (HA) node cluster

### Data Format ###
All Data is exchanged in JSON format

## API ##
GET /v1/ha/<aggregate_id>

Returns the HA configuration state for the host aggregate

Example:
```
{
    "status":
    [
     { "id": 1, "state": "enabled" },
    ]
}
```

HA configuration requires a minimum of three hosts. It is said to be
non-available if the aggregate has less than three hosts.

GET /v1/ha/\<aggregate_id>

Returns HA configuration state for one host aggregate

Example:
```
{
    "status":
    [
     { "id": 1, "state": "enabled" },
     { "id": 11, "state": "disabled" },
     { "id": 14, "state": "not-available" }
    ]
}
```

PUT /v1/ha/\<aggregate_id>/enable

Activates the HA configuration on all hosts in the given aggregate.
1. If HA is not yet enabled for given aggregate:  The eligible hosts are determined by looking at their
host aggregate metadata. All hosts in the host aggregate are treated as one HA cluster
2. If HA is already enabled for given aggregate: No action is performed.
3. If HA cannot be enabled for given aggregate: This can happen if there are
less than three hosts in the host aggregate. The API fails in such a case.

PUT /v1/ha/\<aggregate_id>/disable

Disables HA for an aggregate. With following possible outcomes --
1. If given aggregate is HA enabled, it is disabled. The clustering
services are removed from all participating hosts.
2. If the aggregate has HA disabled, no action is taken.
3. If the aggregate was not found, the API reports failure.

Once an aggregate is HA enabled, the hosts added to such aggregate
are automatically added to HA cluster services.

branch_name: refs/heads/atherton

gha_language: Python


text:
# Spiro
## Overview
Very rudimentary implementation of the old Spirograph toy.  Draws a set of nested circles, from `0` to `2*pi`.  Each circle has a `frequency` and a `radius`

## How to use
For example, this snippet of code

```
figure whatever
colour green
width 2
circle(1, 100)
circle(36, 10)
end
```

produces this image

![example](spiro1.png)

## Can I try?

Probably, it should be hosted here [http://lyra.stikman.co.uk/spiro/Spiro.html], hopefully it'll stay put...

## How is it made?
It's written in Java, on top of [http://www.gwtproject.org/] which is effectively a cross-compiler to JavaScript.  It lets you write web applications without having to touch JS, which I think is just fab.

The actual implementation just draws lines on a `<canvas>` element

repository: stikdragon/spiro

repo_name: stikdragon/spiro


text:
---
title: |
    556. Angel Voices Sweetly Singing - Church Hymnal 1941
metadata:
    description: |
        Church Hymnal 1941 556. Angel Voices Sweetly Singing.  Angel voices sweetly singing,  Echoes through the blue dome ringing,  News of wondrous gladness bringing;  Ah, 'tis heaven at last!
    keywords:  |
        Church Hymnal 1941, adventhymnals, advent hymnals, Angel Voices Sweetly Singing, Angel voices sweetly singing. Heaven at last, heaven at last;
    author: Brian Onang'o
---

#### Advent Hymnals
## 556. ANGEL VOICES SWEETLY SINGING
####  Church Hymnal 1941,

```txt
1.
Angel voices sweetly singing,
Echoes through the blue dome ringing,
News of wondrous gladness bringing;
Ah, 'tis heaven at last!
REFRAIN:
Heaven at last, heaven at last;
O, the joyful story of heaven at last!
Heaven at last, heaven at last;
Endless, boundless glory, In heaven at last.

2.
On the jasper threshold standing,
Like a pilgrim safely landing,
See the strange bright scene expanding;
Ah, 'tis heaven at last!

3.
Softest voices, silver pealing,
Freshest fragrance, spirit healing,
Happy hymns around us stealing;
Ah, 'tis heaven at last!

4.
Not a teardrop ever falleth,
Not a pleasure ever palleth,
Song to song forever calleth;
Ah, 'tis heaven at last!

5.
Christ Himself the living splendor,
Christ the sunlight, mild and tender;v
Praise to the Lamb we render;
Ah, 'tis heaven at last!

```

- |   -  |
-------------|------------|
Title | Angel Voices Sweetly Singing |
Key | E♭ Major |
Titles | Heaven at last, heaven at last;  |
First Line | Angel voices sweetly singing |
Author | Horatius Bonar
Year | 1941
Composer| William J. Kirkpatrick |
Hymnal|  - |
Tune| HEAVEN AT LAST |
Metrical pattern | |
# Stanzas |  |
Chorus |  |
Chorus Type |  |
Subjects | Sabbath School: His Kingdom and Reign |
Texts | undefined |
Print Texts |
Scripture Song |  |

repository: GospelSounders/adventhymnals

repo_name: GospelSounders/adventhymnals


text:
Choose one of the templates below:

# Fingerprint
This pull requests adds a fingerprint for <Make - Model - Year - Trim>.

This is an explorer link to a drive with the stock system enabled: ...

# Car support
This pull requests adds support for <Make - Model - Year - Trim>.

This is an explorer link to a drive with the stock system enabled: ...
This is an explorer link to a drive with openpilot system enabled: ...

# Feature
This pull requests adds feature X

## Description
Explain what the feature does

## Testing
Explain how the feature was tested. Either by the added unit tests, or what tests were performed while driving.

repository: Gernby/raspberry-pilot

branch_name: refs/heads/resonant-rails

gha_language: C

repo_name: Gernby/raspberry-pilot


text:
# CALCULATOR APP
#### The Calculator App 24th April
#### By **Leo Igane Owen Muriithi Mercy Rigua Naftal Tedy**
## Description
The site is part of class work as I learn how to develop a Calculator app
## Setup/Installation Requirements
* This is a great place
* See a simple one page website
* in a simple
* easy-to-understand
* format

## Technologies Used
We used HTML CSS and JavaScript.
## Support and contact details
In case you want to contribute please do so contact me on<EMAIL_ADDRESS>### License
*This project is licensed under the terms of the MIT license.*
Copyright (c) 2018 **Leo Igane**

repository: BenkiKuu/calculator-project

repo_name: BenkiKuu/calculator-project


text:
---
id: 3742
title: Zooey Deschanel
date: 2021-04-06T11:36:53+00:00
author: Laima
layout: post
guid: https://ukdataservers.com/zooey-deschanel/
permalink: /04/06/zooey-deschanel/
---

* some text
{: toc}

## Who is Zooey Deschanel

Television and film actress who plays the character Jess Day on the sitcom New Girl. Her film credits include The Good Girl, Elf, Bridge to Terabithia, Almost Famous and The Hitchhiker’s Guide to the Galaxy.

## Prior to Popularity

She befriended fellow actors Jake Gyllenhaal and Kate Hudson while attending high school with them in Santa Monica, California. She made her film debut in the 1999 film Mumford.

## Random data

She formed the musical duo She & Him with singer/guitarist M. Ward. They released their debut album, Volume One, in 2008.

## Family & Everyday Life of Zooey Deschanel

She was married to Death Cab For Cutie frontman Ben Gibbard from 2009 until 2011. In January 2015, she got engaged to Jacob Pechenik, and the couple married later that year. She and Jacob had a daughter named Elsie Otter and a son named Charlie Wolf before separating in 2019. She then began dating Jonathan Scott. Her dad is Academy Award-nominated cinematographer Caleb Deschanel and her mom is acclaimed actress Mary Jo Deschanel. Her sister is actress Emily Deschanel.

## People Related With Zooey Deschanel

She began starring alongside Jake Johnson on the series New Girl in 2011.


text:
# CGDemo-OpenGL
A mini project for understanding OpenGL (Computer Graphics - Class Assignment) (VTU - BE - 6th Semester) (2015)

> Below model is not designed using tools like 3Ds Max or Blender. Its just **pure C++ code!** :-)

-----
![Alt Text](Assets/demo.gif)
-----
To run this demo, extract Debug.zip

This project is built using Glut - [OpenGL Utility ToolKit](https://www.opengl.org/resources/libraries/glut/)

> [GLut installation instrauctions](https://stackoverflow.com/a/20559229)
-----
## Files
> Structure
+ CGDemo
    + butterfly.h - draws butterfly
    + cgl.h - initializes OpenGL
    + const.h - definition of basic premitives like cube, polygon etc.
    + draw.h -  Custom library to draw basic OpenGl shapes
    + stars.h - draw stars
    + tablefan.h - draw table fan
------

repository: sandeepsj/CGDemo-OpenGL

repo_name: sandeepsj/CGDemo-OpenGL


text:
# Korny's Simple Dashboard
This is a very simple html dashboard, for managing my local bookmarks.  It's all html/css/javascript, so can be hosted
very easily - in fact you can host it trivially just by copying the whole "public" directory to DropBox.

Note this will only work reliably on a modern browser - it might be OK on ie7, but really it's been tested on Chrome,
Safari and Firefox, and nowhere else.

See a working sample dashboard at: [http://kornysietsma.github.com/dashboard/](http://kornysietsma.github.com/dashboard/)

Goals:

* simple - to deploy, to edit, to understand
* fast - I could use something like the Google Desktop if I wanted lots of bells and whistles; I just want a clean set of my regularly used bookmarks
* clear - Every browser has it's own bookmarks, but they are a tiny bar at the top of the page. I want a nice visible set of pages so it's easy on the eyes, and the brain

## Hosting / Running
* Copy everything in the "public" directory to a web host, or even just a local file system.
* Open "public/dashboard.html" in a web browser.
* Enjoy!

## Editing tags
All tag data is in the file public/javascript/dashboard_data.js.  There is no server.  To edit the tags, edit the data file, and reload the browser.

One day there might be a server to host this data via a JSON api, and a UI to edit it, but so far editing json by hand has been good enough for me, and a lot less work!

*New* There are now special attributes for mobile versions (currently based on browser width - resize down to 600px and you'll see the mobile version):

* d_only = true - this tag is desktop only
* m_only = true - this tag is mobile only
* m_url - special value of url for mobile (i.e. m.delicious.com)
* m_title - special value of title for mobile (i.e. short names for small screens)

A section with no visible tags won't show up. (There is no other way to disable a section - sorry, if you are keen, fork it yourself!)

## Building the css
There is almost no "build" step in this site - but if you want to change any css, you'll need to buld the css from the base .scss files:

* install ruby - any version should do
* install Sass - see the [Sass](http://sass-lang.com) site for more, or if you have ruby and rubygems set up, "gem install haml" should do it.
* edit the scss files in views/scss
* run "./precompile.sh" to build the public/stylesheets/dashboard.css file
* or run "./watch_all.sh" which will run a background task that automatically rebuilds the css from the scss source whenever a file changes.

The dashboard.css file is checked in as a convenience - you shouldn't ever edit it directly!

## Other notes
This has grown over the years from a range of original html/css files on my local machine.
The original concept came from Ryan Allan's dashboard: https://github.com/ryan-allen/dashboard

see separate TODO.md file for future plans.

Much of this was bootstrapped from code in my [Loosely Coupled Web App Skeleton](http://github.com/kornysietsma/lcwa_skeleton) code.

repository: kornysietsma/dashboard

repo_name: kornysietsma/dashboard


text:
## 1.2

``` sh
[moonlight@ArchLinux c1]$ ./a.out <IP_ADDRESS>
^C
[moonlight@ArchLinux c1]$
```

if the host is down, the program will be blocked by the read(), else:

``` sh
[moonlight@ArchLinux c1]$ ./a.out <IP_ADDRESS>
Tue Oct 30 19:07:25 2018
```

## 1.3

``` sh
[moonlight@ArchLinux ex]$ ./a.out <IP_ADDRESS>
socket error: Address family not supported by protocol
```

errno = 97

``` sh
[moonlight@ArchLinux ex]$ grep /usr/include "supported by protocol"
grep: supported by protocol: No such file or directory
[moonlight@ArchLinux ex]$ grep "supported by protocol" -r /usr/include
/usr/include/glusterfs/compat-errno.h:#define GF_ERROR_CODE_AFNOSUPPORT    97      /* Address family not supported by protocol */
/usr/include/apr-1/apr_errno.h:#define SOCEAFNOSUPPORT         (SOCBASEERR+47)            /* Address family not supported by protocol family */
/usr/include/asm-generic/errno.h:#define	EAFNOSUPPORT	97	/* Address family not supported by protocol */
```

``` sh
man 3 socket
```

> ERRORS
       The socket() function shall fail if:

       EAFNOSUPPORT
              The implementation does not support the specified address family.

       EMFILE All file descriptors available to the process are currently open.

       ENFILE No more file descriptors are available for the system.

       `EPROTONOSUPPORT`
              The protocol is not supported by the address family, or the protocol is not supported by the implementation.

       EPROTOTYPE
              The socket type is not supported by the protocol.

       The socket() function may fail if:

       EACCES The process does not have appropriate privileges.

       ENOBUFS
              Insufficient resources were available in the system to perform the operation.

       ENOMEM Insufficient memory was available to fulfill the request.

       The following sections are informative.

## 1-4

``` sh
[moonlight@ArchLinux ex]$ ./a.out <IP_ADDRESS>
Tue Oct 30 19:39:38 2018
count = 1
```

## 1-5

``` C
servaddr.sin_port = htons(9999);

Bind(listenfd, (SA *)&servaddr, sizeof(servaddr));

Listen(listenfd, LISTENQ);

for (;;) {
    connfd = Accept(listenfd, (SA *)NULL, NULL);

    while (1) {
        memset(buff, 0, sizeof(buff));
        ticks = time(NULL);
        snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));
        Write(connfd, buff, strlen(buff));
        sleep(1);
    }

    close(connfd);
}
```

It works!
``` sh
[moonlight@ArchLinux ex]$ ./1.5c <IP_ADDRESS>
Tue Oct 30 20:59:08 2018
Tue Oct 30 20:59:09 2018
Tue Oct 30 20:59:10 2018
Tue Oct 30 20:59:11 2018
Tue Oct 30 20:59:12 2018
Tue Oct 30 20:59:14 2018
Tue Oct 30 20:59:14 2018
Tue Oct 30 20:59:16 2018
^C
[moonlight@ArchLinux ex]$ ps
  PID TTY          TIME CMD
 1934 pts/0    00:00:00 bash
11546 pts/0    00:00:00 ps
[1]+  Broken pipe             ./1.5s
[moonlight@ArchLinux ex]$
```

Broken pipe

repository: fATwaer/UNP

repo_name: fATwaer/UNP