text:
# Sumokoin

Copyright (c) 2017-2021, Sumokoin Projects

Portions Copyright (c) 2014-2021, The Monero Project

Portions Copyright (c) 2012-2013, The Cryptonote developers

## Table of Contents
  - [Development resources](#development-resources)
  - [Coverage](#coverage)
  - [Introduction](#introduction)
  - [Coin Supply & Emission](#coin-supply-&-emission)
  - [About this project](#about-this-project)
  - [License](#license)
  - [Compiling Sumokoin from source](#compiling-sumokoin-from-source)
    - [Dependencies](#dependencies)
  - [Using Tor](#using-tor)
  - [Pruning](#Pruning)
  - [Debugging](#Debugging)
  - [Known issues](#known-issues)

## Development Resources

- Web: [www.sumokoin.org](https://www.sumokoin.org)
- Mail: [contact<EMAIL_ADDRESS>
Please note that code is developed on the [dev branch](https://github.com/sumoprojects/sumokoin/tree/dev), if you want to check out the latest updates, before they are merged on main branch, please refer there. Master branch will always point to a version that we consider stable, so you can download the code by simply typing `git clone https://github.com/sumoprojects/sumokoin.git`

## Coverage

| Type         |    Status |
|--------------|-----------|
|Workflows     | [![WorkFlow Status](https://github.com/sumoprojects/sumokoin/workflows/Continuous_Integration_Testing/badge.svg)](https://github.com/sumoprojects/sumokoin/actions)

## Introduction

Sumokoin (スモコイン in Japanese) is a fork from Monero, one of the most respectable cryptocurrency well-known for **security, privacy, untraceability** and **active development**. Starting as an educational project, we found that it would be great to create a new coin with high level of privacy by (1) moving forward right away to **Ring Confidential Transactions (RingCT)**, (2) setting **minimum transaction _mixin_ to 12 (current minimum mixin set at 48)** that would greatly reduce chance of being attacked, traced or identified by (blockchain) statistical analysis.

Sumokoin, therefore, is a new Monero without its legacy, a _truely fungible_ cryptocurrency among just a few ones in the market.

## Coin Supply & Emission

- **Total supply**: **88,888,888** coins in first 20 years, then **263,000** coins each year for inflation.
About 10% (~8.8 million) was premined to reserve for future development, i.e. **80 million coins available** for community mining.
- **Coin symbol**: **SUMO**
- **Coin Units**:
  + 1 Sumoshi  = 0.000000001 **SUMO** (10-9 - _the smallest coin unit_)
  + 1 Sumokun = 0.000001 **SUMO** (10-6)
  + 1 Sumosan = 0.001 **SUMO** (10-3)
- **Hash algorithm**: CryptoNight R (cnR, CNv4) (Proof-Of-Work)
- **Emission scheme**: Sumokoin's block reward changes _every 6-months_ as the following "Camel" distribution* (inspired by _real-world mining production_ like of crude oil, coal etc. that is often slow at first,
accelerated in the next few years before declined and depleted). However, the emission path of Sumokoin is generally not far apart from what of Bitcoin (view charts below).

![](https://i.imgur.com/muvKFKg.jpg)

![](https://i.imgur.com/219P7WW.png)

![](https://i.imgur.com/UV36DfE.png)

\* The emulated algorithm of Sumokoin block-reward emission can be found in Python and C++ scripts at [scripts](scripts) directory.

## About this Project

This is the core implementation of Sumokoin. It is open source and completely free to use without restrictions, except for those specified in the license agreement below. There are no restrictions on anyone creating an alternative implementation of Sumokoin that uses the protocol and network in a compatible manner.

As with many development projects, the repository on Github is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability.

**Anyone is welcome to contribute to Sumokoin's codebase!** If you have a fix or code change, feel free to submit is as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request.

## License

Please view [LICENSE](LICENSE)

[![License](https://img.shields.io/badge/license-BSD3-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)

## Compiling Sumokoin from source

### Dependencies

The following table summarizes the tools and libraries required to build. A
few of the libraries are also included in this repository (marked as
"Vendored"). By default, the build uses the library installed on the system,
and ignores the vendored sources. However, if no library is found installed on
the system, then the vendored source will be built and used. The vendored
sources are also used for statically-linked builds because distribution
packages often include only shared library binaries (`.so`) but not static
library archives (`.a`).

| Dep          | Min. version  | Vendored | Debian/Ubuntu pkg    | Arch pkg     | Fedora              | Optional | Purpose         |
| ------------ | ------------- | -------- | -------------------- | ------------ | ------------------- | -------- | --------------- |
| GCC          | 5.4.0         | NO       | `build-essential`    | `base-devel` | `gcc`               | NO       |                 |
| CMake        | 3.5           | NO       | `cmake`              | `cmake`      | `cmake`             | NO       |                 |
| pkg-config   | any           | NO       | `pkg-config`         | `base-devel` | `pkgconf`           | NO       |                 |
| Boost        | 1.58          | NO       | `libboost-all-dev`   | `boost`      | `boost-devel`       | NO       | C++ libraries   |
| OpenSSL      | basically any | NO       | `libssl-dev`         | `openssl`    | `openssl-devel`     | NO       | sha256 sum      |
| libzmq       | 4.2.0         | NO       | `libzmq3-dev`        | `zeromq`     | `zeromq-devel`      | NO       | ZeroMQ library  |
| OpenPGM      | ?             | NO       | `libpgm-dev`         | `libpgm`     | `openpgm-devel`     | NO       | For ZeroMQ      |
| libnorm[2]   | ?             | NO       | `libnorm-dev`        |              |                     | YES      | For ZeroMQ      |
| libunbound   | 1.4.16        | YES      | `libunbound-dev`     | `unbound`    | `unbound-devel`     | NO       | DNS resolver    |
| libevent     | ?             | NO       | `libevent-dev`       | `libevent`   | `libevent-devel`    | YES      | For unbound
| libsodium    | ?             | NO       | `libsodium-dev`      | `libsodium`  | `libsodium-devel`   | NO       | cryptography    |
| libunwind    | any           | NO       | `libunwind8-dev`     | `libunwind`  | `libunwind-devel`   | YES      | Stack traces    |
| liblzma      | any           | NO       | `liblzma-dev`        | `xz`         | `xz-devel`          | YES      | For libunwind   |
| libreadline  | 6.3.0         | NO       | `libreadline6-dev`   | `readline`   | `readline-devel`    | YES      | Input editing   |
| ldns         | 1.6.17        | NO       | `libldns-dev`        | `ldns`       | `ldns-devel`        | YES      | SSL toolkit     |
| expat        | 1.1           | NO       | `libexpat1-dev`      | `expat`      | `expat-devel`       | YES      | XML parsing     |
| GTest        | 1.5           | YES      | `libgtest-dev`[1]    | `gtest`      | `gtest-devel`       | YES      | Test suite      |
| Doxygen      | any           | NO       | `doxygen`            | `doxygen`    | `doxygen`           | YES      | Documentation   |
| Graphviz     | any           | NO       | `graphviz`           | `graphviz`   | `graphviz`          | YES      | Documentation   |
| libhidapi    | ?             | NO       | `libhidapi-dev`      | `hidapi`     | `hidapi-devel`      | YES      | Hardware wallet |
| libusb       | ?             | NO       | `libusb-1.0-0-dev`   | `libusb`     | `libusbx-devel`     | YES      | Hardware wallet |
| protoc       | ?             | NO       | `protobuf-compiler`  | `protobuf`   | `protobuf-compiler` | YES      | Hardware wallet |
| libudev      | ?             | No       | `libudev-dev`        | `systemd`    | `systemd-devel`     | YES      | Hardware wallet |

[1] On Debian/Ubuntu `libgtest-dev` only includes sources and headers. You must
build the library binary manually. This can be done with the following command ```sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make && sudo mv libg* /usr/lib/ ```
[2] libnorm-dev is needed if your zmq library was built with libnorm, and not needed otherwise

Install all dependencies at once on Debian/Ubuntu:

``` sudo apt update && sudo apt install build-essential cmake pkg-config libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libldns-dev libexpat1-dev libpgm-dev qttools5-dev-tools libhidapi-dev libusb-1.0-0-dev libudev-dev libboost-chrono-dev libboost-date-time-dev libboost-filesystem-dev libboost-locale-dev libboost-program-options-dev libboost-regex-dev libboost-serialization-dev libboost-system-dev libboost-thread-dev ccache doxygen graphviz ```

Install all dependencies at once on macOS with the provided Brewfile:
``` brew update && brew bundle --file=contrib/brew/Brewfile ```

FreeBSD one liner for required to build dependencies
```pkg install git gmake cmake pkgconf boost-libs libzmq4 libsodium```

### Cloning the repository

`$ git clone https://github.com/sumoprojects/sumokoin`

### Build instructions

Sumokoin uses the CMake build system and a top-level [Makefile](Makefile) that
invokes cmake commands as needed.

#### On Linux and macOS

* Install the dependencies (see the list above)

    \- On Ubuntu, essential dependencies can be installed with the following command:

    	sudo apt update && sudo apt install build-essential cmake pkg-config libboost-all-dev libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libldns-dev libexpat1-dev doxygen graphviz libpgm-dev libhidapi-dev libusb-dev

* Change to the root of the source code directory and build:

    ```bash
    cd sumokoin
    make
    ```

    *Optional*: If your machine has several cores and enough memory, enable
    parallel build by running `make -j<number of threads>` instead of `make`. For
    this to be worthwhile, the machine should have one core and about 2GB of RAM
    available per thread.

    *Note*: The instructions above will compile the most stable release of the
    Sumokoin software. If you would like to use and test the most recent software,
    use ```git checkout master```. The master branch may contain updates that are
    both unstable and incompatible with release software, though testing is always
    encouraged.

* The resulting executables can be found in `build/release/bin`

* Add `PATH="$PATH:$HOME/sumokoin/build/release/bin"` to `.profile`

* Run Sumokoin with `sumokoind --detach`

* **Optional**: build and run the test suite to verify the binaries:

    ```bash
    make release-test
    ```

    *NOTE*: `core_tests` test may take a few hours to complete.

* **Optional**: to build binaries suitable for debugging:

    ```bash
    make debug
    ```

* **Optional**: to build statically-linked binaries:

    ```bash
    make release-static
    ```

Dependencies need to be built with -fPIC. Static libraries usually aren't, so you may have to build them yourself with -fPIC. Refer to their documentation for how to build them.

* **Optional**: build documentation in `doc/html` (omit `HAVE_DOT=YES` if `graphviz` is not installed):

    ```bash
    HAVE_DOT=YES doxygen Doxyfile
    ```

#### On the Raspberry Pi

Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (2017-09-07 or later) from https://www.raspberrypi.org/downloads/raspbian/. If you are using Raspian Jessie, [please see note in the following section](#note-for-raspbian-jessie-users).

* `apt-get update && apt-get upgrade` to install all of the latest software

* Install the dependencies for Sumokoin from the 'Debian' column in the table above.

* Increase the system swap size:

    ```bash
    sudo /etc/init.d/dphys-swapfile stop
    sudo nano /etc/dphys-swapfile
    CONF_SWAPSIZE=2048
    sudo /etc/init.d/dphys-swapfile start
    ```

* If using an external hard disk without an external power supply, ensure it gets enough power to avoid hardware issues when syncing, by adding the line "max_usb_current=1" to /boot/config.txt

* Clone sumokoin and checkout most recent release version:

    ```bash
    git clone https://github.com/sumoprojects/sumokoin.git
    cd sumokoin
    git checkout tags/v<IP_ADDRESS>
    ```

* Build:

    ```bash
    make release
    ```

* Wait 4-6 hours

* The resulting executables can be found in `build/release/bin`

* Add `PATH="$PATH:$HOME/sumokoin/build/release/bin"` to `.profile`

* Run Sumokoin with `sumokoind --detach`

* You may wish to reduce the size of the swap file after the build has finished, and delete the boost directory from your home directory

#### *Note for Raspbian Jessie users:*

If you are using the older Raspbian Jessie image, compiling Sumokoin is a bit more complicated. The version of Boost available in the Debian Jessie repositories is too old to use with Sumokoin, and thus you must compile a newer version yourself. The following explains the extra steps, and has been tested on a Raspberry Pi 2 with a clean install of minimal Raspbian Jessie.

* As before, `apt-get update && apt-get upgrade` to install all of the latest software, and increase the system swap size

    ```bash
    sudo /etc/init.d/dphys-swapfile stop
    sudo nano /etc/dphys-swapfile
    CONF_SWAPSIZE=2048
    sudo /etc/init.d/dphys-swapfile start
    ```

* Then, install the dependencies for Sumokoin except `libunwind` and `libboost-all-dev`

* Install the latest version of boost (this may first require invoking `apt-get remove --purge libboost*` to remove a previous version if you're not using a clean install):

    ```bash
    cd
    wget https://sourceforge.net/projects/boost/files/boost/1.64.0/boost_1_64_0.tar.bz2
    tar xvfo boost_1_64_0.tar.bz2
    cd boost_1_64_0
    ./bootstrap.sh
    sudo ./b2
    ```

* Wait ~8 hours

    ```bash
    sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a install
    ```

* Wait ~4 hours

* From here, follow the [general Raspberry Pi instructions](#on-the-raspberry-pi) from the "Clone sumokoin and checkout most recent release version" step.

#### On Windows:

Binaries for Windows are built on Windows using the MinGW toolchain within
[MSYS2 environment](https://www.msys2.org). The MSYS2 environment emulates a
POSIX system. The toolchain runs within the environment and *cross-compiles*
binaries that can run outside of the environment as a regular Windows
application.

**Preparing the build environment**

* Download and install the [MSYS2 installer](https://www.msys2.org), either the 64-bit or the 32-bit package, depending on your system.
* Open the MSYS shell via the `MSYS2 Shell` shortcut
* Update packages using pacman:

    ```bash
    pacman -Syu
    ```

* Exit the MSYS shell using Alt+F4
* Edit the properties for the `MSYS2 Shell` shortcut changing "msys2_shell.bat" to "msys2_shell.cmd -mingw64" for 64-bit builds or "msys2_shell.cmd -mingw32" for 32-bit builds
* Restart MSYS shell via modified shortcut and update packages again using pacman:

    ```bash
    pacman -Syu
    ```

* Install dependencies:

    To build for 64-bit Windows:

    ```bash
    pacman -S mingw-w64-x86_64-toolchain make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-openssl mingw-w64-x86_64-zeromq mingw-w64-x86_64-libsodium mingw-w64-x86_64-hidapi mingw-w64-x86_64-unbound
    ```

    To build for 32-bit Windows:

    ```bash
    pacman -S mingw-w64-i686-toolchain make mingw-w64-i686-cmake mingw-w64-i686-boost mingw-w64-i686-openssl mingw-w64-i686-zeromq mingw-w64-i686-libsodium mingw-w64-i686-hidapi mingw-w64-i686-unbound
    ```

* Open the MingW shell via `MinGW-w64-Win64 Shell` shortcut on 64-bit Windows
  or `MinGW-w64-Win64 Shell` shortcut on 32-bit Windows. Note that if you are
  running 64-bit Windows, you will have both 64-bit and 32-bit MinGW shells.

**Cloning**

* To git clone, run:

    ```bash
    git clone https://github.com/sumoprojects/sumokoin.git
    ```

**Building**

* Change to the cloned directory, run:

    ```bash
    cd sumokoin
    ```

* If you would like a specific [version/tag](https://github.com/sumoprojects/sumokoin/tags), do a git checkout for that version. eg. 'v<IP_ADDRESS>'. If you don't care about the version and just want binaries from master, skip this step:

    ```bash
    git checkout v<IP_ADDRESS>
    ```

* If you are on a 64-bit system, run:

    ```bash
    make release-static-win64
    ```

* If you are on a 32-bit system, run:

    ```bash
    make release-static-win32
    ```

* The resulting executables can be found in `build/release/bin`

* **Optional**: to build Windows binaries suitable for debugging on a 64-bit system, run:

    ```bash
    make debug-static-win64
    ```

* **Optional**: to build Windows binaries suitable for debugging on a 32-bit system, run:

    ```bash
    make debug-static-win32
    ```

* The resulting executables can be found in `build/debug/bin`

### On FreeBSD:

The project can be built from scratch by following instructions for Linux above(but use `gmake` instead of `make`).
If you are running Sumokoin in a jail, you need to add `sysvsem="new"` to your jail configuration, otherwise lmdb will throw the error message: `Failed to open lmdb environment: Function not implemented`.

### On OpenBSD:

You will need to add a few packages to your system. `pkg_add cmake gmake zeromq libiconv boost`.

The `doxygen` and `graphviz` packages are optional and require the xbase set.
Running the test suite also requires `py-requests` package.

Build sumokoin: `env DEVELOPER_LOCAL_TOOLS=1 BOOST_ROOT=/usr/local gmake release-static`

Note: you may encounter the following error, when compiling the latest version of sumokoin as a normal user:

	LLVM ERROR: out of memory
	c++: error: unable to execute command: Abort trap (core dumped)

Then you need to increase the data ulimit size to 2GB and try again: `ulimit -d 2000000`

### On NetBSD:

Check that the dependencies are present: `pkg_info -c libexecinfo boost-headers boost-libs protobuf readline libusb1 zeromq git-base pkgconf gmake cmake | more`, and install any that are reported missing, using `pkg_add` or from your pkgsrc tree.  Readline is optional but worth having.

Third-party dependencies are usually under `/usr/pkg/`, but if you have a custom setup, adjust the "/usr/pkg" (below) accordingly.

Clone the sumokoin repository and checkout the most recent release as described above. Then build sumokoin: `gmake BOOST_ROOT=/usr/pkg LDFLAGS="-Wl,-R/usr/pkg/lib" release`.  The resulting executables can be found in `build/NetBSD/[Release version]/Release/bin/`.

### On Solaris:

The default Solaris linker can't be used, you have to install GNU ld, then run cmake manually with the path to your copy of GNU ld:

	mkdir -p build/release
	cd build/release
	cmake -DCMAKE_LINKER=/path/to/ld -D CMAKE_BUILD_TYPE=Release ../..
	cd ../..

Then you can run make as usual.

### Building portable statically linked binaries

By default, in either dynamically or statically linked builds, binaries target the specific host processor on which the build happens and are not portable to other processors. Portable binaries can be built using the following targets:

* ```make release-static-linux-x86_64``` builds binaries on Linux on x86_64 portable across POSIX systems on x86_64 processors
* ```make release-static-linux-i686``` builds binaries on Linux on x86_64 or i686 portable across POSIX systems on i686 processors
* ```make release-static-linux-armv8``` builds binaries on Linux portable across POSIX systems on armv8 processors
* ```make release-static-linux-armv7``` builds binaries on Linux portable across POSIX systems on armv7 processors
* ```make release-static-linux-armv6``` builds binaries on Linux portable across POSIX systems on armv6 processors
* ```make release-static-win64``` builds binaries on 64-bit Windows portable across 64-bit Windows systems
* ```make release-static-win32``` builds binaries on 64-bit or 32-bit Windows portable across 32-bit Windows systems

### Cross Compiling

You can also cross-compile static binaries on Linux for Windows and macOS with the `depends` system.
Read more at [contrib/depends/README.md](contrib/depends/README.md)

* ```make depends target=x86_64-linux-gnu``` for 64-bit linux binaries.
* ```make depends target=x86_64-w64-mingw32``` for 64-bit windows binaries.
  * Requires: `python3 g++-mingw-w64-x86-64 wine1.6 bc`
* ```make depends target=x86_64-apple-darwin14``` for macOS binaries.
  * Requires: `cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python-dev python-pip`, and `pip install setuptools`
* ```make depends target=i686-linux-gnu``` for 32-bit linux binaries.
  * Requires: `g++-multilib bc`
* ```make depends target=i686-w64-mingw32``` for 32-bit windows binaries.
  * Requires: `python3 g++-mingw-w64-i686`
* ```make depends target=arm-linux-gnueabihf``` for armv7 binaries.
  * Requires: `g++-arm-linux-gnueabihf`
* ```make depends target=aarch64-linux-gnu``` for armv8 binaries.
  * Requires: `g++-aarch64-linux-gnu`
* ```make depends target=riscv64-linux-gnu``` for RISC V 64 bit binaries.
  * Requires: `g++-riscv64-linux-gnu`
* ```make depends target=x86_64-unknown-freebsd``` for FreeBSD 64-bit binaries.
  * Requires: `clang-8`
* ```make depends target=arm-linux-android``` for 32bit android binaries
* ```make depends target=aarch64-linux-android``` for 64bit android binaries

The required packages are the names for each toolchain on apt. Depending on your distro, they may have different names.

Using `depends` might also be easier to compile Sumokoin on Windows than using MSYS. Activate Windows Subsystem for Linux (WSL) with a distro (for example Ubuntu), install the apt `build-essentials` and follow the `depends` steps as depicted above.

The produced binaries still link libc dynamically. If the binary is compiled on a current distribution, it might not run on an older distribution with an older installation of libc. Passing `-DBACKCOMPAT=ON` to cmake will make sure that the binary will run on systems having at least libc version 2.17.

## Running sumokoind

The build places the binary in `bin/` sub-directory within the build directory
from which cmake was invoked (repository root by default). To run in
foreground:

```bash
./bin/sumokoind
```

To list all available options, run `./bin/sumokoind --help`.  Options can be
specified either on the command line or in a configuration file passed by the
`--config-file` argument.  To specify an option in the configuration file, add
a line with the syntax `argumentname=value`, where `argumentname` is the name
of the argument without the leading dashes, for example `log-level=1`.

To run in background:

```bash
    ./bin/sumokoind --log-file sumokoind.log --detach
```

To run as a systemd service, copy
[sumokoind.service](utils/systemd/sumokoind.service) to `/etc/systemd/system/` and
[sumokoind.conf](utils/conf/sumokoind.conf) to `/etc/`. The [example
service](utils/systemd/sumokoind.service) assumes that the user `sumokoin` exists
and its home is the data directory specified in the [example
config](utils/conf/sumokoind.conf).

If you're on Mac, you may need to add the `--max-concurrency 1` option to
sumo-wallet-cli, and possibly sumokoind, if you get crashes refreshing.

## Using Tor

> There is a new, still experimental, [integration with Tor](ANONYMITY_NETWORKS.md). The
> feature allows connecting over IPv4 and Tor simulatenously - IPv4 is used for
> relaying blocks and relaying transactions received by peers whereas Tor is
> used solely for relaying transactions received over local RPC. This provides
> privacy and better protection against surrounding node (sybil) attacks.

While Sumokoin isn't made to integrate with Tor, it can be used wrapped with torsocks, by
setting the following configuration parameters and environment variables:

* `--p2p-bind-ip <IP_ADDRESS>` on the command line or `p2p-bind-ip=<IP_ADDRESS>` in
  sumokoind.conf to disable listening for connections on external interfaces.
* `--no-igd` on the command line or `no-igd=1` in sumokoind.conf to disable IGD
  (UPnP port forwarding negotiation), which is pointless with Tor.
* `DNS_PUBLIC=tcp` or `DNS_PUBLIC=tcp://x.x.x.x` where x.x.x.x is the IP of the
  desired DNS server, for DNS requests to go over TCP, so that they are routed
  through Tor. When IP is not specified, sumokoind uses the default list of
  servers defined in [src/common/dns_utils.cpp](src/common/dns_utils.cpp).
* `TORSOCKS_ALLOW_INBOUND=1` to tell torsocks to allow sumokoind to bind to interfaces
   to accept connections from the wallet. On some Linux systems, torsocks
   allows binding to localhost by default, so setting this variable is only
   necessary to allow binding to local LAN/VPN interfaces to allow wallets to
   connect from remote hosts. On other systems, it may be needed for local wallets
   as well.
* Do NOT pass `--detach` when running through torsocks with systemd, (see
  [utils/systemd/sumokoind.service](utils/systemd/sumokoind.service) for details).
* If you use the wallet with a Tor daemon via the loopback IP (eg, <IP_ADDRESS>:9050),
  then use `--untrusted-daemon` unless it is your own hidden service.

Example command line to start sumokoind through Tor:

```bash
DNS_PUBLIC=tcp torsocks sumokoind --p2p-bind-ip <IP_ADDRESS> --no-igd
```

### Using Tor on Tails

TAILS ships with a very restrictive set of firewall rules. Therefore, you need
to add a rule to allow this connection too, in addition to telling torsocks to
allow inbound connections. Full example:

```bash
    sudo iptables -I OUTPUT 2 -p tcp -d <IP_ADDRESS> -m tcp --dport 19734 -j ACCEPT
    DNS_PUBLIC=tcp torsocks ./sumokoind --p2p-bind-ip <IP_ADDRESS> --no-igd --rpc-bind-ip <IP_ADDRESS> \
        --data-dir /home/amnesia/Persistent/your/directory/to/the/blockchain
```

## Pruning

As of June 2021, The full Sumokoin blockchain file is on about 22 GB. One can store a pruned blockchain, which is **less than one
fourth** in size from the full blockchain size (June 2020 4.6 GB).
A pruned blockchain can only serve part of the historical chain data to other peers, but is otherwise identical in
functionality to the full blockchain.
To use a pruned blockchain, it is best to start the initial sync with --pruned-blockchain. However, it is also possible
to prune an existing blockchain using the sumo-blockchain-prune tool or using the --pruned-blockchain sumokoind option
with an existing chain. If an existing chain exists, pruning will temporarily require disk space to store both the full
and pruned blockchains.

# Debugging

This section contains general instructions for debugging failed installs or problems encountered with Sumokoin. First, ensure you are running the latest version built from the Github repo.

### Obtaining stack traces and core dumps on Unix systems

We generally use the tool `gdb` (GNU debugger) to provide stack trace functionality, and `ulimit` to provide core dumps in builds which crash or segfault.

* To use `gdb` in order to obtain a stack trace for a build that has stalled:

Run the build.

Once it stalls, enter the following command:

```bash
gdb /path/to/sumokoind `pidof sumokoind`
```

Type `thread apply all bt` within gdb in order to obtain the stack trace

* If however the core dumps or segfaults:

Enter `ulimit -c unlimited` on the command line to enable unlimited filesizes for core dumps

Enter `echo core | sudo tee /proc/sys/kernel/core_pattern` to stop cores from being hijacked by other tools

Run the build.

When it terminates with an output along the lines of "Segmentation fault (core dumped)", there should be a core dump file in the same directory as sumokoind. It may be named just `core`, or `core.xxxx` with numbers appended.

You can now analyse this core dump with `gdb` as follows:

```bash
gdb /path/to/sumokoind /path/to/dumpfile
```

Print the stack trace with `bt`

 * If a program crashed and cores are managed by systemd, the following can also get a stack trace for that crash:

```bash
coredumpctl -1 gdb
```

#### To run sumokoin within gdb:

Type `gdb /path/to/sumokoind`

Pass command-line options with `--args` followed by the relevant arguments

Type `run` to run sumokoind

### Analysing memory corruption

There are two tools available:

#### ASAN

Configure Sumokoin with the -D SANITIZE=ON cmake flag, eg:

```bash
cd build/debug && cmake -D SANITIZE=ON -D CMAKE_BUILD_TYPE=Debug ../..
```

You can then run the Sumokoin tools normally. Performance will typically halve.

#### valgrind

Install valgrind and run as `valgrind /path/to/sumokoind`. It will be very slow.

### LMDB

Instructions for debugging suspected blockchain corruption as per @HYC

There is an `mdb_stat` command in the LMDB source that can print statistics about the database but it's not routinely built. This can be built with the following command:

```bash
cd ~/sumokoin/src/lmdb/db_drivers/liblmdb && make
```

The output of `mdb_stat -ea <path to blockchain dir>` will indicate inconsistencies in the blocks, block_heights and block_info table.

The output of `mdb_dump -s blocks <path to blockchain dir>` and `mdb_dump -s block_info <path to blockchain dir>` is useful for indicating whether blocks and block_info contain the same keys.

These records are dumped as hex data, where the first line is the key and the second line is the data.

# Known Issues

## Protocols

### Socket-based

Because of the nature of the socket-based protocols that drive sumokoin, certain protocol weaknesses are somewhat unavoidable at this time. While these weaknesses can theoretically be fully mitigated, the effort required (the means) may not justify the ends. As such, please consider taking the following precautions if you are a sumokoin node operator:

- Run `sumokoind` on a "secured" machine. If operational security is not your forte, at a very minimum, have a dedicated a computer running `sumokoind` and **do not** browse the web, use email clients, or use any other potentially harmful apps on your `sumokoind` machine. **Do not click links or load URL/MUA content on the same machine**. Doing so may potentially exploit weaknesses in commands which accept "localhost" and "<IP_ADDRESS>".
- If you plan on hosting a public "remote" node, start `sumokoind` with `--restricted-rpc`. This is a must.

### Blockchain-based

Certain blockchain "features" can be considered "bugs" if misused correctly. Consequently, please consider the following:

- When receiving sumokoin, be aware that it may be locked for an arbitrary time if the sender elected to, preventing you from spending that sumokoin until the lock time expires. You may want to hold off acting upon such a transaction until the unlock time lapses. To get a sense of that time, you can consider the remaining blocktime until unlock as seen in the `show_transfers` command.

repository: sumoprojects/sumokoin

repo_name: sumoprojects/sumokoin


text:
# NetDagGlobals

## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**Kind** | **string** | Kind of entity | [optional] [default to null]
**Name** | **string** | Name of entity | [optional] [default to null]
**RoundRobinMode** | **string** | Specifies whether the round robin disaggregator (DAG) on a blade can disaggregate packets to all the TMMs in the system or only to the TMMs local to the blade. The default value is global, meaning all TMMs in the system. | [optional] [default to null]

[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
## Introduction

We use GitOps to continuously deliver application changes

[Argo CD](https://argoproj.github.io/argo-cd/) is a declarative, GitOps continuous delivery tool for Kubernetes. The deployment environment is a namespace in a container platform.

Argo CD models a collection of applications as a project and uses a Git repository to store the application's desired state.

Argo CD is flexible in the structure of the application configuration represented in the Git repository.

Argo CD supports defining Kubernetes manifests in a number of ways:

- helm charts
- kustomize
- ksonnet
- jsonnet
- plain directory of yaml/json manifests
- custom plugins

Argo CD compares the actual state of the application in the cluster with the desired state defined in Git and determines if they are out of sync. When it detects the environment is out of sync, Argo CD can be configured to either send out a notification to kick off a separate reconciliation process or Argo CD can automatically synchronize the environments to ensure they match.

**Terminology:**

Argo CD uses a number of terms to refer to the components:

- Application: A deployable unit
- Project: A collection of applications that make up a solution


text:
---
layout: default
---

# 1996-07-03 - Re: Ken Bass: Wire tap only useful for conviction (Was: SAFE Forum--some  comments)

## Header Data

From: Michael Froomkin<EMAIL_ADDRESS>To: Ernest Hua<EMAIL_ADDRESS>Message Hash: 91779590f33c3486b572c1b0c8170584279c51a438ce9b1c1a942ac816e2b246

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1996-07-03 17:28:14 UTC

Raw Date: Thu, 4 Jul 1996 01:28:14 +0800

## Raw message

```
{% raw  %}From: Michael Froomkin<EMAIL_ADDRESS>Date: Thu, 4 Jul 1996 01:28:14 +0800
To: Ernest Hua<EMAIL_ADDRESS>Subject: Re: Ken Bass: Wire tap only useful for conviction (Was: SAFE Forum--some  comments)
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

On Tue, 2 Jul 1996, Ernest Hua wrote:

>
> > And here I'll comment on Ken Bass's excellent comments (there were many
> > excellent points).
> >
> > He pointed out that the driving force for crypto policy is probably the
> > _law enforcement_ camp, not the _intelligence agency_ camp.
>
> Ken pointed out that law enforcement had to have gotten enough
> evidence prior to a wire tap request to show probable cause.
> If this is the case, then the only usefulness of wire taps is
> to improve the likelihood of conviction and not the detection
> of potential terrorist (or child molestation or your favorite
> bad guy) plots.

I thought Ken Bass was wrong on this point (I agreed with everything else
he said): wiretaps help LEOs identify co-conspirators.  They are not
without intelligence value.

[This message may have been dictated with Dragon Dictate 2.01.
Please be alert for unintentional word substitutions.]

A. Michael Froomkin        | +1<PHONE_NUMBER>; +1<PHONE_NUMBER> (fax)
Associate Professor of Law |
U. Miami School of Law     |<EMAIL_ADDRESS>P.O. Box 248087            | http://www.law.miami.edu/~froomkin
Coral Gables, FL 33124 USA | It's hot here.  And humid.

{% endraw %}
```

## Thread

+ Return to [July 1996](/archive/1996/07)

+ Return to "[Ernest Hua <hua@XENON.chromatic.com>](/authors/ernest_hua_hua_at_xenon_chromatic_com_)"
+ Return to "[Jeff Davis <eagle@armory.com>](/authors/jeff_davis_eagle_at_armory_com_)"
+ Return to "[Michael Froomkin <froomkin@law.miami.edu>](/authors/michael_froomkin_froomkin_at_law_miami_edu_)"
+ Return to<EMAIL_ADDRESS>(Timothy C. May)](/authors/tcmay_at_got_net_timothy_c_may_)"
+ Return to "["Vladimir Z. Nuri" <vznuri@netcom.com>](/authors/vladimir_z_nuri_vznuri_at_netcom_com_)"

+ 1996-07-03 (Wed, 3 Jul 1996 09:30:05 +0800) - [SAFE Forum--some comments](/archive/1996/07/6cdf322a5deec1f45d0f0926eae5b41afcb90d0a07364b47b9bd3709eb99de71) -<EMAIL_ADDRESS>(Timothy C. May)_
  + 1996-07-03 (Wed, 3 Jul 1996 09:20:35 +0800) - [Re: SAFE Forum--some comments](/archive/1996/07/84bd4b399632660b395bdbc1cb6df87d58972fd4f659347fc11ba943bb15a998) - _"Vladimir Z. Nuri"<EMAIL_ADDRESS>    + 1996-07-03 (Wed, 3 Jul 1996 22:17:11 +0800) - [Re: SAFE Forum--some comments](/archive/1996/07/3147b03a31af62da8b6a9ac14a0a719da74ebb5ce8f967b4fed411cfebc37672) - _Jeff Davis<EMAIL_ADDRESS>  + 1996-07-03 (Wed, 3 Jul 1996 12:49:59 +0800) - [Ken Bass: Wire tap only useful for conviction (Was: SAFE Forum--some comments)](/archive/1996/07/13398e652f532cd67db8f74a55e6a3c49997938ae5202907785183369ac70547) - _Ernest Hua<EMAIL_ADDRESS>    + 1996-07-03 (Thu, 4 Jul 1996 01:28:14 +0800) - Re: Ken Bass: Wire tap only useful for conviction (Was: SAFE Forum--some  comments) - _Michael Froomkin<EMAIL_ADDRESS>  + 1996-07-03 (Wed, 3 Jul 1996 20:02:51 +0800) - [Re: SAFE Forum--some comments](/archive/1996/07/f0e9f5e1a99e5b9fb55667297d20faf041aedc7dd2d96d81d8be4395abd9b584) - _Jeff Davis<EMAIL_ADDRESS>

license: MIT

gha_license_id: MIT


text:
# [Nervos CKB](https://www.nervos.org/) - The Common Knowledge Base

[![Version](https://img.shields.io/badge/version-0.112.0--pre-orange.svg)](https://github.com/nervosnetwork/ckb/releases)
[![Nervos Talk](https://img.shields.io/badge/discuss-on%20Nervos%20Talk-3CC68A.svg)](https://talk.nervos.org/t/where-to-discuss-ckb-and-how-to-ask-for-support/6024)

master | develop
-------|----------
[![Unit Tests](https://github.com/nervosnetwork/ckb/actions/workflows/ci_unit_tests_ubuntu.yaml/badge.svg?branch=master)](https://github.com/nervosnetwork/ckb/actions/workflows/ci_unit_tests_ubuntu.yaml?query=branch%3Amaster) | [![Unit Tests](https://github.com/nervosnetwork/ckb/actions/workflows/ci_unit_tests_ubuntu.yaml/badge.svg?branch=develop)](https://github.com/nervosnetwork/ckb/actions/workflows/ci_unit_tests_ubuntu.yaml?query=branch%3Adevelop)
[![Integration Tests](https://github.com/nervosnetwork/ckb/actions/workflows/ci_integration_tests_ubuntu.yaml/badge.svg?branch=master)](https://github.com/nervosnetwork/ckb/actions/workflows/ci_integration_tests_ubuntu.yaml?query=branch%3Amaster) | [![Integration Tests](https://github.com/nervosnetwork/ckb/actions/workflows/ci_integration_tests_ubuntu.yaml/badge.svg?branch=develop)](https://github.com/nervosnetwork/ckb/actions/workflows/ci_integration_tests_ubuntu.yaml?query=branch%3Adevelop)

---

## About CKB

CKB is a public and permissionless layer-1 blockchain. CKB uses [Proof of Work](https://en.wikipedia.org/wiki/Proof-of-work_system) and [improved Nakamoto consensus](https://medium.com/nervosnetwork/breaking-the-throughput-limit-of-nakamoto-consensus-ccdf65fe0832) to achieve maximized performance on average hardware and network bandwidth, without sacrificing layer-1's core values - decentralization and security.

CKB supports scripting in any programming language with its own [CKB-VM](https://github.com/nervosnetwork/ckb-vm/), a virtual machine fully compatible with RISC-V ISA.
CKB is a [Universal Verification Layer](https://medium.com/nervosnetwork/https-medium-com-nervosnetwork-cell-model-7323fca57571) which focuses on verification, leaves computation to layer 2 (and higher) applications/protocols.

[CKB](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0002-ckb/0002-ckb.md) is a part of [Nervos Network](https://www.nervos.org), which defines [a suite of scalable and interoperable blockchain protocols](https://github.com/nervosnetwork/rfcs) to create a self-evolving distributed economy.

Support for different platforms are organized into [three tiers](docs/platform-support.md), each with a different set of guarantees.

**Notice**: The ckb process will send stack trace to sentry on Rust panics. This is enabled by default before the mainnet launch, which can be opted out by setting
the option `dsn` to empty in the config file.

## License [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fnervosnetwork%2Fckb.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fnervosnetwork%2Fckb?ref=badge_shield)

Nervos CKB is released under the terms of the MIT license. See [COPYING](COPYING) for more information or see [https://opensource.org/licenses/MIT](https://opensource.org/licenses/MIT).

## Join a Network

- Mainnet Mirana: Use the [latest release](https://github.com/nervosnetwork/ckb/releases/latest) and run `ckb init --chain mainnet` to initialize the node.
    - Mirana is active since the epoch 5414, see the [migration guide](https://github.com/jordanmack/nervos-ckb2021-hard-fork-migration-guide) to upgrade from Lina.
- Testnet Pudge: Use the [latest release](https://github.com/nervosnetwork/ckb/releases/latest) and run `ckb init --chain testnet` to initialize the node.
    - Pudge is active since the epoch 3113.

See more networks to join in the [wiki](https://github.com/nervosnetwork/ckb/wiki/Chains).

## Mining

CKB uses the [Eaglesong](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0010-eaglesong/0010-eaglesong.md) mining algorithm.

## Development Process

The `master` branch is regularly built and tested. It is considered already production ready; The `develop` branch is the work branch to merge new features, and it's not stable. The CHANGELOG is available in [Releases](https://github.com/nervosnetwork/ckb/releases) and [CHANGELOG.md](https://github.com/nervosnetwork/ckb/blob/master/CHANGELOG.md) in the `master` branch.

## How to Contribute

The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md), and security policy is described in [SECURITY.md](SECURITY.md). To propose new protocol or standard for Nervos, see [Nervos RFC](https://github.com/nervosnetwork/rfcs).

---

## Documentations

[Latest version](https://github.com/nervosnetwork/ckb#documentations) is hosted in GitHub.

The default branch in GitHub is `develop`, if you are looking for docs for the
Mainnet Mirana or Testnet Pudge, switch to the branch [master].

[master]: https://github.com/nervosnetwork/ckb/tree/master#documentations

- [Quick Start](docs/quick-start.md)
- [Configure CKB](docs/configure.md)
- [Platform Support](docs/platform-support.md)
- [How to Download or Build CKB Binary](https://docs.nervos.org/docs/basics/guides/get-ckb)
- [How to Download or Build CKB Binary on Windows](https://docs.nervos.org/docs/basics/guides/ckb-on-windows)

You can find a more comprehensive document website at [https://docs.nervos.org](https://docs.nervos.org).

repository: nervosnetwork/ckb

branch_name: refs/heads/develop

gha_language: Rust

repo_name: nervosnetwork/ckb


text:
# Snake
Snake is a common video game where the player maneuvers a line which
grows in length, with the line itself being a primary obstacle. The
player controls a square and as it moves forward, it leaves behind a
trail, resembling a moving snake. The player attempts to eat items by
running into them with the head of the snake. Each item eaten makes the
snake longer so controlling it is progressively more difficult.

# Getting Started
To get a copy of this game onto your local machine, simply click the
*clone* button at the top of the page and follow the prompts thereafter.

## Prerequisites
This game requires Python to be installed for it to run. To install
Python, click [here](https://www.python.org/downloads/).

# Usage
From a terminal, navigate into the project directory.
```
$ cd snake/src
```
To run the game:
```
$ python snake.py
```
The arrow keys on the keyboard are then used to control the snake.

# Contributing
Please read [HOW_TO_CONTRIBUTE.md](https://github.com/eric-mahasi/snake/blob/master/HOW_TO_CONTRIBUTE.md) for details on submitting pull
requests.

# License
This project is licensed under the MIT license - see the [LICENCE.md](https://github.com/eric-mahasi/snake/blob/master/LICENSE.md)
for details.

# Acknowledgements
This project was inspired by
[Jody LeCompte](https://github.com/jodylecompte/)'s amazing tutorial
which can be found [here](https://medium.com/@jodylecompte/code-your-first-game-in-pygame-5585dfcc6388).

repository: eric-mahasi/snake

repo_name: eric-mahasi/snake


text:
# glum

[![styled with prettier](https://img.shields.io/badge/styled_with-prettier-ff69b4.svg)](https://github.com/prettier/prettier)
[![Travis](https://img.shields.io/travis/com/nebrelbug/glum/master.svg)](https://travis-ci.com/nebrelbug/glum)
[![Coveralls](https://img.shields.io/coveralls/nebrelbug/glum.svg)](https://coveralls.io/github/nebrelbug/glum)
[![Dev Dependencies](https://img.shields.io/david/dev/nebrelbug/glum)](https://david-dm.org/nebrelbug/glum?type=dev)
[![Donate](https://img.shields.io/badge/donate-paypal-blue.svg)](https://paypal.me/bengubler)

**Summary**

glum is a super lightweight Enum library that makes use of Symbols to achieve type-safety.

_What if my environment doesn't support ES6?_

If you're in a browser, use a polyfill.
If you're running in Node, chances are that Symbols are supported: they're supported in all versions after 5.12.0.

**Why use Glum?**

- Type-safety. When you declare an Enum, members are unique and can't be mimicked by strings, numbers, etc.
- Allows for passing in polyfills
- Don't reinvent the wheel

## :scroll: Docs

### Installation

```
npm install glum
```

Or, if in a browser,

```
<script crossorigin src="https://cdn.jsdelivr.net/npm/glum"></script>
```

[Note: this will create a global variable called Glum]

### Usage

We distribute a UMD build, so you can use it with ES modules, CommonJS, AMD, or in the browser

```js
import Enum from 'glum'
// or var Enum = require 'glum'

let FRUIT = new Enum('APPLE', 'ORANGE', 'PEAR')

function nameFruit (fruit) {
  if ((fruit = FRUIT.APPLE)) {
    console.log("It's an apple")
  }
}

console.log(FRUIT.getName(FRUIT.APPLE)) // APPLE
```

### API

#### `new Enum(... enumNames, [symbolPolyfill])`

Create a new Enum.
_Ex._ `let fruits = new Enum("APPLE", "ORANGE", "PEAR")`
_Ex. with polyfill_ `let fruits = new Enum("APPLE", "ORANGE", "PEAR", function(name) {return '@@\_Symbol:' + name})`

#### `Enum.has(member)`

Check if a member is part of an enum. **Note:** this will primarily be used to accept function parameters, variables, etc. that must be a member of a certain enum.
_Ex._

```js
let fruits = new Enum('APPLE', 'ORANGE', 'PEAR')
fruits.has(fruits.APPLE) // true
fruits.has(fruits.HI) // false
```

#### `Enum.getName(member)`

Get the name of an enum member. **Note:** this is usually used to get the name of an Enum member passed as a parameter, variable, etc.
_Ex._

```js
let fruits = new Enum('APPLE', 'ORANGE', 'PEAR')
fruits.getName(fruits.APPLE) // "APPLE"
```

## :heavy_check_mark: Tests

Tests can be run with `npm test`. Multiple tests check that things return expected results, formatting follows guidelines, and code coverage is at the expected level.

## Projects using `glum`

Create an issue to add yours!

## Credits

Made with :heart: by [@nebrelbug](https://github.com/nebrelbug) and all these wonderful contributors ([emoji key](https://github.com/kentcdodds/all-contributors#emoji-key)):

<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->
<!-- prettier-ignore -->
<!-- ALL-CONTRIBUTORS-LIST:END -->

This project follows the [all-contributors](https://github.com/kentcdodds/all-contributors) specification. Contributions of any kind are welcome!

repository: nebrelbug/glum

gha_language: TypeScript

repo_name: nebrelbug/glum


text:
# Distribution-cheatsheet
A lookup repo for a variety of distributions (implemented in Python).
***

## Distribution Characteristics
The characteristics of each distribution are seperated into the following paragraphs:
1. Definition & Formula
2. Parameter
3. Implementation in Python
4. Inference of Parameter

## Overview
The following distributions are (or will be) implemented in this repository:
- [Beta Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Beta%20Distribution.ipynb)
- [Binomial Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Binomial%20Distribution.ipynb)
- [Cauchy Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Cauchy%20Distribution.ipynb)
- [Chi-Squared Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Chi-Squared%20Distribution.ipynb)
- F Distribtution
- Gamma Distribution
- [Geometric Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Geometric%20Distribution.ipynb)
- [Hypergeometric Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Hypergeometric%20Distribution.ipynb)
- [Normal Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Normal%20Distribution.ipynb)
- [Poisson Distribution](https://github.com/jgoerner/distribution-cheatsheet/blob/master/notebooks/Poisson%20Distribution.ipynb)
- T Distribution


text:
# :gear:{.blink} iCub HW Documentation
First draft of iCub HW documentation.

### Main HW Repositories
- [Mechanical CAD Libraries](https://github.com/icub-tech-iit/cad-libraries)
- [Mechanical CAD](https://github.com/icub-tech-iit/cad-mechanics-public)
- [Electronics Boards](https://github.com/icub-tech-iit/electronics-boards-public)
- [Wiring Schematics](https://github.com/icub-tech-iit/electronics-wiring-public)

## [The iCub Versions Table](./icub_versions/index.md)
[iCub Versions Table](./icub_versions/index.md) is a table containing the current known iCub versions.

## [The iCub Wiring](./icub_wiring/index.md)
[iCub Wiring](./icub_wiring/index.md) contains the documentation about the Logic and Harness schematics of iCub

## [iCub Tendons](./icub_tendons/index.md)
[iCub Tendons](./icub_tendons/index.md) contains the ultimate step-by-step guide on how to replace broken or out of place tendons of the iCub. It includes also some tutorials on how to build forearms and the overall tendons constituting iCub.

## [The Upgrade Kits](./upgrade_kits/index.md)
The design of our robot evolves in time. We have been asking ourselves how to propagate the mechanical or hardare enhancements we design to older robots. Our solution is to define upgrade kits that can be applied to specific robots.

An [upgrade kit](./upgrade_kits/index.md) is a plastic bag with mechanical parts, hardware boards, screws, wires, tendons and whatever it is required to perform a physical upgrade of the robots, including the instructions.

## [iCub Kinematics](./icub_kinematics/index.md)
Here you can find informations about iCub's kinematics.

## [iCub 3](./icub3/icub3-joints.md)
Here are described the elctrical and mechanical specifications for each joint.

## [Hands](./hands/index.md)
Here's reported info about the hands installed on the robots.

## [iCub CPU boards](./icub_cpu_boards/icub_cpu_boards.md)
Here's reported info about CPU boards installed on iCub.

## [F/T Sensors](./ft_sensors/index.md)
Here's reported info about `F/T sensors`.

## [Custom components](./custom_components/custom_components.md)
Here's reported info about `third-party custom components`.

repository: fiorisi/documentation

repo_name: fiorisi/documentation


text:
group theory: convergent markov chains.

## Experiment:

A) have each state transition to 1 state, 100% probability

B) have each state transition to 3 states, split probability.

C) have each state transition to 3 states and noise, 30/30/30 10% noise (random other)

D) have the intelligence broach new states which can
alter the probabilities for the next state or subsequent states.

## First Experiment

We have an extensible expectation matrix, and
a return ratio for the investment in the correct
guess.

## Cap on Stored Energy as incentive to forward plan
One has the option to place saved energy (stored energy from the multiplier) in future, we may introduce a handle
which caps or progressively taxes higher energy states.

basically we can start with a cap, which creates incentive for forward investment after a certain level (as this is permanently stored energy if it is correct).

(In life higher energy levels can make one volatile.)

## Details of first experiment/Spec

Monte Carlo exploration (like random flash cards for vocabulary), then creative reconstruction.

At first you have bins/states, option 1, option 2, and noise.  the number of non-noise options needs to incur some cost or energy (perhaps checking these takes time, and time takes energy), and creating an incentive to reduce the number of top possibilities.

At first we can maybe have 7 such states, and a noise category.  At first when a state is added, it has a high probability, so introduction to the topic is really important.  Rejecting probabilites one way to accomplish will be to decrease the probability of transitions to these states, which incurs energy/memory allocation/cost.

Reducing the chance of noise is also interesting, so this makes the result dependent on traning set.

## Spec Spec

7 bins 8 noise. when a new state is introduced in stage 1,
we have a simple collection of probability and a chance to filter out noise by weighting tried and true guesses to stay on board, and shucking the lower probabilities to the noise bin (if noise bin reaches a certain probability, then we increase the number of tracked states).

we can actually scale up from 1 possibility, and experiment with starting at 2 or 3, to reduce the overhead from having to expand the matrix due to inevitable noise from multiple probable outcomes.

algorithm for that, start out with if probability of noise is over 70% (resetting trials to being 20 long) then we expand the possibilities by 1.  If the probability of noise is lower than 10% then we may attempt to reduce the possibilities by 1.

There is also a balance between breadth and depth, and the effective use of energy for future plans.  Let us make a decision  (can test this later) not to explore implications of noise (can explore this later).  Limiting this to only the probable outcomes, then we will lose energy by doing more breath even if a small probability designates small piece of the pie.  We can weed out those bins which do not pay off after a certain amount of trials.

## high risk high reward modelling

Right now all possibilities are being treated as equal, but in reality some paths are more high stakes than others.

How to model this.. hmm, perhaps certain paths can lead to more depth with less breadth, we can model this by having tdifferent ambiguity for different states (3 paths + random vs 1 path + random, vs 1 path period).

This way you can save energy in the long run by betting probablistically disproportional amounts on these low probability outcomes.

This might become important as we introduce broaching, since one can potentially take part in reducing the alternate possibilities and planning very far ahead, by "betting" on broaches which will narrow the possibilities, and prepare routes as well towards ameliorating your broaches with the hiprobable results.

## Goal: convergence with global mastery.

The goal is not only to have all of the associations, but to match as closely as possible the global markov matrix.

### Rules for broaching, hanging state introduced

needs to be resolved, blocks the continuation of state until a route connects this state with the current transition.

How does it's transition probability's alter the next state?

it is a marriage of the broached word's probability with the interlocutor's next probability.

The other bin might have a large percentage, then the conversation can crash.

1) Broached word first associations alone to a connection to next topic (6 degrees).

2) Broached word with context associations, permutations of markov chains with the words in the topic, and finding a route/path between the broached word and the target state.  This is used typically for seeing if you're on the same thread.

3) Under a "Lens" might be including the "Lens" word/topic/Markov-Matrix as a first filter for the subsequent associations.

4) learning the rhythm (the operator/operator-combination) for transitioning states, is important as well for keeping on the same thread.


text:
# Notes on Kubernetes

## What is Kubernetes?
["...container-focused cluster management thing"](http://kamalmarhubi.com/blog/2015/08/27/what-even-is-a-kubelet/)

## Why I care about Kubenetes
* For distributed data analytics using [Dask](http://docs.dask.org/en/latest/) in the cloud
* The basic workflow I'd like to master are
	1. Create a cluster in the cloud
	2. Using Dask, offload data preprocessing on cluster
	3. Scale up/down cluster according to needs
* The services I'll need to do this are
	1. Google Kubernetes Engine for creating the Kubernetes cluster
	2. Helm for package management in Kubernetes

## FAQs
* What lives inside a pod? Containers (e.g. Docker)
* How many containers can live in a pod? Any number, but usually just two
* Where do pods live? In a node
* What is a node? A physical or virtual machine (e.g. in GCP, a VM instance)
* How many pods can live in a node? Any number, but constrained by number of cores and memory available in the node

## Resources to Learn
* [A few things I've learned about Kubernetes by Julia Evans](https://jvns.ca/blog/2017/06/04/learning-about-kubernetes/)
	* Contains good references for beginners
	* See section on "__Kubernetes from the ground up__"
* [Kubernetes BootCamp](https://kubernetesbootcamp.github.io/kubernetes-bootcamp/)
* [The Illustrated Childrens Guide to Kubernetes](https://cdn.chrisshort.net/The-Illustrated-Childrens-Guide-to-Kubernetes.pdf)
* [Managing Containers at Scale with CoreOS and Kubernetes by Kelsey Hightower](https://www.youtube.com/watch?v=pozC9rBvAIs)

repository: palpen/ProgrammingNotes

repo_name: palpen/ProgrammingNotes


text:
# Installation

## Dependencies

Java 1.8+ (OpenJDK 8 or higher)

!(only for install via docker) [Docker](https://docs.docker.com/install/) 18.09.1+

## Quick Install

(Applicable in Linux, Mac, and Windows)

* Step 1: Download the latest version of [geoweaver.jar](https://github.com/ESIPFed/Geoweaver/releases/download/latest/geoweaver.jar)

* Step 2: Run the command:

```shell
java -jar geoweaver.jar
```

* Step 3: Open browser and enter: http://localhost:8070/Geoweaver/ .That's it!

## Build from source

Use maven to build. In the command line go to the root folder and execute `mvn install`. After a success build, the Geoweaver jar package will be under the directory: `Geoweaver/target/Geoweaver-<version>.jar`.

## Install using Docker

* Step 1: Install Docker Desktop if you haven't (please refer to [Get Docker](https://docs.docker.com/get-docker/)).

* Step 2: Pull geoweaver image using command:

`docker pull jensensun/geoweaver`

* Step 3: Run geoweaver using command:

`docker run -t -i -v <YOUR_HOME_DIRECTORY>:/home/marsvegan/ -p 8070:8070 jensensun/geoweaver`

> *What is going on?* : `-v <YOUR_HOME_DIRECTORY>:/home/marsvegan/` is for mounting your current home directory into the docker containers. `marsvegan` is the user name within geoweaver containers. `-p 8070:8070` maps the port so you can access Geoweaver from your browser. `jensensun/geoweaver` is the published docker image url in DockerHub.

> *Tip*: You can create an alias so next time you won't copy and paste such a long command:

`alias geoweaver="docker run -t -i -v <YOUR_HOME_DIRECTORY>:/home/marsvegan/ -p 8070:8070 jensensun/geoweaver"`

Then start it by simply typing:

`geoweaver`

* Step 4: Open web browser and input `http://localhost:8070/Geoweaver`. Geoweaver should show up in a sec. That is it!

## Reset Password for Localhost

Geoweaver will automatically create a password for localhost. It will only show once at first run of Geoweaver. It is recommended to copy and save it at a safe place. If forget or missed that password, please run the following command to reset:

```
java -jar geoweaver.jar resetpassword
```

If you used `Docker`, use the following command:

```
docker run -t -i -v <YOUR_HOME_DIRECTORY>:/home/marsvegan/ -p 8070:8070 jensensun/geoweaver resetpassword
```

## [Set up HTTP Proxy](http-proxy.md)

repository: aulenbac/Geoweaver

repo_name: aulenbac/Geoweaver


text:
[![Build Status](https://travis-ci.org/MattesGroeger/MGBenchmark.png?branch=master)](https://travis-ci.org/MattesGroeger/MGBenchmark) [![Coverage Status](https://coveralls.io/repos/MattesGroeger/MGBenchmark/badge.png)](https://coveralls.io/r/MattesGroeger/MGBenchmark)

## Introduction

Easily measure code execution times. This is especially interesting for load operations that are difficult to profile with [Instruments](http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html).

### Features

* Measure total execution times
* Measure individual steps of execution
* Find steps that take longest
* Get the average execution time of all steps
* Have multiple benchmark sessions at the same time
* Use macros for easy usage
* Implement custom output targets
* Measure times across different threads (thread-safe)

## Installation via CocoaPods

- Install CocoaPods. See [http://cocoapods.org](http://cocoapods.org)
- Add the MGBenchmark reference to the Podfile:
```
    platform :ios
    	pod 'MGBenchmark'
    end
```

- Run `pod install` from the command line
- Open the newly created Xcode Workspace file
- Implement your commands

## Quick Guide

The quickest way is to use the provided macros. They give you the basic console log functionality with very little code. The benchmark will only work when `DEBUG` is set.

```obj-c
#import "MGBenchmark.h"

MGBenchStart(@"Test");

// code to measure

MGBenchStep(@"Test", @"1"); // << BENCHMARK [Test/1] 0.01s (step 1) >>

// code to measure

MGBenchStep(@"Test", @"2"); // << BENCHMARK [Test/2] 0.01s (step 2) >>
MGBenchEnd(@"Test"); // << BENCHMARK [Test/total] 0.02s (2 steps, average 0.01s) >>
```

That's it. For most cases that should be enough. However if you want to customize the output that's possible as well.

## Class methods

The aforementioned macros use the following class methods under the hood:

```obj-c
[MGBenchmark start:@"demo"]; // start measuring

// code to measure

[[MGBenchmark session:@"demo"] step:@"1"]; // << BENCHMARK [demo/1] 0.01s (step 1) >>

// code to measure

[[MGBenchmark session:@"demo"] step:@"2"]; // << BENCHMARK [demo/2] 0.01s (step 2) >>
[[MGBenchmark session:@"demo"] total]; // << BENCHMARK [demo/total] 0.02s (2 steps, average 0.01s) >>

[MGBenchmark finish:@"demo"]; // garbage collect
```

Nevertheless `[MGBenchmark start:@"foo"]` returns an instance as well:

```obj-c
MGBenchmarkSession *session = [MGBenchmark start:@"demo"];

[session step:@"1"];
[session step:@"2"];
[session total];

[MGBenchmark finish:@"demo"]; // garbage collect
```

## Live Environment

You can keep the benchmark code integrated even in the live environment. But rather then logging to the console, you should send the results [to a tracking database](#custom-output-target). Or set the target to `nil` to ignore the results.

```objc
#if DEBUG
[MGBenchmark setDefaultTarget:[[MGConsoleOutput alloc] init]]; // log to console
#elif RELEASE
[MGBenchmark setDefaultTarget:[[FlurryTarget alloc] init]]; // send to server
#else
[MGBenchmark setDefaultTarget:nil]; // ignore results
#endif
```

## Customizing the Logs

There are different ways to customize the benchmark results:
* Directly use the results
* Customize the default target
* Choose another pre-defined target
* Implement your own output target

### Using Results Directly

You can easily create your own console logs. For that you should disable the default console output:

```obj-c
[MGBenchmark setDefaultTarget:nil];
```

Then you can use the return values of `step:` and `total` to do your custom logging:

```obj-c
MGBenchmarkSession *benchmark = [MGBenchmark start:@"custom"];

// code to measure

<EMAIL_ADDRESS>[benchmark step:@"sleep1"]); // 1.01s

// code to measure

<EMAIL_ADDRESS>[benchmark step:@"sleep2"]); // 2.01s
```

You can also access the amount of steps as well as the average execution times:

```obj-c
<EMAIL_ADDRESS>(steps: %d | average: %d)", [benchmark total], benchmark.stepCount, benchmark.averageTime); // 3.03s (steps: 2 | average: 2.02s)
```

### Customize the Default Target MGConsoleOutput

The provided console target is very customizable. You can configure the output by providing strings containing placeholders. The available placeholders differ for the `step:` and `total` benchmark:

**Step**
```
${sessionName}
${stepName}
${passedTime}
${stepCount}
```

**Total**
```
${sessionName}
${passedTime}
${stepCount}
${averageTime}
```

You can also change the measured time format. By changing the multiplier you can get measured times in milliseconds for example:

```obj-c
MGConsoleOutput *output = [[MGConsoleOutput alloc] init];
output.timeMultiplier = 1000; // to get ms rather than seconds
output.timeFormat = @"%.3fms"; // with 3 digits after comma
output.stepFormat = @"${stepName}: ${passedTime}";
output.totalFormat = @"total: ${passedTime}";

[MGBenchmark setDefaultTarget:output];

id session = [MGBenchmark start:@"demo"];
[session step:@"step1"]; 	// step1: 0.004ms
[session step:@"step2"]; 	// step2: 0.320ms
[session step:@"step3"]; 	// step3: 0.298ms
[session total]; 			// total: 0.884ms
[MGBenchmark finish:@"demo"];
```

### MGConsoleSummaryOutput

Use this target to find steps that take longest. When using the `total` method it will print out all individual steps ordered by time.

Using...

```obj-c
[MGBenchmark setDefaultTarget:[[MGConsoleSummaryOutput alloc] init]];
```

... will result in these logs:

```
<< BENCHMARK [demo/total] 4.00138s (3 steps, average 1.33379s) >>
<< BENCHMARK 2.00084s (50.0%) step2 >>
<< BENCHMARK 1.00039s (25.0%) step1 >>
<< BENCHMARK 1.00010s (25.0%) step3 >>
```

You can customize this target as well ([see the example code](https://github.com/MattesGroeger/MGBenchmark/blob/master/MGBenchmarkExample/ViewController.m)).

### Custom Output Target

If you want to use a different output format, the best way is to define a custom target. For that you need to implement the `MGBenchmarkTarget` protocol. It declares 3 methods which are all optional:

* `passedTime:forStep:inSession` – called for step time benchmark
* `totalTime:inSession` – called for total time benchmark

Here is an example that sends the total benchmark to [Flurry](http://www.flurry.com/flurry-analytics.html). Note that you need to initialize Flurry beforehand.

```obj-c
@interface FlurryTarget : NSObject <MGBenchmarkTarget>
@end
```

```obj-c
@implementation FlurryTarget

- (void)totalTime:(NSTimeInterval)passedTime inSession:(MGBenchmarkSession*)session
{
	[Flurry logEvent:session.name withParameters:@{
		@"totalTime": [NSString<EMAIL_ADDRESS>passedTime],
		@"steps": @(session.stepCount),
		@"averageStepTime": [NSString<EMAIL_ADDRESS>session.averageTime]
	}];
}

@end
```

Use your custom output target:

```obj-c
// set the default output for all sessions
[MGBenchmark setDefaultTarget:[[FlurryTarget alloc] init]]];
```

## Changelog

**0.3.0** (2014/01/17)

* [NEW] Macros for easier usage (Thanks [Nano](https://github.com/workwithnano))
* [CHANGED] Simplified output target session handling (no need to store session)

**0.2.0** (2013/03/28)

* [NEW] `MGBenchmark` is now thread-safe
* [NEW] `MGBenchmarkTarget` protocol methods are optional now
* [NEW] `MGConsoleSummaryOutput` for sorted step times (what takes longest?)

**0.1.1** (2013/03/24)

* [BUGFIX] More fault-tolerant (doesn't use NSAssert anymore)

**0.1.0** (2013/03/24)

* [NEW] Measure total execution times
* [NEW] Measure individual steps of execution
* [NEW] Get the average execution time of all steps
* [NEW] Have multiple benchmark sessions at the same time
* [NEW] Implement custom output targets

## Contribution

This library is released under the [MIT licence](http://opensource.org/licenses/MIT). Contributions are more than welcome!

Also, follow me on Twitter if you like: [@MattesGroeger](https://twitter.com/MattesGroeger).

repository: javenl/JsonReciprocity

repo_name: javenl/JsonReciprocity


text:
---
title: Empty state
category: Principles
---

Always provide instructions in an empty UI area on how to make it not empty. Instructions help users understand what the area is for and how to work with it.
Empty UI areas described here are:
* [Tool window, list, tree or table](#tool-windows-lists-trees-and-tables)
* [Detail area in a master-detail layout](#master-detail-layout)
* Empty search results — TBD

[comment]: <> (TODO: add link to Textual Output)

## Tool windows, lists, trees and tables
Instructions text for these UI areas has three parts:
![]({{site.baseurl}}/images/empty_state/database-tw-callouts.png)

How to use these parts:

### 1. Reason why empty
* Required part. The reason explains what the area is for and the current state of the area.
* General pattern is “_No [entity] added._”
  * The verb: in the end of the reason text, write the action that is needed to fill the UI area. It shows that the UI area can be filled by the user and not by an external system. If _added, created, configured_ or other such verbs are synonyms in a particular case, prefer the verb _added_ for consistency.
  * End the reason text with a dot.
![]({{site.baseurl}}/images/empty_state/libraries-before-after.png)
*Avoid ”Nothing to show”, not informative.*

* The entity can be elaborated:
![]({{site.baseurl}}/images/empty_state/tasks-before-launch.png)
*“Tasks to run before launch” better explains what the area is for than just “Tasks”.*

* The entity should be clear to users:
![]({{site.baseurl}}/images/empty_state/sql-dialect-before.png)
*The word mapping introduces a new entity while there are already two in the table header — path and SQL dialect. In the instructions, it is better to use already existing entities to connect them to what users see on the screen.*
![]({{site.baseurl}}/images/empty_state/sql-dialect-after.png)
*The word “individual” is used in contrast with the project SQL dialect above the table. The verb specified is used instead of added because, in the table, SQL dialects are not added but selected from a drop-down list in the SQL Dialect column.*

### 2. Actions to make the area not empty
* Required part. Makes easier to understand what action to start with, compared to searching for a necessary icon on a toolbar. Educates about a shortcut.
* Use one or two actions. Three and more would make it harder to choose what to start from.
![]({{site.baseurl}}/images/empty_state/maven-tw.png)
*Instructions with two actions.*

* Pattern: “[Action link] [(Shortcut)]”. Do not add a dot after an action. If two actions, put a comma between them.

* Use sentence style for an action. This is against the general recommendation but here an action appears as a part of a text paragraph and title-capitalization would disrupt reading.

* Wording:
  * Avoid words that describe physical actions like _press_ and _click_ — they are already understood from how the link element works.
  * Avoid “_add new_”. Use just add because all that is added is new in the context of an empty UI area.

* If an action opens a popup, open it at the same position where it would be opened with a corresponding toolbar button. This would explain what toolbar icon opens the popup.

* If an action that fills an empty area cannot be tied to a link, explain what to do. Treat the explanation text as a usual text, both for wording and syntax:
![]({{site.baseurl}}/images/empty_state/todo-tw.png)
*TODO items are actually detected not by the word “TODO” in a comment but by the regexp pattern specified in the settings. The instruction text should be formatted as “...write [first pattern from settings] in a source code comment” to account for a rare case when the default pattern has been redefined.*

### 3. Help topic
* Optional part.

* **For tool windows**, provide if there is a help topic that explains the concept and the whole set of functionality behind it, like a “Getting started” topic. Show as a link to the topic with the question mark icon in the beginning:
![]({{site.baseurl}}/images/empty_state/database-tw-segment.png)

* **For tables, trees and lists**, provide according to [these rules]({{site.baseurl}}/principles/context_help). Show as a help tooltip or as an inline text. Compared to complex tool windows, smaller UI areas rarely require in-depth explanation. A short help text should be enough and it does not require switching contexts.
![]({{site.baseurl}}/images/empty_state/todo-filters-incorrect.png)
*Do not use a help topic link in a table and UI areas other than tool windows.*
![]({{site.baseurl}}/images/empty_state/todo-filters-correct.png)
*Place an inline help text under the table. See the Context help topic for where to show help for other UI elements and layouts.*

## Master-detail layout
* Instructions text for the detail area in a master-detail layout has only the action part.

   The detail area is filled when an item is selected in the master part. This behavior is too familiar to be explained — the reason why the area is empty is not needed.

   The action is an obvious one but it serves as a visual marker to where settings for the selected item appear.

   The help topic, if needed, can be provided in the master area.

* The general pattern for the action is “_Select_ [entity] _to configure_”.

* The master area is usually a list or a tree, and if empty, its instructions text should follow the guidelines for lists and trees.

![]({{site.baseurl}}/images/empty_state/app-servers.png)

![]({{site.baseurl}}/images/empty_state/run-configs.png)
*The link “Add Java application configuration” is a shortcut to creating a new configuration instead of clicking the + button in the toolbar. See more on actions below.*

## Layout and colors
* Minimum text width — 40 characters. If an area is too narrow to show the minimum text width, show text in area fields. And if no fields left, then under area borders.

* Use non-breaking spaces in an action name and shortcut, so it does not break in two lines.

* Grey text color #999999, both for light themes and Darcula.

* The link should be the non-underlined kind (see example of such link in the Settings dialog, the topmost node “Appearance & Behavior”).

* The text is center-aligned. If possible, the center for the help topic link should be calculated with an 11 px inset on the left. This helps visually aligning the help link with the lines above it.
![]({{site.baseurl}}/images/empty_state/database-tw-markup1.png)

* Fields and vertical spaces:
![]({{site.baseurl}}/images/empty_state/database-tw-markup2.png)

* The text should wrap when a UI area’s width changes:
![]({{site.baseurl}}/images/empty_state/database-tw-horizontal.png)
![]({{site.baseurl}}/images/empty_state/database-tw.png)

In Darcula:
![]({{site.baseurl}}/images/empty_state/database-tw-darcula.png)

repository: Bhanditz/ui

repo_name: Bhanditz/ui


text:
# Excel-Matrix-Rewrite (aka pySAP-Security)
Code written to replace VBA code.  Looks up items in CSVs based on user input.
# Requirements
Requires Python 3.7.  Other versions may work, but this was our development environment.
It is not Python 2 compatable.
# Instructions
Move the sample data folders where you want, but you must document the location in the main code.
There is a data structure called a 'Company', and this structure must contain this information.
If you want to work with your own data, you must maintain this.
# Future Plans
0. Make code PEP-8 compliant.
1. Combine SAP production and SAP single approvers into one menu.
2. Make a .ini file to house company specific information (moving data out of code).

(Program is expected to be depricated by the end of 2019.  Replaced by internal SAP (GRC) automation.)

repository: joefriedrich/Excel-Matrix-Rewrite

gha_language: Python

repo_name: joefriedrich/Excel-Matrix-Rewrite


text:
---
layout: default
---

# 1997-04-10 - Information Systems Security Board

## Header Data

From: John Young<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 785dfce0938aa6926397ca60801d518f2152b728fcf3ff6a238b23de676799d0

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1997-04-10 11:16:35 UTC

Raw Date: Thu, 10 Apr 1997 04:16:35 -0700 (PDT)

## Raw message

```
{% raw  %}From: John Young<EMAIL_ADDRESS>Date: Thu, 10 Apr 1997 04:16:35 -0700 (PDT)
To<EMAIL_ADDRESS>Subject: Information Systems Security Board
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

On December 13, 1996, representatives from The National
Information Infrastructure (NII) Task Force of The President's
National Security Telecommunications Advisory Committee
(NSTAC) held a meeting at Steptoe & Johnson in Washington, D.C.
to discuss industry interest in developing an industry-run
Information Systems Security Board (ISSB).

Stewart Baker of Steptoe & Johnson discussed the antitrust laws
and their application to the meeting, with particular emphasis on
the need to avoid discussion of competitive conditions and to show
openness to all interested participants.

Guy Copeland, a representative from the Task Force, briefly
discussed the ISSB model and the purposes of the meeting. Will
Ozier, Chairman of the GSSP Committee, next discussed the efforts
of the Generally Accepted System Security Principles (GSSP) project.

Several representatives from the Administration expressed support
for the concept of the ISSB. These representatives also indicated
that the Administration would like private industry to take the
lead in this area and is more than willing to take "a back seat"
to such an effort. These representatives did request for periodic
updates on any industry driven initiative in this area.

-----

For full report and links to background documents:

   http://jya.com/issb.htm

Thanks to RH.

{% endraw %}
```

## Thread

+ Return to [April 1997](/archive/1997/04)

+ Return to "[John Young <jya@pipeline.com>](/authors/john_young_jya_at_pipeline_com_)"

+ 1997-04-10 (Thu, 10 Apr 1997 04:16:35 -0700 (PDT)) - Information Systems Security Board - _John Young<EMAIL_ADDRESS>


text:
---
layout: post
title: Apple Keynote treatment and storyboard template
description: Apple Keynote theme for film treatments and storyboards, in 2.39:1 (Scope) aspect ratio
date: '2018-09-17T10:21:39+02:00'
categories:
- Templates
---

{% include gumroad-overlay.html id="scope-treatment" %}

This is a paginated Apple Keynote theme for film treatments and storyboards, in 2.39:1 (Scope) aspect ratio. This theme has 12 master slides ready for print or screen use. It has a title page, an intro page, three frames + text, six frames variations plus an icon master.

Get this film treatment and storyboard theme


text:
---
title: Grouping
page_title: Grouping
description: Check our "Grouping" documentation article for the RadDataServiceDataSource {{ site.framework_name }} control.
slug: raddataservicedatasource-grouping
tags: grouping
published: True
position: 5
---

# Grouping

__WCF Data Services__ do not support grouping. For consistency reasons, grouping criteria is simply converted to sorting criteria by __RadDataServiceDataSource__.

So for example, if you group by country, you will still get a flat list of all cities, but they will be ordered according to their country. If you group a __RadGridView__ that is bound to a __RadDataServiceDataSource__, __RadDataServiceDataSource__ will order the data on the server and bring it back, but the actual grouping will be performed by __RadGridView__ on the client.

repository: telerik/xaml-docs

gha_language: JavaScript

gha_license_id: NOASSERTION

repo_name: telerik/xaml-docs


text:
## About Laravel

Laravel is a web application framework with expressive, elegant syntax. We believe development must be an enjoyable and creative experience to be truly fulfilling. Laravel takes the pain out of development by easing common tasks used in many web projects, such as:

- [Simple, fast routing engine](https://laravel.com/docs/routing).
- [Powerful dependency injection container](https://laravel.com/docs/container).
- Multiple back-ends for [session](https://laravel.com/docs/session) and [cache](https://laravel.com/docs/cache) storage.
- Expressive, intuitive [database ORM](https://laravel.com/docs/eloquent).
- Database agnostic [schema migrations](https://laravel.com/docs/migrations).
- [Robust background job processing](https://laravel.com/docs/queues).
- [Real-time event broadcasting](https://laravel.com/docs/broadcasting).

Laravel is accessible, powerful, and provides tools required for large, robust applications.

# Tests
*My first steps in this framework.*

This site was built using YouTube channel: [Hilos de Fuego](https://www.youtube.com/channel/UCm-g2KbMuqYgLU15wz0JYWg).

## First tests
```
It's very simple, using UIkit instead of Bootstrap.
```
![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/secondTest.png)

## Second tests
```
Well, two days after, I made litle changes, and already preparing things for the CRUD.
```
![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/thirdTest.png)

## Third tests?
```
I add new registers in the DB (MySQL), and are of my YouTube videos channel !
```
![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/fourthTest.png)

# CRUD

*Okay, trying to be a good developer, I explain what is a CRUD. Is the acronym of Create, Read, Update and Delete.
I developed a CRUD with Laravel because I'm studying this framework actually.*

###### *Create*
```
First, I created a href to go the create new register's page.
```
![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/crud_img/C-1.png)

```
Then, you can see the form, with title and embed link input.
```
![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/crud_img/C-2.png)

###### *Read*
```
Okay, to start with, I tell you that it already brings the information from MySQL automatically,
but it can also be viewed individually. Selecting "See it!" in the options.
```

![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/crud_img/R-1.png)

```
Then, you'll see the video you selected before.
```

![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/crud_img/R-2.png)

###### *Update*
```
You remind the options we saw in the first "Read" image?
If you'll select "Edit" option, other view will load.
```
In this, all the values attributes of "input" come from MySQL database, and you can edit these and update.

![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/crud_img/U-1.png)

###### *Delete*
```
Don't move from that page!
In it, if you go below from the above, you'll find
the video that has been selected, and below, the option to delete it.
```

![testImage](https://raw.githubusercontent.com/Jasa-Hollow/Laravel_test/main/crud_img/D-1.png)

## License

The Laravel framework is open-sourced software licensed under the [MIT license](https://opensource.org/licenses/MIT).

branch_name: refs/heads/main

gha_language: PHP


text:
# News app

Go application that reads RSS feeds defined in `data/data.json` and provides all on one HTML page.

## Preparation

1. Go must have been installed

## Build

Switch to the folder in which this file resides and call

```bash
go build
```

## Run

```bash
./newsapp
```

Point your browser to http://localhost:8080.

## Docker

To create a Docker image:

```bash
docker build -t windsource/newsapp .
```

To run the image

```bash
docker run -p 8080:8080 windsource/newsapp
```

repository: windsource/newsapp

repo_name: windsource/newsapp


text:
# Tock Overview

Tock is a secure, embedded operating system for Cortex-M microcontrollers.
While it could potentially be ported to other architectures, its current
design and implementation assumes a Cortex-M that has a memory protection
unit (MPU). Systems without an MPU cannot simultaneously support untrusted
processes and retain Tock's safety and security properties. The Tock
kernel and its extensions (called *capsules*) are written in Rust.

Tock can run multiple, independent untrusted processes written in
any language. The number of processes Tock can simultaneously support
is constrained by MCU flash and RAM. The Tock scheduler is preemptive and
uses a round-robin policy. Tock uses a microkernel architecture: complex
drivers and services are often implemented as untrusted processes, which
other processes, such as applications, can invoke through inter-process
commmunication (IPC).

This document gives an overview of Tock's architecture, the different
classes of code in Tock, the protection mechanisms it uses, and how this
structure is reflected in the software's directory structure.

## Tock Architecture

![Tock architecture](architecture.png)

The above Figure shows Tock's architecture. Code falls into one of three
categories: the *core kernel*, *capsules*, and *processes*.

The core kernel and capsules are both written in Rust. Rust is a
type-safe systems language; other documents discuss the language and
its implications to kernel design in greater detail, but the
key idea is that Rust code can't use memory differently than intended
(e.g., overflow buffers, forge pointers, or have pointers to dead
stack frames). Because these restrictions prevent many things that
an OS kernel has to do (such as access a peripheral that exists at a
memory address specified in a datasheet), the very small core kernel
is allowed to break them by using "unsafe" Rust code. Capsules,
however, cannot use unsafe features. This means that the core kernel
code is very small and carefully written, while new capsules added
to the kernel are safe code and so do not have to be trusted.

Processes can be written in any language. The kernel protects itself and
other processes from bad process code by using a hardware memory
protection unit (MPU). If a process tries to access memory it's not
allowed to, this triggers an exception. The kernel handles this exception
and kills the process.

The kernel provides four major system calls:

  * command: makes a call from the process into the kernel
  * subscribe: registers a callback in the process for an upcall from the kernel
  * allow: gives kernel access to memory in the process
  * yield: suspends process until after a callback is invoked

Every system call except yield is non-blocking. Commands that
might take a long time (such as sending a message over a UART)
return immediately and issue a callback when they complete.
The yield system call blocks the process until a callback
is invoked; userland code typically implements blocking
functions by invoking a command and then using yield to wait
until the callback completes.

The command, subscribe, and allow system calls all take a driver
ID as their first parameter. This indicates which driver in the
kernel that system call is intended for. Drivers are capsules that
implement the system call

## Tock Memory Map

Tock is intended to run on Cortex-M microcontrollers, which have
non-volatile flash memory (for code) and RAM (for stack and data) in a
single address space. While the Cortex-M architecture specifies a
high-level layout of the address space, the exact layout of Tock can
differ from board to board. Most boards simply define the beginning and
end of flash and SRAM in their `layout.ld` file and then include the
[generic Tock memory map](../boards/kernel_layout.ld).

Tock's memory has three major regions: kernel code, process code, and
RAM: For the SAM4L, these are laid out as follows. This allocation assumes
the SAM4L which has 512kB of flash and 64kB of RAM:

| Region  | Start Address | Length |
| ------- | ------------- | ------ |
| kernel  | 0x00000000    |  192kB |
| process | 0x00030000    |  320kB |
| RAM     | 0x20000000    |   64kB |

So Tock allocates 192kB of flash for kernel code and 320kB of flash for
appliation code.

### Kernel code

The kernel code is split into two major regions, `.text` which holds the
vector table, program code, initialization routines, and other read-only data.
This section is written to the beginning of flash.

This is immediately followed by the `.relocate` region, which holds values the
need to exist in SRAM, but have non-zero initial values that Tock copies from
flash to SRAM as part of its initialization (see [Startup](Startup.md)).

### Process code

Processes can either be statically compiled into a Tock image,
or dynamically loaded onto the microcontroller. The symbol `_sapps`
denotes the start of the process code section. The process code section
has one or more process code blocks in it; the kernel defines a static
limit for how many processes can be supported. Imix, for example, currently
supports two processes. This is a static number so that the kernel does
not have to dynamically allocate memory.

The first word of a process code block is the length of the block. So the
first word of the process code section is the length of the code of the
first process (including this size field). If the length is zero, there is
no process. So on boot, the kernel checks the length at `_sapps`, if it is
non-zero, loads the process code there, then checks the length at `_sapps`
plus the length of the first process. This continues until it finds a
length of zero or it reaches the maximum number of processes.

| contents |       size     |
| -------- | ---------------|
|  length  | (4 bytes)      |
|   code   | (length bytes) |
|  length  | (4 bytes)      |
|   code   | (length bytes) |

Note that this means a linker script needs to set the first unused word
of the application code region to 0; otherwise, if there is uncleared flash
memory the kernel might conclude there are applications there.

### RAM

RAM contains four major regions:

* kernel data (initialized memory, copied from flash at boot),
* kernel BSS (uninitialized memory, zeroed at boot),
* the kernel stack,
* process memory.

## Tock Directory Structure

Tock has seven principal code directories.

The *arch* directory stores architecture-specific code. I.e., code that
is Cortex-M0 and Cortex-M4 specific. This includes code for performing
context switches and making system calls (trapping from user code to
kernel code).

The *boards* directory contains code for specific Tock platforms, such as
the imix, the Firestorm, and the nrf51dk. This is typically the structure
that defines all of the capsules the kernel has, the code to configure the
MCU's IO pins into the proper states, initializing the kernel and loading
processes. The principal file in this directory is `main.rs`, and the
principal initialization function is `reset_handler` (which executes
when the MCU resets). The board code also defines how system call device
identifiers map to capsules, in the `with_driver` function.

The *capsules* directory contains MCU-independent kernel extensions that
can build on top of chip-specific implementations of particular peripherals.
Some capsules provide system calls. For example, the `spi` module in capsules
builds on top of a chip's SPI implementation to provide system calls on
top of it.

The *chips* directory contains microcontroller-specific code, such as the
implementations of SPI, I2C, GPIO, UART, and other microcontroller-specific
code. The distinction between chips and boards is the difference between
a microcontroller and a full platform. For example, many microcontrollers
have multiple UARTs. Which UART is the principal way to communicate with
Tock, or which is used to control another chip, is defined by how the chip
is placed on board and which pins are exposed. So a chip provides the UART
implementation, but a board defines which UART is used for what.

The *extern* directory contains external code that is not part of the Tock
operating system, such as the Rust compiler.

The *kernel* directory contains microcontroller-independent kernel code,
such as the scheduler, processes, and memory management. This directory
and arch are were where all core kernel code reside.

The *tools* directory are associated tools to help in compilation and
code maintenance, such as checking code formatting, converting binaries,
and build scripts.

The *userland* directory contains process code, including example
applications, userland drivers, and the userland system call functions
that translate friendly API calls such as `led_on(int led_num)` into
underlying system calls such as `command(DRIVER_NUM_LEDS, 0, led_num)`.

repository: frenicth/tock

repo_name: frenicth/tock


text:
# GUI
This section will go into details about GUI elements in Valheim. For a tutorial on how to create one, check [here](../../tutorials/overview.md).

## List of all Valheim Sprites
See the [list of all Sprites currently in the game](sprite-list.md).

branch_name: refs/heads/dev

gha_language: C#


text:
# Mango-Pineapple Sorbet

## Ingredients
 * 5 cups (24 oz.) frozen mangoes, thawed (3 cups after thawing)
 * 3 tablespoons lime juice
 * 1/2 cup sugar
 * 1 cup unsweetened pineapple juice

## Directions
Puree mangoes with lime juice and sugar in blender or food
processor. Place in a large bowl. Add pineapple juice; mix with a
whisk until blended. Cover; refrigerate 30 minutes.
Start ice cream maker and pour mango mixture through hole in lid.
Churn 20—40 minutes or until desired consistency.

license: ISC

repository: stevenharradine/Recipes

repo_name: stevenharradine/Recipes


text:
# 🧭 ExploreRxSwift

**ExploreRxSwift** is a Swift implementation of [kaushikgopal's](https://github.com/kaushikgopal) [RxJava Android Samples](https://github.com/kaushikgopal/RxJava-Android-Samples), as well as collection of additional examples of RxSwift in action. Hope is to make this a great resource for Swift developers new to ReactiveX by demonstrating its benefits with simple use cases. For those with more experience, **ExploreR** will try to document potential pitfalls and other do's and (maybe) don’ts.

### Cold launch
- Official documentation on [ReactiveX website](http://reactivex.io/intro.html)
- [Missing Guide](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754) by [staltz](https://github.com/staltz)
- [Is RxSwift for me?](https://academy.realm.io/posts/tryswift-Marin-Todorov-I-create-iOS-apps-is-RxSwift-for-me/) by [icanzilb](https://github.com/icanzilb)
- [Basics of RxSwift in 10 Minutes](https://medium.com/ios-os-x-development/learn-and-master-%EF%B8%8F-the-basics-of-rxswift-in-10-minutes-818ea6e0a05b) by [SebastianBoldt](https://github.com/SebastianBoldt)

### Colab guide
Share your experience by opening a [pull request](/pulls).


text:
# Pier3
Pier3 is a content management system (CMS) written in Smalltalk, official site is: http://www.piercms.com/. It relies on the Seaside webserver (http://www.seaside.st), and uses Magritte and Pillar as its model. This version has been tested only in Pharo (https://pharo.org).

This is a port of the code to Github, instructions on loading are: http://www.myborden.com/pier/john-c-borden/smalltalk/pier/loading-with-gofer

This can be loaded from Pharo 7 by running this in a workspace:
```
Metacello new
  baseline:'PierCore';
  repository: 'github://Pier-CMS/Pier3:master/repository';
  onConflictUseLoaded;
  load.
```
A more complete system with extra goodies can be loaded with:
```
Metacello new
  baseline:'PierAddons';
  repository: 'github://Pier-CMS/Pier3:master/repository';
  onConflictUseLoaded;
  load.
```