text:
# bioprotocol-service

`bioprotocol-service` is an application that receives requests from the [eLife journal](https://elifesciences.org) for
[Bioprotocol](https://bio-protocol.org/) data and keeps Bioprotocol updated with newly published articles.

It is a Python and Django application.

## API

`bioprotocol-service` can be accessed directly at https://prod--bp.elifesciences.org/, and content is available at
`/bioprotocol/article/{msid}`, for example, [Homo Naledi](https://prod--bp.elifesciences.org/bioprotocol/article/9560):

```json
{
    "total": 19,
    "items": [
        {
            "sectionId": "s5-1-1",
            "title": "Australopithecus afarensis",
            "status": false,
            "uri": "https://bio-protocol.org/eLIFErap09560?item=s5-1-1"
        },
        {
            "sectionId": "s5-1-2",
            "title": "Australopithecus africanus",
            "status": false,
            "uri": "https://bio-protocol.org/eLIFErap09560?item=s5-1-2"
        },
        {
            "sectionId": "s5-1-3",
            "title": "Australopithecus garhi",
            "status": false,
            "uri": "https://bio-protocol.org/eLIFErap09560?item=s5-1-3"
        },

        [...]

        {
            "sectionId": "s5-6",
            "title": "Stature estimation methods",
            "status": false,
            "uri": "https://bio-protocol.org/eLIFErap09560?item=s5-6"
        }
    ]
}
```

`bioprotocol-service` is available through the eLife API gateway at: https://api.elifesciences.org/bioprotocol/

The availability of the API can be tested with [/ping](https://prod--bp.elifesciences.org/ping)

The status of the API can be tested with [/status](https://prod--bp.elifesciences.org/status)

## eLife updates of Bioprotocol data

`bioprotocol-service` will monitor an AWS SQS queue for article publication notifications, download the article, convert
it to a Bioprotocol-preferred data structure and then HTTP POST the results to the Bioprotocol servers. This ensures
Bioprotocol has the most recent set of published articles and relieves them of polling eLife infrastructure for new
articles.

Articles that fail to send to Bioprotocol can be re-sent with:

    ./resend-elife-article-to-bp.sh {msid}

## Bioprotocol updates of article data

Bioprotocol data is sent to eLife's `bioprotocol-service` as it becomes available via a HTTP POST request.

Bioprotocol data that fails to be ingested can be reloaded with:

    ./reload-article-data-from-bp.sh {msid}

## Installation

    ./install.sh

## Testing

    ./test.sh

## Maintenance

    ./update-dependencies.sh
    ./update-fixtures.sh

## Copyright & Licence

Copyright 2019 eLife Sciences.

The `bioprotocol-service` project is [MIT licenced](LICENCE.txt).

repository: elifesciences/bioprotocol-service

branch_name: refs/heads/develop

repo_name: elifesciences/bioprotocol-service


text:
# Read: 02 - The Coder's Computer

- A text editor is a piece of software that you download and install on your computer, or you access online through your web browser, that allows you to write and manage text, especially the text that you write to build a website.

## Features to look for in a text editor

- code completion
    - display possible suggestions based on what you originally typed.
    - Finishes tags, brackets, quotes, etc.

## Syntax highlighting

- takes the text you type, and makes it more noticeable by colorizing the text.
- Color coordinated so easier to read and look up mistakes

## a nice variety of themes (to reduce eye strain and fatigue)

- allow you to change the color of the background of your text editor, the series of colors in your text, and sometimes themes will affect other aspects of your text editing software as well.
- web developers use a dark background and brightly colored text. This combination seems to be easier on the eyes—but there are other themes to choose from as well.

## the ability to choose from a healthy selection of extensions available when you need them

- like plugins for your text editor, that allow you to have superpowers that you wouldn’t have otherwise.

### Please make sure that when you’re saving your file, that they have the appropriate extension at the end of the file names.

- ## For example, your main HTML file should be called, “index.html.” Your CSS file should be called something like “style.css.” The filename isn’t as important as the extension (the “.html” and the “.css”).

## The Difference Between Text Editors and IDEs (Integrated Development Environment)

## IED

- a text editor, a file manager, a compiler, and a debugger all in one software package

## Command Line

- is a text based interface to the system. You are able to enter commands by typing them on the keyboard and feedback will be given to you similarly as text

## Basic Navigation

### pwd

- which stands for Print Working Directory
- It tells you what your current or present working directory is

### The command for this task is ‘ls’

- It's short for list
- single command line option ( -l ) which indicates we are going to do a long listing

## Absolute and relative. Whenever we refer to a file or directory we are using one of these paths

- ### Absolute paths specify a location (file or directory) in relation to the root directory. You can identify them easily as they always begin with a forward slash ( / )

- ### Relative paths specify a location (file or directory) in relation to where we currently are in the system. They will not begin with a slash

### ~ (tilde)

- This is a shortcut for your home directory. eg, if your home directory is /home/ryan then you could refer to the directory Documents with the path /home/ryan/Documents or ~/Documents

### . (dot)

- This is a reference to your current directory. eg in the example above we referred to Documents on line 4 with a relative path. It could also be written as ./Documents (Normally this extra bit is not required but in later sections we will see where it comes in handy).

### .. (dotdot)

- This is a reference to the parent directory. You can use this several times in a path to keep going up the hierarchy. eg if you were in the path /home/ryan you could run the command ls ../../ and this would do a listing of the root directory.

### In order to move around in the system we use a command called ‘cd’ which stands for change directory

## Going over commands and advice

### pwd - Print Working Directory - ie. Where are we currently

### ls - List the contents of a directory

### cd - Change Directories - ie. move to another directory

### Relative path

- A file or directory location relative to where we currently are in the file system.

### Absolute path

- A file or directory location in relation to the root of the file system.

### File

- obtain information about what type of file a file or directory is.

### ls -a

- List the contents of a directory, including hidden files.

### Everything is a file under Linux

- Even directories.

### Linux is an extensionless system

- Files can have any extension they like or none at all.

### Linux is case sensitive

- Beware of silly typos.

[Back to Main](README.md)

license: MIT

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# Project: Stonk Options
Investment firms, hedge funds and retail investors use financial models to understand market behavior and make profitable investments.
A plethora of information is available in the form of historical stock prices and company performance data, which makes them suitable for machine learning algorithms to process.

Our predictive model regression framework builds on well documented Moving Averages, Momentum, and Volume-based technical indicators with an implementation of regularized regression.
Our web app dashboard generates a forecast of individual stock returns and buy/sell signals in a portfolio of equities for a specified time period.
Given a list of high conviction equity investments, our model recommends suitable entry or exit strategies with an optimal payoff structure using market traded derivatives.

## Pre-requisite
1) MySQL Connection
Execute the following SQL scripts:
```
user.sql
tables.sql
procedures.sql
```

2) IEX API Connection
[Documentation](https://iexcloud.io/docs/api/)
```python
env = 'sandbox'
token = 'Tpk_d7aa551ec78a42ef9b7933450b0d29dc'

env = 'cloud'
token = 'pk_8f217a39af964a708a5981d1f9cfa931'
```

3) Environment Setup
```bash
chmod 755 setup.sh
./setup.sh
```

## Data Parser Usage
Start the MySQL server
```
sudo service mysql start
```

Populate database with all stock historical data:
```bash
python3 parser.py max
```

Update last week's stock prices & next 12 month's option data (scheduled cron job):
```bash
python3 parser.py
```

## Data Analyzer Usage

## Dashboard Usage

## License
[MIT License](https://github.com/jk5ho/stonks-options/blob/master/LICENSE)

gha_language: Python

gha_license_id: MIT


text:
# Testing FIDL protocols

## Prerequisites

This tutorial builds on the [HLCPP getting started tutorials][overview].

## Overview

This tutorial walks through the process of writing a test for the
`Echo.EchoString` method. This tutorial shows you how to use the two utilities
available for testing FIDL protocols implemented in HLCPP:

* The `gtest` test loop fixture `sys::testing::ComponentContextProvider`.
* The `fidl_test_base.h` file provided by the HLCPP bindings

If you want to write the code yourself, delete the following directories:

```posix-terminal
rm -r examples/fidl/hlcpp/testing/*
```

The test will be written in `examples/fidl/hlcpp/testing/main.cc`.

## Set up dependencies

To set up dependencies:

1. Include the libraries that are needed for the test:

  ```cpp
  {% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/hlcpp/testing/main.cc" region_tag="includes" %}
  ```

2. Add a build rule for the test in `examples/fidl/hlcpp/testing/BUILD.gn`:

  ```gn
  {% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/hlcpp/testing/BUILD.gn" %}
  ```

## Create a server implementation

To create a server implementation:

1. Add an implementation for the `Echo` protocol that is tested:

   ```cpp
   {% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/hlcpp/testing/main.cc" region_tag="impl" %}
   ```

   Rather than inheriting from `fuchsia::examples::Echo`, this implementation
   inherits from the [corresponding test base class][test-base]. This means that
   the implementation only needs to override the methods that are being tested
   (in this case, `EchoString`), as well as the `NotImplemented_` method, which
  is called if any of the request handler methods that are not overridden get
  called.

1. Create a test class that wraps the logic of publishing the echo protocol:

   ```cpp
   {% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/hlcpp/testing/main.cc" region_tag="wrapper" %}
   ```

   This is similar to the code that is explained in the
   [server tutorial][server-tut], but the `fidl::Binding` is owned by the class.
   This makes the binding's destructor get called when the class is destroyed.
   This enables the code to publish the echo protocol on each test case given
   a new instance of the test component context.

## Implement the test fixture class

```cpp
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/hlcpp/testing/main.cc" region_tag="fixture" %}
```

The test fixture does the following:

* Holds an instance of a `ComponentContextProvider`. Each test, it uses it to
  create a new test context, and binds the Echo implementation to it using the
  `EchoServerInstance` class.
* Provides a `GetProxy()` method initializes a proxy to the current test
  component context and returns it.

## Add tests

This is an example test that can you can write with the test fixture:

```cpp
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/hlcpp/testing/main.cc" region_tag="test" %}
```

## Run the test

To run the test:

1. Configure your GN build to include the test:

   ```posix-terminal
   fx set core.x64 --with //examples/fidl/hlcpp/testing

   ```
1. Run the test:

   ```posix-terminal
   fx test -vo example-hlcpp-protocol-test
   ```

You should see the test output indicating a success.

## Summary

* The `gtest::TestLoopFixture` removes the need for boilerplate async loop
  setup code. Each test case can simply call `RunLoopUntilIdle()` instead of
  manually managing an `async::Loop`.
* The `ComponentContextProvider` makes it easy to mock the component context
  during a test. This is useful to e.g. provide specific capabilities to the
  a component.
* The HLCPP bindings test scaffolding provides a test base for each protocol
  class that has a placeholder implementation for each method. This allows tests
  to only implement the methods under test.

<!-- xrefs -->
[test-base]: /docs/reference/fidl/bindings/hlcpp-bindings.md#test-scaffolding
[server-tut]: /docs/development/languages/fidl/tutorials/hlcpp/basics/server.md
[overview]: /docs/development/languages/fidl/tutorials/hlcpp/README.md

repository: gnoliyil/fuchsia

branch_name: refs/heads/main

repo_name: gnoliyil/fuchsia


text:
# Thelotrema compunctum (Ach.) Nyl. SPECIES

#### Status
SYNONYM

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Mém. Soc. Imp. Sci. Nat. Cherbourg 5: 118 (1857)

#### Original name
Lichen compunctus Sm.

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Ascomycota/Lecanoromycetes/Ostropales/Graphidaceae/Leucodecton/Leucodecton occultum/ Syn. Thelotrema compunctum/README.md

repo_name: mdoering/backbone


text:
# Introduction

This is a CRC32C implementation in C#. The implementation has support for SSE4.2 CRC32 intrinsics.

# Examples

You can use this Library like this:

```csharp
CRC32C crc = new CRC32C();

crc.Calculate(bytes, from, count);

Console.WriteLine($"CRC: {crc.CRC.ToString("X08")}");
```

There are other variants of `Calculate` accepting `byte*` or single bytes.

The library will do hardware support detection. You can force the library to use the software implementation like this:

```csharp
CRC32C.InitializeSoftwareTable();
CRC32C.Acceleration = HardwareAcceleration.Software;
```


text:
## Table of contents:
   - [Features](index.md): List the features of the loggers library
   - [Implementation](implementation.md): This document

## Implementation details

You do not need to read or understand this document to use the loggers.
Its aim is to highlight some of the implementation choices that were made
in the design of this library, and how they impact the performance.

### Asynchronous logging

Arguably the most important feature of this library is its support for
asynchronous logging, where user tasks delegate as much work as possible to
one or more background tasks in charge of doing the actual formatting of
messages and writing them to their final destination.

The workflow is as follows:

 1. user builds a message via one or more calls to the `"&"` operators;
 1. user calls `Log` to emit the message
 1. simple filtering based on severity threshold is applied, and message is
   possibly discarded immediately;
 1. if doing synchronous logging, skip the following two steps
    1. all needed information is saved and queued for the background
      task;
    1. background task polls the queue, decodes the message and forwards it
      to one or more streams, depending on the logger the message was sent to;
 1. each stream applies its filter to decide whether to discard the message;
 1. each stream formats the message, applying the decorators specified by the
   user in the configuration, converting the message components to string,...
 1. each stream writes the resulting string to its final destination.

#### building a message (capturing components)

A `Msg_Type` is essentially an array of message components. This array has
a limited size (after various experimentations, we ended up with a maximum
of 15 components). This limitation allows us to avoid any dynamic memory
allocation when logging messages, which speeds things up and eases the
management of memory (no question as to when we should free a message).

The message itself is built via one or more calls to `"&"`, as in:

```ada

   function "&" (M : Msg_Type; Component : Integer) return Msg_Type;
   function "&" (M : Msg_Type; Component : String) return Msg_Type;
   --  one overload per possible type of component

   Log (Me.Debug & "string" & Comp2 & Comp3 & Comp4);
```

where the first component must always be a string (as a way to limit the number
of overloads of `"&"`).

If a user adds more than 15 components in a single call of `Log`, the extra
components are replaced with a single "..." string. Because of the way we
dynamically build a message, the compiler cannot statically detect that we
provided too many messages.

At this stage, components are **captured**, i.e. we simply keep an unsafe
pointer to the object. That object will exist at least as long as `Log` is
executing.

Because the actual parameters to `"&"` might be passed by copy or by reference,
the loggers provide two generic procedures. Their implementation is made
simple by using GNAT's `Deref` attribute, though it is possible to use
a standard `Address` attribute and carefully copying bits.

For instance:

```ada
   generic
      type T (<>) is limited private;
   package Captures_By_Ref is
      procedure Capture (Data : T; Into : out Captured_Parameter_Type)
         with Inline;
      function Get (Comp : Captured_Parameter_Type) return access constant T
         is (T_Access'Deref (Comp'Address));
   end Captures_By_Ref;

   package body Captures_By_Ref is
      By_Reference : constant Boolean := Capture'Mechanism_Code (1) = 2;
      pragma Assert (By_Reference, "must be by reference");

      procedure Capture (Data : T; Into : out Captured_Parameter_Type) is
      begin
         T_Access'Deref (Into'Address) := Data'Unrestricted_Access;
      end Capture;
   end Captures_By_Ref;
```

As a simple optimization, if the severity of the message
(debug, info, error,...) is lower than the logger's threshold, we do not even
do the capturing (though the compiler still has to call each of the `"&"`
operators.

The actual call to Log and the first level of filtering are simple and require
no special detailing.

####  Queuing messages

When doing asynchronous logging, we need to save everything that the background
task will need later on to write the message to a stream. We can no longer
rely on the unsafe pointers created during the capture phase described
above, because the data might be freed, popped from the stack,...

We now **encode** the message into a binary format. For each component, we
capture the bytes. For instance, an integer requires 4 bytes, a string requires
8 bytes for its bounds and then one byte per character,... All the bytes for
these components are written into a newly allocate memory record, one after
the other. Apart from the memory allocation itself, this is a fast operation,
only involving some copying of bytes in the memory.

A pointer is more complex, of course. Currently we simply encode the 8 bytes
for its address, but it will never be dereferenced afterward (we log the
pointer address itself, not the pointed object).

That binary object is added to a very efficient lock-free queue. We have one
such queue per asynchronous stream.

#### Dequeuing messages

The background queue (a different task) will later retrieve that binary
object, decode it back to its components (4 bytes back to the integer,...)
and pass the decoded result to each stream. This decoding in general requires no
copy because we simply use the bytes where they are in memory.

The decoded message is not exactly the equivalent of the original `Msg_Type`
(Ada does type checking after all !), so the streams have two different
primitive operations to handle both kinds of messages.

### Task safety

This library is fully task safe. Because we care about efficiency, however,
we try to avoid locking when possible.

A call to `Log` (in the user task) requires no locking at all when using
asynchronous logging, because the queue is a lock-free data structure. In
addition to some speed improvement, this also means it is safe to call `Log`
from a protected object (the Ada standard declares that calling a potentially
blocking operation from a protected object is a bounded error).

Each asynchronous stream (i.e. where the `type` is defined as `async` in the
config file) has its own queue and background task. In general, applications
will have a single such asynchronous stream.

Each stream can be called from multiple tasks, either directly by the user
task when using synchronous logging, or by one or more of the background tasks
associated with the synchronous logging. Locking is used here, trying to keep
the locked section to the smallest possibly size to improve throughput.

The code is also split into multiple packages, so that if you decide to
build your application without tasking support, using the loggers doesn't
initialize GNAT's tasking runtime at all. For this, we use low-level primitives
for locks (as opposed to protected types) in a number of places, and the code
that actually requires tasks (e.g. asynchronous logging) is carefully isolated
in optional packages that your application can chose not to import.

### Inlining

A lot of subprograms are marked as inline, and kept small so that the compiler
indeed obeys that request. If we look at the code for `Log`, for instance,
we have:

```ada
   procedure Log_Out_Of_Line
      (Message  : Msg_Type;
       Location : String;
       Entity   : String) with No_Inline;

   procedure Log_Out_Of_Line
      (Message  : Msg_Type;
       Location : String;
       Entity   : String) is
   begin
      ... do the actual logging
   end Log_Out_Of_Line;

   procedure Log
      (Message  : Msg_Type;
       Location : String := GNAT.Source_Info.Source_Location;
       Entity   : String := GNAT.Source_Info.Enclosing_Entity)
   is
   begin
      if Optimization.Likely (Message.Logger = null) then
         return;
      end if;
      Log_Out_Of_Line (Message, Location, Entity);
   end Log;
```

The call to `Optimization.Likely` uses gcc builtins to tell the compiler that
the most likely execution path is that the message will in fact be discarded.
That let's the branch prediction of the processor take full advantage for
further optimization. The `Log_Out_Of_Line` subprogram should not be inlined,
though, as this actually results in slower code in this case.

### Task termination on exception

We want to log a message when a user task terminates because of an
unhandled exception. If we do not, it is sometimes hard to understand why
and when a part of the application has suddenly stopped working.

We could of course require that all user tasks have proper exception handlers
in place, and do their own logging. But it is easy to forget to add them...

So we make use of GNAT's `Ada.Task_Termination` hooks for that purpose.
The code outline looks like:

```ada

with Ada.Exceptions;
with Ada.Task_Termination; use Ada.Task_Termination;
package body Loggers is

   protected Callbacks is
      procedure On_Termination (
        Cause : Ada.Task_Termination.Cause_Of_Termination;
        T     : Ada.Task_Identification.Task_Id;
        X     : Ada.Exceptions.Exception_Occurrence
      );
      procedure Set_Handler;
   private
      Prev : Ada.Task_Termination.Termination_Handler;
   end Callbacks;

   Termination_Handler : constant Ada.Task_Termination.Termination_Handler
      := Callbacks.On_Termination'Access;

   protected body Callbacks is

      procedure On_Termination (
        Cause : Ada.Task_Termination.Cause_Of_Termination;
        T     : Ada.Task_Identification.Task_Id;
        X     : Ada.Exceptions.Exception_Occurrence) is
      begin
         case Cause is
            when Normal => null;
            when Abnormal | Unhandled_Exception =>
               --  do some logging
         end case;
      end On_Termination;

      procedure Set_Handler is
      begin
         Prev := Current_Task_Fallback_Handler;
         Set_Dependents_Fallback_Handler (Termination_Handler);
      end Set_Handler;
   end Callbacks;

begin
   Callbacks.Set_Handler;
end Loggers;
```

### Application finalization

Handling application finalization in the context of asynchronous logging was
one of the most complicated part of the design.

In Ada, the main subprogram will not terminate while any of the task it has
created is still running. None of the global controlled objects will be
`Finalize`d either, because the application is in effect still running.

So potentially that means we need to stop the background tasks associated with
the asynchronous loggers. The usual way to do this is to check whether the
environment task is callable, as in:

```ada
task body Background_Task is
begin
   while Ada.Task_Identification.Is_Callable
      (Ada.Task_Identification.Environment_Task)
   loop
      --  write messages
   end loop;
end Background_Task;
```

The problem is that the user's own tasks might decide to still do some work
at this stage (possibly for a very long time !), and in particular log
messages that we do not want to discard. But the background tasks are not
running any more, so the queue of messages will just keep growing forever...

We tried various approaches, including having `Log` do locking and actual
writing to file when the background task has terminated, but this change of
semantics (and performance profile) is very often not acceptable.

In the end, we settled for using a low-level subprogram provided by the
GNAT runtime:

```ada
task body Background_Task is
   Ignore : constant Boolean := System.Tasking.Utilities.Make_Independent;
begin
   loop
      select
         accept Terminate_After_Dequeue;
         exit;
      or
         delay 0.1;
         --  write messages
      end select;
   end loop;
end Background_Task;
```

The background task is owned by one of the asynchronous streams, via a
controlled type.

When the application is terminated, our background task is no longer blocking
the finalization. So the application will wait for all user tasks to properly
terminate (at which point they are no longer doing any logging). Then as
usual it will `Finalize` all remaining controlled objects, including the one
associated with the stream. That finalization will then rendez-vous with
the `Terminate_After_Dequeue` entry, which will end the background task,
and finally let the application exit cleanly.

### Generics vs tagged types

This library uses a lot of generics to share code. Those are preferred
over tagged types because the compiler can statically optimize the code,
do more inlining,... Those generics are used for the performance critical
parts of the code, in particular the implementation of the `"&"` operators
that are used to build log messages in the user tasks.

However, the streams are implemented as tagged types, so that we keep the
flexibility of configuring them via config files. They are called often, but
from the background task, so they have no impact on the performance of the
user tasks. In fact, streams are controlled types because on finalization
they need to properly close the associated file, socket,...


text:
---
layout: post
title: "Setting up NFS"
published: true
---

In this post we will create an NFS share that will be used by all the machines on our Host-Only network.

#### Setting up NFS Server

On our main server, labx-server, install nfs-server

* Install file server group list

	`yum -y groupinstall file-server`

* Enable services on boot

	`systemctl enable rpbcind nfs-server`

* Start the services

	`systemctl start rpcbind`
	`systemctl start nfs-server`

* Setup the shared directories

	`mkdir /nfs ; chmod 0777 /nfs`

* Edit /etc/exportfs to assign permissions

	`/nfs	<IP_ADDRESS>/24(rw,sync)`

* Export the directory

	`exportfs -avr`

* Confirm the share

	`showmount -e localhost`

#### Setting up the clients

* Install nfs-utils and rpcbind

	`yum -y install nfs-utils rpcbind`

* Start rpbcind

	`systemctl enable rpcbind ; systemctl start rpcbind`

* Create the mount point

	`mkdir -p /nfs`

* Edit /etc/fstab and add the mount point

	`<IP_ADDRESS>:/nfs	/nfs	nfs	defaults 0 0`

gha_language: CSS


text:
# closure-react-demo

[![Build Status](https://travis-ci.org/BrotherJing/closure-react-demo.svg?branch=master)](https://travis-ci.org/BrotherJing/closure-react-demo)

A sample project showing how to integrate closure library with react(or other 3rd-party lib), and use closure compiler to minify the code.

#### Getting started

```bash
yarn install
yarn run build-dev
```
Then open `index.html`.

#### Production build(Closure compiler advanced mode)

```bash
yarn run build
```
Then open `advanced.html`.

#### Run test

```bash
yarn run test:unit
```

## Feature list

- [x] React component and closure library component demo
- [x] use `goog.module` syntax
- [x] use webpack and closure-webpack-plugin to build
- [x] use babel loader to convert jsx syntax
- [x] React calling closure function
- [x] use `material-ui`, treat them as external libraries. Only our own code go through advanced compilation.
- [x] test framework with karma, mocha, enzyme, etc.
- [x] use `webpack-merge-and-include-globally` to bundle libraries.

repository: BrotherJing/closure-react-demo

gha_language: JavaScript

repo_name: BrotherJing/closure-react-demo


text:
# Leucophleps spinispora Fogel, 1979 SPECIES

#### Status
ACCEPTED

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Can. J. Bot. 57(16): 1724 (1979)

#### Original name
Leucogaster levisporus Zeller, 1941

### Remarks
null


text:
---
layout: post
title:  "Monday"
date:  "2020-02-03"
author: me
---

Strangeness in extinction laws. Talked with Scott on persistence.

<!--more-->

Today was interesting at coffee, I read about [planet radius gap in K2 data](https://ui.adsabs.harvard.edu/abs/2020arXiv200111511H/abstract), but I need ot get more in deoth on it. I spoke to Scott on the persitence stuff, need to revisit Long et al 2013 about the behavior/origin of the law.

Also got the extinction law worked into the galactic model. Super stoked on that actually ,still need ot test it out though. Still a lot to do on it though.


text:
# Design resources

## Internet current buzz words
 - [an introduction to http/2](https://developers.google.com/web/fundamentals/performance/http2/)
 - [Introducing redux](https://blog.andyet.com/2015/08/06/what-the-flux-lets-redux/)

## Rest concepts
- [HAL specification](http://stateless.co/hal_specification.html)
- A very broad tutorial on [how to integrate Spring with React](https://spring.io/guides/tutorials/react-and-spring-data-rest/)
- [Rest or RPC](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)

## Data persistence
 - [A good overview of the MySql vs MongoDB discussion](https://www.upguard.com/articles/mysql-vs-mongodb)

### PWA ###
- [Basic tutorial](https://codebrahma.com/building-progressive-web-app-react/)
- [A more complete one](https://medium.com/@addyosmani/progressive-web-apps-with-react-js-part-i-introduction-50679aef2b12)

## SysAdmin

### Profiling and monitoring
- [An introduction to flame graphs](http://www.brendangregg.com/flamegraphs.html) and corresponding [full article](http://queue.acm.org/detail.cfm?id=2927301)

repository: bsinou/springframework-patterns

repo_name: bsinou/springframework-patterns


text:
---
date: 2007-3-23
speaker: "Mainak Poddar ISI Kolkata"
title: "How interesting are orbifolds?"
time: "4:00 p.m."
venue: "Lecture Hall - I, Department of Mathematics"
---
Orbifolds are generally regarded as generalizations of manifolds. On the other hand, finite groups are also orbifolds. In this survey talk, I will focus on how orbifolds appear naturally in some important areas of Mathematics and Physics. I will also describe some features of the geometry of orbifolds.

repository: siddhartha-gadgil/DeptWeb

gha_language: HTML

repo_name: siddhartha-gadgil/DeptWeb


text:
# Using the ODBC jEDI

<PageHeader />

## Using the ODBC jEDI with an existing table

Creating an *ODBC* type file from an existing table can be as simple as:

```
CREATE-FILE tablename TYPE=ODBC COLS=*
```

This creates a stub that maps to the **tablename** parameter, and generates a dictionary for each table column so they're ready for querying with *jQL*.

### Note #1

> A comma separated map/definition is generated in lieu of an existing csv.
> If you only want to map to a subset of the table, you can specify a column list and an optional primary key (if none of the columns are primary keys).

### Example #1

You might have a table of ORDERS containing an auto sequenced key, an ORDER\_NBR column, and some other columns you wish to combine into the ODBC jEDI *view* of the table:

CREATE-FILE ORDERS TYPE=ODBC COLS=ORDER\_NBR,PRODUCT,PRICE,DATE\_ORDERED KEY=ORDER\_NBR

The example above will create a stub pointing to the **ORDERS** table, but will treat the **ORDER\_NBR**column as the key to the jBASE dynamic record. The **PRODUCT**, **PRICE,** and **DATE\_ORDERED** columns will be mapped to attributes **1, 2, 3** and **4** (*datetime* fields are by default split into two fields, therefore the date portion maps to attribute **3** and the time portion to attribute **4**).

## Steps to create an ODBC jEDI stub using a CSV

To generate a valid csv mapping file, and map it into your desired *RDBMS,*do the following in jBASE:

1. **CREATE-FILE DICT** ***filename* 1**

2. Create a dictionary for each table column you wish to map. The ID for each dictionary should be a *valid* column name. The attribute can be whatever you want, however the primary key column must be 0. The dictionary type should be **A** if using the classic PICK style, or **D** for the Prime/Universe style. The heading, justification, and width attributes are not used by the *jEDI* interface, only for running jBASE queries.

### Note #2

> You can create other dictionaries for reporting purposes but you should use S (for classic PICK style) or V / I for Prime/Universe style.
>
3. **jCreateCSV {-O}** -D*type* *filename* **tablename.csv**

The above command reads in all relevant dictionaries for filename, and generates a csv in the CSVdir parameter value defined in the **jEDIdrivers.ini**file.

### Note #3

>It's recommended the csv files are named according to their intended table name (which could be the same as the filename). However, this is not an absolute requirement. Additionally, you can modify the resulting csv if desired using any jBASE or operating system text editor.

4. **CREATE-FILE DATA** *filename* **TYPE=ODBC** {*additional qualifiers*}

### Note #4

> The above example assumes the csv is *filename*.csv
> The EXISTING argument is optional (the default value is set to YES, meaning the table exists; NO means the table does not exist, and will be created).

### ODBC CREATE-FILE Arguments and Information

Additional arguments you can use in the CREATE-FILE include:

|  |  |
| --- | --- |
| **CSV=csvname** | The csv option is required if the csv is not filename.csv |
| **Table=tablename** | The tablename if not the same as filename |
| **UniqueKey=YES\|NO** | Defaults to YES. NO is used if the key column (i.e. attribute 0) is not a unique value per record/row |
| **Existing=YES\|NO** | Specifies whether the table already exists, or should be created |
| **WRITEOPTS=[I,U,D]** | Used to restrict updates to a given table. The argument can use any combination of the following values:
<**I**>nsert
<**U**>pdate
<**D**>elete
For example, **WRITEOPTS=U** would only allow updates, **WRITEOPTS=ID** would allow inserts and deletes, and **WRITEOPTS=** would not allow any updates |
| **Connect=dsn\_label** | Specifies which database connection information string to use from the jEDIdrivers.ini file (**default** is used if this argument is not specified) |

### Note #5

> The attribute mapping from SQL column to multi-value record is arbitrary as there are no duplicates

## CSV/Schema Cleansing

When creating a csv definition from an existing jBASE file, the dictionaries used to generate the csv may cause a table column to not be 100% compliant with the data in the original dynamic-array record (e.g. typically resulting in a {VAR}CHAR type of an insufficient size).

The **jCheckSchema** command can be used to verify and even update the csv so that all the original records can be written to the *RDBMS*.

**jCheckSchema *original\_jBASE\_file* {*schema\_path*} *schema\_def* *{ID}* {options}**

If ***ID*** is specified, only that record (keyed by *ID)* is checked. Otherwise, all records (or those in the current active select list) are checked.

**jCheckSchema** options:

|  |  |
| --- | --- |
| **-a*****list*** | Ignore "undefined" for the **attributes** specified in *list*(comma separated) |
| **-c** | **Check** data integrity |
| **-i** | **Interactive:** *prompts for changes* |
| **-q** | **Quiet:** no progress displayed |
| **-rn** | **Round** column lengths up to nearest factor of *n* |
| **-w** | Disable control character **warnings** |
| **-R** | **Report** only |

### Example #2

```
jCheckSchema CUSTOMER CUSTOMER.csv -r5
```

This will read all records in the CUSTOMER file and check that the types and lengths of each attribute are compliant with the csv definition.

### Note #6

> **jCheckSchema** will detect multi{sub}-value fields that have not been defined, however, it won't define them for you. You will need to amend the csv and specify multi{sub}-value association groups or positional multi-value options (if they are not repeating multi{sub}-values).

## IOCTL

The jBC (BASIC) language has an IOCTL function which has the syntax of:

***result\_code*= IOCTL(*file\_var*, *IOCTL\_option*, *in\_out\_arg*)**

The *ODBC jEDI* has the following non-standard IOCTL options:

|  |  |
| --- | --- |
| **68** | Over-riding SQL SELECT statement (**in\_out\_arg**) for the next **SELECT *file\_var*** statement (note: the result set must match the type and number of columns expected for the primary key denoted by the **def** in the *stub*. |
| **98** | Specify the **in\_out\_arg** number of writes before a commit will be performed (useful for improved performance when performing a high volume of insert/update/delete operations). |
| **99** | Issue a commit. |
| **7000** | Execute the **in\_out\_arg** as an SQL statement on the target RDBMS (typically a singleton query-statement) |

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

[Introduction to the ODBC jEDI](./../introduction-to-the-odbc-jedi)

[Installing the ODBC jEDI on Linux/UNIX](./../installing-the-odbc-jedi-on-linux&unix)

[Installing the ODBC jEDI on Windows](./../installing-the-odbc-jedi-on-windows)

[Structure of ODBC jEDI Initialization Files](./../structure-of-odbc-jedi-initialization-files)

[Structure of ODBC jEDI Mapping Files](./../structure-of-odbc-jedi-mapping-files)

[Configuring the ODBC jEDI on Linux/UNIX](./../configuring-the-odbc-jedi-on-linux&unix)

[Configuring the ODBC jEDI on Windows](./../configuring-the-odbc-jedi-on-windows)

Back to [ODBC](./../README.md)

<PageFooter />

repository: josepheshaw/docs

repo_name: josepheshaw/docs


text:
# place_xeogl
## new updates
https://webpack.docschina.org/guides/getting-started/
run
```npm run build```
and
```npm start```

### What this repo is about:
This repo initially started as a 3d visualization project. As project progresses, this repo is then developed into the fundation for future visualization dashboard. This repo is maintained by xionjjlj and wzt1001.

### Some major changes on this branch compared to master by zwang (20-02-01):
1. Split into two htmls, index.html as a layout for data visualization, 3d-vis.html as an independent page for 3d visualzation. 3d-vis.html is loaded into index.html as an <iframe>, as provide as a standard method for loading xeogl visualizations to other pages. As such, the css is also splited into main.css + annotation-style.css
2. for index.html, bootstrap is added for easier page layouting
3. cleaned some hardcoded parts in loadModel.js
4. optimized the click/hover events
5. added some missing images for cameras

### TO-DOs (20-02-03 to 20-02-09)
1. add legends for the visualization
2. highlight store zone, or camera if clicked
3. other aesthetic changes as to be suggested by UX designer

Also, please see the example for the final visualization:
https://gisanddata.maps.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6


text:
# Licensing

For licensing the Citrix ADC CPX, you need to provide the following information in the YAML for the Citrix Application Delivery Management (ADM) to automatically pick the licensing information:

-  **LS_IP (License server IP)** – Specify the Citrix ADM IP address.

-  **LS_PORT (License server Port)** – This is not a mandatory field. You must specify the ADM port only if you have changed it. The default port is 27000.

-  **PLATFORM** – Specify the Platform License. Platform is **CP1000**.

The following is a sample yaml file:

```yml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cpx-ingress
  labels:
    name: cpx-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      name: cpx-ingress
  template:
    metadata:
      labels:
        name: cpx-ingress
      annotations:
        NETSCALER_AS_APP: "True"
    spec:
      serviceAccountName: cpx
      containers:
        - name: cpx-ingress
          image: "cpx-ingress:latest"
          securityContext:
            privileged: true
          env:
            - name: "EULA"
              value: "YES"
            - name: "NS_PROTOCOL"
              value: "HTTP"
            #Define the NITRO port here
            - name: "NS_PORT"
              value: "9080"
            - name: "LS_IP"
              value: "<ADM IP>"
            - name: "LS_PORT"
              value: "27000"
            - name: "PLATFORM"
              value: "CP1000"
          args:
            - --ingress-classes
              citrix-ingress
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
            - name: nitro-http
              containerPort: 9080
            - name: nitro-https
              containerPort: 9443
          imagePullPolicy: Always
```


text:
# lambda-layer-demo

Add desired library folders to a folder named `python`

Zip the contents
`zip -r custom_lambda_funcs.zip ./python`

Upload as AWS Lambda Layer

Add layer to your function

Import from your included directories in your function:
e.g.,

>import simplejson
>
>def lambda_handler(event, context):
>
>
>    return {
>        'statusCode': 200,
>        'body': simplejson.dumps('Hello from Lambda!')
>    }

## Notes
You can also create the `python` directory in the format `python/lib/python3.8/site-packages`

Update the 3.8 to whichever python you're using. But the plain ol' `/python` directory works in most cases

repository: BrockNicholas/lambda-layer-demo

repo_name: BrockNicholas/lambda-layer-demo


text:
# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [1.2.7] - 2020-12-10
### Changed
- Changelog

## [1.2.6] - 2020-12-10
### Changed
- Keywords in package.json

## [1.2.5] - 2020-12-10
### Added
- Option to allow risky rules

### Changed
- Code formatting

## [1.1.5] - 2020-12-09
### Fixed
- Single quotes on Windows 10

## [1.1.4] - 2020-09-07
### Changed
- Enclosed filenames with single quotes

## [1.1.3] - 2020-02-25
### Changed
- Changelog

## [1.1.2] - 2020-02-25
### Added
- Better error messages

## [1.1.1] - 2020-02-19
### Changed
- Dont use caching

## [1.1.0] - 2020-02-19
### Fixed
- Command not found on latest VS Code version.

## [1.0.0] - 2019-07-21
### Removed
- Success info message

## [0.0.9] - 2019-06-22
### Added
- Example usage of PHP-CS-Fixer extension

## [0.0.8] - 2019-06-21
### Changed
- Improved extension icon

## [0.0.7] - 2019-06-21
### Changed
- Description for some configurations
- Code cleanup

## [0.0.6] - 2019-06-19
### Added
- Extension Icon

## [0.0.5] - 2019-06-19
### Added
- Configuration: `php-cs-fixer.pathMode`

## [0.0.4] - 2019-06-19
### Changed
- Bump version

## [0.0.3] - 2019-06-19
### Changed
- Updated package.json with missing entries

## [0.0.2] - 2019-06-19
### Fixed
- File Indentaions

### Changed
- Updated package.json with missing entries

## [0.0.1] - 2019-06-19
- Initial release

[Unreleased]: https://github.com/higoka/php-cs-fixer/compare/v1.2.7...HEAD
[1.2.7]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.2.7
[1.2.6]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.2.6
[1.2.5]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.2.5
[1.1.5]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.1.5
[1.1.4]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.1.4
[1.1.3]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.1.3
[1.1.2]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.1.2
[1.1.1]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.1.1
[1.1.0]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.1.0
[1.0.0]: https://github.com/higoka/php-cs-fixer/releases/tag/v1.0.0
[0.0.9]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.9
[0.0.8]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.8
[0.0.7]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.7
[0.0.6]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.6
[0.0.5]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.5
[0.0.4]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.4
[0.0.3]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.3
[0.0.2]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.2
[0.0.1]: https://github.com/higoka/php-cs-fixer/releases/tag/v0.0.1

repository: higoka/php-cs-fixer

repo_name: higoka/php-cs-fixer


text:
### [CVE-2017-13849](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13849)
![](https://img.shields.io/static/v1?label=Product&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

An issue was discovered in certain Apple products. iOS before 11.1 is affected. tvOS before 11.1 is affected. watchOS before 4.1 is affected. The issue involves the "CoreText" component. It allows remote attackers to cause a denial of service (application crash) via a crafted text file.

### POC

#### Reference
- https://www.exploit-db.com/exploits/43161/

#### Github
No PoCs found on GitHub currently.

repository: trickest/cve

repo_name: trickest/cve


text:
# V1 to V2

V1 has been around for quite some time.
Since the low-level SOAP parts became very stable and trustworthy,
We decided to move them [to a separate organisation](https://github.com/php-soap/).
This will make it easier to make changes in both this soap-client and the more low-level SOAP parts.
An additional benefit is that the robust SOAP fundamentals can be used by other SOAP clients as well.
We hope this will lead to an even more stable SOAP core.

The focus of this package shifted to the generation of SOAP client code.
This is the part that makes it easy to interact with your SOAP service.
We decided to make it more opinionated, so that you have to deal with less strange SOAP related bugs than before.

By moving the low-level SOAP stuff out, we can now focus on improving WSDL metadata collection,
which will results in more strictly typed generated code.
You can expect this to come in one of the next releases.

## Prerequisites

If your application does not contain a PSR-18 client, you'll have to
choose which HTTP client you want to use.
This package expects some PSR implementations to be present in order to be installed:

* PSR-7: `psr/http-message-implementation` like `nyholm/psr7` or `guzzlehttp/psr7`
* PSR-17: `psr/http-factory-implementation` like `nyholm/psr7` or `guzzlehttp/psr7`
* PSR-18: `psr/http-client-implementation` like `symfony/http-client` or `guzzlehttp/guzzle`

Example implementations:

```
composer require symfony/http-client nyholm/psr7
```

## Upgrading

```bash
composer require phpro/soap-client:^2.0
```

We suggest you to use the `soap-client` CLI tools again if you want to upgrade and existing application:

```
./vendor/bin/soap-client wizard
```

From this point on, you can re-add the custom parts of your existing SOAP client back into the new SOAP client.

**You can check the updated documentation in order to discover how you need to do specific actions like adding middleware in v2.**

This update comes with some breaking changes:

## php-soap

The new php-soap organisation provides most of the interfaces that were previously in this package.

### Engine

https://github.com/php-soap/engine

Provides following interfaces:

* [Engine](https://raw.githubusercontent.com/php-soap/engine/main/src/Engine.php) : Replaces the old `EngineInterface`
* [Metadata](https://raw.githubusercontent.com/php-soap/engine/main/src/Metadata/Metadata.php) : Replaces the old `MetadataInterface`
* [MetadataProvider](https://raw.githubusercontent.com/php-soap/engine/main/src/Metadata/MetadataProvider.php) : Replaces the old `MetadataProviderInterface`
* [Driver](https://raw.githubusercontent.com/php-soap/engine/main/src/Driver.php) : Replaces the old `DriverInterface`
* [Decoder](https://raw.githubusercontent.com/php-soap/engine/main/src/Decoder.php) : Replaces the old `DecoderInterface`
* [Encoder](https://raw.githubusercontent.com/php-soap/engine/main/src/Encoder.php) : Replaces the old `EncoderInterface`

If you use any of these interfaces in your own code, you will need to replace them with the `php-soap` alternatives.

**Note:**

* The metadata has slightly been changed : property and parameter collections are replacing plain arrays.

### Transport

https://github.com/php-soap/psr18-transport/

* [Transport](https://raw.githubusercontent.com/php-soap/engine/main/src/Transport.php) : Replaces the old `HandlerInterface`

By default we will be using a [PSR-18](https://www.php-fig.org/psr/psr-18/) based transport.
The `ExtSoapClientTransport` is still available, but won't be used by default anymore,
because it has many known issues in PHP's bug tracker.

The downside is that you have to decide which PSR-18 HTTP client you want to use before installing this package.
For example:

```bash
composer require symfony/http-client nyholm/psr7
```

The HTTP middleware are now regular [httplug](http://httplug.io/) plugins, which are also moved to another package:
You can find a full list of plugins that can be used here:

* [All HTTPlug plugins](https://docs.php-http.org/en/latest/plugins/)
* [Authentication plugins](https://github.com/php-soap/psr18-transport#authentication)
* [Soap - WSDL middleware](https://github.com/php-soap/psr18-transport/tree/main/src/Middleware)
* [WSSE - WSA middleware](https://github.com/php-soap/psr18-wsse-middleware)

### ExtSoap

https://github.com/php-soap/ext-soap-engine/

All `ext-soap` quirks are now maintained in a separate package.
This will most likely have impact on:

* [SoapOptions](https://github.com/php-soap/ext-soap-engine/#extsoapoptions): The same as before, but without metadata manipulators. You can now configure them in the Engine factory.
* [ClassMap](https://github.com/php-soap/ext-soap-engine/#classmap): It now takes variadic `ClassMap` arguments as arguments instead of an array.
* [TypeConverter](https://github.com/php-soap/ext-soap-engine/#typeconverter): Moved
* [WsdlProvider](https://github.com/php-soap/ext-soap-engine/#wsdlprovider): New WSDL providers were added to the new repo

If you have custom classes implementing one of the items above, they will require some love whilst upgrading.

**Note:**

* By default, the Transport does not contain any last request information anymore. There is a `TraceableTransport` available that you can decorate another transport with in order to get this functionality back.

## Dependency upgrades

* Symfony to LTS (4.4)
* PHP (^8.0)
* Removed a lot of old dependencies and suggestions
* Removed ext-*, since they are required in the specific php-soap packages

## Removed deprecations

### Events

The custom event dispatchers are removed.
We now support any [PSR-14 event dispatcher](https://www.php-fig.org/psr/psr-14/).

Fully qualified class names will be used as event names.
The old deprecated event names are now removed from the codebase.

The events won't contain the SOAP client anymore.
We don't want them to be service containers.
So instead, if you require the SOAP client in the event listeners, you need to inject them manually.

## Client

We don't work with a base client anymore.
Instead, a `Caller` is injected into the client you fully own.
The caller is responsible for transporting the request.
We provide an engine caller and an event dispatching caller
so that your client keeps on working how you expect it to.

Example of generated client:

```php
use Calculator\Type\Add;
use Calculator\Type\AddResponse;
use Phpro\SoapClient\Caller\Caller;

class CalculatorClient
{
    /**
     * @var Caller
     */
    private $caller;

    public function __construct(\Phpro\SoapClient\Caller\Caller $caller)
    {
        $this->caller = $caller;
    }

    public function add(Add $parameters) : AddResponse
    {
        return ($this->caller)('Add', $parameters);
    }
}
```

We removed the debugging method from the soap-client.
Instead, you can either debug the request or result directly.
If you want to have access to the HTTP SOAP payload, we suggest adding a logger plugin to the HTTP client.
There is also a `TraceableTransport` available that can be used to detect the last SOAP request and response like you would in the old client.

This implies that changes where done to:

* the client generator
* the client factory generator
* the configuration generator

## Client Factory

In order to make the new `Caller` system available for your SOAP client,
the factory now injects the caller into your SOAP client.

```php
use Symfony\Component\EventDispatcher\EventDispatcher;
use Phpro\SoapClient\Soap\DefaultEngineFactory;
use Soap\ExtSoapEngine\ExtSoapOptions;
use Phpro\SoapClient\Caller\EventDispatchingCaller;
use Phpro\SoapClient\Caller\EngineCaller;

class CalculatorClientFactory
{
    public static function factory(string $wsdl) : CalculatorClient
    {
        $engine = DefaultEngineFactory::create(
            ExtSoapOptions::defaults($wsdl, [])
                ->withClassMap(CalculatorClassmap::getCollection())
        );

        $eventDispatcher = new EventDispatcher();
        $caller = new EventDispatchingCaller(new EngineCaller($engine), $eventDispatcher);

        return new CalculatorClient($caller);
    }
}
```

You can opt-out on the event dispatching logic or decorate your own caller.

The `DefaultEngineFactory` can now be configured with a transport and the metadata options.
Full example on how you can personalize your factory class:

```php
use Http\Client\Common\PluginClient;
use Http\Discovery\Psr18ClientDiscovery;
use Phpro\SoapClient\Soap\DefaultEngineFactory;
use Phpro\SoapClient\Soap\ExtSoap\Metadata\Manipulators\DuplicateTypes\RemoveDuplicateTypesStrategy;use Phpro\SoapClient\Soap\Metadata\Manipulators\TypesManipulatorChain;
use Phpro\SoapClient\Soap\Metadata\MetadataOptions;
use Soap\ExtSoapEngine\ExtSoapOptions;
use Soap\ExtSoapEngine\Wsdl\Naming\Md5Strategy;
use Soap\ExtSoapEngine\Wsdl\PermanentWsdlLoaderProvider;
use Soap\Psr18Transport\Psr18Transport;
use Soap\Psr18Transport\Wsdl\Psr18Loader;

$httpClient = Psr18ClientDiscovery::find();
$engine = DefaultEngineFactory::create(
    ExtSoapOptions::defaults($wsdl, [])
        ->withClassMap(CalculatorClassmap::getCollection())
        ->withWsdlProvider(
            new PermanentWsdlLoaderProvider(
                Psr18Loader::createForClient($httpClient),
                new Md5Strategy(),
                'target/location'
            )
        ),
    Psr18Transport::createForClient(
        new PluginClient(
            $httpClient,
            [
                $middleware1,
                $middleware2,
            ]
        )
    ),
    MetadataOptions::empty()->withTypesManipulator(
        new TypesManipulatorChain(
            new RemoveDuplicateTypesStrategy()
        )
    )
);
```

repository: phpro/soap-client

gha_language: PHP

repo_name: phpro/soap-client


text:
---
title: HTTP/2 "Dropped Frame" Frame
abbrev: http2-nak-frame
docname: draft-kerwin-http2-nak-frame-03
date: 2019
category: std

ipr: trust200902
area: Applications and Real-Time
workgroup:
keyword:
 - HTTP
 - H2

stand_alone: yes
pi: [toc, tocindent, sortrefs, symrefs, strict, compact, comments, inline]

author:
 - ins: M. Kerwin
   name: Matthew Kerwin
   organization:
   email<EMAIL_ADDRESS>   uri: https://matthew.kerwin.net.au/

normative:
  RFC2119:
  RFC7540:
  RFC8174:

informative:

--- abstract

This document defines an extension to the Hypertext Transfer Protocol Version 2 (HTTP/2) that
allows an endpoint to signal to its peer that an unsupported extension frame was discarded.

--- note_Note_to_Readers

The issues list for this draft can be found at <https://github.com/phluid61/internet-drafts/labels/HTTP%2F2%20NAK%20Frame>

The most recent (often unpublished) draft is at <https://phluid61.github.io/internet-drafts/http2-nak-frame/>

--- middle

# Introduction

Out of the box, the Hypertext Transfer Protocol Version 2 (HTTP/2) {{RFC7540}} makes provision for
extension frames to be sent on a connection, with or without prior agreement from either peer, with
the assertion that "implementations MUST discard frames that have unknown or unsupported types"
({{RFC7540}}, Section 5.5).  However it can be useful to explicitly notify the peer if such a frame
is discarded.

This document defines an extension to HTTP/2 that allows a peer to signal that a received frame
was discarded, without altering the stream or connection state ({{RFC7540}}, Section 5.1), and in
particular without triggering an error condition.

## Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they
appear in all capitals, as shown here.

# Additions to HTTP/2 {#additions}

This document introduces a new HTTP/2 frame type ({{RFC7540}}, Section 11.2).

## DROPPED\_FRAME {#dropped-frame}

<cref anchor="NOTE-1" source="MK">This is an experimental value; if standardised, a permanent value will be assigned.</cref>

DROPPED\_FRAME frames (type code=0xf1) can be sent on a connection at any time after the
connection preface except in the middle of a header block ({{RFC7540}}, Section 4.3) to indicate
that a received extension frame was discarded without any other action being taken.

~~~~~~~~~~
  +---------------+
  |   Type (8)    |
  +---------------+
~~~~~~~~~~
{: title="DROPPED_FRAME Frame Payload"}

The DROPPED\_FRAME frame contains a single 8-bit integer containing the value of the Type field
from the discarded frame.

The DROPPED\_FRAME frame does not define any flags.

An endpoint SHOULD send a DROPPED\_FRAME frame for an unknown or unsupported extension frame type
the first time it discards a frame of that type.

An endpoint MAY send a DROPPED\_FRAME frame for a particular frame type only once, even if it
discards multiple frames of that type.

An endpoint that receives a DROPPED\_FRAME frame ought to take it as an indication that the
extension is not supported by the peer, and MAY subsequently choose not to send further frames of
that type or to attempt extension negotiation with the peer.

Receipt of a DROPPED\_FRAME frame does not necessarily mean that all frames on that connection with
the discarded type will be discarded in future.  A transparent intermediary that forwards an
extension frame in one direction and a corresponding DROPPED\_FRAME frame in the other direction
MUST NOT intercept future frames of that type and preemptively reply with a DROPPED\_FRAME frame.

DROPPED\_FRAME frames are not associated with any individual stream.  If a DROPPED\_FRAME frame is
received with a stream identifier field value other than 0x0, the recipient MUST respond with a
connection error ({{RFC7540}}, Section 5.4.1) of type PROTOCOL\_ERROR.

Receipt of a DROPPED\_FRAME frame with a length field value other than 1 MUST be treated as a
connection error ({{RFC7540}}, Section 5.4.1) of type FRAME\_SIZE\_ERROR.

An endpoint MUST NOT send a DROPPED\_FRAME frame with a Type of DROPPED\_FRAME (0xf1).  If a
DROPPED\_FRAME frame is received with a Type field value of 0xf1, the recipient MUST respond with
a connection error ({{RFC7540}}, Section 5.4.1) of type PROTOCOL\_ERROR.

Likewise, an endpoint MUST NOT send a DROPPED\_FRAME frame for a type it does not discard -- including
the frame types defined in {{RFC7540}}, Section 6, unless otherwise negotiated.  If a
DROPPED\_FRAME frame is received for a type that can not be discarded by the sending peer, the
recipient MUST respond with a connection error ({{RFC7540}}, Section 5.4.1) of type PROTOCOL\_ERROR.

Extensions that define new HTTP/2 frame types MAY specify behaviours in response to DROPPED\_FRAME
frames with those types, however extensions that change the semantics of existing protocol
components, including those defined in this document, MUST be negotiated before being used
({{RFC7540}}, Section 5.5).

# Security Considerations

Receipt of a DROPPED\_FRAME frame does not guarantee that the sending peer will send one for
every frame type it drops, and the absence of a DROPPED\_FRAME frame does not imply that the peer
has not discarded a frame.  Implementations MUST NOT depend on the use of DROPPED\_FRAME frames to
indicate acceptance or rejection of extension frames.

# IANA Considerations  {#iana}

This document updates the registry for frame types in the "Hypertext Transfer Protocol (HTTP) 2
Parameters" section.

## HTTP/2 Frame Type Registry Update

This document updates the "HTTP/2 Frame Type" registry ({{RFC7540}}, Section 11.2).  The entries
in the following table are registered by this document.

 |-----------------------|------|---------------------------|
 | Frame Type            | Code | Section                   |
 |-----------------------|------|---------------------------|
 | DROPPED\_FRAME        | TBD  | {{dropped-frame}}         |
 |-----------------------|------|---------------------------|

--- back

# Changelog

Since -02:

Since -01:

* use experimental value for frame ID
* forbid sending a DROPPED\_FRAME for any frame that isn't dropped

Since -00:

* Largely editorial; clarifications about when a frame can be received and what it
  can reasonably contain.

gha_language: XSLT


text:
# Contributing to Home Assistant

Everybody is invited and welcome to contribute to Home Assistant. There is a lot to do...if you are not a developer perhaps you would like to help with the documentation on [home-assistant.io](https://home-assistant.io/)? If you are a developer and have devices in your home which aren't working with Home Assistant yet, why not spent a couple of hours and help to integrate them?

The process is straight-forward.

 - Fork the Home Assistant [git repository](https://github.com/balloob/home-assistant).
 - Write the code for your device, notification service, sensor, or IoT thing.
 - Check it with ``pylint`` and ``flake8``.
 - Create a Pull Request against the [**dev**](https://github.com/balloob/home-assistant/tree/dev) branch of Home Assistant.

Still interested? Then you should read the next sections and get more details.

## Adding support for a new device

For help on building your component, please see the [developer documentation](https://home-assistant.io/developers/) on [home-assistant.io](https://home-assistant.io/).

After you finish adding support for your device:

 - Update the supported devices in the `README.md` file.
 - Add any new dependencies to `requirements.txt`.
 - Update the `.coveragerc` file.
 - Provide some documentation for [home-assistant.io](https://home-assistant.io/). The documentation is handled in a separate [git repository](https://github.com/balloob/home-assistant.io).
 - Make sure all your code passes Pylint and flake8 (PEP8 and some more) validation. To generate reports, run `pylint homeassistant > pylint.txt` and `flake8 homeassistant --exclude bower_components,external > flake8.txt`.
 - Create a Pull Request against the [**dev**](https://github.com/balloob/home-assistant/tree/dev) branch of Home Assistant.
 - Check for comments and suggestions on your Pull Request and keep an eye on the [Travis output](https://travis-ci.org/balloob/home-assistant/).

If you've added a component:

 - Update the file [`home-assistant-icons.html`](https://github.com/balloob/home-assistant/blob/master/homeassistant/components/frontend/www_static/polymer/resources/home-assistant-icons.html) with an icon for your domain ([pick one from this list](https://www.polymer-project.org/1.0/components/core-elements/demo.html#core-icon)).
 - Update the demo component with two states that it provides
 - Add your component to home-assistant.conf.example

Since you've updated `home-assistant-icons.html`, you've made changes to the frontend:

 - Run `build_frontend`. This will build a new version of the frontend. Make sure you add the changed files `frontend.py` and `frontend.html` to the commit.

### Setting states

It is the responsibility of the component to maintain the states of the devices in your domain. Each device should be a single state and, if possible, a group should be provided that tracks the combined state of the devices.

A state can have several attributes that will help the frontend in displaying your state:

 - `friendly_name`: this name will be used as the name of the device
 - `entity_picture`: this picture will be shown instead of the domain icon
 - `unit_of_measurement`: this will be appended to the state in the interface
 - `hidden`: This is a suggestion to the frontend on if the state should be hidden

These attributes are defined in [homeassistant.components](https://github.com/balloob/home-assistant/blob/master/homeassistant/components/__init__.py#L25).

### Proper Visibility Handling

Generally, when creating a new entity for Home Assistant you will want it to be a class that inherits the [homeassistant.helpers.entity.Entity](https://github.com/balloob/home-assistant/blob/master/homeassistant/helpers/entity.py) class. If this is done, visibility will be handled for you.
You can set a suggestion for your entity's visibility by setting the hidden property by doing something similar to the following.

```python
self.hidden = True
```

This will SUGGEST that the active frontend hides the entity. This requires that the active frontend support hidden cards (the default frontend does) and that the value of hidden be included in your attributes dictionary (see above). The Entity abstract class will take care of this for you.

Remember: The suggestion set by your component's code will always be overwritten by user settings in the configuration.yaml file. This is why you may set hidden to be False, but the property may remain True (or vice-versa).

### Working on the frontend

The frontend is composed of [Polymer](https://www.polymer-project.org) web-components and compiled into the file `frontend.html`. During development you do not want to work with the compiled version but with the seperate files. To have Home Assistant serve the seperate files, set `development=1` for the *http-component* in your config.

### Notes on PyLint and PEP8 validation

In case a PyLint warning cannot be avoided, add a comment to disable the PyLint check for that line. This can be done using the format `# pylint: disable=YOUR-ERROR-NAME`. Example of an unavoidable PyLint warning is if you do not use the passed in datetime if you're listening for time change.

repository: maddox/home-assistant

branch_name: refs/heads/dev

repo_name: maddox/home-assistant


text:
# ἅμα

<!-- Status: S2=NeedsEdits -->
<!-- Lexica used for edits:   -->

## Word data

* Strongs: G02600

* Alternate spellings:

* Principle Parts:

* Part of speech:

adv.

* Instances in Scripture: 10

* All Scriptures cited: Yes

## Etymology:

* LXX/Hebrew glosses:

* Time Period/Ancient Authors:

* Related words:

* Antonyms for all senses

* Synonyms for all senses:

## Senses

### Sense  1.0:

#### Definition:

#### Glosses:

at once;

#### Explanation:

together with;
early in the morning;

#### Citations:

at once (Lat. [simul]()): [Ac 24:26](Act 24:26) [27:40](Act 27:40), [Ro 3:12](Rom 3:12) (one and all = [יַחַד](//en-uhl/H3162), [Ps 14:3](Psa 14:3)), [Col 4:3](Col 4:3), [I Ti 5:13](1Ti 5:13), [Phm 22](Phm 1:22); seq. [σύν](), [I Th 4:17](1Th 4:17) [5:10](1Th 5:10); as prep. c. dat., together with: [Mt 13:29](Mat 13:29) (v. MM, VGT, s.v.); also, c. adv., [ἅ. πρωΐ]() (cl., [ἅ. ἕω](), etc.), early in the morning: [Mt 20:1](Mat 20:1).†

repository: mandolyte/uw-obsidian

repo_name: mandolyte/uw-obsidian


text:
---
layout: default
---

# 1996-07-22 - Re: Game Theory and its Relevance to Cypherpunks

## Header Data

From<EMAIL_ADDRESS>(Timothy C. May)

To<EMAIL_ADDRESS>Message Hash: a8fc209f05da456dcf2c5dbe459d75ec20364fd13753d069dc95b4559b90881f

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-07-22 06:13:11 UTC

Raw Date: Mon, 22 Jul 1996 14:13:11 +0800

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Timothy C. May)
Date: Mon, 22 Jul 1996 14:13:11 +0800
To<EMAIL_ADDRESS>Subject: Re: Game Theory and its Relevance to Cypherpunks
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Steve Tonnesen<EMAIL_ADDRESS>is the winner of the 5 point prize,
for his submission to me, the first I received with the correct answer:

At 3:24 AM 7/22/96, Steve Tonnesen wrote:

>>"I have a .45 and a shovel; I doubt you'll be missed." (5 points to
>>whomever first identifies the movie this was in)
>
>"Clueless",  I believe.
>

--Tim May

Boycott "Big Brother Inside" software!
We got computers, we're tapping phone lines, we know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
<EMAIL_ADDRESS>408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Licensed Ontologist         | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

{% endraw %}
```

## Thread

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

+ Return to<EMAIL_ADDRESS>(Timothy C. May)](/authors/tcmay_at_got_net_timothy_c_may_)"

+ 1996-07-22 (Mon, 22 Jul 1996 14:13:11 +0800) - Re: Game Theory and its Relevance to Cypherpunks -<EMAIL_ADDRESS>(Timothy C. May)_


text:
# wharf

A system for managing and provisioning Docker containers on a remote host using Ansible.

I developed this to quickly deploy multiple client projects to a server without worrying about polluting the server with conflicting dependencies or anything like that.

---

## Initial server setup for `WHARF_HOST`

`wharf` has only been tested on Ubuntu 18.04, but it should work on any system that supports Ansible and Docker. These instructions are for Ubuntu specifically.

```
sudo apt update
sudo apt upgrade -y

# Ansible requirements
sudo apt install -y python python-pip python-setuptools
sudo pip install docker-py # 2.7; for 3 use "docker"

# Install Docker
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install -y docker-ce

# Install nginx
sudo apt install -y nginx
```

---

## Control machine setup

1. Install Ansible: `pip install ansible`
2. Create `authorized_keys` in the `docker` folder (in this repo) with your public SSH key. This public key will be set as an authorized key for the Docker container, which gives Ansible access to provision it.
3. In your `/etc/environment` file (or wherever else you define environment variables), define an env var called `WHARF_HOST` which should be set to the host server IP or hostname, and one called `WHARF_USER` which is the user to login to `WHARF_HOST` as.
4. Add your public SSH key to the `WHARF_HOST` server.
5. Copy this repo to `/opt/wharf/`.
6. Symlink the `wharf` script to a more convenient location, e.g. `/usr/local/bin/`:

```
sudo ln -s /opt/wharf/wharf /usr/local/bin/wharf
```

---

## Usage

To deploy an application:

```
wharf deploy <APP NAME> <APP PLAYBOOK> <DOMAIN NAME>:<APP PORT>

# Example
wharf deploy example-project example/playbook.yml foo.site.com:8001
```

Note that `<APP PORT>`s must be unique for a server.

To destroy an application:

```
wharf destroy <APP NAME>
```

To see what containers are deployed:

```
wharf ls
```

To follow container logs:

```
wharf log <APP NAME>
```

To start a `bash` shell in an app container:

```
wharf bash <APP NAME>
```

To clean dangling docker images:

```
wharf clean
```

---

## How it works

Note on hosts: the parent host (the server, `WHARF_HOST`) is `wharf`, and the target Docker container is `container`.

1. Creates a base Docker image on `WHARF_HOST` with Ansible and SSH installed, and runs a script at `/usr/share/start.sh` (if you want to, for example, start a Flask application, you should create your own `start.sh` and overwrite the default one in your `<APP PLAYBOOK>`)
2. Creates `container` with the specified `<APP NAME>`, then exposes its SSH port to port 8888 on `WHARF_HOST` (so that Ansible can access it)
3. Uses the specified `<APP PLAYBOOK>` to deploy to the `WHARF_HOST`'s port 8888 (i.e. to `container`)
4. Unbinds the container's SSH port from `WHARF_HOST`'s port 8888 and binds its port 8000 (assumed port your service is running on) to the specified `<APP PORT>` of `container`
5. Mounts `/var/log/<APP NAME>` as `container`'s `/var/log` so logs are persisted on the host system
6. Setup nginx (w/ HTTPS/SSL) for the specified `<DOMAIN NAME>`, passing traffic to the specified `<APP PORT>`

---

## Tips

- Make sure your web service uses the host `<IP_ADDRESS>` and port `8000`.
- If you need files to persist between Docker image builds, you can use `/var/local/` in the container. This is mounted to `/var/local/<APP NAME>` on the host system.

---

## Example

A simple Flask playbook is included at `example/playbook.yml`.

TODO: update the example to use uwsgi/supervisor

---

# MIT License

Copyright 2019 Francis Tseng

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

repository: frnsys/wharf

repo_name: frnsys/wharf


text:
# Simple Local Testnet

With a functional [development environment](./setup.md), starting a local multi-node
testnet is easy:

1. Start the first node: `$ lighthouse bn testnet -f recent 8`
1. Start a validator client: `$ lighthouse bn testnet -b insecure 0 8`
1. Start more nodes with `$ lighthouse bn -b 10 testnet -f bootstrap
   http://localhost:5052`
   - Increment the `-b` value by `10` for each additional node.

## Detailed Instructions

First, setup a Lighthouse development environment and navigate to the
`target/release` directory (this is where the binaries are located).

## Starting a beacon node

Start a new node (creating a fresh database and configuration in `$HOME/.lighthouse`), using:

```bash
$ lighthouse bn testnet -f recent 8
```

> Notes:
>
> - The `-f` flag ignores any existing database or configuration, backing them
>   up before re-initializing.
> - `8` is number of validators with deposits in the genesis state.
> - See `$ lighthouse bn testnet recent --help` for more configuration options,
>   including `minimal`/`mainnet` specification.

## Starting a validator client

In a new terminal window, start the validator client with:

```bash
$ lighthouse vc testnet -b insecure 0 8
```

> Notes:
>
> - The `-b` flag means the validator client will "bootstrap" specs and config
>   from the beacon node.
> - The `insecure` command uses predictable, well-known private keys. Since
>   this is just a local testnet, these are fine.
> - The `0 8` indicates that this validator client should manage 8 validators,
>   starting at validator 0 (the first deposited validator).
> - The validator client will try to connect to the beacon node at `localhost`.
>   See `--help` to configure that address and other features.

## Adding another beacon node

You may connect another (non-validating) node to your local network using the
lighthouse `bootstrap` command.

In a new terminal window, run:

```bash
$ lighthouse bn -b 10 testnet -r bootstrap
```

> Notes:
>
> - The `-b` (or `--port-bump`) increases all the listening TCP/UDP ports of
>   the new node to `10` higher. Your first node's HTTP server was at TCP
>   `5052` but this one will be at `5062`.
> - The `-r` flag creates a new data directory with a random string appended
>   (avoids data directory collisions between nodes).
> - The default bootstrap HTTP address is `http://localhost:5052`. The new node
>   will download configuration via HTTP before starting sync via libp2p.
> - See `$ lighthouse bn testnet bootstrap --help` for more configuration.

repository: cryptomental/lighthouse

repo_name: cryptomental/lighthouse


text:
RLib provides several new abstractions for easier use of RDMA.
It is a header-only library with minimal dependices, i.e., `ibverbs`.

Please find examples in `./examples` for how to use RLib.
For detailed documentations or benchmark results (including code and scripts),
please check `docs`.

## Example

Here is a simplified example of using RLib to implement an one-sided READ:
```c++
      Arc<RC> qp; // some pre-initialized QP

      // An example of using Op to post an one-sided RDMA read.
      ::rdmaio::qp::Op op;
      op.set_rdma_rbuf(rmr.buf + 0xc, rmr.key).set_read();
      op.set_payload((u64)(lmr.buf), sizeof(u64), lmr.key)

      // post the requests
      auto ret = op.execute(qp, IBV_SEND_SIGNALED);
      RDMA_ASSERT(ret == IOCode::Ok);

     // wait for the completion
     auto res = qp->wait_one_comp();
     RDMA_ASSERT(res == IOCode::Ok) << "req error: " << res.desc;

```

For more examples, please check the `examples` folder.
There is a description of the examples in `docs/examples/` .

## License

RLib is released under the [Apache 2.0 license](http://www.apache.org/licenses/LICENSE-2.0.html).

As RLib is the refined execution framework of DrTM+H,
if you use RLib in your research, please cite our paper:

    @inproceedings {drtmhosdi18,
        author = {Xingda Wei and Zhiyuan Dong and Rong Chen and Haibo Chen},
        title = {Deconstructing RDMA-enabled Distributed Transactions: Hybrid is Better!},
        booktitle = {13th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 18)},
        year = {2018},
        isbn = {978-1-939133-08-3},
        address = {Carlsbad, CA},
        pages = {233--251},
        url = {https://www.usenix.org/conference/osdi18/presentation/wei},
        publisher = {{USENIX} Association},
        month = oct,
    }


text:
# react-simple-triangle

![alt text](https://raw.githubusercontent.com/randy-r/react-simple-triangle/master/screenshot.png)

Responsive triangle rendering react component.

The motivation behind this project/package emerged after attempts to apply a glow to the side(segments) composing a triangle.

The component will fill the width of the container element.

## Installation

```$npm install --save react-simple-triangle``` or ```yarn add react-simple-triangle```

or as an UMD module
```html
<script crossorigin src="https://unpkg.com/react-simple-triangle/umd/react-simple-triangle.min.js"></script>
```

## Usage
You can use it by writing in node
```javascript
import Triangle from '../react-simple-triangle/src/index';
```
or
```javascript
const Triangle = require('../react-simple-triangle/src/index').default;
```
(if using UMD)
```javascript
const Triangle = reactSimpleTriangle.Triangle
```

and place it where ever you need it. None of the props is necessary.

```javascript
ReactDOM.render(
  <div style={containerStyle} >
    <Triangle color="#f0ffef" glowColor='rgb(0,255,0)' onClick={() => alert('cliked')} />
  </div>,
  document.getElementById('root'),
);
```

## Licence
This project is licensed under the terms of the MIT license.

repository: randy-r/react-simple-triangle

repo_name: randy-r/react-simple-triangle


text:
---
layout: post
title: Predicting Car Prices in British Columbia
image: corolla_depreciation_highres.png
date: 2021-02-28 10:53:00 -0800
tags:
categories: Project
---
- Try out the live price predictor [here](https://vehicle-price-estimator.herokuapp.com/).
- Scraped and cleaned ~37,000 Craigslist vehicle listings from southern British Columbia
- Trained and productionized a gradient boosting model (MAE $2,300) to predict the market value of vehicles posted on Craigslist.
- Trained a linear model (MAE $6,500) to predict a dollar value for important vehicle features (e.g. size, fuel type, manufacturer, odometer, etc.)
  - Predictions indicate that diesel vehicles are worth ~$9,000 more than non-diesel vehicles, and that purchasing a vehicle directly from the owner (as apposed to a dealer) can save ~$2,000 off the asking price.
- Exploratory Data Analysis:
  - Found depreciation time constants for the most common vehicle models and manuacturers (e.g. which vehicles 'hold their value' the best). Found Toyota, Honda, and Volkswagen depreciate the slowest, while Dodge, Chevrolet, and Ford depreciate the fastest.
  - Produced a geographic distribution of vehicle types in the region (see below). The distribution of trucks was much flatter thoughout the region with smaller peaks around the urban centres, indicating a strong consumer preference for trucks in the suburbs.
  - Used interpolation/smoothing to create average contours of price vs odometer reading and age. This gave a benchmark depreciation of $0.20/km driven for the region.
  - From price distribution curves, found that sellers tend to price vehicles just under round multiples of $10,000, likely as a psychological pricing strategy.

# Code/Resources

**Python Version:** 3.8.5
**Libraries Used:** bs4, numpy, pandas, matplotlib, seaborn, scipy, geopandas, contextily, geoplot, sklearn, lightgbm

**Craigslist Web Scraping by Riley Predum:** https://towardsdatascience.com/web-scraping-craigslist-a-complete-tutorial-c41cea4f4981
**Data Science Project Walkthough by Ken Jee:** https://github.com/PlayingNumbers/ds_salary_proj#data-science-salary-estimator-project-overview
**Linear Coefficient Interpretation:** https://scikit-learn.org/stable/auto_examples/inspection/plot_linear_model_coefficient_interpretation.html

# 1. Web Scraping

I used the tutorial above as a basis to scrape vehicle listings from Craigslist. I needed to expand on the code a fair bit in order to scrape data from each individual vehicle listing page (as apposed to the search page which displays 120 listings at a time). In the end I was able to extract 16 features from each listing:

- body text (the main text of the listing)
- condition (eg. new, salvage)
- drive (front, rear, or 4wd)
- fuel (type of fuel)
- latlong (latitude and longitude associated with the posting)
- location (location associated with the posting, e.g. 'Vancouver')
- make (year make and model of the vehicle in a string, e.g. '2020 Toyota Corolla')
- odometer (odometer reading in km)
- paint color
- price (in $ CAD)
- sale type (owner or dealer)
- title status (e.g. clean, rebuilt)
- transmission (manual or automatic)
- type (e.g. sedan, minivan)
- cylinders (number of cylinders in the vehicles engine)
- size (e.g. full-size, compact)

# 2. Data Cleaning

About 11% of the scaped data was missing values. The columns with missing values were:

- condition:  21.3%
- drive:      24.5%
- odometer:   0.3%
- paint color:29.8%
- type:       30.7%
- cylinders:  37.4%
- size:       57.8%

I opted to fill most of this missing data before going forward.  'type', 'size', 'drive', and 'cylinders' were filled with the mode of the data, 'odometer' was filled by the mean, and 'paint color' and 'condition' were replaced with 'unknown.

Additional cleaning steps were:

- Combine 'pickup' and 'truck' into one category
- Convert the 'price' from a string to a number
- Split the latitude/longitde into distinct numerical columns
- Clean up the location column by taking only the first word of the location with some exceptions
- Split out the year, make and model of the vehicle into separate columns
- Split out the newly created model column into a base model and modifiers (many models have modifiers at the end such as 'lxt')
- Create an 'age' column by subtracting the current year from the 'year' column
- Create new columns based on if the text body contained words I selected as 'positive' (e.g. 'vintage') or 'negative' (e.g. 'torn'). Also created a column to indicate if the text had few (less than 30) words

# 3. Exploratory Data Analysis (EDA)

Major graphics and findings from the EDA are below. See the 'EDA' notebook for additional details.

## 3.1 Price Histogram and Density Functions

![Price Histogram](/images/price_hist.png)

Price distribution for all of the vehichles. The overall distribution is skewed right, with the most common price being between $3,000-$8,000. Note the dips in price at multiples of $10,000. This indicates a psychological pricing strategy (eg. asking $19,000 instead of $20,000 in hopes that the price will seem lower than it actually is).

![Price Density](/images/price_density.png)

Probability density of price for sedans, SUVs, and Trucks. The curves have been noramlized so the area under each curve is 1. Sedans are the most skewed to the low price end. SUVs and trucks have lower end options (under $10,000) but are also commonly found in the $30,000-$40,000 range. The psychological strategy of pricing just under multiples of $10,000 is more apparent here. This might be a good selling strategy if buyers use the pricing filter their search with a bands at round numbers.

Another interesting feature is the dip in trucks between $15,000 and $30,000, this may indicate there is less turnover in trucks for this price. The mean year and odometer reading for trucks in this price range is 2010 and 170,000km. Perhaps this means people are happy with their trucks in this range, so if you find one it could be a good buy.

## 3.2 Price Distribution by Odometer and Year

A contourplot of price vs odometer and year can give a birds-eye view of how vehicles depreciate over their lifetime. However generating such as plot is complicated by the noise and sparsity of the pricing data. That is, for a given year and odometer reading, there can be many different prices in the dataset, and the data is not filled in in a nice grid-like fashion. To get around this, the pricing data was first interpolated, then smoothed with a moving average filter.

The plots below and to the left show the raw scattered datapoints and three different methods for interpolating into a uniform grid. The 'nearest' was chosen and smoothed using a moving average with a window of 30,000km and 3 years. The result is shown on the contour plot below and to the right.

Odometer reading is much more important than year to determine price. According to this data, a newer vehicle would only loose ~20% ($8,000) of its value after 40 years with no driving. On the other hand, the same vehicle driven 50,000km in one year would lose 20-30% of its value.

The arrow on the plot indicates the depreciation for a vehicle driven 13,100 km driven per year ([average for British Columbia](https://www.ahainsurance.ca/car-insurance/average-mileage-per-year-canada/#:~:text=According%20to%20Natural%20Resources%20Canada,Canada%20is%20about%2015%2C200%20kilometres.)) for 10 years. This works out to a depreciation rate of $0.20/km.

## 3.3 Pricing of the Most Popular Vehicles

![pricing_popular](/images/pricing_popular.png)

## 3.4 Depreciation of the Most Popular Vehicles
When buying a car, you are not only interested in the current price, but the future price you might be able to sell it for. Here we will fit a decaying exponential function to individual model of vehicle to quantify the depreciation of that model over time. This will tell us if that model 'holds its value'. Below is the fit for the Toyota Corolla data.
![corolla_depreciation](/images/corolla_depreciation_highres.png)

By aggregating the depreciation time constant for the top 10 vehicles under each manufacturer, we can get an idea of which manufacturers hold their value the best. As shown below Toyotas lead the pack with a median time of about 2.1 years for a vehicle to depreciate 20%. Meanwhile a Dodge would only take 1.5 years to depreciate the same fraction. There is still large variability within manufacturers, so it is likely best to determine the depreciation value for the individual model in question when considering a purchase.

![deprecition_by_manufacturer](/images/deprecition_by_manufacturer.png)

## 3.5 Geographic Distribution of Vehicles

The plot below shows the distribution of sedan, suv, and truck sales by owner in lower mainland BC (where the heighest concentration of data is located). The top probability density curves show the normalized distribution of each vehicle type over longitude. As expected, distinct peaks in both curves occur around Vancouver/Richmond and Surrey where many sales are located.

Note that sedan and SUVs sales are more highly concentrated in the urban centres and truck sales are more evenly distribued. While it might be intuitive that trucks are more likely to be found in the suburbs, it is intersting to note that SUVs are found in high proportion in the city centres alongside sedans.

![geography_by_type](/images/geography_by_type.png)

# 4 Model Building

## 4.1 Lasso with Coefficient Interpretation (MAE $6,500)

Lasso is a linear model with an imposed penalty based on the sum of the linear coefficeints. This is useful in dealing with feature co-linearity as some of the coefficents can shrink to zero. The goal for this model was not produce the highest accruacy, but rather produce a set of linear coefficents which can be interpreted as dollar values for a vehicle possessing certain features.

Only the top 15 most popular brans were considered in this analysis. They are (in order of popuularity): Ford, Toyota, Honda, Chevrolet, Mazda, Nissan, Dodge, BMW, Hyundai, Volkswagen, Mercedes, Kia, Jeep, Audi, and GMC.

The model results are shown in the plot below, and can be used to get an idea of the value of the given vehicle traits. Values shown are averages over 5 cross-validation data sets repeated 5 times for a total of 25 models. The error bars show the extent of the data with outliers shown as separate dots. Most traits are 'yes/no'. The exceptions are cyilnders ($ per cylinder), age ($ per 5 years), odometer ($ per 25,000 km), and size ($ per step up between: sub-compact, compact, mid-size, full-size)

Keep in mind that this linear model is not particularly accurate (MAE $6,500), but it does capture the general trend of the data.

![](/images/Lasso.png)

## 4.2 LightGBM (MAE $2,300)

This tree-based gradient boosting model performed much better than the linear model. Only minor changes to the data were performed before fitting: outliers with a price above $100,000 and odometer above 1,000,000km were droped, and the few rows with missing data were dropped. LightGBM can handle categorical features directly so no encoding was required.

Optimal hyperparameters for the model were found with a cross-validated gridsearch over the entire dataset (sklearn GridSearchCV). Next 20% of the data was held out for validation and training/validation scores were plotted against boosting round iteration. While the training score dropped much lower than the validation score, the validation score at no point started to increase (see below).

With the hyperparameters and number boosting rounds chosen, the model was fit to the entire dataset for productionization.

![](/images/lgb_error.png)

extension: markdown


text:
# Face_Pose
Based on output of a face detector, this repository intends to estimate the pose of a detected human face.

This repository provides two different methods to estimate the pose (rotation angles) of a detected human face. Pose includes three parameters: Roll, Yaw, and Pitch (as shown in the following picture). The repository uses two different face detectors (MTCNN and RetinaFace) to show the effectiveness of the methods.

![Alt text](./pose_demo.png?raw=true "Title")

Method 1

Roll: -x to x (0: no rotation, positive: clock-wise rotation, negative: anti-clock-wise rotation)

Yaw:  -x to x (0: no rotation, positive: looking right, negative: looking left)

Pitch: 0 to 4 (0: looking upward, 1: looking straight, >1: looking downward)

Roll, Yaw and Pitch are in pixel ratios and provide an estimate of where the face is looking at. In case of mtcnn Roll is (-50 to 50), Yaw is (-100 to 100). Pitch is 0 to 4 because you can divide the distance between eyes and lips into 4 units where one unit is between lips to nose-tip and 3 units between nose-tip to eyes.

Method 2: as accurate as [NIST Face Image Quality Assessment](https://pages.nist.gov/frvt/api/FRVT_ongoing_quality_sidd_api.pdf)

This method provides pose parameters in angels (degrees).

Roll: -90 to 90 (0: no rotation, positive: clock-wise rotation, negative: anti-clock-wise rotation)

Yaw:  -90 to 90 (0: no rotation, positive: looking left, negative: looking right)

Pitch: -90 to 90 (0: no rotation, positive: looking upward, negative: looking downward)

Smile detection

In addition to pose, the repository also provide some additional features like smile detection.

Demo

Each of the two python files run a demo that estimates pose of a face in a live video stream from webcam/video file.

Note: These methods are very efficient and do not require huge data, training or machine learning.

Tested on:

Ubuntu 18.04, Ubuntu 22.04.1 LTS

numpy==1.17.0 to numpy==1.23.2

tensorboard==2.0.0 to tensorboard==2.9.1

opencv-python==<IP_ADDRESS> to opencv-python==<IP_ADDRESS>

Acknowledgement:

Face detection using mtcnn https://github.com/ipazc/mtcnn.

Face detection using retinaface https://github.com/peteryuX/retinaface-tf2