text:
---
layout: page
title: Designing and implementing a protocol in Ivy
---

In this tutorial, we'll learn how to take a distributed protocol from
an abstract model to working implementation in Ivy. The example we
will use is a simple ring-based leader election protocol introduced in
[this paper](http://dl.acm.org/citation.cfm?id=359108) in
1979.  The Ivy source code is in the file `leader_tutorial.ivy`.
This is an example of a *parameterized system*, because the
protocol can have an arbitrary number of similar participants. We will
see how parameterized protocols are modeled and implemented in Ivy.

In the leader election protocol, we have a collection of distributed
processes organized in a ring. Each process can send messages to its
right neighbor in the ring and receive message from left neighbor. A
process has a unique `id` drawn from some totally ordered set (say,
the integers). The purpose of the protocol is to discover which
process has the highest `id` value. This process is elected as the
"leader".

The protocol itself is trivially simple. Each process transmits its
own `id` value. When it receives a value, it retransmits the value,
but only if it is *greater than* the process' own `id` value. If a
process receives its own `id`, this value must have traveled all the
way around the ring, so the process knows its `id` is greater than all
others and it declares itself leader.

### The service specification

When designing a system in Ivy, we start with a *service
specification*. The service specification describes the interface of
the system, and tells us what properties the interface should satisfy.
In Ivy, a unit of verification is called an *isolate* (because it is
verified in isolation). An isolate consists of an *interface*,
containing exported types, procedures and functions, a
*specification*, describing the externally observable properties of
the interface, and an *implementation* that provides executable bodies
for interface functions and procedures, as well as variables and theories
that are hidden from the isolate's environment.

Here is how the interface and specification of the leader election
service are described in Ivy:

    isolate leader = {

        action elect(self:node)

        specification {
            before elect {
                ensure pid(self) >= pid(X)
            }
        }
    }

Procedures in Ivy are called *actions*. Unlike functions, actions may
have side effects. The external interface of our isolate `leader` consists of
one action, which is a callback: `elect` is called by the isolate
when a node is elected leader, and implemented by the
environment. There is no explicit declaration in Ivy as to which
isolate implements a given interface action. Ivy only requires that
each action have at most one implementation.

The `elect` action has parameter `self` of type `node`. This
parameter acts like a process identifier. It tells us the *location*
in which the action occurs. This is how Ivy represents a
parameterized, distributed system -- an action has a location
determined by its first parameter.

The `specification` section tells us what is assumed and what
guaranteed by isolate `leader`. In this case, the specification says
only that before calling `elect`, the implementation guarantees that
its `pid` is the maximum among all processes. The guarantee is given
by an `ensure` statement. This is like an `assert` statement in other
languages, which gives a formula that must be true when the statement
executes. The difference is the `ensure` defines an assertion that is
a *guarantee* for the isolate. It is the responsibility of the
implementation of `leader` to make this assertion true, regardless of
what the environment does.

We will postpone the definitions the datatype `node` and the
function `pid` that are used in this specification.

### An abstract model of leader election

After specifying the interface of our system, our next task is to
model the protocol abstractly. An abstract model, by hiding details of
the implementation, allows us to focus on the essence of the proof.
Once we have verified an abstract model, we can use the correctness of
the abstract model as a lemma in the proof of various implementations.

An abstract model of a protocol usually has a variety of actions
corresponding to various steps in the protocol. It has state
variables that typical describe in some abstract way the information
that has been transmitted between parties in the protocol. In the case
of the leader election ring, we have two abstract actions: `send(n,p)`
corresponds node `n` sending pid `p` to the next node in the ring, while
`elect(n)` corresponds to a node `n` declaring
itself leader. We have one state variable called `sent`. This is a
binary relation between pids and nodes, such that `sent(P,N)` is true
when pid `P` has been sent to node `N`. When possible, we represent
the abstract state of protocols with relations rather than functions
(i.e., maps) in order to keep our proof obligations within the
decidable EPR fragment.

Here is the representation of the abstract protocol model in Ivy:

    isolate abstract_model = {
        action send(n:node,p:id)
        action elect(n:node)

        specification {
            relation sent(V:id,N:node)

            after init {
                sent(V,N) := false;
            }

            before send {
                require sent(p,n) & p > pid(n) | p = pid(n);
                sent(p,n.get_next) := true;
            }

            before elect {
                require sent(pid(n),n);
                ensure forall N. pid(N) <= pid(n);
            }
        }
    } with node, id, pid_injective

Notice that the specification section has a state variable
`sent`. Specification state of an isolate is visible to its
environment, and is often used to help specify properties. On the
other hand, implementation state of an isolate is hidden from its
environment. The variable `sent` is initialized in an `after init`
block.  In the assignment `sent(V,N) := false`, the capitalized
symbols `V` and `N` are placeholders. This represents a simultaneous
update of `sent(V,N)` top false for all values of `V`, `N` (thus
initially, no pids have been sent).

Before an `send(n,p)` event can occur, we require that either `p` is
the pid of node `n`, or that `p` has been sent to `n` and is higher
than the pid of `n`. This is represented by a `require` statement.
The `require` statement is another form of assertion that states a
condition that is n *assumption* for the isolate. It is the
responsibility of the *environment* to make sure this assertion is
true. Before an `elect(n)` event occurs, we require that node `n` has
been sent its own pid (meaning that this pid must have made a complete
circuit, and hence is as high as than any other pid in the ring).

We have one additional specification for `elect`: we ensure that in
fact the pid of node `n` is maximal in the ring. Finally, notice the
declaration `with node,id,pid_injective` at the end of the
isolate. This tells Ivy that the correctness of this isolate depends
on the specifications of isolates `node` and `id`. These isolates are
abstract datatypes that we will examine shortly. We also use an axiom
`pid_injective` (which we will examine later) which states that the
pids of the nodes are distinct. Without this fact, the protocol
doesn't work, since a node could receive its own pid without that
value having made a full tour of the ring.

### Proving the abstract model

Before continuing, we should prove that our abstract model is correct
(meaning that the `ensure` condition always holds, assuming that the
environment satisfies the `require` conditions).  We do this by
providing an *inductive invariant*. An inductive invariant is a
formula about the state that has the following key properties:

- *initiation*: It is true in all initial states.

- *consecution*: If it is true in a state, then after executing any
action, the formula remains true.

An inductive invariant for an isolate is guaranteed to hold at all times
between executions of the interface actions.
An inductive invariant is relatively easy to prove, since
we only have to verify the initiation and consecution properties, a task
which Ivy can usually perform automatically. Often, though, the
invariant properties we really want to prove are not inductive and we
therefore require some cleverness to *strengthen* the desired
invariant to make it inductive.

Ivy makes this step easier by providing tools to visualize the
failures of inductive proofs and suggest possible refinements to the
proof. We start by naively trying to verify the abstract model using
this command:

    $ ivy_check isolate=abstract_model trace=true leader_tutorial_no_proof.ivy

Ivy uses the Z3 theorem prover to try to verify the program
assertions, given the invariants.  Since we have given no invariants,
it effectively has to verify that the `ensure` condition holds when the
action `elect` is occurs in any state (and given the specifications of
the datatypes `node` and `id`). This is not the case, so a
counterexample execution is produced (we know a counterexample can be
produced because we are using only the EPR logic, which has the finite
model property).

The counterexample trace starts in a state with two nodes, in which
the node having the smaller pid is receiving its own pid. Clearly,
this state should not be possible. We can rule out this state (and others like it)
be dding the following invariant to the isolate:

    invariant ~(N.pid < M.pid & sent(N.pid,N))

The capital letters in this formula are free variables. They are
implicitly universally quantifier, so this statement applies to all
nodes `M` and `N`.  It says that it should never be the case that a
node receives its own pid and another node has a greater pid. In fact,
Ivy can help us to construct this invariant from the counterexample (see
[this tutorial](http://microsoft.github.io/ivy/examples/leader.html)).

We add this invariant to the isolate and try again.  This time, Ivy
show us a counterexample to induction with three nodes in the
ring. The nodes occur in the order `0`, `1`, `2`.  Node `2` is
receiving the pid of node `0`, but the pid of node `1` is higher.
This leads to a state in which `0` is receiving its own pid
incorrectly, violating our stated invariant. Clearly, this situation
is not possible, since the pid of `0` cannot bypass node `1` to reach
node `2`. This leads to the following conjectured invariant (which
again Ivy can help us construct):

    invariant ~(L < M & M < N & L.pid < M.pid & sent(L.pid,N))

This says that it is never the case that three nodes occur in the order `L < M < N`,
such that the pid of `L` is less than the pid of `M` and the pid of `L` has reached `N`.
After two more similar counterexamples and strengthenings we reach an inductive invariant
which can be stated as follows:

    private {
        invariant ~(pid(N) < pid(P) & sent(pid(N),N))
        invariant ~(L < M & M < N & pid(L) < pid(M) & sent(pid(L),N))
        invariant ~(L < M & M < N & pid(M) < pid(N) & sent(pid(M),L))
        invariant ~(L < M & M < N & pid(N) < pid(L) & sent(pid(N),M))
    }

We put the invariants inside a private section, so that they are
hidden from other isolates.

At this point, the abstract model is verified and Ivy says `OK`. This
mode of constructing an inductive invariants iteratively by
considering counterexamples is typical. In this process, it is
advantageous to restrict oneself to a decidable logical fragment such
as EPR, so that one can reliable generate true
counterexamples. Otherwise, considerable effort can be wasted in
determining why the theorem prover failed to prove an invariant.
We will next consider *why* the formulas to be proved in this case are
actually in EPR.

### Abstract datatypes

An important trick for keeping proof obligations in a decidable
fragment is to use *abstract datatype*. Consider in our case the types
`node` and `pid`. If these are represented by integers (or in the case
of `node`, the integers modulo a constant) the above invariant is
certainly correct. However, this would take us outside EPR, since the
`<` sign would be *interpreted* as the arithmetic less-than
relation. This would take us not only outside of EPR, but outside of
the richer fragment FAU support by Z3.

It turns out, however, that we don't need to know that the `node` and
`id` types are integers to do the proof. This is an unnecessarily
strong assumption. Instead, we only need some simple properties of
these types that *are* expressible in EPR.

For example, we do need the fact that both types are totally ordered
(without these facts, Ivy will give a counterexample). We can write down the
total order properties as follows:

    module totally_ordered(t) = {
        property [transitivity] X:t < Y & Y < Z -> X < Z
        property [antisymmetry] ~(X:t < Y & Y < X)
        property [totality] X:t < Y | X = Y | Y < X
    }

A `module` in Ivy is a kind of template. This template can be
instantiated for any type `t` and states that the `<` relation on type
`t` is totally ordered.  This is not an assumption: the stated
properties must be *proved* for each such type.

As an example, the `id` abstract datatype is declared as follow:

    isolate id = {
        type this
        specification {
            instantiate totally_ordered(this)
        }

        implementation {
            interpret this -> bv[32]
        }
    }

The isolate `id` exports a type as part of its interface. The name of
this type is also `id`, which we declare using the special notation
`type this`. The specification *instantiates* the total order
properties for type `id`. This means that the environment can rely on
these properties.  The *implementation* section tells us that the type
`id` is actually represented by bit vectors of length 32. The notation
`bv[32]` stands for the *theory* of 32-bit vectors, which is built
into Z3, and includes interpretations of (unsigned) arithmetic
operators and inequalities. If we included this theory in the
specification of `id`, Ivy would try to use it in verifying our
abstract model. However, since we hide it in the implementation, the
proof of the abstract model uses only the total order properties in
the specification section.

The `id` datatype requires verification. Ivy can accomplish this automatically using
this command:

    $ ivy_check isolate=id leader.ivy

Ivy uses the built-in bit vector theory of Z3 to prove the total order properties.
This is easy, because it requires no reasoning about quantifiers over long bit vectors,
as all the quantifiers in the properties become Skolem symbols.

The `node` datatype is a little more complex. This is because we need
a `next` operator gives the next node in the ring. In the
implementation of `node`, we could use a fixed datatype (for example,
a particular integer subrange or bit vector length). However, we want
our system to be *parameterized* so that we can instantiate and run it
for any size ring. To accomplish this, we use a built-in module called
`iterable`. It provides a finite sequence of values whose length is
determined by a run-time parameter. It defines a symbol `max` that
gives the last element of the sequence and an action `next` that gives
the next element in the sequence if there is one.

    instance node : iterable

We can then refine this built-in type by giving it additional traits:

    object node = { ...
        action get_next(x:this) returns (y:this)

        specification {
            after get_next {
                ensure (y <= X & X <= x) | (x < y & ~ (x < Z & Z < y))
            }
        }

        implementation {
            implement get_next {
                y := 0 if x = node.max else x.next;
            }
        }
    }

The `node` isolate provides an action `get_next` that returns the next
node in the ring. This specified by an `ensure` statement that must
hold when the action returns. This says that either there are no
values between the input `x` and the output `y`, or `x` is the maximum
value of the type and `y` is the minimum (in other words, the ring
wraps around from the last element to the first). In the
implementation of `get_next`, we return 0 for `max` and the next value
otherwise. The properties of `iterable` are enough for Z3 to prove the
`ensure` condition of `get_next` (in fact, this proof uses only EPR).

Notice what we have accomplished here: we have used modularity to
hide the theories `bv[32]` and `iterable`. In this way we have eliminated
arithmetic reasoning from the verification of our abstract model.
This is important because mixing arithmetic with quantifiers could
make the theorem prover behave unreliably. It also makes the
abstract model more generic. That is, we know that we can substitute
for `node` and `id` any datatypes that satisfy their specifications.

A final element that we require is the map from nodes to process ids.
The map could be chosen randomly. However, we will make it a run-time
parameter. We can declare it like this:

    parameter pid(N:this) : id

    axiom [pid_injective] pid(N) = pid(M) -> N = M

Since the pids will be provided by the user at run time, there is no
way us to prove that all the pids are distinct. Instead we take it as
an *axiom*. We use this axiom when proving the abstract model.

### Implementing the protocol

Now it is time to implement the service specification. To make things
interesting, we will add a small optimization to the
implementation. That is, rather than having a node pass on every id it
receives, it will instead accumulate the highest pid seen and
periodically pass this along.

To implement the protocol, we will need a transport service that sends
messages on an actual network. The Ivy standard library provides some
simple services for this purpose. We will use one called `udp_simple`
that implements an unreliable datagram service using UDP. The service
specification of `udp_simple` looks like this:

    module udp_simple(addr,pkt) = {

        import action recv(dst:addr,v:pkt)
        export action send(src:addr,dst:addr,v:pkt)

        specification {
            var sent(V:pkt, N:addr) : bool
            after init {
                sent(V, N) := false
            }
            before send {
                sent(v,dst) := true
            }
            before recv {
                ensure sent(v,dst)
            }
        }
    }

It takes a type of process identifier `addr` and a type of packet `pkt`
and provides actions for sending and receiving packets. Notice that
the first parameter of each action defines the *location* where the
event occurs (it is the destination for a receive event and the
source for a send event). The specification records only which packets
have been sent to which destinations, and ensures only that a packet
received at a destination must have been sent to that destination.  Of
course, the fact that the actual operating system and network
implement the `upd_simple` specification can't be proved (apart form the fact the
the OS is hard to verify, we can prove nothing about the physical
configuration of the hardware). We can *test* that the actual system
conforms to this specification, but formally it remains an assumption.

We also use a system timer service to call us periodically. Here is its
interface:

    module timeout_sec = {
        action timeout
    }

This interface doesn't actually specify anything formally about the timer service.
The service calls action `timeout` once per second, but Ivy doesn't provide a way
to specify real time properties and our protocol doesn't depend on them.

Using these system services, here is the implementation of `leader`:

    isolate leader = { ...

        implementation {

            instantiate net : udp_simple2(node,id)

            instantiate timer(N:node) : timeout_sec

            var highest(N:node) : id

            after init {
                highest(N) := pid(N);
            }

            implement timer.timeout(self:node) {
                call abstract_model.send(self,highest(self));
                call net.send(self,self.get_next,highest(self));
            }

            implement net.recv(self:node,v:id) {
                if v = pid(self) {
                    call abstract_model.elect(self);
                    call elect(self);
                }
                else if v > highest(self)  {
                    highest(self) := v;
                }
            }
        }

    } with node, id, abstract_model

Our implementation of `leader` contains an instance `net` of `udp_simple`,
with `node` as the address type and `id` as the packet type. It also
contains a parameterized collection of instances of the `timeout_sec`
service. That is, there is one instance of `timeout_sec` for each node.

The state of the node is capture by one state variable, `highest`,
representing the highest pid seen so far by the node. Notice that this
variable is also parameterized, since there is one instance of it per node.
Initially, we set the value of `highest(N)` to be the pid of node `N`.
This is another example of a parameterized assignment. In this case, the
assigned value depends on the parameter `N`.

Now we implement two actions. The first is `timer.timeout`. When a
timeout occurs, we send the highest pid we have seen to the next node
in the ring.  We also create a corresponding abstract model event by
calling its `send` action.  When this occurs, we execute the `require`
statement of `send` in the abstract model, which means we must verify
that node `n` is either sending its own pid, or a higher pid that has
been sent to it in the past. IN other words, the `require` condition is an
*assumption* for the `abstract_model` isolate, but a *guarantee* for
the `leader` isolate.  Assuming the condition holds the abstract model's
specification state is updated to reflect the send action.

When a network receive event occurs, the action `net.recv` is
called. Because of the `require` statement in the specification of
`udp_simple`, the caller of this action guarantees that the received
message has been sent in the past to node `n`. If node `n` receives
its own pid, it has the maximum pid.  It therefore calls the abstract
model `elect` action. This action has a `require` condition that in
fact the pid of `n` has been sent to `n` in the abstract model.  The
implementation must guarantee this condition. If this holds, then the
abstract model ensures that in fact the pid of node `n` is
maximal. Thus, in the next step when we call the `elect` action of
`leader`, we know that its precondition is satisfied.  In effect, we
have used `abstract_model` as a lemma in the proof of `leader`. If we
satisfy its `require` conditions, we can rely on its `ensure`
conditions. This is very similar in concept to the use of functions
and procedures as lemmas in languages such as Dafny and F*. The
difference here is that we are using a stateful interface as a lemma.

In the `with` clause of `leader`, we specify `abstract_model`, since
we use the specification of `abstract_model` to prove `leader`. Notice
that we don't specify the axiom `pid_injective`, because it isn't
needed for the proof. This axiom has been effectively hidden by the
abstract model, and replaced by its `ensure` condition. This kind of hiding can
useful to keep our proof obligations in the prover's decidable fragment (though
this is not needed here).

To finish the program, we add this declaration:

    import leader.elect

This says that the `elect` action of the `leader` isolate will be
implemented by the run-time environment.

### Proof of the implementation

No we have to do the proof. That is, we have to prove that in fact
`leader` guarantees the requirements of the abstract mode actions it
calls, and that, given the assurances made by the abstract model, it
satisfies its own specification.

We can ask Ivy to do the verification like this:

    $ ivy_check isolate=leader leader.ivy

Ivy will show us a counterexample to induction. In the counterexample,
we may see a state in which node `n` in `leader` sends its `highest`
pid, but this pid has never been sent in the abstract model. We need
to specify an inductive invariant to show that the two models stay in
sync. We need to say that the `highest` value of each node has been
sent to that node in abstract model, or is its own pid. We also have
to say that every message sent in `net` has also been sent in the
abstract model.  Finally, we have to say that the `highest` value of
`n` is at least as large as its own pid. Each of these invariants can
be derived by considering counterexamples to induction. Here is our invariant
for leader:

    invariant highest(N) = pid(N) | abstract_model.sent(highest(N),N)
    invariant net.sent(V,N) -> abstract_model.sent(V,N)
    invariant highest(N) >= pid(N)

Notice that we do not have to concern ourselves here with the
invariants that were used to prove correctness of `elect`. This is
guaranteed to us by `abstract_model`. The invariant we used as a joint
invariant of `leader` and `abstract_model`. We can also think of it as
a *refinement relation* since it gives a correspondence between states
of the two isolates that proves that every action of `leader` corresponds to
an appropriate action of `abstract_model`. In general, the invariants of an isolate
refer to its own state and the *specification* state of the isolates it depends on, but not the implementation state, which is hidden.

### Abstracting a distributed implementation

We wrote `leader` as a sequential reactive program (reactive meaning
it only acts in reaction to events in its environment). Runs of this
sequential program can be thought of as concurrent runs in which each
action call occurs in a location (i.e., a separate process space) that
is determined by its first parameter. This illusion is maintained so
long as each action refers only to state that is stored in its own
location.  For example, the implementation of `net.recv` may refer to
`highest(n)`, where `n` is its location, but not to any other element
of `highest`. If this condition holds, we say the parameterized
program is *non-interfering*. From a non-interfering program, the Ivy compiler
can construct an executable corresponding to a single location `n`. This program is called
an `extract`. We specify it like this:

    extract code(n:node) = leader(n), pid(n), node, id

The extract is parameterized on a node `n`. It consists of the `leader` isolate
for parameter `n`, the value of the `pid` map for `n`, as well as the node and
id isolates (which are not parameterized, and which therefore cannot have state).

When we extract code, the specification sections of the isolates are
erased.  The specification state variables and code (including
assertions) are not present in the extract. Ivy verifies that this
erasure is sound, in the sense that the erased code has no effects
that are visible to the remaining code (including non-termination).
This means that the observable behavior of the program is not affected
by erasure of the specifications. In particular, since out abstract
model is a pure specification, it is not extracted. The calls from
`leader` to `abstract_model` are "ghost" code, having no effect.

We still need to know, however, that the distributed program is in
some sense equivalent to the sequential program that we verified.  Ivy
guarantees that the distributed version is serializable, in the sense
the every concurrent execution is observably equivalent to a
sequential execution, in which each action completes atomically. The
proof of this uses Lipton's theory of left- and right-movers (in
particular, each incoming call to the program is a right-mover, while
each outgoing call is a left-mover). The validity of this argument
(which is made "on paper") depends on the fixed specifications of the
run-time services.

We compile the code with this command:

    $ ivyc leader.ivy

This produces a binary executable file called `leader` (under
Unix-like operating systems).

### Running the leader election protocol

We can now run the protocol for a chosen ring size. The `leader` binary
takes three parameters on the command line: `node.size` (the size
parameter of the `node` type) `pid` (the pid value for the node) and
`n` (the node identifier, in the range `[0,node.size)`. The order of these
parameters on the command line is determined by their order of declaration
in the program.

For a ring of size three, we can create three terminals named `A`, `B`, `C`
and execute the following commands:

    A: $ ./leader 3 1 0
    B: $ ./leader 3 3 1
    C: $ ./leader 3 0 2

The UDP port numbers for these process are chosen by a default scheme -- for a real
system we would have to provide the IP addresses of all of the processes.
Notice that process `B` should be the leader, since it has the highest pid. In fact,
after three seconds, we see this output on terminal `B`:

    < leader.elect
    < leader.elect
    < leader.elect
    ...

The compiler gave `leader.elect` a default implementation, which is simply to
print a log message.  We can also compile the program as library and provide
our own implementation of `leader.elect` in C++.

### Conclusion

We have seen how to use Ivy to implement a distributed protocol. There are three
main components: a service specification, an abstract model and an implementation.
The abstract model is not absolutely necessary, but it can simplify the proof process,
by allowing us to disregard implementation details. The abstract model state is usually
expressed using only relations, so we can do the proof in the decidable fragment EPR.
To achieve this, we also hide the full theories of the datatypes inside isolates,
using only the abstract properties of these types that are needed for by the protocol.
The implementation is then specified and proved using the abstract mode as a lemma, and
using system services provided by the Ivy run-time. The abstract model can also be used
theories from the implementation.

The resulting proved parameterized sequential program can then be extracted to an
executable distributed program with an arbitrary number of processes, provided some
non-interference conditions are met.

repository: MadeByMars/ivy

gha_license_id: NOASSERTION

repo_name: MadeByMars/ivy


text:
# SizeExplorer

A visualizer for il linker related data

# To launch local instance of Visualizer:
Run `sh ./run.sh <path of dll>`

# Directory Structure:
```
WebApp/: WebApp created using WebAssembly and d3.js to plot wasm linker performance

tools/:
    | web/: files for plotting JSON with d3.js
    | pyscripts/: preliminary python scripts for data exploration
```

# To run web app separately:
In the WebApp/ folder, run:

`dotnet run`

Go to localhost:5001

Data is in the `WebApp/wwwroot/json/` directory, and should be a json of the format:

```
[
    {
        "name": assembly name,
        "size": #,
        "sections": [
            {
                "name": class name,
                "size": #,
                "sections": [
                    {
                        "name": method name,
                        "size": #,
                        "sections": null
                        ...
```

license: MIT

repository: wasm-spot/Visualizer

branch_name: refs/heads/master

extension: md

gha_language: Jupyter Notebook

gha_license_id: MIT

license_type: permissive

repo_name: wasm-spot/Visualizer


text:
# Has Flutter passed React Native yet?

> A Dart Web App to compare GitHub stars of Flutter and React Native

![Screenshot](screenshot/1.png)

## Development Tools
- [Dart](https://webdev.dartlang.org/tools/sdk#install)
- [Web Storm](https://www.jetbrains.com/webstorm/)

## Todo
- [ ] Visual Polish
- [ ] Refresh Button

## Inspired By
[hasvuepassedreactyet](https://github.com/stursby/hasvuepassedreactyet) Created by [Charlie Hield](https://github.com/stursby/)

## Credits
Created from templates made available by Stagehand under a BSD-style
[license](https://github.com/dart-lang/stagehand/blob/master/LICENSE).

gha_language: JavaScript


text:
title=ManageInventory Interface Specification
type=partial
~~~~~~

# Introduction

## Purpose

The purpose of this document is to describe the Service interface from the logical (functional) perspective.

## Scope

The structure of the document reflects the key parts of the interface. This includes the:

- Operation Behavior
- Request
- Response
- Faults

This document applies to:

- The functional level interface description for the service
- It details the service from a non-technical “black box” level to describe the service input and output messages and concepts.

This document does NOT address:

- Technical specifications, or physical design details of the service
- Description of Functional and Non functional requirements

## Target Audience

| Audience             | Intended Purpose |
|----------------------|------------------|
| Business Stakeholder | High level understanding. Provide non-technical audience with a broad understanding of the service behaviour and constraints. |
| Project  Team        | Project Planning. To support ongoing project planning. |

repository: drewstewart/nbn-jbake

repo_name: drewstewart/nbn-jbake


text:
# Bubble Menu

This package creates a cool customizable menu for atom.

![Image](media/bubblemenu.gif?raw=true)

The menu is hidden by default and can be triggered by hovering on the bottom right corner of your your editor window.

You can customize it with preferred colors, commands and icons.

![Image](media/colorss.png?raw=true)

## Installation

The easiest way to install bubble-menu is to do as follows:

- Go to Atom > Settings
- Click "+ Install"
- Search for `bubble-menu` and click `packages` button to search.
- Browse for `bubble-menu` and click `install`
- Restart atom to activate the package.

Alternatively you can use the [Atom Package Manager](https://github.com/atom/apm):

```bash
apm install bubble-menu
```

---

## Customizing

### adding and editing bubbles.

To add your own bubbles or edit the existing ones,

- Right click on your editor
- Look for `bubble-menu-config` and click it.
- edit the displayed file [`bubble-menu.cson`] following the existing style. i.e
  ![Image](media/config.png?raw=true)
  - Enter a new entry as shown below.
  - The new entry should entered before the close of the square bracket `]` ( example after line `26` in the above image) .
  - After editing, you'll have to restart atom for the changes to take effect.

```
{
  command: "your command"
  icon: "selected icon"
  text: "text to be displayed beside the icon"
}
```

**PS**:

- Select icons only from the available ones included [here](https://dann254.github.io/bubble-menu-icons).
- You can find commands available on your editor using `command - shift - P` or `ctrl - shift - P` if you are on windows.</br>
  Hovering on the commands displayed on the modal, shows the precise text you can use on `bubble-menu`.
  ![Image](media/commands.png?raw=true)
- bubble-menu supports only 15 bubbles. any extra bubbles will not be displayed.
- Any errors in the bubble-config might cause the bubble to be displayed in a weird manner or cause the package to fail. Good for you, Atom will notify you of this 😆.
- You can reorder the bubbles in the config file as per your preference.

### Bubble menu settings.

After installing bubble-menu.

- Go to Atom > settings
- Click `Packages`
- Search for bubble-menu
- click the settings button on the bubble menu card.

![Image](media/settings.png?raw=true)

These settings allow you to customize the look and experience of the bubble-menu.

# Just incase you are wondering 🙂

- **UI theme** : [atom-ice-ui](https://atom.io/themes/atom-ice-ui)
- **Syntax theme** : [atom-ice-syntax](https://atom.io/themes/atom-ice-ui)

---

# Contributing

Anyone is welcome to contribute to the development of this package. It can be a lot of work to keep up on, and I'll take help wherever i can get it :)

## Getting The Code

### 1. Fork

If you're keen to contribute, start by [forking](https://github.com/dann254/bubble-menu#fork-destination-box) the repo and cloning it to your computer.

**Note:** To use the development version, you must first install the production version (`apm uninstall bubble-menu`), then and run the following commands from the root of the bubble-menu project:

```sh
# To install the local version as an Atom Theme
apm link .

# Open with dev mode:
atom --dev .
```

### 2. Make Some Changes

Once this is complete you will be able to edit bubble-menu files directly in Atom and see your UI changes in real time other changes might need you to reload the editor.

### 3. Create a Pull Request

Once you are satisfied, with your updates, commit your change, push them to your fork and submit a pull request with a description of the changes that you made.

### 4. Unlink

Once you're done working locally and ready to install the production version again, simply run `apm unlink .` from the root of the bubble-menu project.

---


text:
# babel-nodepack

[![NPM version][npm-image]][npm-url]
[![Build status][travis-image]][travis-url]
[![Test coverage][codecov-image]][codecov-url]
[![Dependency Status][david-image]][david-url]
[![License][license-image]][license-url]
[![Downloads][downloads-image]][downloads-url]

A bundler for node.js projects using [babel](http://babeljs.io/).
Compiles all your _local_ files into a single script suitable for node.js usage.
This differs from webpack/browserify in that:

- It's much simpler
- Only uses babel
- Does not parse `node_modules` - it assumes modules will still be available
- Only supports CommonJS build outputs

## Features

- Automatically caches builds to the local file system.

## Caveats

- `__dirname` and `__filename` are not supported
- Dynamic requires like `require('./' + 'file')` are not supported

## API

### nodepack(options).then(result => )

Returns:

- `result.tree` - the dependency tree as an array
- `result.code` - the JS code bundled together

Options:

- `filename` - entry file
- `hash` - hash for the entire build for testing.
  This should primarily be based on babel configs.
- `presets` - an array of babel presets to use.
- `plugins` - an array of babel plugins to use.

### nodepack.cache.CACHE_DIR

The location of the cache directory.
You could also set it via `BABEL_NODEPACK_CACHE_DIR=`.

### nodepack.cache.rimraf().then(() => )

Clear the nodepack cache folder.

### nodepack.cache.mkdirp().then(() => )

Make sure the nodepack cache folder exists.

[npm-image]: https://img.shields.io/npm/v/babel-nodepack.svg?style=flat-square
[npm-url]: https://npmjs.org/package/babel-nodepack
[travis-image]: https://img.shields.io/travis/jonathanong/babel-nodepack.svg?style=flat-square
[travis-url]: https://travis-ci.org/jonathanong/babel-nodepack
[codecov-image]: https://img.shields.io/codecov/c/github/jonathanong/babel-nodepack/master.svg?style=flat-square
[codecov-url]: https://codecov.io/github/jonathanong/babel-nodepack
[david-image]: http://img.shields.io/david/jonathanong/babel-nodepack.svg?style=flat-square
[david-url]: https://david-dm.org/jonathanong/babel-nodepack
[license-image]: http://img.shields.io/npm/l/babel-nodepack.svg?style=flat-square
[license-url]: LICENSE
[downloads-image]: http://img.shields.io/npm/dm/babel-nodepack.svg?style=flat-square
[downloads-url]: https://npmjs.org/package/babel-nodepack

repository: jonathanong/babel-nodepack

repo_name: jonathanong/babel-nodepack


text:
### Level-set grid for 1/2 circular cylinder

Compressible potential flow at Mach 0.4 over a circular cylinder using a
1/2 mesh with symmetry conditions.

### Steps to make the run
1. Check the paths in `run.sh`
2. Note that you need the ogrid mesh generator from lns3d
3. `./run.sh`

### Visualizing the results

To use `paraview` you may want to do:

    ln -s grid.dat grid.xyz

### Sample Results

#### Contours of streamwise velocity

![Streamwise velocity](https://github.com/sscollis/npot/blob/master/test/cyl/u.png)

#### Computational Mesh

![Mesh](https://github.com/sscollis/npot/blob/master/test/cyl/mesh.png)

S. Scott Collis\

repository: sscollis/npot

gha_language: Fortran

repo_name: sscollis/npot


text:
# ubuntu-document-templates

Document templates for Ubuntu

## Installation

Assuming yout Templates folder is empty (which is the case in a new Ubuntu installation), simply clone as follows:

```bash
git clone https://github.com/javiercejudo/ubuntu-document-templates.git ~/Templates
```
Otherwise, clone it in a subfolder.

repository: javiercejudo/ubuntu-document-templates

repo_name: javiercejudo/ubuntu-document-templates


text:
---
title: Routing & filters
weight: 50
menu:
  main:
    parent: using-vamp
---
# Routing & Filters

A routing defines a set of rules for routing traffic between different services within the same cluster.
Vamp allows you to determine this in two ways:

1. by setting a **weight** in the percentage of traffic.
2. by setting a **filter** condition to target specific traffic.

You can define routings inline in a blueprint or store them separately under a unique name and just use that name to reference them from a blueprint.

Let's have a look at a simple, inline, routing. This would be used directly inside a blueprint.

```yaml
---
weight: 10  # Amount of traffic for this service in percents.
filters:
  - condition: User-Agent = IOS
```

The example above could be reused by just giving it a name and storing it by using a `POST` request to the `/routings` endpoint.

```yaml
name: cool_routing   # Custom name, can be referenced later on.
weight: 10
filters:
  - condition: user-agent = ios
  - really_cool_filter
```

> **Notice:** we added a filter named `really_cool_filter` here. This filter is actually a reference to a separately stored filter definition we stored under a unique name on the `/filters` endpoint.

## Defining weights

When defining weights, please make sure the total weight always adds up to 100%. This means that when doing a straight three-way split you give one service 34% as `33+33+34=100`. Vamp has to account for all traffic and 1% can be a lot in high volume environments.

## Defining filters
Creating filters is quite eas y. Checking Headers, Cookies, Hosts etc. is all possible. Under the hood, Vamp uses [Haproxy's ACL's](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.1) and you can use the exact ACL definition right in the blueprint in the `condition` field of a filter.

However, ACL's can be somewhat opaque and cryptic. That's why Vamp has a set of convenient "short codes"
to address common use cases. Currently, we support the following:

```
User-Agent = *string*
Host = *string*
Cookie *cookie name* Contains *string*
Has Cookie *cookie name*
Misses Cookie *cookie name*
Header *header name* Contains *string*
Has Header *header name*
Misses Header *header name*
```

We also allow simple negation of filter statements using the `!` operator on any shortcode with an `=`, i.e:

```
User-Agent != IOS
Host != www.google.com
```

Vamp is also quite flexible when it comes to the exact syntax. This means the following are all equivalent:

```
hdr_sub(user-agent) Android   # straight ACL
user-agent=Android            # lower case, no white space
user.agent=Android            # lower case, no white space, period instead of dash
User-Agent=Android            # upper case, no white space
user-agent = Android          # lower case, white space
```

Having multiple conditions in a filter is perfectly possible. In this case all filters are implicitly
"OR"-ed together, as in "if the first filter doesn't match, proceed to the next". For example, the following filter would first check whether the string "Chrome" exists in the User-Agent header of a
request. If that doesn't result in a match, it would check whether the request has the header
"X-VAMP-MY-COOL-HEADER". So any request matching either condition would go to this service.

```yaml
---
routing:
  weight: 0
  filters:
    - condition: User-Agent = Chrome
    - condition: Has Header X-VAMP-MY-COOL-HEADER
```

Using a tool like [httpie](https://github.com/jakubroztocil/httpie) makes testing this a breeze.

    http GET http://<IP_ADDRESS>:9050/ X-VAMP-MY-COOL-HEADER:stuff

**Notice** we set the weight to 0 in the above example. This means per default no traffic is send to a service that has this routing. *Only* when one of the filter conditions is met any traffic will flow to this service.

repository: rbramwell/vamp

repo_name: rbramwell/vamp


text:
---
title: 'List Layout Document'
bookcase_cover_src: 'cover/list.png'
bookcase_cover_src_dark: 'cover/list_dark.png'
weight: 40
changelogs:
---

List layout is the built-in section layout. Monochrome add options to adjust its behavior.

## Configuration

### Group by year

An option to control group setting.

```yaml
group_by_year: false
```

> default: theme's [`list_layout.enable_group_by_year`](/hugo-theme-monochrome/configuration/theme/#group-by-year)

### Show date

Show / Hide date right after the post entry.

```yaml
show_date: false
```

> default: theme's [`list_layout.enable_show_date`](/hugo-theme-monochrome/configuration/theme/#show-date)

### Pagination

```yaml
pagination: false
```

> default: theme's [`list_layout.enable_pagination`](/hugo-theme-monochrome/configuration/theme/#pagination)


text:
# github-standard-labels [![stability][0]][1]
[![npm version][2]][3] [![build status][4]][5]
[![downloads][8]][9] [![js-standard-style][10]][11]

Create a standard set of issue labels for a GitHub project

## Usage
```txt
  Usage:
    $ github-standard-labels <username> <project>

  Commands:
    <default>   Create a set of labels for a project

  Options:
    -h, --help      Print usage
    -v, --version   Print version
```

## Labels
```txt
duplicate             #ededed
greenkeeper           #ededed
good first issue      #7057ff
help wanted           #128A0C
starter               #ffc0cb
Priority: Critical    #ee0701
Priority: High        #d93f0b
Priority: Low         #0e8a16
Priority: Medium      #fbca04
Status: Abandoned     #000000
Status: Available     #c2e0c6
Status: Blocked       #ee0701
Status: In Progress   #cccccc
Status: On Hold       #e99695
Status: Proposal      #d4c5f9
Status: Review Needed #fbca04
Type: Bug             #ee0701
Type: Documentation   #5319e7
Type: Enhancement     #1d76db
Type: Maintenance     #fbca04
Type: Question        #cc317c
```

See what they look like on the [demo issue][12].

## API
### githubStandardLabels(opts, cb([err]))
Apply labels to a project. `opts` should be an object containing:
- __.github:__ an instance of `ghauth`
- __.username:__ the name of the project owner
- __.repo:__ the repository name

## Acknowledgements
- [Joe Hand](https://github.com/joehand/) for showing me this cool labeling scheme

## See Also
- https://developer.github.com/v3/issues/labels

## License
[MIT](https://tldrlegal.com/license/mit-license)

[0]: https://img.shields.io/badge/stability-experimental-orange.svg?style=flat-square
[1]: https://nodejs.org/api/documentation.html#documentation_stability_index
[2]: https://img.shields.io/npm/v/github-standard-labels.svg?style=flat-square
[3]: https://npmjs.org/package/github-standard-labels
[4]: https://img.shields.io/travis/yoshuawuyts/github-standard-labels/master.svg?style=flat-square
[5]: https://travis-ci.org/yoshuawuyts/github-standard-labels
[6]: https://img.shields.io/codecov/c/github/yoshuawuyts/github-standard-labels/master.svg?style=flat-square
[7]: https://codecov.io/github/yoshuawuyts/github-standard-labels
[8]: http://img.shields.io/npm/dm/github-standard-labels.svg?style=flat-square
[9]: https://npmjs.org/package/github-standard-labels
[10]: https://img.shields.io/badge/code%20style-standard-brightgreen.svg?style=flat-square
[11]: https://github.com/feross/standard
[12]: https://github.com/yoshuawuyts/github-standard-labels/issues/2

repository: tducasse/github-standard-labels

repo_name: tducasse/github-standard-labels


text:
Introduction
============
This quickstart demonstrates the usage of a rules service in conjunction with a camel service, creating a Content-Based Router.
This quickstart also demonstrates the ability to use MVEL expressions to extract objects (the Widgets from their Boxes) and insert them as facts inside the rules engine.
The drl resource is specified using annotations within the DestinationServiceRules interface, and checks the id of Widgets to determine the destination to set on their Boxes.
Then, a Camel route looks at the destination set on the Box for each Widget, and routes it to the appropriate service (RedService, GreenService, or BlueService).

If you would like to watch the rules execution, uncomment these lines in
src/main/resources/META-INF/switchyard.xml:
<rules:listeners>
    <rules:listener class="org.kie.api.event.rule.DebugAgendaEventListener"/>
    <rules:listener class="org.kie.api.event.rule.DebugRuleRuntimeEventListener"/>
</rules:listeners>

![Rules Camel CBR Quickstart](https://github.com/jboss-switchyard/quickstarts/raw/master/rules-camel-cbr/rules-camel-cbr.jpg)

Preqrequisites
==============
Maven

Running the quickstart
======================

EAP
----------
If installers have been previously installed on EAP skips the steps 1-4

1.  Download Jboss EAP 6.4 or upper

2.  Install them over your EAP instance:

           java -jar fuse-eap-installer.jar ${eap.home}

3.  Install the kie eap installer:

        java -jar kie-eap-installer.jar ${eap.home}

4.  Install the fuse-integration installer:

        java -jar fuse-integration-eap-installer-${version.fuse.bxms-integration}.jar ${eap.home}

5. Start JBoss AS 7 in standalone mode:

        ${AS}/bin/standalone.sh

6. Build and deploy the Quickstart :

        mvn install -Pdeploy

7. Use the RulesCamelCBRClient class to send a request message to the Dealer service.  The client can be
   run from the command-line using:

        mvn exec:java

See the "Expected Output" section for the expected results.

8. Undeploy the quickstart:

        mvn clean -Pdeploy

FUSE
----------
1. Start Fuse:

${FUSE_HOME}/bin/karaf

2. Ensure that the drools and switchyard compatible features URL files have been added to your Fuse instance.
   In case they are not added then:

    features:addurl mvn:org.drools/drools-karaf-features/${version.org.kie}/xml/${drools.karaf.features.classifier}

3. Add the features URL for the respective version of BXMS.

JBossFuse:karaf@root> features:addurl mvn:org.jboss.integration.fuse.quickstarts/karaf-features/${project.version}/xml/features

4. Install the feature for the Rules Camel CBR quickstart :

JBossFuse:karaf@root> features:install fuse-bxms-quickstart-switchyard-rules-camel-cbr

5. To submit a webservice request to invoke the SOAP gateway, run the quickstart client :

```
mvn exec:java -Pkaraf
```

6. Check the log for the expected results :

karaf@root> log:display

7. Undeploy the quickstart:

JBossFuse:karaf@root> features:uninstall fuse-bxms-quickstart-switchyard-rules-camel-cbr

KARAF
----------
1. Start the Karaf server :

${KARAF_HOME}/bin/karaf

2. Ensure that the drools and switchyard compatible features URL files have been added to your Karaf instance.
   In case they are not added then:

    features:addurl mvn:org.switchyard.karaf/switchyard/${version.switchyard}/xml/features
    features:addurl mvn:org.drools/drools-karaf-features/${version.org.kie}/xml/${drools.karaf.features.classifier}

3. Add the features URL for the respective version of BXMS.

karaf@root> features:addurl mvn:org.jboss.integration.fuse.quickstarts/karaf-features/${project.version}/xml/features

4. Install the feature for the Rules Camel CBR quickstart :

karaf@root> features:install fuse-bxms-quickstart-switchyard-rules-camel-cbr

5. To submit a webservice request to invoke the SOAP gateway, run the quickstart client :

```
mvn exec:java -Pkaraf
```

6. Check the log for the expected results :

karaf@root> log:display

7. Undeploy the quickstart:

karaf@root> features:uninstall fuse-bxms-quickstart-switchyard-rules-camel-cbr

Expected Output
======================
```
13:52:09,079 INFO  [org.switchyard.quickstarts.rules.camel.cbr.RedServiceBean] (http-/<IP_ADDRESS>:8080-1) Red service processing boxed widget with id: FF0000-ABC-123
```

## Further Reading

1. [Configuration Documentation](https://docs.jboss.org/author/display/SWITCHYARD/Configuration)
2. [Rules Services Documentation](https://docs.jboss.org/author/display/SWITCHYARD/Rules)
3. [Camel Services Documentation](https://docs.jboss.org/author/display/SWITCHYARD/Camel)
4. [Bean Services Documentation](https://docs.jboss.org/author/display/SWITCHYARD/Bean)

repository: jboss-integration/fuse-bxms-integ

gha_language: Java

repo_name: jboss-integration/fuse-bxms-integ


text:
# Middleman::Graphviz

This middleman extension creates a helper which lets you embed svg graphs
inside of your documents using the [dot language](http://www.graphviz.org/pdf/dotguide.pdf)

It is confirmed to be compatible with Middleman 4.2, your mileage may vary with more recent versions.

## Installation

Install graphviz if you haven't already.  On OSX you do:

```sh
$ brew install graphviz
```

Make sure the `dot` command is accessible using `which dot`.

Add this line to your middleman application's Gemfile:

```ruby
gem 'middleman-graphviz'
```

And then execute:

    $ bundle install

Then activate the extension in `config.rb`

```ruby
activate :graphviz
```

## Usage in ERB

You use the `graphviz` helper with a block.  The content of the block will be passed into the `dot` command, and the SVG output will be rendered inside of the page:

For example:

```erb
<% graphviz do %>
digraph G {

  subgraph cluster_0 {
    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 -> a1 -> a2 -> a3;
    label = "process #1";
  }

  subgraph cluster_1 {
    node [style=filled];
    b0 -> b1 -> b2 -> b3;
    label = "process #2";
    color=blue
  }
  start -> a0;
  start -> b0;
  a1 -> b3;
  b2 -> a3;
  a3 -> a0;
  a3 -> end;
  b3 -> end;

  start [shape=Mdiamond];
  end [shape=Msquare];
}
<% end %>
```

## Usage in Markdown

Most middleman blog posts are created with `.markdown`.  You need to rename these files to be `.markdown.erb` so they get processed through ERB first.

## Contributing

1. Fork it ( https://github.com/HappyFunCorp/middleman-graphviz/fork )
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create a new Pull Request

repository: HappyFunCorp/middleman-graphviz

gha_language: Ruby

repo_name: HappyFunCorp/middleman-graphviz


text:
# Changelog

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

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

This package is following [Semantic Versioning](https://semver.org/spec/v2.0.0.html):

## Unreleased

Nothing here yet

<!--
### Security

### Changed

### Added

### Fixed

### Removed
-->

## 0.3.1 (August 9th, 2021)

### Fixed

- Use key "orders" instead of "errors" in API errors processing

## 0.3.0 (August 9th, 2021)

### Changed

- Raise `ShipmentOrderError` in `Client.add_shipment_orders` on error
- Process optional fields in `ShipmentOrder.to_xml`

## 0.2.0 (April 13th, 2021)

### Changed

- Change `ee_destinations` name in `smartpost.Client` to `get_ee_terminals` to better communicate what is actually returned
- Change `ee_express_destinations` name in `smartpost.Client` to `get_ee_express_terminals` to better communicate what is actually returned

### Added

- Add `get_fi_terminals` method to `smartpost.Client` for getting Finnish terminals list
- Add `get_fi_post_offices` method to `smartpost.Client` for getting Finnish post offices list
- Add `add_shipment_orders` method to `smartpost.Client` for adding new shipment orders to SmartPost system
- Add `get_labels_pdf` method to `smartpost.Client` for getting PDF files with shipment order labels

## 0.1.0 (April 13th, 2021)

### Added

- Add async `Client` wrapper (`smartpost.Client`)
- Add `ee_destinations` method to `smartpost.Client` for getting Estonian destinations list
- Add `ee_express_destinations` method to `smartpost.Client` for getting Estonian destinations with express delivery list

license: Unlicense

branch_name: refs/heads/main


text:
# Playtest for [Boy Adventure the Game ]

* Made in unity Code : Jonatan Sosa @jjonatansosa
Art: Jonatan Sosa @jjonatansosa
Sfx : Jonatan Sosa @jjonatansosa
Music : Gravity Sound GravitySonud

* 4  out of 5  i like games like this simple but make you think plus  i am a sucker for old school games

* [Game Title Website] https://jjonatansosa.itch.io/boy-adventure-the-game

**Question:** During your playtesting where the rules of the game understandable? If not, what was not clear.
> The rules or not complete from the beginning  there is no time table and it is a puzzle game clearly but i think better than average games would get that.

**Question:** During gameplay did you notice anything that shouldn't be in the game or could be removed and it wouldn't effect game play?
>at the beiginning of the game  the game has a key block logo on block on it that makes you think you need to collect but it is there for show it can be confusing if you do not play through long enough

**Question:** Is this game balanced? If not, what is the target audience for this game based on that imbalance?
the game does not seem unbalanced i guess meaning people would die alot, the game seems to be a average gamer , hardcore game. I dont think casual would pick this up

( can you break down what you mean by this question when you grade it)

**Question:** Does the timing of this game appear to be about right for this type of game?
> I would say yes because it helps excercise your brain to solve the games puzzle

( can you break down what you mean by this question when you grade it)

**Question:** During gameplay did the mechanics and theme go together and reinforce each other?
> yes the game has simple mechanics such as jump and move side to side

**Question:** Did you have fun playing this game?
> yes i love this game because i am a hardcore game so trying to beat or understand or be great is what i like to do plus i played darksouls. I think because all the graphics are not there some people main not be turned on by this

**Question:** During gameplay what problems or issues seemed to happen and how did you get them to reoccur?
> no


text:
Returns a new list, composed of n-tuples of consecutive elements. If `n` is
greater than the length of the list, an empty list is returned.

Acts as a transducer if a transformer is given in list position.

@func
@memberOf R
@since v0.12.0
@category List
@sig Number -> [a] -> [[a]]
@param {Number} n The size of the tuples to create
@param {Array} list The list to split into `n`-length tuples
@return {Array} The resulting list of `n`-length tuples
@see R.transduce
@example

     R.aperture(2, [1, 2, 3, 4, 5]); //=> [[1, 2], [2, 3], [3, 4], [4, 5]]
     R.aperture(3, [1, 2, 3, 4, 5]); //=> [[1, 2, 3], [2, 3, 4], [3, 4, 5]]
     R.aperture(7, [1, 2, 3, 4, 5]); //=> []

repository: knpwrs/npm-ramda

repo_name: knpwrs/npm-ramda


text:
mongoose-temporal - Plugin support for temporal types in Mongoose
=================

### Overview

Mongoose-Temporal is an extension for Mongoose that implements support for temporal types using the
Mongoose ORM.

### Installation
	npm install mongoose-temporal

### Setup
To install all of the types, plugins, patches and utilities provided by the extension into a Mongoose
instance:

	var mongoose = require("mongoose");

	// Create a connection to your database
	var db = mongoose.createConnection("mongodb://localhost/sampledb");

	// Access the mongoose-temporal module and install everything
	var temporal = require("mongoose-temporal");
	var utils = temporal.utils

	// Install the types, plugins and monkey patches
	var loaded = temporal.install(mongoose);

The `loaded` value returned contains 2 properties:

- `loaded.types` : the join types that were loaded
- `loaded.plugins` : the extension plugins that were loaded

To just install the types provided by the extension (either all types or a list of named types):

	var mongoose = require("mongoose");

	// Create a connection to your database
	var db = mongoose.createConnection("mongodb://localhost/sampledb");

	// Access the mongoose-temporal module
	var temporal = require("mongoose-temporal");
	var utils = temporal.utils

	// Install the plugins
	var loaded = temporal.loadTypes(mongoose);

The `loaded` value returned contains the types that were loaded, keyed by the name of each type
loaded.

To just install the plugins provided by the extension (either all plugins or list of named plugins):

	var mongoose = require("mongoose");

	// Create a connection to your database
	var db = mongoose.createConnection("mongodb://localhost/sampledb");

	// Access the mongoose-temporal module
	var temporal = require("mongoose-temporal");
	var utils = temporal.utils

	// Install the plugins
	var loaded = temporal.installPlugins(mongoose);

The `loaded` value returned contains the plugins that were loaded, keyed by the name of each plugin
loaded.

To just install the patches provided by the extension (either all patches or list of named patches):

	var mongoose = require("mongoose");

	// Create a connection to your database
	var db = mongoose.createConnection("mongodb://localhost/sampledb");

	// Access the mongoose-temporal module and the utilities
	var temporal = require("mongoose-temporal");
	var utils = temporal.utils;

	// Install the monkey patches
	temporal.installPatches(mongoose);

### Contributors
- [Stuart Hudson](https://github.com/goulash1971)

### License
MIT License

### Acknowledgements
- [Brian Noguchi](https://github.com/bnoguchi) for the 'mongoose-types' extension that was used as a template for this extension

---
### Author
Stuart Hudson


text:
# Troopers19_Badge
My inoffical collection of Troopers19 Badge Stuff

## ESPTool stuff
* install esptool from https://github.com/espressif/esptool
* check connection and hardware: `esptool.py -p /dev/ttyUSB0 flash_id`
* connect to serial with screen: `screen /dev/ttyUSB0 115200` (exit with CTRL-A K)
* write image: `esptool.py -p /dev/ttyUSB0 write_flash 0x0 flash_4MB.bin

## Micropython stuff
* connect to serial with screen: `screen /dev/ttyUSB0 115200` (exit with CTRL-A K) (or miniterm or minicom or putty or...)
* it seems you need to break the current (menu?) program with `CTRL-C`to go to the `>>>` prompt
### fiddling with files (all commands within Micropython (MP) prompt
Hint: TAB completion works. so type `os.`and hit TAB to see posibilities
```python
import os
os.listdir()        # see directory /
os.listdir("/apps") # see directory /apps

fs = open("config.json")
fs.read("config.json")
fs.close()
```

## Others Work
* Nice GIST about uploading images: https://gist.github.com/doegox/042c400e19394e6bca4dae70067d4dc3


text:
This page contains instructions to interact with PIV card.

See https://piv.idmanagement.gov/engineering/ssh/ for more information.

I installed *OpenSC* open-source tool on Mac. There may be similar tools for Linux and Windows OS.

### Install OpenSC

`brew install opensc`

### Test OpnSC Installation

Insert PIV card in Smart card reader. Run the following command. The command will go through all keys on PIV card; and it
will prompt for PIN for each key.

`pkcs11-tool -login --test`

### List all PIV keys

`pkcs15-tool --list-public-keys`

### Display Smart card PIV Auth public key

`pkcs15-tool --read-ssh-key  01`

### SSH using PIV card

`ssh -I /usr/local/lib/opensc-pkcs11.so <user>@<remote_host>`

## Using MacOS utilities

MacOS provides native tools to read PIV card.

### Read Public key from PIV card

1. Insert PIV card into reader and login

2. Run the following command in your terminal program

     `security find-certificate | grep keychain | cut -d : -f2`

3. Take the output of the previous command (including the quotes) and replace $KEYCHAIN in the next command

     `ssh-keygen -i -m pkcs8 -f <(security find-certificate -p $KEYCHAIN | openssl x509 -noout -pubkey)`

Output of this command (including the ssh-rsa part) is your PIV SSH public key.

repository: sshussain/programo-utileco

repo_name: sshussain/programo-utileco


text:
# Network Status

{% hint style="success" %}
See [https://harmony.one/status](https://harmony.one/status%20%20) for the current network status and endpoints.
{% endhint %}

## Network Overview

Harmony runs not only a production mainnet but also several other testnets.

| **Network** | **Audience** | **Usage** |
| :--- | :--- | :--- |
| Mainnet | All | Harmony Production Mainnet |
| Long Running Testnet | Developers | Smart Contract and DApp Development |
| Open Staking Testnet | Validators | Open Staking Testing and [StakeHeist](https://medium.com/harmony-one/coming-soon-on-pangaea-stake-heist-23bd201d08a7) |
| Partner Testnet | Partners | Staking Partners building for Open Staking |

## Outages

Information about outages and postmortems on those outages can be found [here]().

repository: harmony-one/docs-home-cn

repo_name: harmony-one/docs-home-cn


text:
# WebMobileInputFix
A Unity WebGL workaround to enable mobile input (virtual keyboard) be triggered by Input Fields

## What this fixes
When you try to interact with any input field in a WebGL application in mobile, the virtual keyboard will never be triggered. This is a fix to that. Also, this can be used to enable copy/paste to the input fields

## How to use
Simply add the "KeyboardController" component to any object in the scene

## How it works
This workaround is a combination of getting inputs natively from a html input field and binds them to a Input Field
KeyboardController.cs is a Singleton that will manage automatically this binding of input fields and will be the bridge between the native javascript calls and the interaction with input fields.
This solution works with TMPro Input fields, just add the DEFINE #USE_TMPRO to your project

If you are using a custom index.html template, check the FixIndexFile.cs script, because it is a post build process to add some necessary entries to the index.html file
(or add this to your index.html manually)

```
<script>
		function FixInputOnSubmit() {
			document.getElementById("fixInput").blur();
			event.preventDefault();
		}
	</script>
    <div>
		<form onsubmit="FixInputOnSubmit()" autocomplete="off" style="width: 0px; height: 0px; position: absolute; top: -9999px;">
			<input type="text" id="fixInput" oninput="gameInstance.Module.ccall('FixInputUpdate', null)" onblur="gameInstance.Module.ccall('FixInputOnBlur', null)" style="font-size: 42px;">
		</form>
	</div>
```

## Known problems
The caret position and text selection will not work properly


text:
[![Unitary Fund](https://img.shields.io/badge/Supported%20By-UNITARY%20FUND-brightgreen.svg?style=for-the-badge)](http://unitary.fund)
# QuNetSim

![QuNetSim Tests](https://github.com/tqsd/QuNetSim/workflows/QuNetSim%20Tests/badge.svg)

QuNetSim is a quantum-enabled network simulator that adds common quantum networking tasks like teleportation, superdense coding, sharing EPR pairs, etc. With QuNetSim, one can design and test robust quantum network protocols under various network conditions.

## Installation and Documentation

See https://tqsd.github.io/QuNetSim/ for documentation. To install the latest release via pip:
```
pip install qunetsim
```

## Quick Start Guide

### Templater

The QuNetSim pip package comes with a templater. After installing the library, simply type `template` and follow the instructions. A template QuNetSim example will be generated.

### Quick Example

```
from qunetsim.components import Host, Network

network = Network.get_instance()
network.start()

alice = Host('Alice')
bob = Host('Bob')

alice.add_connection(bob.host_id)
bob.add_connection(alice.host_id)

alice.start()
bob.start()

network.add_hosts([alice, bob])

# Block Alice to wait for qubit arrive from Bob
alice.send_epr(bob.host_id, await_ack=True)
q_alice = alice.get_epr(bob.host_id)
q_bob = bob.get_epr(alice.host_id)

print("EPR is in state: %d, %d" % (q_alice.measure(), q_bob.measure()))
network.stop(True)
```

## Contributing

Feel free to contribute by adding Github issues and pull requests. Adding test cases for any contributions is a requirement for any pull request to be merged.

## Citation
```
@article{diadamo2020qunetsim,
  title={QuNetSim: A Software Framework for Quantum Networks},
  author={DiAdamo, Stephen and N{\"o}tzel, Janis and Zanger, Benjamin and Be{\c{s}}e, Mehmet Mert},
  journal={IEEE Transactions on Quantum Engineering},
  year={2021},
  doi={10.1109/TQE.2021.3092395}
}
```

repository: tqsd/QuNetSim

gha_language: Python

repo_name: tqsd/QuNetSim


text:
# Cell Counter

Count cells on a hemocytometer plate. Developed for use at the Bebout Lab, NASA Ames.

## Running

To use, simply upload your selected files and set your classification parameters.
* CLI: `pip install -r requirements.txt`, then `python cell-cli.py`
* (No longer hosted) ~~Website: https://rapid-cell-counter.herokuapp.com/~~

## Example
Before:
![Before](https://cloud.githubusercontent.com/assets/1396242/16716266/1f135a34-46ac-11e6-8c64-5cc7661f832e.jpg)

After:
![After](https://cloud.githubusercontent.com/assets/1396242/16716264/1a70bc56-46ac-11e6-8d9d-92eec5fda6d9.png)

## Acknowledgements

This site uses the [TrackPy - Particle Tracking Toolkit](https://github.com/soft-matter/trackpy).

## Future plans

The next version of this site will use a least squares approach to iteratively determining the best fit parameters.


text:
[![Build Status](https://travis-ci.org/hurricanehrndz/ansible-openssh.svg?branch=master)](https://travis-ci.org/hurricanehrndz/ansible-openssh)

# ansible-openssh

[OpenSSH](https://wikipedia.org/wiki/OpenSSH) - the OpenBSD Secure Shell

[![Licence](https://img.shields.io/badge/License-MIT-blue.svg)](https://tldrlegal.com/license/mit-license)
[![Platforms](http://img.shields.io/badge/platforms-ubuntu-lightgrey.svg?style=flat)](#)

## Description

OpenSSH is a suite of security-related network-level utilities based on the SSH
protocol, which help to secure network communications via the encryption of
network traffic over multiple authentication methods and by providing secure
tunneling capabilities.

## Tunables

* `openssh_client` (boolean) - Install as client?
* `openssh_server` (boolean) - Install as server?
* `openssh_ports` (list) - Ports to listen on
* `openssh_append_ciphers` - (list) ciphers to append to openssh_default_ciphers
* `openssh_append_key_exchange_algorithms` - (list) key exchanges to append to openssh_default_key_exchange_algorithms
* `openssh_append_mac_algorithms` - (list) message integrety checking to append to openssh_default_mac_algorithms
* `openssh_default_ciphers` (list) - Ciphers to allow (prefer openssh_append_key_exchange_algorithms when possible)
* `openssh_default_key_exchange_algorithms` (list) - Key Exchange Algorithms to allow (prefer openssh_append_ciphers when possible)
* `openssh_default_mac_algorithms` (list) - MAC Algorithms to allow (prefer openssh_append_mac_algorithms when possible)
* `openssh_auth_methods` (list) - Set ssh daemon AuthenticationMethods i.e. ("publickey", "publickey,keyboard-interactive:pam")
* `openssh_users_and_auth_methods` (dictionary list) - Set AuthenticationMethods for specific users.

## Dependencies

* None

## Example Playbook
```yaml

    - hosts: servers
      roles:
         - role: ansible-openssh
           openssh_server: yes
           openssh_client: yes

## Static Host Key
           openssh_static_host_keys:
            rsa:
                public: |
                    REDACT
                private: |
                    REDACT
            ed25519:
                public: |
                    REDACT
                private: |
                    REDACT
```

## Example Playbook 2FA for all 1FA for kitchen
```yaml
- hosts: test-kitchen
  remote_user: root

  roles:
    # name of role to test
    - role: ansible-openssh
      openssh_client: yes
      openssh_server: yes
      openssh_auth_methods:
        - "publickey"
        - "keyboard-interactive:pam"
      openssh_users_and_auth_methods:
        - user: "kitchen"
          auth_method: "publickey"
      openssh_kbd_interactive_auth: "yes"
```

## Contributors

* [Chris Olstrom](https://colstrom.github.io/) |<EMAIL_ADDRESS>| [Twitter](https://twitter.com/ChrisOlstrom)
* Steven Harradine
* Aaron Pederson
* Carlos Hernandez(https://github.com/hurricanehrndz) |<EMAIL_ADDRESS>| [Twitter](https://twitter.com/hurricanehrndz)

repository: hurricanehrndz/ansible-openssh

repo_name: hurricanehrndz/ansible-openssh


text:
# Rocket map selector

[Download link](https://www.file.io/download/7unnjFu3sU8P)

Rocket maps is an app that helps you manage your custom map library from the steam workshop since there's no way (yet) to play on those maps from the epic games launcher

Functionnalities :

- Add a new map
- Change the name of a map
- Remove a map
- Add / Remove favorite
- Basic search and filter

If you are ready to start you first need to download / extract the app and then you can just follow the steps below

![Step One](captures/1.PNG)

The map path is a random folder to store the maps you will download on your disk

The game folder is the path to your RL installation

![Step Two](captures/2.PNG)

![Step Three](captures/workshop/7.PNG)

Now pick a map you like on the workshop and copy the url
![Step Four](captures/workshop/8.PNG)
![Step Five](captures/workshop/9.PNG)

![Step Six](captures/workshop/10.PNG)

Paste the url in the text input and click on download
![Step Seven](captures/workshop/11.PNG)

![Step Eight](captures/3.PNG)

Give a name to the map and select the file you just downloaded (the .zip file)
![Step Nine](captures/4.PNG)
![Step Ten](captures/5.png)
Now click on the play button
![Step Eleven](captures/6.png)

If everything went well you can start RL and go to
Training -> Freeplay and select the Pillar map

By default this is the one being replaced by the map from the workshop, you can change this in the settings

### Misc informations

You don't have to restart your game everytime you want to play on an other map, you juste have to go back to the main menu and click on the play button of the map new map

The app doesn't collect any data and doesn't send anything over the network, it only works on your computer

Settings are stored in AppData\Roaming\rlmapselector

If you have any request or question you can contact me on github or send me an email

Enjoy :)

repository: jordanghub/rocket-maps

repo_name: jordanghub/rocket-maps


text:
---
layout: default
---

# 1996-11-26 - Re: KILL cypherpunks !!!

## Header Data

From: Eric Wilson<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 1ed269fdd62ea335e871e7672d839df3093d35a0ca1326bf56085b9187ca39d2

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-11-26 03:06:23 UTC

Raw Date: Mon, 25 Nov 1996 19:06:23 -0800 (PST)

## Raw message

```
{% raw  %}From: Eric Wilson<EMAIL_ADDRESS>Date: Mon, 25 Nov 1996 19:06:23 -0800 (PST)
To<EMAIL_ADDRESS>Subject: Re: KILL cypherpunks !!!
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

At 07:28 PM 11/25/96 -0500, you wrote:
>On Mon, 25 Nov 1996, aga wrote:

< whole bunch of stuff >

>> This is a world-wide internet problem that you are about to get
>> taken care of.  You will be among the first locations to be
>> eliminated.  And just remember that your termination is your own
>> doing.

Wow, I'm going to miss cypherpunks. I didn't post much, but I've always
been an avid reader (sniff). If I only had it to do all over again...
Oh, by the way, since you're planning on doing away with things, could you
get rid of some of these outfits that do the mass e-mails, thanks in advance.

>> I pump iron and run three times a week.  And as a Tae Kwon Do
>> black belt holder, I get lots of physical activity. I am in
>> better physical shape than any other man that you know.
>
>I have a date this weekend already, thanks.

I find you're martial arts reference very interesting. But if you were truly
any good, you wouldn't be waving it in everyones face like a banner. I find
your demeanor to be that of someone that has never practiced the warrior
arts. If you had, you'd have developed more respect for your fellow human
beings.
         Share your pain with us, and
together we'll grow stronger ( Star Trek reference ;)).

Eric Wilson
-----------------------------------------------------------------
Join the BugList!
"How many times?" The Blind Man
http://case.cioe.com/~serw30

{% endraw %}
```

## Thread

+ Return to [November 1996](/archive/1996/11)

+ Return to "[Eric Wilson <serw30@laf.cioe.com>](/authors/eric_wilson_serw30_at_laf_cioe_com_)"

+ 1996-11-26 (Mon, 25 Nov 1996 19:06:23 -0800 (PST)) - Re: KILL cypherpunks !!! - _Eric Wilson<EMAIL_ADDRESS>


text:
# Reduxsauce Example

This repo is created to illustrate how to use reduxsauce.

## Prerequisuites
1.  Node v12+
2.  Yarn v1.22+
3.  Serve v11.x+ - Only needed for production serving. `yarn global add serve`

## Setup
```
# install deps
yarn

# start dev server
yarn start
```

## Production
```
yarn build
serve -s build -l 5000  # app is now running on port 5000, this port is the default port
```

repository: jkeam/reduxsauce-example

repo_name: jkeam/reduxsauce-example


text:
# ElasticSearch - PHP

This library executes Query DSL (Domain Specific Language) based on JSON, of extremely simple format to comunicate with the ElasticSearch.
Also contain  a **Scroll**  function for the execute of paginate in queries.

> This library support ALL methods GET, PUT, POST, DELETE ... :heart_eyes:

### Config

Declare class.

```php
$es=new Elasticsearch('http://<IP_ADDRESS>:9200');
```

### Example

Example of use.

```php
$es->method='GET';
$es->path='/_stats';
$es->query='{}';
$es->result=$es->execute($es->method, $es->path, $es->query);
```

For **BigData** execute Scroll.

```php
$es->result=$es->scroll($es->path, $es->query);
```

> This is very good :sunglasses:

For _GET_ execute.

```php
$es->get('/index/_doc/_search', '{"size":9}');
```

For _PUT_ execute.

```php
$es->put('/index/_doc/:id', '{}');
```

For _POST_ execute.

```php
$es->post('/index/_doc/:id', '{}');
```

For _DELETE_ execute.

```php
$es->delete('/index/_doc/:id');
```

repository: thiagoeti/elasticsearch-php

repo_name: thiagoeti/elasticsearch-php


text:
# Sources

### Overview

A `source` is a data source that can be used to find feature data. Users define sources as part of [feature tables](feature-tables.md). Currently, Feast supports the following source types:

* Batch Source
  * File
  * [BigQuery](https://cloud.google.com/bigquery)
* Stream Source
  * [Kafka](https://kafka.apache.org/)
  * [Kinesis](https://aws.amazon.com/kinesis/)

### Structure of a Source

For both batch and stream sources, the following configurations are **necessary**:

* **created\_timestamp\_column**: Name of column containing timestamp when data is created.
* **event\_timestamp\_column**: Name of column containing timestamp when event data occurred.

When configuring data source options, see the [Feast Python API documentation](https://api.docs.feast.dev/python/) for more details.

Some valid source specifications are shown below:

{% tabs %}
{% tab title="batch\_sources.py" %}
```python
from feast import FileSource
from feast.data_format import ParquetFormat

batch_file_source = FileSource(
    file_format=ParquetFormat(),
    file_url="file://feast/*",
    event_timestamp_column="event_timestamp",
    created_timestamp_column="created_timestamp",
)
```
{% endtab %}

{% tab title="stream\_sources.py" %}
```python
from feast import KafkaSource
from feast.data_format import ProtoFormat

stream_kafka_source = KafkaSource(
    bootstrap_servers="localhost:9094",
    message_format=ProtoFormat(class_path="class.path"),
    topic="driver_trips",
    event_timestamp_column="event_timestamp",
    created_timestamp_column="created_timestamp",
)
```
{% endtab %}
{% endtabs %}

The [Feast Python API documentation](https://api.docs.feast.dev/python/) provides more information about options to specify for the above sources.

{% hint style="info" %}
When creating a Feature Table for use in training datasets, specify a batch source already containing materialized data.
{% endhint %}

### Working with a Source

#### Creating a Source

Sources are required when specifying a [feature table](feature-tables.md):

```python
batch_bigquery_source = BigQuerySource(
    table_ref="gcp_project:bq_dataset.bq_table",
    event_timestamp_column="event_timestamp",
    created_timestamp_column="created_timestamp",
)

stream_kinesis_source = KinesisSource(
    bootstrap_servers="localhost:9094",
    record_format=ProtoFormat(class_path="class.path"),
    region="us-east-1",
    stream_name="driver_trips",
    event_timestamp_column="event_timestamp",
    created_timestamp_column="created_timestamp",
)
```

Feast ensures that the source complies with the schema of the feature table. These specified data sources can then be included inside a feature table specification and registered to Feast Core.


text:
# Diamond analysis

## Description
This project consists of an analysis of the diamonds dataset, available at the `{ggplot2}` package. Particularly, we focus on the diamond prices and how to predict them based on other characteristics.

## How to run
It is easy, just run script `app.R`. If you are not on RStudio, you may need to open the app in your browser using the link produced when running `app.R`. It is available as "Listening on `<link>`".

repository: GiuseppeTT/structured-examples

repo_name: GiuseppeTT/structured-examples


text:
---
layout: tutorials
title: Periodic wakeup with SAMD21

dependancies:
  - name: Arduino Low Power
    url: https://github.com/arduino-libraries/ArduinoLowPower
dev_board: RobotDyn M0 Mini
chips:
  - SAMD21
features:
  - wakeup
  - sleep
  - periodic
video: xV1l5SdE8sk
images:
  prototype: periodic-wakeup-prototype.jpg
  schematic: periodic-wakeup-schematic.png
references:
  - name: External Wakeup
    url: https://www.arduino.cc/en/Tutorial/LowPowerTimedWakeup
  - name: Low Power library
    url: https://www.arduino.cc/en/Reference/ArduinoLowPower
  - name: ArduinoLowPower
    url: https://github.com/arduino-libraries/ArduinoLowPower
  - name: Low Power Library for Arduino
    url: https://github.com/rocketscream/Low-Power
  - name: RTC Library for SAMD21 based boards
    url: https://github.com/arduino-libraries/RTCZero
  - name: Serial not working after wakeup
    url: https://github.com/arduino-libraries/ArduinoLowPower/issues/7
  - name: RobotDyn SAMD21 M0 mini board
    url: https://robotdyn.com/samd21-m0-mini.html
---

Sleep for 30 minutes and wakeup to make 10 LED blinks before going back to sleep again for another 30 minutes.

Note that the [serial prints will not work after wakeup](https://github.com/arduino-libraries/ArduinoLowPower/issues/7). Hence use a USB to UART chip to get the `Serial1` prints. This is because during sleep, the entire USB peripheral also sleeps along with the MCU, except for the RTC.

During sleep, only power indicator green LED `ON` will be lighted on the [RobotDyn dev board](https://robotdyn.com/samd21-m0-mini.html).


text:
# tiup

https://docs.pingcap.com/tidb/stable/maintain-tidb-using-tiup
https://github.com/pingcap/tiup

https://github.com/go-kratos

The two things above give use lots of what we need for the whole architecture

- Many binaries but its ok, because it tiup has good tooling to boot it up and stop it.
	- Will just mean we need good desktop packaging for Usrs because we must be able to submit it to app store.
	- Will mean signing many binaries.
	- Not sure Grafana, which is unpacked at runtime will be OK in terms of signing on a mac...
		- needs investigation.

- Patching
	- https://docs.pingcap.com/tidb/stable/maintain-tidb-using-tiup#replace-with-a-hotfix-package
		- Need for dev time too so wokring is fats

- CQRS and CDC basis
	- We know we need this and TIDB is pretty muc the best. Better than cockroachdb in many ways.
	- https://github.com/pingcap/ticdc
	- Need to add NATS and LiftBridge and we have a CQRS basis
	- Need to chekc Materialised Views in TIDB and SQL Parser.
		- Cant do it: https://docs.pingcap.com/tidb/stable/views#limitations
		- SO just use Tables, and implement our a Query parser to check if a Mutation from the CDC affects a SQL Query or not.
			- If it does then we just need to emit the query result set as a CUD Event to the Client.
	- Can we do encryption at rest ?
		- Check..

- Its a Cluster discovery and ops and install tool all in one.
	- Exactly what we were needing.

- Its got Prom and Graphana
	- And the crazy config it needs too.
	- We can extend to have victoria metrics and Loki.

- Files DB
	- There is no reason we cant use TIDB to store the chunked versions of the Files
	- And use the TIDB cluster aspects to do what SeeweedFS does and have the Directory of the files held in TIDB also.
	- In this way the location of the files and the file chunks are decoupled. Just like Seeweedfas does.
		- see: https://github.com/geohot/minikeyvalue

- But how easy to extend TIUP ?
	- Need our Sys and Modules
	- Need Victoria Metrics
	- JSONNET / Config

- TIDB and CI / CD
	- Need a Gitops, Flagger setup.

- go-kratos
	- It also use TIDB
	- It has nicely packaged the code gen for GRPC, GRPC-Web, and a few other things, and so we can extend from it
		- Will be pat of Booty repo.
		- Can wrap with mage, so that CI and CD and use it.
	- Has a project creator
		- https://github.com/go-kratos/service-layout#create-a-project
		- Needed for our Modules.

- gui
	- https://pub.dev/packages/pluto_grid
	- definitly the right fit as its excel with type bindings, and so can link backwared to the data model to edit data in a MView but also the sources in the flow alos.

- VPP ( virtual POwer plant)
	- Its exactly the same as a CQRS compute system, and what we will do with EU.
	- IEC 61850-7-420
	- https://www.vde-verlag.de/iec-normen/preview-pdf/info_iec61850-7-420%7Bed1.0%7Db.pdf
	- https://de.wikipedia.org/wiki/Virtuelles_Kraftwerk

repository: joe-getcouragenow/shared

repo_name: joe-getcouragenow/shared


text:
# ***CLI+ HAS BEEN DICONTINUED SO THIS HAS BEEN ARCHIVED***

# Configure-CLI
An fork of ASF-WebConfigGenerator

Standalone web config generator for SaladCLI+

***

## Build Setup

```bash
# install dependencies
npm ci

# build
npm run build
```

The compiled files are available in `docs` directory. Launch index.html with your browser of choice.

## Development Setup

```bash
npm run dev
```

A web browser should automatically open `localhost:8080`. Changes in files are automatically reloaded after compilation.


text:
# Debug feature tests

Add a `binding.pry` into the context of a test that you want to investigate.

Copy the name of the test (relative path) of the test in question, run `rspec` in your terminal with the `CHROME` flag.

For example, I want to run the `clients_searching_sorting_and_filtering_spec` spec:

```bash
# In the root of the vita-min project
CHROME=y rspec spec/features/hub/clients_searching_sorting_and_filtering_spec.rb
```

This will open a Chrome browser to the context that you added your binding. Now you can execute commands in terminal and see them work in the browser.

Here's a [video showing this in action](https://user-images.githubusercontent.com/9101728/119901780-fa4fa080-bf0b-11eb-86d4-a29cb77a8b9f.mp4).

repository: codeforamerica/vita-min

repo_name: codeforamerica/vita-min


text:
# HyperFool

HyperFool is a Web Debugging Proxy that helps web developers figure out stuff about HTTP(S) traffic between your computer and a backend server. It uses an HTTP proxy / HTTP monitor / Reverse Proxy to show you all the HTTP requests going between, say a web page, and a server.

Fooling around with HTTP requests from a backend is not easy nowadays (11.2017), we've got over-powered tools that most web developers don't use, such as Fiddler or Charles. They do too much, and not one feature is web related. We need something simple, straightforward, and command line extensible, but packaged in a GUI form because we like to see and fool around before we drill down to details and script stuff.

Specifically:
1. The ability to (EASILY, FAST) mock out a backend call.
1.1. Based on an existing call - "Take whatever this specific call just returned, and keep returning the same response until I say otherwise".
1.2. Return variations of a JSON based on regex's / code.
2. The ability to grep (search) through multiple HTTP requests responses / requests (can't do that ATM with Chrome Dev Tools)
3. Save HTTP requests "samples", easily categorize / search through them.
4. ???
5. Profit.

repository: wildeyes/hyperfool

repo_name: wildeyes/hyperfool


text:
Marketplace
===========

[![Build Status](https://secure.travis-ci.org/StratusLab/marketplace.png)](https://secure.travis-ci.org/StratusLab/marketplace.png)

Contains the Marketplace, a registry of virtual appliances, that
promotes sharing of those appliances and trust between the creators,
users, and cloud administrators.

System Requirements
-------------------

The only requirement is JDK v1.7+. As such the Marketplace should install on most systems, once this dependency is met.

The metadata files and searchable metadata index, are stored locally as flat files. The Marketplace host should have adequate storage for these.

Installation
-------------

StratusLab runs its own YUM repository, so you must add it to your YUM configuration. Drop a file (named say stratuslab-releases.repo) in the /etc/yum.repos.d/ with the following content, modifying the OS as required:
```
[StratusLab-Releases]
name=StratusLab-Releases
baseurl=http://yum.stratuslab.eu/releases/centos-6.2-v2.0
gpgcheck=0
enabled=1
```
With this in place, you can now install the package:

```
yum install stratuslab-marketplace
```

This will install the Marketplace, along with a default configuration file /etc/stratuslab/marketplace.cfg. This file should be modified to configure the Marketplace as required.

An important step is to ensure that the two directories data.dir and pending.dir exist and are writeable by the user that will be running the Marketplace instance.

By default the Marketplace will use a Memory store as the backend. This type of store is volatile, and any uploaded metadata will not persist if the Marketplace is restarted. For this reason, for use in a production environment the Marketplace should be configured to use a Native store as the storage backend.

Starting the service
---------------------

The Marketplace can be started with the following command:

/etc/init.d/marketplace start

This will start the Jetty server. By default this will start on port 8081, meaning the Marketplace can be accessed on http://localhost:8081. The port can be changed by modifying the file /opt/stratuslab/marketplace/etc/jetty-stratuslab.xml.

Configuration reference
------------------------

The following describes the parameters in the Marketplace configuration file.
```
# Directory containing raw metadata data entries.
data.dir=/var/lib/stratuslab/marketplace

# Directory for pending (unconfirmed) entries.
pending.dir=/var/lib/stratuslab/pending

# Storage type for metadata database (memory or native)
store.type=native

# Flag to determine if endorser email address must be validated.
validate.email=false

# Flag to enable/disable Endorser reminder emails
endorser.reminder=false

# Email address for Marketplace administrator.
<EMAIL_ADDRESS>
# Host for SMTP server for sending email notifications.
mail.host=smtp.example.org

Port on SMTP server (defaults to standard ports).
mail.port=465

# Username for SMTP server.
<EMAIL_ADDRESS>
Password for SMTP server.
mail.password=xxxxxxx

# Use SSL for SMTP server (default is 'true').
mail.ssl=true

# Debug mail sending (default is 'false').
mail.debug=false

```

Replication settings
---------------------

The Marketplace can be configured to allow for replication. This is done through a central Git repository.

```
replication.enabled=true|false
replication.type=public|private
```

With replication enabled the Marketplace will periodically pull metadata files from the configured Git repository in order to update its internal index. If the replication type is set to public, metadata files uploaded to the Marketplace will be pushed to the Git repository. With private replication the files will not be pushed, and will only be available locally.

The Git repository to use is set with the following property:

```
git.uri=https://github.com/repo/metadata.git
```

Authentication with the Git repository can be either by username and password or SSH key. For username/password set:
```
git.user=
git.password=
```

For SSH key authentication use:
```
git.key=
git.key.passphrase=
git.known.hosts=
```

Email verification
-------------------

It is possible to configure the Marketplace to require email verification of uploaded metadata. The Marketplace will send an email to the metadata endorser requiring them to verify their uploaded entry. Whilst awaiting verification the metadata will be stored in the pending.dir.

The relevant configuration parameters are:

```
validate.email=true
<EMAIL_ADDRESS>mail.host=smtp.example.org
mail.port=465
<EMAIL_ADDRESS>mail.password=xxxxxxx
mail.ssl=true
mail.debug=false
```

Changing the Marketplace Style
-------------------------------

The current release contains code to allow the page style to be changed easily. The instructions are the following:

1. Copy the current web archive (war) for the service to a temporary directory.
```
$ cp /opt/stratuslab/marketplace/webapps/marketplace-server-war-1.0.13-SNAPSHOT.war .
```
2. Extract the contents of the archive. (You must have the java development tools installed.)
```
$ jar xf marketplace-server-war-1.0.13-SNAPSHOT.war
```
3. Create a new directory hierarchy to hold the modified style files. You can choose any path here, but it is best to follow the usual java conventions and use an inverted domain name. This CANNOT be eu/stratuslab/style/css if you want your changes to be visible.
```
$ mkdir -p eu/egi/style/css
```
4. Copy the current style files into your new directory hierarchy.
```
$ cp WEB-INF/classes/eu/stratuslab/style/css/* eu/egi/style/css/
```
5. Change the CSS and other files as you like. Note that some of the images are used by the javascript for the service, so it is better to replace images or add new ones rather than delete existing ones.

6. Create a new jar file with your modified style files and verify the correct hierarchy within the jar file.
```
$ jar cf egi-style.jar eu
$ jar tf egi-style.jar
```
7. Drop this jar file into the Marketplace server's extensions directory.
```
$ cp egi-style.jar /opt/stratuslab/marketplace/lib/ext/
```
8. Modify the server's configuration file by adding the style.path option. NOTE: The path must match the path in the jar file and MUST start and end with a slash!
```
style.path=/eu/egi/style/css/
```
9. Restart the service.
```
$ service marketplace restart
```
At this point your new style should be active.

If necessary you can also perform the same operation for the service javascript. The configuration option is named js.path and the procedure is complete analogous to the one used for style.path.

Using the client
----------------
The client eases appliances update/migration.
This has been written to be able to test and use Stratuslab appliances (e.g. locally, with other cloud middlewares).
It is made of a python script that saves appliances metadata having an HTTP URI, each appliance on their own directory labelled by the appliance uuid.
It also contains a shell script as exemple.

* stratuslab_getimages.py
This downloads appliances metadata and dumps those that are subject to be downloaded (aka. images with an HTTP URI).
This script expects a valid stratuslab marketplace endpoint either read from $HOME/.stratuslab/stratuslab-ser.cfg or provided on the command line.
The appliance metadata are dump to stdout
(an 'images.json' is provided as an output example).
For each appliance, this scripts creates one directory labelled with the appliance uuid where it stores two files:
appliance.json contains the appliance metadata; uri.txt contains the appliance image URI only.

* stratuslab_download_and_convert_images_to_qcow2.sh
Having this URI, the user can download appliances image to test them locally, convert them to another format etc.
A shell script is provided as exemple; this read uri.txt from each found directory.

License
-------

Licensed under the Apache License, Version 2.0 (the "License"); you
may not use this file except in compliance with the License.  You may
obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.  See the License for the specific language governing
permissions and limitations under the License.

Acknowledgements
----------------

This software originated in the StratusLab project that was co-funded
by the European Community’s Seventh Framework Programme (Capacities)
Grant Agreement INFSO-RI-261552 and that ran from June 2010 to May
2012.

repository: StratusLab/marketplace

repo_name: StratusLab/marketplace