text:
# Assignment 1 - 3 Container Application

- Run `nginx`, `mysql`, `httpd` (apache) servers
- Detach all of them and give them all a name.
- Port mappings
    - nginx: 80:80
    - httpd: 8080:80
    - mysql: 3306:3306
- Use `--env` to generate a random root password for the mysql instance in the
  mysql container. Use `docker container logs` to get that password.
- Use docker container stop and docker container rm to clean up afterward.
- Use docker container ls to show that everything is cleaned up.

license: Unlicense

repository: AustinTSchaffer/Docker-Certification

gha_language: JavaScript

gha_license_id: Unlicense

repo_name: AustinTSchaffer/Docker-Certification


text:
---
title: Home
page_id: "home.00"
---

##  Small but Powerful and Efficient

TreeFrog Framework is a high-speed and full-stack C++ framework for developing Web applications, which supports HTTP and WebSocket protocol.

Web applications can run faster than that of scripting language because the server-side framework was written in C++/Qt. In application development, it provides an O/R mapping system and template systems on an MVC architecture, aims to achieve high productivity through the policy of  convention over configuration.

##  Features

  1. High performance - Highly optimized Application server engine of C++.
  2. O/R mapping  - Conceals complex and troublesome database accesses
  3. Template system  - ERB-like template engine adopted
  4. Supported databases  - MySQL, MariaDB, PostgreSQL, ODBC, MongoDB, Redis, Memcached, etc.
  5. WebSocket support  - Providing full-duplex communications channels
  6. Generator  - Generates scaffolds, Makefiles and vue.js templates
  7. Various response types  - JSON, XML and CBOR
  8. Multi-platform  - Same source code can work on Windows, macOS and Linux
  9. OSS  - New BSD License

##  Selecting TreeFrog Framework

It is said that there is a trade-off relationship between development efficiency and operation speed in web application development, is it really true?

There is not such a thing. it is possible to develop efficiently by providing convenient development tools and excellent libraries from the framework and by specifying specifications to minimize the configuration file.

In recent years, cloud computing has emerged, the importance of Web applications is increasing year by year. Although it is known that the execution speed of the script language decreases as the amount of code increases, C++ language can operate at the fastest speed with a small memory footprint and does not decrease execution speed even as the amount of code increases.

Multiple application servers running in scripting language can be aggregated into one without degrading performance.
Try TreeFrog Framework which combines high productivity and high speed operation!

##  News

Mar. 26, 2023
### TreeFrog Framework version 2.7.1 (stable) release New!

  - Fix a bug of opening shared memory KVS.
  - Modified to reply NotFound when it can not invoke the action.

  [ Download this version](/en/download/)

Feb. 25, 2023
### TreeFrog Framework version 2.7.0 (stable) release

  - Fix possibility of thread conflicting when receiving packets.
  - Changed hash algorithm to HMAC of SHA3.
  - Added Memcached as session store.
  - Updated malloc algorithm of TSharedMemoryAllocator.
  - Updated system logger.
  - Performance improvement for pooling database connections.

Jan. 21, 2023
### TreeFrog Framework version 2.6.1 (stable) release

 - Fix a bug of outputting access log.
 - Added a link option for LZ4 shared library on Linux or macOS.

Jan. 2, 2023
### TreeFrog Framework version 2.6.0 (stable) release

 - Implemented in-memory KVS for cache system.
 - Added a link option for Glog shared library.
 - Fix bugs of macros for command line interface.
 - Updated LZ4 to v1.9.4.

Nov. 1, 2022
### TreeFrog Framework version 2.5.0 (stable) release

 - Implemented flushResponse() function to continue the process after sending a response.
 - Updated glog to v0.6.0
 - Performance improvement for redis client.
 - Implemented memcached client. [Experimental]
 - Implemented a cache-store for memcached, TCacheMemcachedStore class.

Aug. 13, 2022
### TreeFrog Framework version 2.4.0 (stable) release

 - Implemented memory store for cache.
 - Updated Mongo C driver to v1.21.2.

May 28, 2022
### TreeFrog Framework version 2.3.1 (stable) release

 - Fix compilation errors on Qt 6.3.

 [ All changelogs](https://github.com/treefrogframework/treefrog-framework/blob/master/CHANGELOG.md)

##  Support Development

TreeFrog Framework is New BSD licensed open source project and completely free to use. However, the amount of effort needed to maintain and develop new features for the project is not sustainable without proper financial backing. We accept donations from sponsors and individual donors via the following methods:

 - Donation with [PayPal ](https://www.paypal.me/aoyamakazuharu)
 - Become a [sponsor in GitHub](https://github.com/sponsors/treefrogframework)
 - BTC Donation. Address: [12C69oSYQLJmA4yB5QynEAoppJpUSDdcZZ]({{ site.baseurl }}/assets/images/btc_address.png "BTC Address")

I would be pleased if you could consider donating. Thank you!

##  Wanted

 - Developers, testers, translators.

Since this site is built with [GitHub Pages](https://pages.github.com/), translations can also be sent by a pull-request.
Visit [GitHub](https://github.com/treefrogframework/treefrog-framework){:target="_blank"}. Welcome!

##  Information

[TreeFrog forum ](https://groups.google.com/forum/#!forum/treefrogframework){:target="_blank"}

Twitter [@TreeFrog_ja ](https://twitter.com/TreeFrog_ja){:target="_blank"}

[Docker Images ](https://hub.docker.com/r/treefrogframework/treefrog/){:target="_blank"}

[Benchmarks ](https://www.techempower.com/benchmarks/){:target="_blank"}

repository: treefrogframework/treefrog-framework

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: treefrogframework/treefrog-framework


text:
# Experiment Utility
Contains utility classes for generating description files for experiments and reading such descriptions to a simple model.

*Note:* The reader uses [yet another tree structure](https://github.com/gt4dev/yet-another-tree-structure) by gt4dev, slightly modified by adding another method for adding a child.

## Generators
The package `generators` currently contains two kinds of file generators which are executed without arguments. The parameters for file generation are specified in a command-line dialogue.\
Please see folder `examples/exampleResults` for an example of generated output files.

### Balanced Latin Square Generator
This generator takes two arguments:
* `number of possible conditions`: The resulting table will contain condition identifiers from `1` up to this number.
* `name of file`: Where the resulting table will be saved. If not already in name, it will be extended with `.txt` automatically.

The result will be a balanced latin square, as defined here:
> Martyn Shuttleworth (May 8, 2009). Counterbalanced Measures Design. Retrieved Dec 05, 2020 from Explorable.com: https://explorable.com/counterbalanced-measures-design

For odd numbers of conditions, the mirrored extension is automatically applied.

### Random Square Generator
This generator takes following arguments:
* `seed`: Arbitrary integer number for the pseudo-random number generator used for all files created in this execution.
* `number of rows`: In all of the created files.
* `number of columns`: In all of the created files.
* `number of possible conditions`: The resulting table will contain condition identifiers from `1` up to this number.
* `number of files`: All are randomly generated using the same pseudo-random number generator.
* `name of file`: Starting name of all files which is extended by the number and extension `.txt` automatically.

## Reader
The package `reader` offers an `ExperimentReader` class to parse a folder of description files into a model of simple Java objects which can be found in the package `common`.

### Model
The classes include:
* `Experiment`: Ordered list of `Task` objects.
* `Task`: Table mapping each subject ID to an ordered list of `Condition` objects.
* `Condition`: Represents a single experimental condition/trial/subtask which can be identified with a `string`.

![Model Overview](docs/experiment-model.svg)

### Should I use the reader?
Check if your experimental procedure can be described with the hierarchy described just above in the Model. In general, user studies with a range of experimental conditions, possibly multiple independent variables with hierarchical order, can be described in this fashion.\
For example lets assume, we want to conduct an experiment to compare 3 kinds of VR controllers (`controller = {1, 2, 3}`) in 2 user poses (`pose = {sit, stand}`). So our participants perform tasks with each of the controllers and within these 3 blocks, also the poses are varied:
* `0` does `1-sit` then `1-stand` then `2-stand` and so on...
* `1` does `2-sit` then `2-stand` then `3-stand` and so on...
* ...

This can easily be described with the above model as an `Experiment` with only one `Task` where each partipant has a different line of `Conditions`.

### How to describe my experiment?
Sticking to our example from above, we now want to write the description files for our VR experiment. Therefore please have a look into the folder `examples/exampleDescription` which describes exactly this case. As we can see, an experiment is described as a folder of files:
1. There is always a `.txt` file describing the order of  conditions (identifiers in row) for each participant (each row).
2. Then there are a number of subdirectories which names end with the identifier in the `.txt` file. E.g. folder `Controller1` contains the part of the experiment for `controller = 1`.

For more complex experiments, this structure can be nested arbitrarily. See `src/resources/` for a larger example of description files.

### How to use the reader?
When a description of the experiment in this format is at hand, one can use the `ExperimentReader.readTask()` method to parse the experiment in the above described model classes. See `Main.java` for an example of this.\
Important parameters are:
* `collapse`: indicates if the specified conditions in the lowest level of file directories should be collapsed to a single condition. Then a line in the `.txt` file with `1 2 3` would be interpreted as one condition `1-2-3` instead of 3 subsequent ones. This is useful if in our example from above, the poses would always be done subsequently without a pause and the whole thing counted as one trial.
* `connector`: if `collapse` is true, then this parameter is the `string` used to join the condition (e.g. `-` to obtain `1-2-3`).
* `merger`: a function combining a range of `strings` to a single `string`. Because we have defined the orders of conditions of our 2 independent variables in separate files, we need to merge them into one. E.g. we could define a function which takes as input an array of `string` and simply joins them into a single `string` with `_` as separator. This way we obtain conditions of form `1_sit` or `3_stand` which are easy to work with.

### What now?
Use the obtained model of Java objects in any way you would like.\
In the future, I might extend this project with a simple GUI to execute the experiment.

license: MIT

repository: MarcRuble/experiment-utility

branch_name: refs/heads/main

repo_name: MarcRuble/experiment-utility


text:
---
title: RDO Ocata released
author: jpena
tags:
date: 2017-02-22 20:43:18 CET
---

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Ocata for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux.
RDO is suitable for building private, public, and hybrid clouds. Ocata is the 15th release from the [OpenStack project](http://openstack.org), which is the work of more than 2500 contributors from around the world ([source](http://stackalytics.com/)).

The [RDO community project](https://www.rdoproject.org/) curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the [CentOS Cloud Infrastructure SIG](https://wiki.centos.org/SpecialInterestGroup/Cloud).
The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds.

All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first.

Interesting things in the Ocata release include:

- [Significant Improvements](https://www.rdoproject.org/blog/2017/02/testing-rdo-with-tempest-new-features-in-ocata/) to Tempest and Tempest plugin packaging in RDO

- The [OpenStack-Ansible](https://docs.openstack.org/releasenotes/openstack-ansible/ocata.html#new-features) project now supports deployment on top of CentOS with the help of RDO-packaged dependencies

For cloud operators, RDO now provides packages for some new OpenStack Services:

- [Tacker](https://docs.openstack.org/developer/tacker/): an ETSI MANO NFV Orchestrator and VNF Manager
- [Congress](https://docs.openstack.org/developer/congress/architecture.html): an open policy framework for the cloud
- [Vitrage](https://docs.openstack.org/developer/vitrage/): the OpenStack RCA (Root Cause Analysis) Service
- [Kolla](https://github.com/openstack/kolla): The Kolla project provides tooling to build production-ready container images for deploying OpenStack clouds

Some other notable additions:

- [novajoin](https://github.com/openstack/novajoin): a dynamic vendordata plugin for the OpenStack nova metadata service to manage automatic host instantiation in an IPA server
- [ironic-ui](https://docs.openstack.org/developer/ironic-ui/): a new Horizon plugin to view and manage baremetal servers
- [python-virtualbmc](https://github.com/openstack/virtualbmc) VirtualBMC is a proxy that translates IPMI commands to libvirt calls. This allows projects such as OpenStack Ironic to test IPMI drivers using VMs.
- [python-muranoclient](https://github.com/openstack/python-muranoclient): a client for the Application Catalog service.
- [python-monascaclient](https://github.com/openstack/python-monascaclient): a client for the Monasca monitoring-as-a-service solution.
- [Shaker](http://pyshaker.readthedocs.io/en/latest/): the distributed data-plane testing tool built for OpenStack
- Multi-architecture support: aarch64 builds are now provided through an experimental repository - enable the RDO 'testing' repositories to get started

From a networking perspective, we have added some new Neutron plugins that can help Cloud users and operators to address new use cases and scenarios:

- [networking-bagpipe](https://docs.openstack.org/developer/networking-bagpipe/): a mechanism driver for Neutron ML2 plugin using BGP E-VPNs/IP VPNs as a backend
- [networking-bgpvpn](https://docs.openstack.org/developer/networking-bgpvpn/): an API and framework to interconnect BGP/MPLS VPNs to Openstack Neutron networks
- [networking-fujitsu](https://github.com/openstack/networking-fujitsu): FUJITSU ML2 plugins/drivers for OpenStack Neutron
- [networking-l2gw](https://github.com/openstack/networking-l2gw): APIs and implementations to support L2 Gateways in Neutron
- [networking-sfc](https://github.com/openstack/networking-sfc): APIs and implementations to support Service Function Chaining in Neutron

From the [Packstack](https://github.com/openstack/packstack) side, we have several improvements:

- We have added support to install Panko and Magnum
- Puppet 4 is now supported, and we have updated our manifests to cover the latest changes in the supported projects

**Getting Started**

There are three ways to get started with RDO.

- To spin up a proof of concept cloud, quickly, and on limited hardware, try the [All-In-One Quickstart](https://www.rdoproject.org/install/packstack/). You can run RDO on a single node to get a feel for how it works.
- For a production deployment of RDO, use the [TripleO Quickstart](https://www.rdoproject.org/tripleo/) and you'll be running a production cloud in short order.
- Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit [TryStack](http://trystack.org/), where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack. (TryStack is not, at this time, running Ocata, although it is running RDO.)

**Getting Help**

The RDO Project participates in a Q&A service at [ask.openstack.org](http://ask.openstack.org), for more developer-oriented content we recommend joining the [rdo-list mailing list](https://www.redhat.com/mailman/listinfo/rdo-list). Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the [RDO docs site](https://www.rdoproject.org/documentation).

The #rdo channel on Freenode IRC is also an excellent place to find help and give help.

We also welcome comments and requests on the [CentOS mailing lists](https://lists.centos.org/) and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience in the RDO venues.

**Getting Involved**

To get involved in the OpenStack RPM packaging effort, see the [RDO community pages](https://www.rdoproject.org/community/) and the [CentOS Cloud SIG page](https://wiki.centos.org/SpecialInterestGroup/Cloud). See also the [RDO packaging documentation](https://www.rdoproject.org/packaging/).

Join us in #rdo on the Freenode IRC network, and follow us at [@RDOCommunity](http://twitter.com/rdocommunity) on Twitter. If you prefer Facebook, [we're there too](http://facebook.com/rdocommunity), and also [Google+](http://tm3.org/rdogplus).

repository: sulaimanothman/website

repo_name: sulaimanothman/website


text:
---
layout: page
permalink: /tutorial/custom_mappers.html
title: Custom Mappers
---

One of the primary goals of Legion is to
make it easy to remap applications onto
different architectures. Up to this point
all of our applications have been mapped
by the `DefaultMapper` implementation that
is distributed with Legion. The `DefaultMapper`
class provides heuristics for performing mappings
that are good, but regularly not optimal for
specific applications or architectures. By
creating custom mappers programmers can make
application- or architecture-specific mapping
decisions. Furthermore, the mapping interface
isolates mapping decisions from application
code, allowing the same Legion applications
to be targeted at different architectures without
having to modify the application source code.

A common problem encountered when writing code
for large distributed and heterogeneous machines
is how mapping impacts correctness. In Legion, any valid set of
mapping decisions will result in the same answer being computed, and
therefore, if an application produces the correct answer on one
machine, it will produce the same answer regardless of the machine or
mapping strategy used. Mapping can therefore be considered orthogonal
to the correct execution of the program.

To introduce how to write a custom mapper we'll
implement two custom mappers. The first will be
an adversarial mapper that makes random mapping
decisions designed to stress-test the Legion runtime.
We'll also have the adversarial mapper report the chosen
mapping decisions (which will change with each run
of the application) to further emphasize the orthogonality
of mapping decisions from correctness. The second mapper
that we'll create will be used for partitioning to decide
how many sub-regions to create using _tunable_
variables. The application code for DAXPY is
identical to the code from
an [earlier example]({{ "/tutorial/partitioning.html" | relative_url }})
and is therefore omitted. We only show the new
code required for creating and implementing the
custom mappers.

#### Mapper Objects and Registration ####

Mappers are classes that implement the interface
declared in the abstract class `Mapper`. Legion provides a default
implementation of this interface defined by the
`DefaultMapper` class. The default mapper allows
applications to be developed without being
concerned with mapping decisions. Once correctness
has been established, programmers can implement
custom mappers to achieve higher performance.
Custom mappers can either extend the `DefaultMapper`
class or implement the `Mapper` interface from
scratch. In this example, we extend the
`DefaultMapper` to create both our `AdversarialMapper`
(line 20) and `PartitioningMapper` (line 41). We then override
four of the mapping interface calls in the `AdversarialMapper`
(lines 25-38) and one in the `PartitioningMapper` (lines 46-49)
to show how they work. We'll describe the semantics of these calls and our implementations
of them in the coming sections.

Mappers objects are instantiated after the
Legion runtime starts but before the application
begins executing. To instantiate mappers, the application
registers a callback function for the runtime to
invoke prior to beginning execution of the application. In this
example we create the `mapper_registration`
function (lines 52-62) and register the function
with runtime using the static method `add_registration_callback`
of `Runtime` (line 469). All callback
functions must have the same type as the `mapper_registration`
function so that the runtime can pass the
necessary parameters for creating new mappers.

In Legion, each kind of
mapper is identified by a `MapperID` (an unsigned integer).
There should be one instance of each kind of mapper
for every processor in the system. Having a single
instance for each processor guarantees that processors
can map tasks in parallel without needing to be
concerned about contention for a single mapper object. Note that in
general, mappers are permitted to be stateful, and users of the
mapping API can choose what state to track and how to manage that
state.

When `mapper_registration` callback function is invoked, it can
instantiate an arbitrary number of mappers and kinds of mappers.
For each kind, it should create one instance for
every processor in the set `local_procs` which
describes the set of processors on the local node. Note that in a
multi-node execution of Legion, this callback will be issued once on
every node in the system. The `MapperID` 0 is reserved for
the `DefaultMapper`, but applications can replace the default with their own mapper
by calling `replace_default_mapper` (lines 57-58). By replacing the default mapper, any tasks in the application will
automatically use the new `AdversarialMapper`. We register `PartitioningMapper` with
the `add_mapper` method and assign it a non-zero ID
`PARTITIONING_MAPPER_ID`. We'll show how to use
mapper IDs to determine which mapper is invoked
momentarily. Finally, notice that we iterate over
all the processors in the set of `local_procs`
to create a distinct instances of both `AdversarialMapper`
and `PartitioningMapper` for each processor (lines 57-60).

#### Legion Machine Model ####

In order to target a specific architecture, mappers need
access to a description of the underlying hardware.
Legion provides a static singleton `Machine` object
that can be used to make queries concerning the
underlying hardware. We show how to make some of these
queries as part of the constructor for our `AdversarialMapper`
object (lines 64-218).

The `Machine` object is passed as part
of the arguments to any mapper constructor, but it
can also always be obtained by calling the static method
`Machine::get_machine` from anywhere in the
application. In our constructor
we begin by obtaining the set of
all the processors in the machine (line 69). The
`Processor` objects are simply light-weight handles
that name the various processors (CPUs, GPUs, etc.) in the
machine. Generally speaking, the number and kind of processors
available in the Legion runtime are configured by passsing
command-line flags such as `-ll:cpu <C>` and `-ll:gpu <G>` (which
would create `C` CPU and `G` GPU processors). Note that certain flags
are only available when the appropriate module has been compiled into
Legion (e.g. the use of GPUs depends on `USE_CUDA` at
compile-time). More details on the available flags can be found at the
[machine configuration
page](/profiling/index.html#machine-configuration).

For illustration, we print the list of processors and memories for our
machine (lines 71-201). Note that in order to avoid seeing multiple
copies of this output, we only run this code on the first mapper (line
70). Recall a separate instance of the `AdversarialMapper`
will be made for every processor. We then
iterate over the set of all processors and print out
their ID and type (lines 75-104). Most objects
obtained from the `Machine` object have an associated
`id` field that can uniquely identify them (the special constant
`IDFMT` contains the appropriate format code for printing an ID).
There are a variety of processor types supported
by the Legion runtime: latency-optimized processors
(`LOC_PROC`) are CPU processors, throughput-optimized
processors (`TOC_PROC`) are GPUs, and utility processors
are special CPU processors used for performing Legion runtime
tasks. Legion also supports special-purpose processors for I/O,
OpenMP, and Python (not shown in this tutorial).

We then print the list of memories (lines 113-201).
Note that memory sizes are controlled by command-line
flags as well and may not accurately reflect the actual
underlying hardware. Again, the list of supported flags can be found
on the [machine configuration
page](/profiling/index.html#machine-configuration).

A useful way to think about the Legion machine model is that the
machine is a graph between processors and memories. Processors and
memories can have different affinities that describe the relative
speeds at which the various processors can access the available
memories. A processor can only access the contents of memories for
which it has an affinity. And similar, edges between memories describe
the paths along which data can be copied around the system. Note that
the exact affinity values are only approximations and do not reflect
the actual transfer bandwidth of the machine.

Line 205 uses
the `get_visible_memories` method to obtain the
set of memories that are visible from the local processor.
We then print out the affinities between the local
processor and each of these memories using the
`get_proc_mem_affinity` method (line 212).

#### Selecting Task Options ####

The first mapper call that we override is the
`select_task_options` call (lines 220-228). This
mapper call is performed on every task launch
immediately after it is made, and is used to configure certain
important aspects of task execution that the runtime needs to know up
front.

In general, mapper calls in Legion use a well-defined set of inputs
and outputs. The inputs are provided by one or more `const`
references, while the output is provided in a single non-`const`
reference struct. In this way, it is possible to determine what fields
a mapper is expected to set simply by looking at the signature of the
mapper call.

In the case of the `select_task_options` call, the following output
fields are provided to the mapper:

  * `inline_task` determines whether the child task should be executed
    directly in the parent tasks's context, using the parent task's
    physical regions. (This is option is usually left to `false` as it
    is desirable for the child to execute asynchronously with the
    parent.)
  * `stealable` is used for work-stealing load balancing and controls
    whether the task is available to be stolen by another
  * `map_locally` determines whether subsequent mapper calls (such as
    `map_task`) should be processed by the current mapper, or the
    mapper for the processor to which the task is to be assigned.
  * `initial_proc` is used to send the task to be mapped on another
    processor. Note that the task may not necessarily execute on
    `initial_proc`, since the mapper can still use the `map_task` call
    to send it to a different final destination.

For our adversarial mapper, to demonstrate that Legion can handle any
possible mapping strategy, we just choose a random processor for the
`initial_proc`. We use two `DefaultMapper` utility methods,
`select_random_processor` and `select_random_processor_kind` to do
this (lines 226-227).

#### Slicing Index Task Spaces ####

The second call that we override is the `slice_task`
method (lines 230-277). The `slice_task` method is used to determine
how to distribute the tasks within an index space launch around the

machine. The mapper is given as input a set of slices (which initially
contains a single element representing the entire launch), and is
expected to produce as output a set of slices. In this case, since we
are attempting to stress the runtime, we create a slice for each point
task and assign it to another processor. In more typical usage, the
slices would be chosen to maximize locality in the application.

The `slice_task` method can optionally be called recursively until the
index space launch has been decomposed down to slices of the desired
size. In this case we disable this feature and only perform one level
of slicing.

#### Task Mapping ####

The next mapping call, `map_task` (lines 279-338) is one of the most
important methods. The call has a number of responsibilities:

  * Select the final (set of) processor(s) that the task will be executed on.
  * Select the variant of the task to execute.
  * Select the physical instances to hold the data for each logical region.
  * Optionally select the task priority.
  * Optionally select profiling information to collect.

On line 298, we select the final processor that the task will execute
on. In this case, we simply keep the processor that was chosen by
`select_task_options`, which is stored in the `task.target_proc`
field. Note that `output.target_procs` is a set and if multiple
processors, task will be load balanced between the selected
processors. It is a common pattern to select all of the processors on
the local node that have the appropriate type. For the adversarial
example, we only choose a single processor.

In general, a task can have multiple variants (e.g. for CPU or GPU, or
for a CPU that supports AVX instructions, or that assumes a specific
memory layout for its physical instances). Lines 283-297 select the
task variant to execute. It is important to choose a variant that is
capable of executing on the selected kind of processor. First we find
the list of available variants (lines 283-284). Then we filter this
down to those that are compatible with the kind of processor we intend
to map on (lines 286-290). Finally, since this is an adversarial
example, we select a random variant from among the valid choices. A
more typical example might use application-specific knowledge to
choose the appropriate variant to use.

Having chosen the target processor and variant, we map all the logical
regions of the task to specific physical instances (lines
299-337).

Note in certain cases, regions may already be mapped. Such regions are
said to be _premapped_. We find a list of such regions on lines
299-304; we'll just skip them in the code below.

Certain variants of tasks may assume that the data has a specific
layout. In order to ensure that the mapping is correct for the given
variant, we use `find_task_layout_constraints` to look up the _layout
constraints_ for the given variant (lines 305-307). Layout constraints
describe the layout that the variant expects to receive.

Legion is very flexible with respect to data layout and provide the
data in C or Fortran array order, in array-of-structs (AOS) or
struct-of-arrays (SOA), or in arbitrary hybrid combinations of those
layouts. Legion will transpose the data as necessary to ensure that it
always provided in the correct layout. The mapper is simply
responsible for choosing the layout that it wants for the data.

To simplify the process of choosing an appropriate layout, we use two
helper methods `map_constrained_requirement` (lines 322-323) and
`map_random_requirement` (lines 326-328) that handle the cases where
the variant specifies constraints on the layout, or leaves the layout
unconstrained, respectively. In an application-specific mapper, the
mapper might have more knowledge of the desired layout and might
include additional code here to choose a specific data layout for the
task.

Note that there are two special cases. First, as noted above, if a
task is premapped we need not (and cannot) map it (lines
309-310). Second, if the instance is _restricted_ then we know a valid
instance already exists and we can simply use this (lines
311-314). Restricted instances occur primarily as a result of
simultaneous coherence, which is an advanced feature of Legion that is
not commonly used. Since this adversarial mapper is striving to be
general-purpose, we must handle all these cases, but an
application-specific mapper could potentially skip them.

On line 330 we assign the task with a random prioritiy. In more
typical usage, the mapper would assign higher priority to tasks along
the critical path of the application, to ensure that those tasks
execute as soon as they are ready.

Finally, `map_task` can request various profiling information about a
task, such as the status (success or failure) of a task, the execution
time, and the overhead incurred (lines 332-337). These results are
then passed back to the mapper via the `report_profiling` callback
once the task completed.

#### Reporting Results ####

The last mapper call that we override for our `AdversarialMapper` is
the `report_profiling` method (lines 340-410). This method prints out
the profiling information obtained from the task execution that was
requested in `map_task`.

#### Handling Tunable Variables ####

When writing tasks, there are often many cases where
variables depend on the underlying nature of the
machine. In Legion we refer to these variables as
_tunable_ because they often need
to be specifically tuned for different architectures.
Since these variables are machine dependent and likely
to affect performance, we prefer to make these variables
explicit. To do this we provide a separate mapping call
`select_tunable_value` to explicitly request that the
mapper pick the value for this variable. We override
this call in our `PartitioningMapper` on lines 410-430.

We make a slight modification to our DAXPY code to
make the number of sub-regions to create a tunable
variable so that the mapper can pick a value based
on the number of processors on the target machine. Note that the
`top_level_task` explicitly invokes the `select_tunable_value`
to find the number of sub-regions to create. (Instead of showing the
full example again, we show only the relevant snippet below.) When
this call is made, we
pass the `PARTITIONING_MAPPER_ID` as the value to the
`MapperID` field, indicating that an instance of
our `PartitioningMapper` should be used to handle
the request and not an instance of the `AdversarialMapper`.
When we make the call we also pass in a `TunableID`
which is used to identify the name of the tunable
variable that should be set. The `TunableID`
can be arbitrary, so long as the mapper that it
is being sent to knows what to do with it. In
this case we pass `SUBREGION_TUNABLE` as the
integer name for tunable variable. The `PartitioningMapper`
instance looks up the total number of processors
in the machine and returns that as the number
of sub-regions to create.

{% highlight cpp %}
int num_subregions =
        runtime->get_tunable_value(ctx, SUBREGION_TUNABLE,
                                   PARTITIONING_MAPPER_ID).get_result<size_t>();
{% endhighlight %}

Tunable variables are returned as a future, so if the application code
needs to use the result it must call `get_result<T>` to get the value.

#### What Next? ####

Congratulations! You've reached the end of the
Legion tutorial as it currently exists. There
are many features already implemented in Legion
which are not covered by this tutorial including:

  * reduction operations, reduction privileges,
    and reduction instances
  * special accessors to obtain raw pointers and strides from physical instances
  * runtime debugging modes and flags
  * runtime performance tuning knobs
  * unmapping and remapping optimizations
  * explicit cross-region copy operations
  * additional mapping calls and settings
  * close operations and composite instances (pending)
  * profiling and debugging tools
  * relaxed coherence modes
  * acquire and release operations for simultaneous coherence
  * reservations and phase barriers for synchronization
    in a deferred execution model
  * predicated operations
  * support for speculative execution (in progress)
  * inner and idempotent tasks
  * efficient data-centric resiliency and recovery (in progress)

If you are interested in learning more about how to
use these features of Legion or you have questions
regarding how to use them, please post to the
[mailing list](http://legion.stanford.edu/resources).

Previous Example: [Multiple Partitions]({{ "/tutorial/multiple.html" | relative_url }})

{% highlight cpp linenos %}
#include <cstdio>
#include <cassert>
#include <cstdlib>
#include "legion.h"

#include "test_mapper.h"
#include "default_mapper.h"

using namespace Legion;
using namespace Legion::Mapping;

enum {
  SUBREGION_TUNABLE,
};

enum {
  PARTITIONING_MAPPER_ID = 1,
};

class AdversarialMapper : public TestMapper {
public:
  AdversarialMapper(Machine machine,
      Runtime *rt, Processor local);
public:
  virtual void select_task_options(const MapperContext    ctx,
				   const Task&            task,
				         TaskOptions&     output);
  virtual void slice_task(const MapperContext ctx,
                          const Task& task,
                          const SliceTaskInput& input,
                                SliceTaskOutput& output);
  virtual void map_task(const MapperContext ctx,
                        const Task& task,
                        const MapTaskInput& input,
                              MapTaskOutput& output);
  virtual void report_profiling(const MapperContext      ctx,
				const Task&              task,
				const TaskProfilingInfo& input);
};

class PartitioningMapper : public DefaultMapper {
public:
  PartitioningMapper(Machine machine,
      Runtime *rt, Processor local);
public:
  virtual void select_tunable_value(const MapperContext ctx,
                                    const Task& task,
                                    const SelectTunableInput& input,
                                          SelectTunableOutput& output);
};

void mapper_registration(Machine machine, Runtime *rt,
                          const std::set<Processor> &local_procs) {
  for (std::set<Processor>::const_iterator it = local_procs.begin();
        it != local_procs.end(); it++)
  {
    rt->replace_default_mapper(
        new AdversarialMapper(machine, rt, *it), *it);
    rt->add_mapper(PARTITIONING_MAPPER_ID,
        new PartitioningMapper(machine, rt, *it), *it);
  }
}

AdversarialMapper::AdversarialMapper(Machine m,
                                     Runtime *rt, Processor p)
  : TestMapper(rt->get_mapper_runtime(), m, p)
{
  std::set<Processor> all_procs;
  machine.get_all_processors(all_procs);
  if (all_procs.begin()->id + 1 == local_proc.id) {
    printf("There are %zd processors:\n", all_procs.size());
    for (std::set<Processor>::const_iterator it = all_procs.begin();
          it != all_procs.end(); it++) {
      Processor::Kind kind = it->kind();
      switch (kind) {
        // Latency-optimized cores (LOCs) are CPUs
        case Processor::LOC_PROC:
          {
            printf("  Processor ID " IDFMT " is CPU\n", it->id);
            break;
          }
        // Throughput-optimized cores (TOCs) are GPUs
        case Processor::TOC_PROC:
          {
            printf("  Processor ID " IDFMT " is GPU\n", it->id);
            break;
          }
        // Processor for doing I/O
        case Processor::IO_PROC:
          {
            printf("  Processor ID " IDFMT " is I/O Proc\n", it->id);
            break;
          }
        // Utility processors are helper processors for
        // running Legion runtime meta-level tasks and
        // should not be used for running application tasks
        case Processor::UTIL_PROC:
          {
            printf("  Processor ID " IDFMT " is utility\n", it->id);
            break;
          }
        default:
          assert(false);
      }
    }
    std::set<Memory> all_mems;
    machine.get_all_memories(all_mems);
    printf("There are %zd memories:\n", all_mems.size());
    for (std::set<Memory>::const_iterator it = all_mems.begin();
          it != all_mems.end(); it++) {
      Memory::Kind kind = it->kind();
      size_t memory_size_in_kb = it->capacity() >> 10;
      switch (kind) {
        // RDMA addressable memory when running with GASNet
        case Memory::GLOBAL_MEM:
          {
            printf("  GASNet Global Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // DRAM on a single node
        case Memory::SYSTEM_MEM:
          {
            printf("  System Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // Pinned memory on a single node
        case Memory::REGDMA_MEM:
          {
            printf("  Pinned Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // A memory associated with a single socket
        case Memory::SOCKET_MEM:
          {
            printf("  Socket Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // Zero-copy memory betweeen CPU DRAM and
        // all GPUs on a single node
        case Memory::Z_COPY_MEM:
          {
            printf("  Zero-Copy Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // GPU framebuffer memory for a single GPU
        case Memory::GPU_FB_MEM:
          {
            printf("  GPU Frame Buffer Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // Disk memory on a single node
        case Memory::DISK_MEM:
          {
            printf("  Disk Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // HDF framebuffer memory for a single GPU
        case Memory::HDF_MEM:
          {
            printf("  HDF Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // File memory on a single node
        case Memory::FILE_MEM:
          {
            printf("  File Memory ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // Block of memory sized for L3 cache
        case Memory::LEVEL3_CACHE:
          {
            printf("  Level 3 Cache ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // Block of memory sized for L2 cache
        case Memory::LEVEL2_CACHE:
          {
            printf("  Level 2 Cache ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        // Block of memory sized for L1 cache
        case Memory::LEVEL1_CACHE:
          {
            printf("  Level 1 Cache ID " IDFMT " has %zd KB\n",
                    it->id, memory_size_in_kb);
            break;
          }
        default:
          assert(false);
      }
    }

    std::set<Memory> vis_mems;
    machine.get_visible_memories(local_proc, vis_mems);
    printf("There are %zd memories visible from processor " IDFMT "\n",
            vis_mems.size(), local_proc.id);
    for (std::set<Memory>::const_iterator it = vis_mems.begin();
          it != vis_mems.end(); it++) {
      std::vector<ProcessorMemoryAffinity> affinities;
      int results =
        machine.get_proc_mem_affinity(affinities, local_proc, *it);
      assert(results == 1);
      printf("  Memory " IDFMT " has bandwidth %d and latency %d\n",
              it->id, affinities[0].bandwidth, affinities[0].latency);
    }
  }
}

void AdversarialMapper::select_task_options(const MapperContext ctx,
                                            const Task& task,
                                                  TaskOptions& output) {
  output.inline_task = false;
  output.stealable = false;
  output.map_locally = true;
  Processor::Kind kind = select_random_processor_kind(ctx, task.task_id);
  output.initial_proc = select_random_processor(kind);
}

void AdversarialMapper::slice_task(const MapperContext      ctx,
                                   const Task&              task,
                                   const SliceTaskInput&    input,
                                         SliceTaskOutput&   output) {
  // Iterate over all the points and send them all over the world
  output.slices.resize(input.domain.get_volume());
  unsigned idx = 0;
  switch (input.domain.get_dim()) {
    case 1:
      {
        Rect<1> rect = input.domain;
        for (PointInRectIterator<1> pir(rect); pir(); pir++, idx++)
        {
          Rect<1> slice(*pir, *pir);
          output.slices[idx] = TaskSlice(slice,
              select_random_processor(task.target_proc.kind()),
              false/*recurse*/, true/*stealable*/);
        }
        break;
      }
    case 2:
      {
        Rect<2> rect = input.domain;
        for (PointInRectIterator<2> pir(rect); pir(); pir++, idx++)
        {
          Rect<2> slice(*pir, *pir);
          output.slices[idx] = TaskSlice(slice,
              select_random_processor(task.target_proc.kind()),
              false/*recurse*/, true/*stealable*/);
        }
        break;
      }
    case 3:
      {
        Rect<3> rect = input.domain;
        for (PointInRectIterator<3> pir(rect); pir(); pir++, idx++)
        {
          Rect<3> slice(*pir, *pir);
          output.slices[idx] = TaskSlice(slice,
              select_random_processor(task.target_proc.kind()),
              false/*recurse*/, true/*stealable*/);
        }
        break;
      }
    default:
      assert(false);
  }
}

void AdversarialMapper::map_task(const MapperContext         ctx,
                                 const Task&                 task,
                                 const MapTaskInput&         input,
                                       MapTaskOutput&        output) {
  const std::map<VariantID,Processor::Kind> &variant_kinds =
    find_task_variants(ctx, task.task_id);
  std::vector<VariantID> variants;
  for (std::map<VariantID,Processor::Kind>::const_iterator it =
        variant_kinds.begin(); it != variant_kinds.end(); it++) {
    if (task.target_proc.kind() == it->second)
      variants.push_back(it->first);
  }
  assert(!variants.empty());
  if (variants.size() > 1) {
    int chosen = default_generate_random_integer() % variants.size();
    output.chosen_variant = variants[chosen];
  }
  else
    output.chosen_variant = variants[0];
  output.target_procs.push_back(task.target_proc);
  std::vector<bool> premapped(task.regions.size(), false);
  for (unsigned idx = 0; idx < input.premapped_regions.size(); idx++) {
    unsigned index = input.premapped_regions[idx];
    output.chosen_instances[index] = input.valid_instances[index];
    premapped[index] = true;
  }
  const TaskLayoutConstraintSet &layout_constraints =
    runtime->find_task_layout_constraints(ctx, task.task_id,
                                          output.chosen_variant);
  for (unsigned idx = 0; idx < task.regions.size(); idx++) {
    if (premapped[idx])
      continue;
    if (task.regions[idx].is_restricted()) {
      output.chosen_instances[idx] = input.valid_instances[idx];
      continue;
    }
    if (layout_constraints.layouts.find(idx) !=
          layout_constraints.layouts.end()) {
      std::vector<LayoutConstraintID> constraints;
      for (std::multimap<unsigned,LayoutConstraintID>::const_iterator it =
            layout_constraints.layouts.lower_bound(idx); it !=
            layout_constraints.layouts.upper_bound(idx); it++)
        constraints.push_back(it->second);
      map_constrained_requirement(ctx, task.regions[idx], TASK_MAPPING,
          constraints, output.chosen_instances[idx], task.target_proc);
    }
    else
      map_random_requirement(ctx, task.regions[idx],
                             output.chosen_instances[idx],
                             task.target_proc);
  }
  output.task_priority = default_generate_random_integer();

  {
    using namespace ProfilingMeasurements;
    output.task_prof_requests.add_measurement<OperationStatus>();
    output.task_prof_requests.add_measurement<OperationTimeline>();
    output.task_prof_requests.add_measurement<RuntimeOverhead>();
  }
}

void AdversarialMapper::report_profiling(const MapperContext      ctx,
					 const Task&              task,
					 const TaskProfilingInfo& input) {
  using namespace ProfilingMeasurements;

  OperationStatus *status =
    input.profiling_responses.get_measurement<OperationStatus>();
  if (status) {
    switch (status->result) {
      case OperationStatus::COMPLETED_SUCCESSFULLY:
        {
          printf("Task %s COMPLETED SUCCESSFULLY\n", task.get_task_name());
          break;
        }
      case OperationStatus::COMPLETED_WITH_ERRORS:
        {
          printf("Task %s COMPLETED WITH ERRORS\n", task.get_task_name());
          break;
        }
      case OperationStatus::INTERRUPT_REQUESTED:
        {
          printf("Task %s was INTERRUPTED\n", task.get_task_name());
          break;
        }
      case OperationStatus::TERMINATED_EARLY:
        {
          printf("Task %s TERMINATED EARLY\n", task.get_task_name());
          break;
        }
      case OperationStatus::CANCELLED:
        {
          printf("Task %s was CANCELLED\n", task.get_task_name());
          break;
        }
      default:
        assert(false); // shouldn't get any of the rest currently
    }
    delete status;
  }
  else
    printf("No operation status for task %s\n", task.get_task_name());

  OperationTimeline *timeline =
    input.profiling_responses.get_measurement<OperationTimeline>();
  if (timeline) {
    printf("Operation timeline for task %s: ready=%lld start=%lld stop=%lld\n",
	   task.get_task_name(),
	   timeline->ready_time,
	   timeline->start_time,
	   timeline->end_time);
    delete timeline;
  }
  else
    printf("No operation timeline for task %s\n", task.get_task_name());

  RuntimeOverhead *overhead =
    input.profiling_responses.get_measurement<RuntimeOverhead>();
  if (overhead) {
    long long total = (overhead->application_time +
		       overhead->runtime_time +
		       overhead->wait_time);
    if (total <= 0) total = 1;
    printf("Runtime overhead for task %s: runtime=%.1f%% wait=%.1f%%\n",
	   task.get_task_name(),
	   (100.0 * overhead->runtime_time / total),
	   (100.0 * overhead->wait_time / total));
    delete overhead;
  }
  else
    printf("No runtime overhead data for task %s\n", task.get_task_name());
}

PartitioningMapper::PartitioningMapper(Machine m,
                                       Runtime *rt,
                                       Processor p)
  : DefaultMapper(rt->get_mapper_runtime(), m, p)
{
}

void PartitioningMapper::select_tunable_value(const MapperContext ctx,
                                              const Task& task,
                                              const SelectTunableInput& input,
                                                    SelectTunableOutput& output) {
  if (input.tunable_id == SUBREGION_TUNABLE) {
    Machine::ProcessorQuery all_procs(machine);
    all_procs.only_kind(Processor::LOC_PROC);
    runtime->pack_tunable<size_t>(all_procs.count(), output);
    return;
  }
  assert(false);
}

/*
 * Everything below here except main is the standard daxpy example and
 * is elided for brevity....
 */

int main(int argc, char **argv) {
  Runtime::set_top_level_task_id(TOP_LEVEL_TASK_ID);

  {
    TaskVariantRegistrar registrar(TOP_LEVEL_TASK_ID, "top_level");
    registrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
    Runtime::preregister_task_variant<top_level_task>(registrar, "top_level");
  }

  {
    TaskVariantRegistrar registrar(INIT_FIELD_TASK_ID, "init_field");
    registrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
    registrar.set_leaf();
    Runtime::preregister_task_variant<init_field_task>(registrar, "init_field");
  }

  {
    TaskVariantRegistrar registrar(DAXPY_TASK_ID, "daxpy");
    registrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
    registrar.set_leaf();
    Runtime::preregister_task_variant<daxpy_task>(registrar, "daxpy");
  }

  {
    TaskVariantRegistrar registrar(CHECK_TASK_ID, "check");
    registrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
    registrar.set_leaf();
    Runtime::preregister_task_variant<check_task>(registrar, "check");
  }

  // Here is where we register the callback function for
  // creating custom mappers.
  Runtime::add_registration_callback(mapper_registration);

  return Runtime::start(argc, argv);
}
{% endhighlight %}

gha_language: Less


text:
# NCTL Deploy Commands - ERC-20

### nctl-erc20-approve owner={X:-1} spender={Y:-1} amount={Z:-1000000000}

Allows a user (the spender) to withdraw upto Z tokens from the account of a token holder (the owner).

```
nctl-erc20-approve

nctl-erc20-approve owner=1 spender=2 amount=1000000000  (same as above)

nctl-erc20-approve owner=2 spender=4 amount=4400000000  (same as above)
```

### nctl-erc20-fund-users amount={X:-1000000000}

Transfers from the installed ERC-20 smart contract X tokens to each of the test user accounts.

```
nctl-erc20-fund-users

nctl-erc20-fund-users amount=1000000000  (same as above)

nctl-erc20-fund-users amount=4440000000
```

### nctl-erc20-install name={X:-Acme Token} symbol={Y:-Acme} supply={Z:-1e33}

Installs the ERC0-20 smart contract under the network's faucet account.

NOTE : The compiled wasm file must have been previously moved to the test network's bin folder (e.g. `casper-node/utils/nctl/assets/net-1/bin`).  For further information refer to the network's smart contract SDK.

```
nctl-erc20-install

nctl-erc20-install name="Acme Token" symbol="ACME" supply=1000000000000000000000000000000000  (same as above)

nctl-erc20-install name="Casper Labs" symbol="CSPR" supply=1000000000000000000000000000
```

### nctl-erc20-transfer from={X:-1} to={Y:-1} amount={Z:-1000000000}

Transfers Z tokens from user X to user Y.

```
nctl-erc20-transfer-from

nctl-erc20-transfer-from from=1 to=2 amount=1000000000  (same as above)

nctl-erc20-transfer-from from=2 to=5 amount=4440000000
```

### nctl-erc20-view-balances net={X:-1} node={Y:-1}

Renders ERC-20 token balances of the network's faucet and user accounts.

```
nctl-erc20-view-balances

nctl-erc20-view-balances net=1 node=1  (same as above)

nctl-erc20-view-balances net=2 node=4
```

### nctl-erc20-view-details net={X:-1} node={Y:-1}

Renders information related to the installed smart contract, e.g. contract hash.

```
nctl-erc20-view-details

nctl-erc20-view-details net=1 node=1  (same as above)

nctl-erc20-view-details net=2 node=4
```


text:
Shed
====

simple local PHP development

**WARNING: This project started as a PHP project and is still in the process of
being ported to Javascript. The Javascript version is mostly untested,
unfinished, and undocumented. You might want to wait.**

Quick Start
-----------

1. You need [Docker](https://www.docker.com/) and [NPM](https://www.npmjs.com/) installed.
2. `npm install -g shed-host`
3. Edit your shed .env to specify your sites folder.
4. `shed up -d`

Introduction
------------

Shed provides a platform for simple, local, PHP development, in the same kind of way MAMP, Laravel Valet, or Homestead does.

* Shed uses Docker, and runs on **every platform** Docker does.
* Shed treats **folders as sites**, so adding a site is just making a folder.
* Shed makes use of **wildcard DNS**, so **no configuration** is required to add sites to Shed.
* Shed runs real Linux, Apache, MySQL, PostgreSQL and PHP, so your local environment matches production.

It's designed to provide a set-it-and-forget-it platform for local, PHP development.

Setup
-----

To run Shed, you only need to be able to run [Docker](https://www.docker.com/) and [NPM](https://www.npmjs.com/). Shed is not tested on Windows yet, but Shed plans to support Windows, Linux, and OS X.

### Default Enviroment

There is a `.env` file in the shed's directory that must be edited by hand for now, until `shed config` is ported over from the PHP version.

Usage
-----

Start Shed by running `shed up` or `shed up -d`. Once it's running, you can access your projects based on their folder names. For example, To access `Projects/example.com`, I would go to

* http://example.com.shed.host

That's it. If you don't want to use shed.host, you can use any of the following:

* imarc.io - owned by [Imarc](https://www.imarc.com)
* localtest.me - [readme.localtest.me](http://readme.localtest.me/)
* lvh.me - owned by [Levi Cook](https://gist.github.com/levicook/563675)
* 42foo.com - owned by [Jorge Bernal](https://jorgebernal.info/2009/07/17/42foo-virtual-hosts-web-development/)
* fuf.me - owned by [fidian](http://www.fidian.com/programming/public-dns-pointing-to-localhost)
* lacolhost.com - owned by [Reenhanced](http://blog.reenhanced.com/post/29566591244/developing-with-subdomains-just-got-a-lot-easier)
* vcap.me - part of [Cloud Foundry](https://github.com/cloudfoundry-attic/vcap)

**Shed assumes** that the document root for all your projects is
`<projectfolder>/public`. If you use `docroot/` instead, you can try creating a
symlink like this:

```
$ ln -s public docroot
```

### How this works

\*.shed.host is setup using wildcard DNS to point to `<IP_ADDRESS>` - one of the IPs designed to always point to your own local system (*localhost*.) This eliminates any need to etc your `/etc/hosts` file.

Within Shed's apache container, it uses `mod_vhost_alias` to map these subdomains back to separate virtualhosts. This means that there's no new apache configuration required.

### Special Subdomains

There are two groups of special domains:

1. [shed.host](http://www.shed.host) and [www.shed.host](http://www.shed.host) get you to Shed's website.
2. [my.shed.host](http://my.shed.host) and [shed.shed.host](http://shed.shed.host) get you to Shed's local, internal site. This is where you can find Adminer and Webgrind.

Adminer
-------

[Adminer](https://www.adminer.org/) is a lightweight webapp for managing databases, including both MySQL and PostgreSQL. The latest release of Adminer is included in Shed.

You can login by going to http://my.shed.host/ and clicking the relevant link, or:

* **MySQL:** host is `mysql`, username is `root`, no password
* **PostgresSQL:** host is `postgres`, username is `postgres`, no password

XDebug and Webgrind
-------------------

XDebug and Webgrind are setup within Shed as well. You can trigger XDebug
profiling by adding `?XDEBUG_PROFILE=1` to the end of a URL.

You can view That profile with Webgrind by going to

* http://my.shed.host/webgrind/

repository: shedhost/shed

gha_language: PHP

repo_name: shedhost/shed


text:
---
id: testing
title: Testing
sidebar_label: Testing
---

Hydra uses a test automation tool called [nox](https://github.com/theacodes/nox) to manage tests, linting, code coverage, etc.
`nox` will run all the configured sessions. You can see the full list of nox sessions with `nox -l` and run specific sessions
with `nox -s NAME` (you may need to quote the session name in some cases)

## With pytest
Run `pytest` at the repository root to run all the Hydra core tests.
To run the tests of individual plugins, use `pytest plugins/NAME`.

:::info NOTE
Some plugins support fewer versions of Python than the Hydra core.
:::

## With nox
See `nox -l`. a few examples:
* `nox -s test_core` will test Hydra core on all supported Python versions
* `nox -s "test_core-3.6(pip install)"` : Test on Python 3.6 with `pip install` as installation method
* `nox -s "test_plugins-3.8(pip install -e)"` : Test plugins on Python 3.8 with `pip install -e` as installation method

repository: facebookresearch/hydra

gha_language: Python

gha_license_id: MIT

repo_name: facebookresearch/hydra


text:
RegRipper2.8
============

RegRipper version 2.8

This is the GitHub repository for RegRipper version 2.8

Updates 21090128
- added Time::Local module
  - this allows plugins to be written that parse string-based date/time stamps, converting
    them to epochs (for timelining, etc.)
- modified C:\Perl\site\lib\Parse\Win32Registry\WinNT\Key.pm
  - extract access_bits and largest_subkey_name_length values from Key node structure
  - call 'get_access_bits()', 'get_largest_subkey_name_lenght()' to retrieve the values for parsing/display
  - IAW https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md

Note: The modifications to Key.pm are 'compiled' into the EXE versions of RegRipper.  In order to fully take
advantage of them with the .pl versions:
- got to \Perl\site\lib\Parse\Win32Registry\WinNT\
- rename Key.pm to Key_old.pm
- copy Key.pm from this distro to the folder

gha_language: Perl

gha_license_id: NOASSERTION


text:
# Master Thesis Example Page

### Prerequisites

None

### Installing

Clone the repo and install dependencies via

```
npm install
```

## Tests

Run tests via

```
npm run test
```

## Run

Run a development build and start a dev server at http://localhost:3000 via

```
npm run dev
```

Create a production build and start a server at http://localhost:3000 via

```
npm run build
npm start
```

Export static HTML/CSS/JS page via

```
npm run export
```

## Deployment

No Deployment mechanics integrated yet

## Built With

- [Next.js](https://github.com/zeit/next.js) - SSR for React

## Authors

- **Timothy Krechel** - _Initial work_ - [timothy.de](https://www.timothy.de)

## License

This project is licensed under the MIT License.

repository: timothyde/thesis-experiment

repo_name: timothyde/thesis-experiment


text:
GaliProg... What is it? It is a tool (sketch) which allows to read/program/erase/verify SPI flash memory image on Intel® Galileo board.

Galiprog may help in a situation when Galileo board is bricked after a failed firmware upgrade.

Version 1.2, Oct 2015, xbolshe

  - added Edison support to use it as a programmator
  - update pack 1.0.4 for Edison board

Version 1.1, Feb 2015, xbolshe
  - added Galileo Gen 1 support to use it as a programmator
  - pack 1.0.4 support is added

Version 1.0, Feb 2015, xbolshe
  - first public release

  ![alt galiprog_scheme](https://github.com/xbolshe/galiprog/blob/master/galiprog_scheme.jpg)

repository: xbolshe/galiprog

repo_name: xbolshe/galiprog


text:
ANTRadioService
===============

Version: 3.0.0

This repository currently only contains the prebuilt (.apk) version of the ANT Radio Service for Android.

For details on adding this to the Android platform source see https://github.com/ant-wireless/ANT_in_Android/wiki


text:
# log4sh

log4sh is an advanced logging framework for shell scripts (eg. sh, bash) that
works similar to the logging products available from the Apache Software
Foundataion (eg. log4j, log4perl).

log4sh provides different releases so that users can depend on functionality
within a release series. It uses a variant of the X.Y.Z
[Semantic Versioning](http://semver.org/) system.

- X -- major release. Significant functionality has changed, and users of the
  code will definitely require changes to continue using it. These are
  extremely rare.
- Y -- minor release. New functionality was added. To maintain stability for
  users, stable releases are numbered with even numbers (e.g. 1.4), with
  development releases numbered with odd numbers (e.g. 1.5). Development
  releases possibly include functionality that breaks backwards compatibility.
- Z -- patch release. Bug fixes, and minor new functionality that remains 100%
  backwards compatible.

log4sh was originally hosted on Source Forge as
https://sourceforge.net/p/log4sh/. It moved here in Sep 2017 to be hosted
alongside the other projects by @kward (https://github.com/kward).

**[2021-12-12]** log4sh ***is not*** Log4Shell. log4sh is written in pure shell
code, and does not use Java in any way, shape, or form. It is therefore ***not
vulnerable*** to the Log4j exploit mentioned in [CVE-2021-4428](https://www.cve.org/CVERecord?id=CVE-2021-44228), which is also named
Log4Shell or LogJam. For more information, about the unrelated exploit, see
https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/.


text:
# Oanda REST API example
This folder has two small apps developed for interfacing with [Oandas](http://developer.oanda.com) REST API.
 Specifically using Oandas V-20 REST API.

Oanda-first only has downloading historical data prices for 'EUR_USD' FOREX prices, and scaling two different currencies.
While Oanda-Event is an intro to an event driven software for streaming live prices from Oanda
as well building on what was learned from Oanda-first to begin data collection for backtesting.
Inspiration for the event driven software written in python comes from [Quant Start](https://www.quantstart.com/articles/Forex-Trading-Diary-1-Automated-Forex-Trading-with-the-OANDA-API).
**Warning, this is for educational purposes only.**

Dependencies       	| Version          |
--------------------|------------------|
Python 				| 3.6.4   		  	|
glob2			       | 0.5     	      |
matplotlib 			| 2.1.0			  	|
numpy 					| 1.13.3 				|
pandas 				| 0.22.0   			|

## Oanda-first

This folder contains a means to look at past FOREX prices, and compare them.

### Functions in OHLC.py
GrabToken() will grab users API token from res folder.
Returns token as string.

```
GrabToken(path=token_path)
```
GrabCandles() requires 6 parameters and returns 12 values.
Parameter gran is granularity or frequency of tick data (OHLC data).
Returns instru, time, volume, bid OHLCs, ask OHLCs, ticks as numpy arrays.

```
GrabCandles(token, instru, start, gran, based, count=1000)
```
### Function in GrabAll.py
GrabAllCandles() grabs different prices at a time from 'EUR' currency
Returns only instru and ask close as numpy arrays.

```
GrabAll()
```

### Function in NormCur.py
NormCur() requires Bid close (s for scale and n for normalize).
This is an ad hoc way to scale Currencies with vastly different prices to be "on top" on one another.
Returns normalized or scaled prices as numpy array.

```
NormCur(BCn, BCs)
```
Now use matplotlib.pyplot to plot simple line graphs to see if you plot the same data as Oanda shows in their downloadable app.
This will show you are connecting with their API correctly.

## Oanda-Event

This folder contains event driven software to stream live tick feed data.
There has been plenty learned from (Oanda-first) which is to be implemented in the Backtest folder.

### enivro.py
The python file one would edit when switching from demo mode (monopoly money) to a live brokerage account, see more at Oandas API website. There are two functions to either GrabToken() or GrabID() which will grab the users info from the res folder (needs to be edited with ones own API key from [Oanda](https://developer.oanda.com/rest-live-v20/introduction/)

### events.py
A simple python script only has two classes since this is a very simple event driven progrom with only two events. The first event is TickEvent class and the other is OrderEvent class. When ever new OHLC data is downloaded, from steam.py, this new data will be queued as a new event for the program. The other type of event is OrderEvent which happens when ever strategy.py script conditions are met.

### strategytest.py
This is the brains of the program and unfortuntely only has a very simple script as this event driven python program will not produce a profit, this is for educational purposes only!

### steam.py
This file is used to request an http session with [Oanda](https://developer.oanda.com/rest-live-v20/account-ep/) endpoints.

### trading.py
The heart of the program will be executed with this script. All events processed with this file and functions are imported, from files above, to download and execute trades on a live demo account (can be upgraded to a live brokerage account but this is outside the scope of this repo).

### Backtest folder
#### Functions in downloadOHLC.py
GrabHistoryPrice() is a class that requires 4 parameters to initialize and one optional parameter.
Returns one HTTP response.

```
GrabHistoryPrice(domain, token, instru, gran, count=500)
```

##### Methods for this class
requestHistStream() is a method that begins an http connection to the endpoint /v3/instruments/ from Oanda's API. This method is never called directly. All other methods in this class build of this one.

```
requestHistStream()
```

downloadSingle() is a method that downloads the single FOREX instrument data in JSON format.

```
downloadSingle()
```

downloadAll() is a method that downloads the all FOREX instruments data in JSON format. The FOREX instruments included are in list found in this method. One can find more about these endpoints [here](https://developer.oanda.com/rest-live-v20/instrument-ep/).

```
downloadAll()
```
#### enviroB.py
This is the python file one would edit when switching from demo mode (monopoly money) to a live brokerage account, see more at Oandas API website. There are two functions to either GrabToken() or GrabID() which will grab the users info from the res folder (needs to be edited with ones own API key from [Oanda](https://developer.oanda.com/rest-live-v20/introduction/)

#### plotOHLC.py
This file has one class to plot OHLC data to visually inspect the data.
plotOHLC() has two arugments, the first one is the primary currency and the second is the granularity of the data (ie 5 second candles, 10 minute, 1 days, etc).

```
plotOHLC(primarycur, gran=None)
```

##

**Please note**
A live tick stream has been developed based on [Quant Start](https://www.quantstart.com/articles/Forex-Trading-Diary-1-Automated-Forex-Trading-with-the-OANDA-API) tutorial on an event driven software to control an automatted trading platform. **WARNING** FOR EDUCATIONAL PURPOSES ONLY.

This code will require folder called res in parent directory (this folder). The res folder will need to have a ids.json file for ID and an oanda_api_key.json file for API token issued by Oanda (example json files in res folder). Token and ID Key can be obtained for free from Oanda.


text:
# RedditUnhider

RedditUnhider unhide all hidden posts on your Reddit account.

## Install

RedditUnhider use [RedditKit.rb](https://github.com/samsymons/RedditKit.rb) to interact with [Reddit API](http://www.reddit.com/dev/api)

Run this from the RedditUnhider directory in the terminal:

    bundle install

Or install it directly:

    gem install redditkit

## Use

Run this from the RedditUnhider directory in the terminal:

    rake USERNAME='your_reddit_username' PASSWORD='your_reddit_password'

repository: masolino/reddit-unhider

repo_name: masolino/reddit-unhider


text:
# Self Study

Author: Jedi Chou
Create at 2018.10.19 8:20 AM

## Daily task

* Mail: check 163.com mail。 11:31
* Daily reading task
  -[x] Feedly RSS reader. 10:35
  -[x] InfoQ check. 11:34
  -[x] ZHIHU Daily check. 11:51
  -[x] Exercise of Vocabulary (vocabulary.com). 12:00

* Daily Check-in task
  -[x] 101WeiQi daily exercise check-in. 9:00
  -[x] Don't memorize words APP check-in. 15:53
  -[x] NowCoder check-in and do an exercise that contains 20 puzzles. 15:53
  -[x] 163 music APP check-in. 15:54
  -[x] Tencent cartoon APP check-in. 15:54
  -[x] Read articles and check interview invitation (MaiMai APP). 15:54
  -[ ] Open class APP by 163.com check-in

* Micro habit
  -[x] Reading 1 minutes at SIMPLE Wiki. 15:58
  -[x] Commit a C code to GITHUB or GITEE. 15:58
  -[x] Reading 1 minutes at SZLIB (BOKAN site). 17:37
  -[x] Read a thesis and don't record. 17:37

## New word or concept from reading, action

* New words for me
  * mankind. 10:15
  * fallacies. 10:18
  * cruise. 11:58
  * When you look long into an abyss, the abyss looks into you (Nietzsche). 12:00
* 心理学上的“权威效应”. 11:49

repository: JediChou/jedi-md-book

repo_name: JediChou/jedi-md-book


text:
# pyGPA

[![CI](https://github.com/TAdeJong/pyGPA/actions/workflows/ci.yaml/badge.svg)](https://github.com/TAdeJong/pyGPA/actions/workflows/ci.yaml)
[![Codecov](https://img.shields.io/codecov/c/gh/TAdeJong/pyGPA)](https://app.codecov.io/gh/TAdeJong/pyGPA)
[![DOI](https://zenodo.org/badge/331613874.svg)](https://zenodo.org/badge/latestdoi/331613874)

A python package collecting an assortment of Geometric Phase Analysis algorithms and tools to analyse regular (moiré) lattices.

Geometric Phase Analysis enables the extraction of a _displacement field_ from a distorted lattice, by comparing to reference waves. As such, it is a spatial variant of lock-in amplification. This package implements several specializations of GPA. In particular:
- It extends the original GPA algorithm by optimizing over a range of reference vectors, (as previously described by\[[1](https://doi.org/10.1016/j.optlaseng.2005.10.012)\]) to achieve accurate characterization of larger distortions. This is especially useful when analysing (atomic) small angle moiré patterns.
- From the displacement field, it is possible to extract local properties of the underlying lattice.
- It is also possible from this displacement field, to correct for the distortion, a process known in STM as the Lawler-Fujita algorithm \[[2](https://doi.org/10.1038/nature09169)\].
- Once the displacement field is known, it is also possible to perform unit cell averaging directly from the distorted image, creating low-noise or higher magnification (depending on the PSF of the instrument) images of the unit cell.
- This unit cell average can be extended back to the full image to create a low noise version, or explore difference from mean unit cell.

## Installation

Installation is somewhat non-trivial, due to dependency on a [non-packaged implementation](https://github.com/TAdeJong/moisan2011) of the smooth + periodic decomposition. Furthermore, to use [CuPy](https://docs.cupy.dev/en/stable/install.html) acceleration, a NVIDIA graphics card and working CUDA installation are needed.

First clone the repository. In the `pyGPA` folder, run the following:

```bash
$ pip install -e .
$ pip install git+https://github.com/TAdeJong/moisan2011.git#egg=moisan2011
```

For CUDA acceleration, follow installation instructions of CuPy https://docs.cupy.dev/en/stable/install.html.

## Testing

This project uses ``pytest`` and ``hypothesis`` to run tests. The test coverage is far from complete and can be extented though! To test:

Install the test dependencies.

```bash
$ pip install -r requirements_test.txt
```

Run the tests.

```bash
$ pytest
========================== 20 passed in 42.28s ============================
```

Note: The `cuGPA` tests will be skipped automatically if no working `CuPy` installation is detected.

## See also

https://github.com/TAdeJong/moire-lattice-generator

[T.A. de Jong _et al._Imaging moiré deformation and dynamics in twisted bilayer graphene. Nat Commun **13**, 70 (2022)](https://doi.org/10.1038/s41467-021-27646-1) ([arxiv](https://arxiv.org/abs/2107.14716))

[T. Benschop, T.A. de Jong _et al._ Phys. Rev. Research *3*, 013153](https://doi.org/10.1103/PhysRevResearch.3.013153) (Code not actually used for that work, but builds upon the ideas)

https://github.com/TAdeJong/weighed_phase_unwrap

Kemao, Qian. "Two-dimensional windowed Fourier transform for fringe pattern analysis: principles, applications and implementations." [Optics and Lasers in Engineering 45.2 (2007): 304-317.](https://doi.org/10.1016/j.optlaseng.2005.10.012)

# Acknowledgement

This work was financially supported by the [Netherlands Organisation for Scientific Research (NWO/OCW)](https://www.nwo.nl/en/science-enw) as part of the [Frontiers of Nanoscience (NanoFront)](https://www.universiteitleiden.nl/en/research/research-projects/science/frontiers-of-nanoscience-nanofront) program.

repository: TAdeJong/pyGPA

repo_name: TAdeJong/pyGPA


text:
# Demo

This package includes a demo.  You can [view source on GitHub]() and adapt it to your purposes.  Or you can follow these instructions to run it in the bottlenose repository:

First, clone the source code:
```bash
git clone https://github.com/buccaneerai/bottlenose.git
```

Then build the packages in bottlenose:
```bash
cd bottlenose
yarn bootstrap
```

Run a Socket.io server:
```bash
cd packages/rxsocketio
node ./demo/server.js
```
You should now see the server listining on port 3000!

In another window (in the same working directory):
```bash
cd packages/rxsocketio
node ./demo/client.js
```
Now your client should connect to the server to send and receive messages!  In the client logs, you should see it logging messages that it receives from the server.  In the server logs, you should it logging messages it receives from the client.

repository: buccaneerai/bottlenose

branch_name: refs/heads/dev

repo_name: buccaneerai/bottlenose


text:
# Benchmarking Tools and Standards

This repository contains specifications for implementing benchmarking tools.
We also provide links to our reference benchmarking engines and their
implementations.

** Note: This is work in progress. **

# Standards and Definitions

See [doc/standards/](doc/standards/) for the current
benchmarking standards and definitions.

# Reference tool implementations

A suite of reference implementations following the standards outlined above are available at [tools/](tools/).
These are submodules which link to the original tool repositories.

# Benchmarking Intermediate Files

The benchmarking process contains a variety of steps and inputs. In
[doc/ref-impl/](doc/ref-impl/), we standardise intermediate
formats for specifying truth sets, stratification regions, and intermediate
outputs from comparison tools.

# Benchmarking resources

In [doc/resources/](doc/resources/), we provide files useful in the benchmarking process.  Currently, this includes standardized bed files describing potentially difficult regions for performance stratification.

repository: pkrusche/benchmarking-tools

repo_name: pkrusche/benchmarking-tools


text:
# e-commerce backend app

## Licensing:
[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)

Apache 2.0

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

    1. Definitions.

    "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

    "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

## Table of Contents
- [Description](#description)
- [Installation](#installation)
- [Usage](#usage)
- [Contribution](#contribution)
- [Testing](#testing)
- [Additional Info](#additional-info)

## Description:
I wanted to make a backend app that furthered my understanding of MVC without the view. This includes creating a class/model and controllers/routes.
I built this app to better my understanding of the backend of applications and how servers, databases, routes all talk to each other.
This app gave me a better understanding of the backend of applications
I learned models, controllers, databases and how to interact with them

* Link to video of using app in insomnia
https://drive.google.com/file/d/1ou4QVwnbSYBFBqUgAWdDeu1Ps2LPtlAq/view?usp=sharing

* routing
```
router.post('/', async (req, res) => {
  // create a new category
  try {
    const categoryData = await Category.create(req.body);
    res.status(200).json(categoryData);
  } catch (err) {
    res.status(400).json(err);
  }
});
```

* Modelling and creating relationships
```
// Categories have many Products
Category.hasMany(Product, {
  foreignKey: 'category_id',
})

// Products belongsTo Category
Product.belongsTo(Category, {
  foreignKey: 'category_id',
})
```

## Installation:
You must use an npm install to get the dependencies and use your database login information to correctly start and seed into the database.

## Usage:
You will need to run the database and seed into it via the terminal. To interact with the backend you will need to use insomnia or similar app.

## Contribution:
Contribute via pull requests on github

## Testing:
No tests for this project

## Additional Info
- Github: [stewsabatino](https://github.com/stewsabatino)
- Email<EMAIL_ADDRESS>

repository: stewsabatino/e-commerce-backend

repo_name: stewsabatino/e-commerce-backend


text:
# Treefrog
[![Treefrog][treefrog-image]][treefrog-url]

[![Read the Docs][docs-image]][docs-url]
[![NPM version][npm-image]][npm-url]
[![NPM downloads][npm-download]][npm-url]
[![Build status][ci-image]][ci-url]
[![Dependency Status][daviddm-image]][daviddm-url]
[![Code Climate][codeclimate-image]][codeclimate-url]

SUPER EXPERIMENTAL, BREAKING CHANGES TO COME IN 1.0 RELEASE

This is [Treefrog](https://treefrog.cali-style.com), an isomorphic frontend framework for building powerful responsive apps, from your friends at [Cali Style](https://cali-style.com).

When ZURB stopped working on foundation-apps, we found a wonderful implementation of flexbox and a well written scss library. So we re-implemented these into Treefrog and converted it to [BEM](http://cssguidelin.es/#bem-like-naming) while also adding our own sugar and scrapping all the javascript. Making it the first frontend framework with [Trails](http://trailsjs.io) and Isomorphic apps in mind.

Treefrog doesn't assume that you want to use react or angular or vanillia javascript.  Instead it's just the frontend style library and you can easily tie your javascript framework to it.

Looking for the Trailpack?  Visit <https://github.com/CaliStyle/trailpack-treefrog>.

Looking for the Generator?  Visit <https://github.com/CaliStyle/generator-treefrog>.

## Requirements

You'll need the following software installed to get started tinkering with Treefrog.

  * [Node.js](http://nodejs.org): Use the installer provided on the NodeJS website.
  * [Gulp](http://gulpjs.com/) Run `[sudo] npm install -g gulp`

## Get Started

The Sass components are available on npm.
```sh
$ npm install treefrog --save
```

While working on your project, run:
```sh
$ npm start
```

This will assemble the templates, static assets, Sass, and JavaScript. You can view the test server at this URL:
```
http://localhost:8080
```

## Building this Repo

If you want to work with the source code directly or compile our documentation, follow these steps:
```
git clone https://github.com/CaliStyle/treefrog.git
cd treefrog
npm install
```

While you're working on the code, run:
```sh
$ npm start
```

The documentation can be viewed at the same URL as above.

### Directory Structure

* `build`: This is where our documentation is assembled. **Don't edit these files directly, as they're overwritten every time you make a change!**
* `docs`: The Treefrog documentation.
* `scss`: The Sass components.
* `dist`: Compiled CSS files, in minified and unmified flavors.
* `tests`: Unit tests.

## Versioning

Treefrog follows semver, so we won't introduce breaking changes in minor or patch versions. The `master` branch will always have the newest changes, so it's not necessarily production ready. The `stable` branch will always have the most recent stable version of the framework.

## Contributing

We love contributions!

For Treefrog please check out our [Contributor's Guide](https://github.com/CaliStyle/treefrog/blob/master/CONTRIBUTING.md) for more information on how our projects are organized and how to get started.

For Trails please check out our [Contributor's Guide](https://github.com/trailsjs/trails/blob/master/CONTRIBUTING.md) for more information on how our projects are organized and how to get started.

If you find a problem or have an idea, open a [new issue](https://github.com/CaliStyle/treefrog/issues) on GitHub. When filing a bug report, make sure you specify the browser and operating system you're on, and toss us a screenshot or show us how we can recreate the issue.

[treefrog-image]: http://i.imgur.com/1IiVqTo.png
[treefrog-url]: http://treefrog.io
[docs-image]: https://readthedocs.org/projects/treefrog/badge/?version=latest
[docs-url]: http://treefrog.readthedocs.io/en/latest/?badge=latest
[npm-image]: https://img.shields.io/npm/v/treefrog.svg?style=flat-square
[npm-url]: https://npmjs.org/package/treefrog
[npm-download]: https://img.shields.io/npm/dt/treefrog.svg
[ci-image]: https://img.shields.io/travis/CaliStyle/treefrog/master.svg?style=flat-square
[ci-url]: https://travis-ci.org/CaliStyle/treefrog
[daviddm-image]: http://img.shields.io/david/CaliStyle/treefrog.svg?style=flat-square
[daviddm-url]: https://david-dm.org/CaliStyle/treefrog
[codeclimate-image]: https://img.shields.io/codeclimate/github/CaliStyle/treefrog.svg?style=flat-square
[codeclimate-url]: https://codeclimate.com/github/CaliStyle/treefrog


text:
# Get Started

## 1. Set up NEUTRINO Environment

Click on the `Settings` button on the menu and then set the `NEUTRINO Path` to your NEUTRINO folder.

## 2. Choose Input Files

Click on the `Project` button on the menu, choose `musicxml` or `xml` for the input file, then choose the file.

Click on the `...` button of the model path and choose a model.

## 3. Generate

Click on the `Run` button and find the `Tasks` button in the menu.

Finally, hit on `Run` button in the `Tasks` panel. Your song is now being generated.


text:
---
layout: essay
type: essay
title: Life as Software Engineer
# All dates must be YYYY-MM-DD format!
date: 2021-12-11
labels:
  - Software Programming
  - Learning
  - Workfield Experience
---

## Software Engineer Job

Software Engineers create and develop application tool and website to suit the need of people. Often the software engineer’s work extends to many different fields in the community and economy, like medical, food service, business, government, military, and etc. As software engineers, we need to explore and learn the work process and things in the different fields for order to engage in our only software engineering work.

#### ICS 414

ICS 414 software engineering II, a course provided for computer engineers, software engineers, and computer science students. It is a continuation of ICS 314, which lets students experience learning web development, and additionally develop students' project management, quality, and productivity control, testing and validation, and team management skills. In the ICS 414 course, students were placed in a team-oriented software-implementation project to develop a working web app for an actual customer. In fall 2021, the customer was The Hawaii H.O.M.E. Project organization, and in the project, students must develop an application tool or website to track, manage, and organize the medicine and medical supply item its own.

#### Med-Warriors Project

In the ICS 414, I was assigned to a team for a software-implementation project and we name our team as Med-Warriors. For the software-implementation project, we created a database website with the collection database to track the medicine and medical supply. Addcationly, we implemented input and output to systems to manage and organize the medicine and medical supply in their storage. In the website development process, our team focuses on three things that are IDPM review, unit testing, and acceptance testing. As a team reviewed and tested the functions, pages, and components in the app, and slowly in the development process we improve our teamwork and project management skill.

Visit med-warriors.github.io

path: /essays/Software Engineering 2.md

filename: Software Engineering 2.md


text:
# WILL THIS BE GOOD

[willthisbegood.website](http://willthisbegood.website) is a singe-page website that tells you if certain things will be good or not. All opinions are final.

This website updates daily. To complain about the website, email<EMAIL_ADDRESS>To complain about the opinions, tweet [@badpun](https://twitter.com/badpun)

# Installation

willthisbegood runs on Flask, python3, and a Gmail account. `process_new_things.py` looks at the gmail account, and grabs all emails sent by the whitelisted email. These are then stored in a sqlite3 database, which `wtbg.py` uses to populate the page. To actually install:

1. Clone this repository

    ```shell
    git clone https://github.com/stephenwashington/willthisbegood
    ```

2. Set up a virtual environment

    ```shell
    cd willthisbegood
    virtualenv venv
    . venv/bin/activate
    ```

3. Install the necessary dependencies via pip3

    ```shell
    pip3 install -r requirements.txt
    ```

4. Set the environmental variables

    ```shell
    export FLASK_APP="wtbg.py"
    export<EMAIL_ADDRESS>    export EMAIL_PASS="yourp4ssword"
    export<EMAIL_ADDRESS>    ```

5. Run init_db() in `wtbg.py`

    ```shell
    >>> from wtbg.py import init_db
    >>> init_db()
    ```

6. Run the Flask app (App will be on http://<IP_ADDRESS>:5000)

    ```shell
    flask run
    ```

repository: stephenwashington/willthisbegood

repo_name: stephenwashington/willthisbegood


text:
# Bash script code quality

This repository demonstrates via its commit history the process of improving the
code quality of a Bash script. The commit messages explain the introduced
changes and their motivation while this document lists the used tools and
references.

## Tools

The [ShellSpec] framework is used for testing as it employs a behaviour-driven
development approach with a domain-specific language that helps create easily
readable tests. In addition, it provides many options for mocking and other
useful testing features.

The other essential tool to detect error-prone code or even bugs is the static
code analyser [ShellCheck]. It can be run in the command line or integrated into
editors.

For example, for the presentation of the process, the [ALE] plugin and [Airline]
status line for Vim have been used to show the annotations in the editor.

The [Flog] plugin for Vim has been used to check out the commits one after
another, so tests could be run at the various stages.

## References

### Calling Docker for separate commands

* [Stack Overflow – What is the runtime performance cost of a Docker container?](https://stackoverflow.com/a/26149994)

### Variables

* [Unix & Linux Stack Exchange – Are there naming conventions for variables in shell scripts?](https://unix.stackexchange.com/a/42849)

* [Bash reference manual – Bash builtin commands, `local`](https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html)

### Initialise and run ShellSpec

* [ShellSpec – Project directory](https://github.com/shellspec/shellspec/blob/b2621f7e3f63a5a683a8994bbc916dc794f2dfb8/README.md#project-directory)
* [ShellSpec – runs specfile using `/bin/sh` by default](https://github.com/shellspec/shellspec/blob/b2621f7e3f63a5a683a8994bbc916dc794f2dfb8/README.md#runs-specfile-using-binsh-by-default)
* [ShellSpec – How to use ShellSpec with Docker, Run simple with helper script and extra hooks](https://github.com/shellspec/shellspec/blob/b2621f7e3f63a5a683a8994bbc916dc794f2dfb8/docs/docker.md#2-run-simple-with-helper-script-and-extra-hooks)

### Unit testing single-file scripts

* [ShellSpec – Using `run source`](https://github.com/shellspec/shellspec/blob/b2621f7e3f63a5a683a8994bbc916dc794f2dfb8/README.md#using-run-source)
* [References](https://github.com/shellspec/shellspec/blob/b2621f7e3f63a5a683a8994bbc916dc794f2dfb8/docs/references.md)

### Error handling

* [Stack Overflow – How to exit if a command failed?](https://stackoverflow.com/q/3822621)
* [Bash FAQ – Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?](https://mywiki.wooledge.org/BashFAQ/105)

* [Bash reference manual – Special parameters, `?`](https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html)
* [Bash reference manual – Bourne Shell builtins, `exit`](https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html)

### Writing output

* [Stack Overflow – Why use printf '%s\n' “message”?](https://stackoverflow.com/a/66439091)
* [Unix & Linux Stack Exchange – Why is printf better than echo?](https://unix.stackexchange.com/a/65819)

* [Bash reference manual – Bash builtin commands, `printf`](https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html)

### ShellCheck shell declaration

* [ShellCheck wiki – Directive, `shell`](https://github.com/koalaman/shellcheck/wiki/Directive#shell)

### Custom assertion counting occurrences of a string

* [Bash reference manual – Here strings](https://www.gnu.org/software/bash/manual/html_node/Redirections.html#Here-Strings)
* [Bash reference manual – Shell parameter expansion, `${parameter:?word}`](https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html)
* [Bash reference manual – Conditional constructs, `((…))`](https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html)

### Match function arguments

* [Bash reference manual – Special parameters, `*`](https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html)
* [Bash reference manual – Pattern matching, `*`](https://www.gnu.org/software/bash/manual/html_node/Pattern-Matching.html)

### Command substitution

* [Bash FAQ – Why is $(...) preferred over `...` (backticks)?](https://mywiki.wooledge.org/BashFAQ/082)

* [Bash reference manual – Command substitution](https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html)

### Working with calculation results

* [Bash reference manual – Arithmetic expansion](https://www.gnu.org/software/bash/manual/html_node/Arithmetic-Expansion.html)

### Define multiline string variables

* [Stack Overflow – How to assign a heredoc value to a variable in Bash?](https://stackoverflow.com/q/1167746)

* [Bash reference manual – Here documents](https://www.gnu.org/software/bash/manual/html_node/Redirections.html#Here-Documents)
* [Bash reference manual – Shell parameter expansion, `${parameter/pattern/string}`](https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html)
* [Bash reference manual – ANSI-C quoting](https://www.gnu.org/software/bash/manual/html_node/ANSI_002dC-Quoting.html)

### Call original command instead of mock

* [ShellSpec – Support commands, Execute the actual command within a mock function](https://github.com/shellspec/shellspec/blob/b2621f7e3f63a5a683a8994bbc916dc794f2dfb8/README.md#execute-the-actual-command-within-a-mock-function)

### Prefer `[[ ]]` test over `[ ]` in Bash

* [Bash FAQ – What is the difference between `test`, `[` and `[[` ?](https://mywiki.wooledge.org/BashFAQ/031)
* [Bash Guide – Practices, Choose your shell](https://mywiki.wooledge.org/BashGuide/Practices#Choose_Your_Shell)

### Define default value for variable

* [Bash reference manual – Shell parameter expansion, `${parameter:-word}`](https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html)

### Problems with looping over `find` output

[Bash Pitfalls – `for f in $(ls *.mp3)`](https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_.2A.mp3.29)

### Read `find` output into array

* [Bash FAQ – How can I find and safely handle file names containing newlines, spaces or both?](https://mywiki.wooledge.org/BashFAQ/020)
* [Stack Overflow – How can I store the “find” command results as an array in Bash](https://stackoverflow.com/a/54561526)
* [Unix & Linux Stack Exchange – Bash: pipe 'find' output into 'readarray'](https://unix.stackexchange.com/questions/263883/bash-pipe-find-output-into-readarray#comment1222591_651445)

* [Bash reference manual – Arrays](https://www.gnu.org/software/bash/manual/html_node/Arrays.html)
* [Bash reference manual – Grouping commands, `{}`](https://www.gnu.org/software/bash/manual/html_node/Command-Grouping.html)
* [Bash reference manual – Bash builtin commands, `readarray`](https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html)
* [Bash reference manual – Process substitution](https://www.gnu.org/software/bash/manual/html_node/Process-Substitution.html)
* [Bash reference manual – Job control builtins, `wait`](https://www.gnu.org/software/bash/manual/html_node/Job-Control-Builtins.html)
* [Bash reference manual – Special parameters, `!`](https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html)

### Useless use of `cat`

* [Wikipedia – Cat, Useless use of cat](https://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat)

### Execute command upon script termination

* [Bash reference manual – Bourne Shell builtins, `trap`](https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html)

[ALE]:
https://github.com/dense-analysis/ale

[Airline]:
https://github.com/vim-airline/vim-airline

[Flog]:
https://github.com/rbong/vim-flog

[ShellCheck]:
https://www.shellcheck.net

[ShellSpec]:
https://shellspec.info

repository: jometzner/bash-script-code-quality

repo_name: jometzner/bash-script-code-quality