text:
# Start building your site

After ICEkit is [installed and running](../intro/install.md), it's time to
create the features of your site.

## Configure your project

You will need to provide some basic information to configure your project.

You can do so with environment variables, or by editing the `docker-cloud.yml`
and `icekit_settings.py` files.

All settings are optional, but you can provide:

  * `BASE_SETTINGS_MODULE` tells ICEkit to run in `develop` or `production`
    mode.

  * `EMAIL_HOST`, `EMAIL_HOST_PASSWORD` and `EMAIL_HOST_USER`, so ICEkit can
    send emails (only in `production` mode).

    We recommend [Mailgun](http://www.mailgun.com/), but any SMTP credentials
    will do.

  * `MASTER_PASSWORD` (only in `develop` mode) so you can login as any user
    with the same password.

  * `MEDIA_AWS_ACCESS_KEY_ID`, `MEDIA_AWS_SECRET_ACCESS_KEY` and
    `MEDIA_AWS_STORAGE_BUCKET_NAME` so ICEkit can store file uploads
    [Amazon S3](https://aws.amazon.com/s3/).

    The specified bucket should already exist, or the credentials provided
    should have permission to create buckets. This is especially important when
    deploying to ephemeral infrastructure, like Docker Cloud.

  * `PGDATABASE`, `PGHOST`, `PGPASSWORD`, `PGPORT` and `PGUSER`, if you need to
    connect to provide credentials for your PostgreSQL database.

    We recommend [Amazon RDS](https://aws.amazon.com/rds/), especially when
    deploying to ephemeral infrastructure, like Docker Cloud.

  * `SENTRY_DSN`, if you want to use [Sentry](https://getsentry.com/) for
    real-time error tracking.

  * `SITE_DOMAIN` and `SITE_NAME`, so ICEkit knows how to generate redirects
    correctly and knows what to call your site.

## Where to put files

Anything you put in the `static` or `templates` directories will override the
default ICEkit static files and templates.

You can specify additional Bower components in `bower.json`, Node modules in
`package.json`, and Python packages in `requirements.txt`.

The `icekit_settings.py` file is a Django settings module. You can override any
default Django/ICEkit settings or configure apps installed via `requirements
.txt`.

## Where's my virtualenv? How do I modify a source package?

If you're running in Docker, the requirements are installed in the Docker image
and aren't on your local machine.

From the [shell](commands.md#opening-a-shell), you can see what those
requirements are with:

    $ pip freeze

Or install packages (into `./var/venv/lib/python2.7/site-packages`):

    $ pip install django-debug-toolbar

Or install editable packages (into `./var/venv/src`):

    $ pip install -e 'git+https://github.com/ic-labs/django-icekit.git#egg=django-icekit'

Or list just the additional packages that you have already installed:

    $ pip freeze --user

You can also create a `requirements-local.txt` file (ignored by Git) that will
be installed automatically when the project is started.

repository: IdPowers/django-icekit

branch_name: refs/heads/develop

repo_name: IdPowers/django-icekit


text:
+++
title = "Go Advent Day 2 - Go 1.2 performance improvements"
linktitle = "Go 1.2 performance improvements"
date = 2013-12-02T06:40:42Z
author = ["Dave Cheney"]
series = ["Advent 2013"]
+++

## Introduction

7 months, 1600 changes, well over 350 issues closed¹, and [Go 1.2 is done](http://blog.golang.org/go12).

Go and install it now -- it's ok, it only takes a few minutes -- I'll wait.

When Go 1.1 was released earlier in the year I did a series of posts ([part 1](http://dave.cheney.net/2013/05/21/go-11-performance-improvements), [part 2](http://dave.cheney.net/2013/05/25/go-11-performance-improvements-part-2), [part 3](http://dave.cheney.net/2013/05/28/go-11-performance-improvements-part-3)) exploring the performance improvements the then current released provided. Go 1.1 was a herculean development effort, stretching some 14 months, and it brought with it equally impressive performance improvements.

This time around, Go 1.2 was a 7 month development effort with a fixed delivery date announced up front. Contributors spent 3-4 months landing improvements before a 3 month feature freeze.

Of course, shorter cycles mean less scope for performance improvement, but as we shall discover, Go 1.2 has not failed to deliver.

¹ [Go 1.2 Closed issues](https://code.google.com/p/go/issues/list?can=1&q=label%3Ago1.2+OR+label%3Ago1.2maybe+AND+status%3AFixed+&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles) -- the real number is probably higher; many issues are closed without being tagged for the release they are fixed in.

## The top line number

A widely quoted figure for the Go 1.1 performance improvements was [30-40%](http://golang.org/doc/go1.1#performance). As Go matures it becomes harder to find big performance gains, and it is just as difficult to summarize them in a single sentence. To find out more, read on.

## Performance headlines

This section highlights some of the major improvements that landed in Go 1.2.

### 8kb stack segments

Since the earliest days of Go, each goroutine has allocated stack segments in units of 4096 bytes. Being equal to the operating system page size made this a sensible default, but it had been known for some time that for code which was recursive or contained inner loops of long call chains (most of the `encoding/*` packages fall into this category) stack splitting, or stack straddling was a significant cause of slowdown and benchmark instability.

In October Russ Cox proposed doubling this value to 8k and [presented a detailed analysis](https://codereview.appspot.com/14317043/) to support this change. This one change boosted many of the Go 1 benchmarks by 10%, but the main clue that this was the right decision was that the infamously unreliable `JsonEncoder` benchmark became stable and predictable.

Russ's data demonstrated that the original 4k stack size was wrong, and as it had been chosen without empirical evidence, it was a number which could not be defended. However, increasing the granularity by which goroutines allocate memory from the operating system has a cost. The tradeoffs of this change are discussed in the final section of this article.

![](/postimages/day-02-go-1.2-performance-improvements/go1-amd64.png)
![](/postimages/day-02-go-1.2-performance-improvements/go1-386.png)
![](/postimages/day-02-go-1.2-performance-improvements/go1-arm.png)

### Preemption

Prior to Go 1.2 a single goroutine could hog the entire CPU if it ran in a tight loop. The effect of this CPU hogging is well known for programs which run with the default value of `GOMAXPROCS` but it has a more subtle effect on garbage collection performance.

When a garbage collection is requested the first action the GC takes is to stop the world; i.e. ask, then wait, for all goroutines to return to the scheduler. A single running goroutine can delay the stop the world phase, theoretically indefinitely, if it is performing a CPU intensive operation.

To solve this problem a check is added to the preamble of every function entry allowing the garbage collector to halt running goroutines faster, lowering the overall time for a GC cycle.

The Go 1.2 release notes [have more information](http://golang.org/doc/go1.2#preemption) on this feature and its limitations.

### Integrated network poller

The work that was started by Mikio Hara, Alex Brainman and Dmirty Vyukov in 1.1 integrating the the network polling subsystem directly into the runtime was completed for Windows and the BSD family. All platforms now use the integrated network poller. This has also resolved [the `freebsd/amd64`](http://golang.org/issue/5596) regression noted during Go 1.1.

![](/postimages/day-02-go-1.2-performance-improvements/freebsd-amd64-http.png)

### Garbage collector improvements

A large amount of work tool place during the 1.2 cycle to further improve the performance of the garbage collector.

While the garbage collector is not yet completely precise, its precision has improved over Go 1.1, which itself was a major improvement over 1.0.

Improving the precision of the garbage collector means fewer values on the heap are mistaken for pointers. This has the direct result that the heap is smaller. A smaller heap leads to lower garbage collection time overall as well as lowering the memory footprint of Go programs.

Sadly, many of the improvements are not enabled by default as they was not ready in time for the September 1 feature freeze. Finishing this work is a major focus of the 1.3 development cycle.

### Faster primitives

In my previous series on Go 1.1 I showed large data sets from the `runtime` package benchmarks. This time around I'm going to focus only on some key improvements.

### Memmove improvements

For Intel platforms [Keith Randall landed](https://codereview.appspot.com/9038048) a change shortly after the 1.2 tree opened that improved small memmove operations, and thus `copy`, significantly.

	 # linux/amd64
	 benchmark                                 old MB/s     new MB/s  speedup
	 BenchmarkMemmove32                         1405.39      5462.62    3.89x
	 BenchmarkMemmove4K                        22415.16     23127.08    1.03x
	 BenchmarkMemmove64K                       18583.10     18477.46    0.99x
	 BenchmarkMemmove4M                         5182.82      5171.82    1.00x
	 BenchmarkMemmove64M                        5159.03      5170.81    1.00x

	 # linux/386
	 benchmark                                 old MB/s     new MB/s  speedup
	 BenchmarkMemmove32                          400.89       942.76    2.35x
	 BenchmarkMemmove4K                         3014.72      3088.95    1.02x
	 BenchmarkMemmove64K                        1871.83      1875.65    1.00x
	 BenchmarkMemmove4M                          889.91       890.49    1.00x
	 BenchmarkMemmove64M                         882.89       888.91    1.01x

### Faster append

The `append` built-in function was improved in Go 1.1 by Rob Pike to reduce its overhead when being called on slices with a small number of elements, a common operation.

During 1.2 this was improved further by [Rémy Oudompheng](https://codereview.appspot.com/12815046/) who moved the append operations into the compiler, thus further reducing their overhead.

![](/postimages/day-02-go-1.2-performance-improvements/append.png)

### Unified strings and bytes primitives

In Go 1.1 `bytes.IndexByte` and `bytes.Equal` received assembly versions for all three architectures which improved their throughput.

### Cypto and compress improvements

One area where Go continues to lag is the performance of its crypto libraries.

During the cycle Nick Craig-Wood contributed a number of faster crypto primatives for arm (and I'm told more is to come).

Rémy Oudompheng significantly improved the speed of `crypto/des` and contributed major speedups to `compress/flate` and `compress/bzip2`

## Real world improvements

As Release Candidates started to arrive in September I took some time to brush the cobwebs off [autobench](https://github.com/davecheney/autobench) and put out a call for benchmark contributions. Along the way new benchmarks were contributed from external Go libraries which give an important view on the performance improvements Go 1.2 brings to code outside the standard library.

### Megajson performance
![](/postimages/day-02-go-1.2-performance-improvements/megajson.png)
Ben Johnson's [Megajson](https://github.com/benbjohnson/megajson) package shows a 15-30% improvement over Go 1.1.2.

### Snappy performance
![](/postimages/day-02-go-1.2-performance-improvements/snappy.png)
Snappy benchmarks show a big improvement on amd64 and arm platforms under Go 1.2. Oddly there is no improvement for 386.

These images are generated by AJ Starks' great [benchviz](http://mindchunk.blogspot.com.au/2013/05/visualizing-go-benchmarks-with-benchviz.html) tool.

## Wrapping up

So, does Go 1.2 deliver on the expectation of performance junkies ? In a word, yes.

A shorter development cycle and fewer low hanging fruit meant that developers had to work harder to find performance gains. For 64 bit Intel platforms the gains appear to be in the 15-20% range for real world code. For the other 32bit platforms, the gains are more modest, around 10%.

## Looking forward to the 1.3 development cycle

Planning for the 1.3 cycle has been underway for a month now. Rob Pike opened the discussion on the 2nd of November with [this thread](https://groups.google.com/d/msg/golang-dev/846QFpppXUo/satz-x5kxosJ) out of which came a [document](http://golang.org/s/go13todo) identifying the major items for this cycle. Russ Cox has also provided a [dashboard](http://research.swtch.com/dashboard/Go1.3#all) to track the progress of 1.3.

Dmitry Vyukov has announced a [performance dashboard](https://groups.google.com/forum/#!msg/golang-dev/SvByhCXPwG8/iDyRCaiQVGAJ) which will track a slew of measurements for each commit. The dashboard is currently running on a [temporary url](http://goperfd.appspot.com/perf) but is expected to be integrated into the [main CI dashboard](http://build.golang.org]) soon.

There is also a renewed focus on toolchain performance. We picked up a 30% speedup in compilation time in 1.1, but have lost most of that over the 1.2 cycle.

Russ Cox has proposed some wide ranging changes to the linker which will move more work to the compiler, thus becoming parallisable. Russ has published a document with his plans for a [revised linker in 1.3](http://golang.org/s/go13linker).

Similarly the size of final Go executables, while never svelte, have been rising steadily for some time now, so work will be done to [understand and reverse](https://code.google.com/p/go/issues/detail?id=6853) this trend.

Lastly, although Russ's work in raising the stack segment size to 8kb bought an important performance improvement, it did so at the cost that each goroutine now needs at least 8kb of stack space. For some applications that were happy with the original 4kb stack size, this is overkill, and depending on the sophistication of your operating system's virtual memory subsystem may lead to a larger memory footprint.

To resolve this Keith Randall has proposed moving the runtime to use [contiguous stacks](http://golang.org/s/contigstacks). Segmented goroutine stacks will grow and shrink as required without the high cost of straddling the stack segment boundary. Interestingly the Rust project developers have come to the [same conclusions](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html) and are also moving to a contiguous stack model.

repository: gopheracademy/gopheracademy-web

branch_name: refs/heads/master

extension: md

gha_language: CSS

gha_license_id: NOASSERTION

license_type: permissive

repo_name: gopheracademy/gopheracademy-web


text:
![build status](https://github.com/haxeui/haxeui-html5/actions/workflows/build.yml/badge.svg)

# haxeui-html5
`haxeui-html5` is the pure HTML5 backend for HaxeUI. It has no other framework dependency except `haxeui-core` itself and outputs a DOM tree.

## Installation
 * `haxeui-html5` has a dependency to `haxeui-core`, and so that too must be installed.

```
haxelib install haxeui-core
haxelib install haxeui-html5
```

## Usage
The simplest method to create a new HTML5 application that is HaxeUI ready is to use one of the haxeui-templates. These templates will allow you to start a new project rapidly with HaxeUI support baked in.

If however you already have an existing application, then incorporating HaxeUI into that application is straightforward:

### Haxe build.hxml
If you are using a command line build (via a `.hxml` file) then add these two lines:

```
-lib haxeui-core
-lib haxeui-html5
```

If you are using an IDE, like Flash Develop, add these lines via the project settings window.

_Note: Currently you must also include `haxeui-core` explicitly during the alpha, eventually `haxelib.json` files will exist to take care of this dependency automatically._

### Toolkit initialisation and usage
Initialising the toolkit requires you to add this single line somewhere _before_ you start to actually use HaxeUI in your application:

```
Toolkit.init();
```
Once the toolkit is initialised you can add components using the methods specified here.

## HTML5 specifics

As well as using the generic `Screen.instance.addComponent`, it is also possible to add components directly to any other DOM node: the `haxeui-html5` backend exposes a special `element` property for this purpose. Eg:

```haxe
js.Browser.document.getElementById("myContainer").appendChild(main.element);
```

### Initialisation options
The configuration options that may be passed to `Tookit.init()` are as follows:

```haxe
Toolkit.init({
    container: js.Browser.document.getElementById("myContainer") // where 'Screen' will place components
                                                                 // defaults to the document body
});
```

### Native components
HTML5 supports various native versions of components, and therefore so does HaxeUI. There are a few different ways to do this:

#### Using a theme (applies to all relevant components)
```haxe
Toolkit.theme = "native"; // will try to use native components where possible
```

#### Using haxe code (applies to single component)
```haxe
var button:Button = new Button();
button.native = true; // this component alone will be native
```

#### Using an inline style (applies to single component)
```xml
<button text="Native" style="native:true;" />
```
#### Using CSS (applies to groups of components)
```css
.button, #myNativeButton, .myNativeStyle {
	native: true;
}

```

## Addtional resources
* component-explorer - Browse HaxeUI components
* playground - Write and test HaxeUI layouts in your browser
* component-examples - Various componet examples
* haxeui-api - The HaxeUI api docs.
* haxeui-guides - Set of guides to working with HaxeUI and backends.

license: MIT


text:
# Utility for extracting a Mattermost auth token.

This is intended to be used with the [Mattermost IRC gateway](https://github.com/42wim/matterircd) when SAML authentication has been enabled.

The plugin works by launching a Chrome browser and authenticating a session. Once authenticated, the session
cookie will be extraced and saved to `~/.mmauthtoken`. The script then output a login line for the IRC gateway.

To install:

```
virtualenv env
. env/bin/activate
pip install -r requirements.txt
python setup.py develop
```

To use from Weechat to automatically authenticate at login set `irc.server.matter.command` to
`"/query -server $server mattermost; /exec -o -buffer irc.$server.mattermost PATH_TO_VIRTUALENV/bin/mattermost-auth -d <domainname> -t <teamname> -u <username>`

repository: recht/mattermost-auth

repo_name: recht/mattermost-auth


text:
GDX-Foogl project setup
===================

GDX-Foogl is based on [libGDX setup)(https://github.com/libgdx/libgdx/tree/master/extensions/gdx-setup). This setup powered by gradle, allowing any combination of sub projects and official extensions to get you up and running in a few clicks.  Although this tool will handle setup for you, LEARN GRADLE!
# What's New
- replace  gradle:2.2.3 with gradle:2.14.1
- replace  com.android.ide.eclipse.adt with  org.eclipse.andmore.AndroidNature

# Using
1. Download [gdxfoogl-setup.jar](gdxfoogl-setup.jar)
2. Double Click gdxfoogl-setup.jar

![Foogl Setup Ui](../www/foogl_setup.png)

The builder will generate the settings.gradle, build.gradle file, as well as alter all the platform specific files that reference dependencies/assets. The generated project can be opened with the Java IDE such as Eclipse, Netbean or Android Studio.

# Eclipse
- We recommend to install the lastest version of Eclipse for Android Developers. You can install via [Eclipse Neon](http://www.eclipse.org/downloads/)
1. Open Menu: File/Import/Gradle

![Eclipse Step 1](../www/eclipse_1.png)
  Import the generated project folder, which is created by GDX-Foogl project setup.

2. Run on Desktop
   Open poject: "your-project-game" and run class com.foogl.game.desktop.DesktopLauncher as Java Application

![Eclipse Step 2](../www/eclipse_2.png)

3. Demo scene will open!!

![Eclipse Step 3](../www/eclipse_3.png)

repository: twachikku/gdx-foogl

gha_language: Java

repo_name: twachikku/gdx-foogl


text:
CSV Wrangler
===================
[![Build Status](https://travis-ci.com/dabapps/csv-wrangler.svg?token=apzD3FKHpTNKHAtAu9xC&branch=master)](https://travis-ci.com/dabapps/csv-wrangler)
[![pypi release](https://img.shields.io/pypi/v/csv-wrangler.svg)](https://pypi.python.org/pypi/csv-wrangler)

Statically-typed Python 3 CSV generation helpers.
Write nicely typed CSV handling logic, with reorderable headers!

## Getting Started

### Installation

Install with `pip`

    pip install csv-wrangler

Add `csv_wrangler` to your installed apps

    INSTALLED_APPS = (
        ...
        'csv_wrangler',
    )

## Usage

### Create an Exporter

Generally, you'll want to subclass `Exporter` and provide two required changes, `headers` and `fetch_records`. You'll also want a way to get data into the exporter - override `__init__` for this.

You'll also need to specify a type for your headers to run over. We recommend you go with something like a `NamedTuple`, but any blob of data that is meaningful to you will do.

Let's create a `llama_exporter.py`:

```python
from typing import List
from csv_wrangler.exporter import Exporter, Header
from .models import Llama

# We start by defining Llama's type
Llama = NamedTuple('Llama', [('first_name': str), ('last_name': str), ('fluff_factor': int)])

# We can define a helper function if needed
def get_full_name(llama):
    return "{} {}".format(llama.first_name, llama.last_name)

# And we'll need our derived class
class LlamaExporter(Exporter):

    headers = [
        Header(label='name', callback=get_full_name),
        Header(label='fluff_factor', callback=lambda llama: str(llama.fluff_factor)),
        Header(label='first_name_length', callback=lambda llama: str(len(llama.first_name))),
    ]  # type: List[Header[Llama]]

    def __init__(self, llamas: List[Llama]) -> None:
        self.data = llamas

    def fetch_records(self) -> List[Llama]:
        return self.data
```

Here, our `fetch_records` is just spitting the data straight to the headers for unpacking. If you have more complex requirements, `fetch_records` is a good place to convert to a list of easily accessed blobs of data.

Note that we specify the type of the header for `headers`. This allows the typechecker to find out quickly if any of your headers are accessing data incorrectly.

When you want to access `self` in `headers`, you can use the function `get_headers` instead. (Try to avoid using this function if not necessary, as it will slow things down) For example, the `LlamaExporter` could look like this:

```python
class LlamaExporter(Exporter):

    def __init__(self, llamas: List[Llama]) -> None:
        self.data = llamas
        self.llamas_are_cute = True

    def fetch_records(self) -> List[Llama]:
        return self.data

    def get_headers(self) -> List[Header[Llama]]:
        return [
            Header(label='name', callback=get_full_name),
            Header(label='fluff_factor', callback=lambda llama: str(llama.fluff_factor)),
            Header(label='first_name_length', callback=lambda llama: str(len(llama.first_name))),
            Header(label='are_llamas_cute?', callback=lambda llama: str(self.llamas_are_cute)),
        ]
```

### Use the Exporter
Now, we can use it. We have several methods for getting data out:

`to_list` will convert the data to a list of lists of strings (allowing you to pass it to whatever other CSV handling options you want):

```python
from .exporters import LlamaExporter
from .models import Llama
...

def some_function_where_i_want_to_use_csv_data():
    my_llamas = Llama.objects.all()
    exporter = LLamaExporter(llamas=my_llamas)
    data = exporter.to_list()
    # perhaps pass data to other CSV handling options
    return
```

whereas `as_response` will turn it into a prepared HttpResponse for returning from one of your views:

```python
from django.views import View
from .exporters import LlamaExporter
from .models import Llama
...

class LlamaCsvExportView(View):

    def get(self, request):
        my_llamas = Llama.objects.all()
        exporter = LLamaExporter(llamas=my_llamas)
        return exporter.as_response(filename='my_llamas')
```

If you simply want to get access to the CSV rows as strings, you can use the `as_csv_rows` method, which returns each row of the CSV in a list (as a generator).

When you want to setup and endpoint for getting the csv, this'll be as simple as adding the following to `urls.py`

```python
url(r'^llamas/csv/$', LlamaCsvExportView.as_view(), name="llama-csv")
```

Other nice features
-----------------
### Streamed Response

If your CSV is large, and takes a long time to generate, you should use a generator, or stream the response. `to_iter` and `as_streamed_response` are the generator_counterparts to the above methods, working in exactly the same way, just returning a generator and a `HttpStreamedResponse` respectively. By default, `to_list` calls `to_iter`, so if you need to do anything custom, it's best to do it in `to_iter`.

### Save to file-like object

Sometimes, you may need to save the CSV rather than return it as a response. To do this, you can pass a file-like object to the `dump` method. The CSV will be dumped into the file, without loading the whole thing into memory first.

This can be combined with [`StringIO`](https://docs.python.org/3/library/io.html#io.StringIO) to access the entire CSV as a string (not recommended for large CSVs).

### Ordering headers
You can also provide an ordering to the headers, if you want.  Simply assign a list of strings to `header_order` and when the data is unpacked, those headers who's labels match these will be placed in that order.

So for example in your view, you can add:

```python
exporter = LLamaExporter(llamas=my_llamas)
exporter.header_order = ['name', 'first_name_length', 'fluff_factor']
```

### Mulitple CSVs
If you end up in a situation where you need to output multiple CSV tables at once, you can use `MultiExporter`

```python
exporter = MultiExporter(
    LlamaExporter(my_llamas),
    AlpacaExporter(my_alpacas)
)
exporter.to_list()
```

This will append the second CSV after the first, with a single blank line between it.

### Simple Exporter
We also provide a `SimpleExporter`, for extracting information from a list of dictionaries.

Say you have a list of dictionaries

```python
dicts = [
    {
        'name': 'Lama glama',
        'fluff_factor': 9,
        'is_cute?': 'yes'
    },{
        'name': 'Lama guanicoe',
        'fluff_factor': 2,
    }
]
```
Then you can create a simple exporter with `headers = ['name', 'fluff_factor', 'is_cute?']` as `exporter = SimpleExporter(headers, dicts)`.
Your `exporter.to_list()` would be `[['name', 'fluff_factor', 'is_cute?'], ['Lama glama', '9', 'yes'], ['Lama guanicoe', '2', '']]`.

### Passthrough Exporter
You can use the `PassthroughExporter` when you already have a List of Lists of Strings.

So when you have the exact data you want to put in your CSV, you can simply create an exporter like this
```python
exporter = PassthroughExporter([
    ['name', 'fluff factor', 'is cute?'],
    ['Alpaca LLama', '10', 'yes'],
    ['Guanaco Llama', '6', 'no'],
])
```

Have fun!

## Code of conduct

For guidelines regarding the code of conduct when contributing to this repository please review [https://www.dabapps.com/open-source/code-of-conduct/](https://www.dabapps.com/open-source/code-of-conduct/)

repository: dabapps/csv-wrangler

gha_language: Python

repo_name: dabapps/csv-wrangler


text:
# FreeBSD-SA-19:05.pf Postmortem

## Summary

A bug in the pf(4) IPv6 fragment reassembly logic incorrectly uses the last extension header offset from the last received packet instead of from the first packet.

## Root Causes

xxx

## Resolution

xxx

## File

* sys/netpfil/pf/pf_norm.c

## Timeline

### Fri Mar 1 07:37:45 2019 +0000

https://github.com/freebsd/freebsd/commit/c674ede188217fc19c9063cbcfa79d2639a033d7

Fixed by kp.

## Supporting information

* Security Advisory: https://www.freebsd.org/security/advisories/FreeBSD-SA-19:05.pf.asc
* CVE: https://nvd.nist.gov/vuln/detail/CVE-2019-5597

repository: metasepi/postmortem

repo_name: metasepi/postmortem


text:
# Spectrum Analyzer
> Code for spectrum analysis of quartz impedance data acquired from Agilent 4294A and E4980A.

This project is aimed to analyze spectrum of certain electronic part. This code is designed to query frequency sweep data from impedance analyzer and analysis the output. By getting the resonate frequency, bandwidth and quality factor of electronic parts changing by time, we trying to find the relationship between impedance and physical property of electronic components.

## Installation

MATLAB:

pull from GitHub and run.

## Usage example

Measurement and Analysis:

1. Setup parameters of experiment in file<EMAIL_ADDRESS>
2. Run measurementExample.m MATLAB code to start experiment.

3. During the code running, copy the image to folder of experiment results.

4. Rename the image with experiment’s property. Like “1um coating PBS pos3.jpg”

5. Wait enough sweeps being finished.

6. Use ‘STOP’ button on Figure to stop measurement.

7. Analysis will automatically start and save the results.

8. Measurement and Analysis:

Analysis only:

1. Run "dataAnalyzerExample.m"
2. Select measurement result folder in pop-up massage box
3. Analysis will start and results will be saved.

## Development setup

## Release History

## Meta

## Contributing

repository: JianzhouSu/SpectrumAnalyzer

gha_language: MATLAB

gha_license_id: MIT

repo_name: JianzhouSu/SpectrumAnalyzer


text:
# Numeriko Core Module

This module contains the core interfaces for N-dimensional arrays
and default implementations of the most common algorithms. It is
experimental and currently in development so it may change without warning.

It's goal is to provide complete and efficient N-dimensional array containers
for general purposes, in particular for numerical computing, following the
kotlin style and idiomatic practices.

## Construction

Generic arrays are constructed with factory functions based on kotlin standard
library or with the DSL.
```kotlin
// standard library style constructor
val anArray = array1DOf("a", "1D", "array") // Array1D<String>

// DSL constructor
val withDsl = A["another", "1D", "array"] // Array1D<String>

// lambda constructor
val withLambda = array1D(3) { i -> "data$i" } // [data0, data1, data2]

//
val twoDimensions = array2D(2, 2) { i0, i1 -> "data$i0$i1" } // [[data00, data01], [data10, data11]]

```

In a very similar way primitive specializations are also constructed.
```kotlin
// standard library style constructor
val numbers = doubleArray1DOf(1.0, 2.0, 3.0) // DoubleArray1D

// DSL constructor, can use be constructed from various Number
val withDsl = D[4.0, 5, 6.5] // DoubleArray1D

// Can have more dimensions
val withDsl2D = D[D[4.0, 5,  6.5],
                  D[7.0, 8, -9  ]] // DoubleArray2D

// lambda constructor
val withLambda = doubleArray1D(4) { i -> 2.0 * i } // [0.0, 2.0, 4.0, 6.0]

// lambda constructor
val twoDimensions = doubleArray2D(4, 4) { i0, i1 -> if (i0 <= i1) 1.0 else 0.0 } // upper triangular

```

To obtain a mutable array, just call `asMutable()` to expose the mutable interface.

```kotlin
// There is also a zero initialized array factory function
val aLotOfZeros = doubleZeros(1000).asMutable() // MutableDoubleArray1D
val evenMoreZeros = doubleZeros(1000, 1000).asMutable() // MutableDoubleArray2D

```

## Basic Operations

### Access

For specialized rank interfaces, a get and set operator is available, for both
indices and ranges. In the case of ranges a view of the array is returned,
not a copy.

```kotlin
val myArray = doubleArray1D(10) { i -> i.toDouble() } // DoubleArray1D

myArray[4] // 4.0
myArray[2..6] // [2.0, 3.0, 4.0, 5.0, 6.0]
myArray[Last] // 9.0

val mutable = myArray.asMutable() // MutableDoubleArray1D

mutable[9] = -1.0
mutable[7..Last] // [7.0, 8.0, -1.0]
myArray[Last] // -1.0

val myArray2D = doubleArray(4, 3) { i0, i1 -> 2.0 * i0 - i1 } // DoubleArray2D

myArray2D[0, 1] // -1.0
myArrat2D[Last, Last] // 5.0

```

### Operators

Basic operator overloads are implemented to have a clean syntax on element
wise operations and index access.

```kotlin
// myArray and yourArray are DoubleArray1D

myArray + yourArray // Element wise addition
myArray - yourArray // Element wise subtraction
myArray * yourArray // Element wise multiplication
myArray / yourArray // Element wise division

3.14 * myArray // Element wise multiplication
```

## The ArrayND interfaces

All the array interfaces comply with the `Collection<T>` interface and
follow kotlin's convention for separation of the read-only and the
mutable interfaces. This enables out variance on the read-only interfaces
as well as self-documenting signatures specifying if the array is being
modified or just read from.

The parent interface is `ArrayND<T>` which is read-only, with
`MutableArrayND<T>` inheriting from it and extending it with content modifying
methods. As N-dimensional arrays tend to occupy a lot of memory, it is usually
desired to access the array with a mutable interface. This is why `ArrayND<T>`
implementations must implement `asMutable()` to provide a mutable interface
to it.

In addition to `ArrayND<T>`, specific implementations for primitives are planned
to be developed, such as `DoubleArrayND` which is currently available. This follows
kotlin's standard library conventions for `Array` such as `DoubleArray` or `IntArray`.
It's mutable versions are also available, for example `MutableDoubleArrayND`.

For additional type safety, low rank arrays have specialized interfaces, such
as `Array1D<T>` and `Array2D<T>`. Again, primitive specializations and mutable
versions are also available (e.g. `MutableDoubleArray2D`).

repository: TomasVolker/numeriko

repo_name: TomasVolker/numeriko


text:
# Tutorial 05 - Safe Globals

## A slightly longer tl;dr

When we introduced the globally usable `print!` macros in [tutorial 03], we
cheated a bit. Calling `core::fmt`'s `write_fmt()` function, which takes an
`&mut self`, was only working because on each call, a new instance of
`QEMUOutput` was created.

If we would want to preserve some state, e.g. statistics about the number of
characters written, we need to make a single global instance of `QEMUOutput` (in
Rust, using the `static` keyword).

A `static QEMU_OUTPUT`, however, would not allow to call functions taking `&mut
self`. For that, we would need a `static mut`, but calling functions that mutate
state on `static mut`s is unsafe. The Rust compiler's reasoning for this is that
it can then not prevent anymore that multiple cores/threads are mutating the
data concurrently (it is a global, so everyone can reference it from anywhere.
The borrow checker can't help here).

The solution to this problem is to wrap the global into a synchronization
primitive. In our case, a variant of a *MUTual EXclusion* primivite. `Mutex` is
introduced as a trait in `interfaces.rs`, and implemented by the name of
`NullLock` in `sync.rs` in the `arch` folder. For teaching purposes, to make the
code lean, it leaves out the actual architecture-specific logic for protection
against concurrent access, since we don't need it as long as the kernel only
executes on a single core with interrupts disabled.

Instead, it focuses on showcasing the Rust core concept of [interior mutability].
Make sure to read up on it. I also recommend to read this article about an
[accurate mental model for Rust's reference types].

If you want to compare the `NullLock` to some real-world mutex implementations,
you can check out implemntations in the [spin crate] or the [parking lot crate].

[tutorial 03]: ../03_hacky_hello_world
[interior mutability]: https://doc.rust-lang.org/std/cell/index.html
[accurate mental model for Rust's reference types]: https://docs.rs/dtolnay/0.0.6/dtolnay/macro._02__reference_types.html
[spin crate]: https://github.com/mvdnes/spin-rs
[parking lot crate]: https://github.com/Amanieu/parking_lot

### Give it a try

```console
make qemu
[...]
[0] Hello from pure Rust!
[1] Chars written: 26
[2] Stopping here.
```

## Diff to previous
```diff

diff -uNr 04_zero_overhead_abstraction/src/arch/aarch64/sync.rs 05_safe_globals/src/arch/aarch64/sync.rs
--- 04_zero_overhead_abstraction/src/arch/aarch64/sync.rs
+++ 05_safe_globals/src/arch/aarch64/sync.rs
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: MIT
+//
+// Copyright (c) 2018-2019 Andre Richter<EMAIL_ADDRESS>+
+//! Synchronization primitives.
+
+use crate::interface;
+use core::cell::UnsafeCell;
+
+//--------------------------------------------------------------------------------------------------
+// Arch-public
+//--------------------------------------------------------------------------------------------------
+
+/// A pseudo-lock for teaching purposes.
+///
+/// Used to introduce [interior mutability].
+///
+/// In contrast to a real Mutex implementation, does not protect against concurrent access to the
+/// contained data. This part is preserved for later lessons.
+///
+/// The lock will only be used as long as it is safe to do so, i.e. as long as the kernel is
+/// executing single-threaded, aka only running on a single core with interrupts disabled.
+///
+/// [interior mutability]: https://doc.rust-lang.org/std/cell/index.html
+pub struct NullLock<T: ?Sized> {
+    data: UnsafeCell<T>,
+}
+
+unsafe impl<T: ?Sized + Send> Send for NullLock<T> {}
+unsafe impl<T: ?Sized + Send> Sync for NullLock<T> {}
+
+impl<T> NullLock<T> {
+    pub const fn new(data: T) -> NullLock<T> {
+        NullLock {
+            data: UnsafeCell::new(data),
+        }
+    }
+}
+
+//--------------------------------------------------------------------------------------------------
+// OS interface implementations
+//--------------------------------------------------------------------------------------------------
+
+impl<T> interface::sync::Mutex for &NullLock<T> {
+    type Data = T;
+
+    fn lock<R>(&mut self, f: impl FnOnce(&mut Self::Data) -> R) -> R {
+        // In a real lock, there would be code encapsulating this line that ensures that this
+        // mutable reference will ever only be given out once at a time.
+        f(unsafe { &mut *self.data.get() })
+    }
+}

diff -uNr 04_zero_overhead_abstraction/src/arch/aarch64.rs 05_safe_globals/src/arch/aarch64.rs
--- 04_zero_overhead_abstraction/src/arch/aarch64.rs
+++ 05_safe_globals/src/arch/aarch64.rs
@@ -4,6 +4,8 @@

 //! AArch64.

+pub mod sync;
+
 use crate::bsp;
 use cortex_a::{asm, regs::*};

diff -uNr 04_zero_overhead_abstraction/src/bsp/rpi.rs 05_safe_globals/src/bsp/rpi.rs
--- 04_zero_overhead_abstraction/src/bsp/rpi.rs
+++ 05_safe_globals/src/bsp/rpi.rs
@@ -4,38 +4,114 @@

 //! Board Support Package for the Raspberry Pi.

-use crate::interface;
+use crate::{arch::sync::NullLock, interface};
 use core::fmt;

 pub const BOOT_CORE_ID: u64 = 0;
 pub const BOOT_CORE_STACK_START: u64 = 0x80_000;

 /// A mystical, magical device for generating QEMU output out of the void.
-struct QEMUOutput;
+///
+/// The mutex protected part.
+struct QEMUOutputInner {
+    chars_written: usize,
+}
+
+impl QEMUOutputInner {
+    const fn new() -> QEMUOutputInner {
+        QEMUOutputInner { chars_written: 0 }
+    }
+
+    /// Send a character.
+    fn write_char(&mut self, c: char) {
+        unsafe {
+            core::ptr::write_volatile(0x3F20_1000 as *mut u8, c as u8);
+        }
+    }
+}

-/// Implementing `console::Write` enables usage of the `format_args!` macros, which in turn are used
-/// to implement the `kernel`'s `print!` and `println!` macros.
+/// Implementing `core::fmt::Write` enables usage of the `format_args!` macros, which in turn are
+/// used to implement the `kernel`'s `print!` and `println!` macros. By implementing `write_str()`,
+/// we get `write_fmt()` automatically.
+///
+/// The function takes an `&mut self`, so it must be implemented for the inner struct.
 ///
 /// See [`src/print.rs`].
 ///
 /// [`src/print.rs`]: ../../print/index.html
-impl interface::console::Write for QEMUOutput {
+impl fmt::Write for QEMUOutputInner {
     fn write_str(&mut self, s: &str) -> fmt::Result {
         for c in s.chars() {
-            unsafe {
-                core::ptr::write_volatile(0x3F20_1000 as *mut u8, c as u8);
+            // Convert newline to carrige return + newline.
+            if c == '\n' {
+                self.write_char('\r')
             }
+
+            self.write_char(c);
         }

+        self.chars_written += s.len();
+
         Ok(())
     }
 }

 //--------------------------------------------------------------------------------------------------
+// BSP-public
+//--------------------------------------------------------------------------------------------------
+
+/// The main struct.
+pub struct QEMUOutput {
+    inner: NullLock<QEMUOutputInner>,
+}
+
+impl QEMUOutput {
+    pub const fn new() -> QEMUOutput {
+        QEMUOutput {
+            inner: NullLock::new(QEMUOutputInner::new()),
+        }
+    }
+}
+
+//--------------------------------------------------------------------------------------------------
+// OS interface implementations
+//--------------------------------------------------------------------------------------------------
+
+/// Passthrough of `args` to the `core::fmt::Write` implementation, but guarded by a Mutex to
+/// serialize access.
+impl interface::console::Write for QEMUOutput {
+    fn write_fmt(&self, args: core::fmt::Arguments) -> fmt::Result {
+        use interface::sync::Mutex;
+
+        // Fully qualified syntax for the call to `core::fmt::Write::write:fmt()` to increase
+        // readability.
+        let mut r = &self.inner;
+        r.lock(|inner| fmt::Write::write_fmt(inner, args))
+    }
+}
+
+impl interface::console::Read for QEMUOutput {}
+
+impl interface::console::Statistics for QEMUOutput {
+    fn chars_written(&self) -> usize {
+        use interface::sync::Mutex;
+
+        let mut r = &self.inner;
+        r.lock(|inner| inner.chars_written)
+    }
+}
+
+//--------------------------------------------------------------------------------------------------
+// Global instances
+//--------------------------------------------------------------------------------------------------
+
+static QEMU_OUTPUT: QEMUOutput = QEMUOutput::new();
+
+//--------------------------------------------------------------------------------------------------
 // Implementation of the kernel's BSP calls
 //--------------------------------------------------------------------------------------------------

-/// Returns a ready-to-use `console::Write` implementation.
-pub fn console() -> impl interface::console::Write {
-    QEMUOutput {}
+/// Return a reference to a `console::All` implementation.
+pub fn console() -> &'static impl interface::console::All {
+    &QEMU_OUTPUT
 }

diff -uNr 04_zero_overhead_abstraction/src/interface.rs 05_safe_globals/src/interface.rs
--- 04_zero_overhead_abstraction/src/interface.rs
+++ 05_safe_globals/src/interface.rs
@@ -20,17 +20,66 @@

 /// System console operations.
 pub mod console {
+    use core::fmt;
+
     /// Console write functions.
-    ///
-    /// `core::fmt::Write` is exactly what we need for now. Re-export it here because
-    /// implementing `console::Write` gives a better hint to the reader about the
-    /// intention.
-    pub use core::fmt::Write;
+    pub trait Write {
+        fn write_fmt(&self, args: fmt::Arguments) -> fmt::Result;
+    }

     /// Console read functions.
     pub trait Read {
-        fn read_char(&mut self) -> char {
+        fn read_char(&self) -> char {
             ' '
         }
     }
+
+    /// Console statistics.
+    pub trait Statistics {
+        /// Return the number of characters written.
+        fn chars_written(&self) -> usize {
+            0
+        }
+
+        /// Return the number of characters read.
+        fn chars_read(&self) -> usize {
+            0
+        }
+    }
+
+    /// Trait alias for a full-fledged console.
+    pub trait All = Write + Read + Statistics;
+}
+
+/// Synchronization primitives.
+pub mod sync {
+    /// Any object implementing this trait guarantees exclusive access to the data contained within
+    /// the mutex for the duration of the lock.
+    ///
+    /// The trait follows the [Rust embedded WG's
+    /// proposal](https://github.com/korken89/wg/blob/master/rfcs/0377-mutex-trait.md) and therefore
+    /// provides some goodness such as [deadlock
+    /// prevention](https://github.com/korken89/wg/blob/master/rfcs/0377-mutex-trait.md#design-decisions-and-compatibility).
+    ///
+    /// # Example
+    ///
+    /// Since the lock function takes an `&mut self` to enable deadlock-prevention, the trait is
+    /// best implemented **for a reference to a container struct**, and has a usage pattern that
+    /// might feel strange at first:
+    ///
+    /// ```
+    /// static MUT: Mutex<RefCell<i32>> = Mutex::new(RefCell::new(0));
+    ///
+    /// fn foo() {
+    ///     let mut r = &MUT; // Note that r is mutable
+    ///     r.lock(|data| *data += 1);
+    /// }
+    /// ```
+    pub trait Mutex {
+        /// Type of data encapsulated by the mutex.
+        type Data;
+
+        /// Creates a critical section and grants temporary mutable access to the encapsulated data.
+        fn lock<R>(&mut self, f: impl FnOnce(&mut Self::Data) -> R) -> R;
+    }
 }

diff -uNr 04_zero_overhead_abstraction/src/main.rs 05_safe_globals/src/main.rs
--- 04_zero_overhead_abstraction/src/main.rs
+++ 05_safe_globals/src/main.rs
@@ -21,6 +21,7 @@

 #![feature(format_args_nl)]
 #![feature(panic_info_message)]
+#![feature(trait_alias)]
 #![no_main]
 #![no_std]

@@ -44,8 +45,12 @@
 ///
 /// - Only a single core must be active and running this function.
 unsafe fn kernel_init() -> ! {
+    use interface::console::Statistics;
+
     println!("[0] Hello from pure Rust!");

-    println!("[1] Stopping here.");
+    println!("[1] Chars written: {}", bsp::console().chars_written());
+
+    println!("[2] Stopping here.");
     arch::wait_forever()
 }

```


text:
# **V1.03.5 Patch Notes**

## **New Commands/Features:**
Added Idol and Group information cards `%card (idol/group name)`

Added Drop One, Save One (AKA Bias Game) `%help BiasGame`

Added `%biasgame (male/female/all) (bracket size(4,8,16,32))`

Added `%stopbg` to end a Bias Game

Added Leaderboards to Bias Game Wins `%listbg`

Renamed `%stopgame` from GuessingGame to `%stopgg`

Added a maintenance reason when bot mods use `%maintenance`

Idol and Group Avatars/Banners are now stored under `images.irenebot.com`

Stray Kids, AleXa, Monsta X, Ateez Photos are currently processing and will be added soon.

Added Custom Commands

Added `%createcommand (command name) (message)` to create commands on a server.

Added `%deletecommand (command name)` to delete a custom command.

Added `%listcommands` to view the custom commands on a server.

Bot Statuses were added to Cache.

Added Bot Mod Command `%removestatus (status index)` to remove an already existing bot status.

A special check has been put in place to check for group photos with the guessing game.

Added ability to report guessing game photos as dead links OR group photos.

Dead Image Links & the channel object is now stored as cache.

## **Bug/Issue/Backend Fixes:**
Removed `quickstart.py` from code as it has not been used for months.

Fixed Infinite Loop of Custom Commands

Fixed Prefix Issue with Custom Commands that allowed any prefix.

Removed `%deletelink` , `%moveto` from Bot Mod commands.

Fixed Music not playing.

Fixed `%card` displaying fake group & idol relationships.

Fixed issue where `.webm` links were not uploading to discord.

repository: mrshahzl/IreneBot

repo_name: mrshahzl/IreneBot


text:
## Weather Today
```
Angular app to tell the weather of the day
```

#### Installation

got the boiler plate from following link
```
git clone --depth=1 https://github.com/angular/angular-seed.git <your-project-name>
```

#### Install dependencies
```
npm install
```

#### Run
```
npm start
```


text:
# Manager README

There’s been a bit of a rise in this idea of a Manager README - a document
wherein a manager essentially explains how they operate as a manager and to give
context about themselves. So here is an exercise in a Manager README.

**Note:** This is no longer a living document. Please see
[https://rfpludwick.github.io](https://rfpludwick.github.io) for the latest
version.

## Preface

My full name is Robert Frederick Philip Ludwick. From a young age, I have always
put my middle initial(s) in name fields, which is why you’ll see my email
signature (and other things) show Robert F.P. Ludwick. The original intent here
was to differentiate me from my grandfather; I’m just used to it now. And I do
have two middle names - I added the second one shortly before my wife and I got
married. There’s a story there, and please feel free to ask me about it
sometime.

I am married; I have a wonderful daughter, two cats, and a dog. I’ve been in
technology for over 15 years and come primarily from the LAMP stack. I became a
manager in early 2015.

This document largely covers my job as Software Development Manager for the
HostBaby Development Team at CD Baby in Portland, Oregon, USA.

## Career Tent-Poles

Most people have a set of career tent-poles - values, morals, and a work style
which are critically important to them as a person. At this point in my career,
I have two:

1. Work-life balance. I strive to ensure this balance for me and for my
employees. There may be occasions when overtime is warranted, but I endeavor to
retain work-life balance at all times. Death marches do nobody any good.
2. Diversity and inclusivity. The greater number of life experiences and
viewpoints brought to a team, the better. Groupthink does not help people grow
and learn. Being inclusive helps the more diverse among us to feel comfortable
in expressing their opinions and feelings.

## My Job

My job covers quite a lot of ground, but here are the highlights:

* Provide resources and context for your work
* Help you to grow in your career and realize your goals
* Help ensure that we deliver quality products and features to our stakeholders
and artists in a timely fashion
* Hold the team accountable for their work

## My Work Style

I am an early bird. With one brief exception, I have started my workdays by 8am
for the past 11 years. I do not expect you to match my schedule, but you may
occasionally get a morning salvo of communication from me if you start later in
the day. I try to get a lot done in the mornings.

I have email and Slack on my phone, and I will occasionally check them in
off-hours. If it is critical to contact me during off-hours, however, please
text me or call me. I will do the same if I must contact you during off-hours.
I cannot guarantee 24/7 availability as I share childcare duties at home.

## Communication

I’ll hold regular 1-on-1s with you - the schedule and length of time may vary,
but at minimum I prefer 30 minutes every two weeks. I will also have a shared
document into which both of us can list agenda items. I intend to not have our
1-on-1s focus on day-to-day operational tasks - ideally we’ll talk about
emerging trends, career trajectory, and such. That aside, I am willing to talk
about whatever you may need to talk about during our 1-on-1s. They’re for you
much more than they are for me.

I can get verbose in my written communication - sometimes too verbose. I believe
that offering plenty of detail and context is helpful in many scenarios, but
there are occasions where I need to be more concise. If you feel I’m getting too
wordy or long-winded, then please let me know. I communicate better in the
written form, and tend to prefer it in order to reduce miscommunications and
ambiguity, and to create a more “permanent record.” It allows me to better
collect my thoughts for dissemination and to refine my messaging. As a result, I
will expect you to read emails and to respond if requested to do so.

I aim to offer feedback as close to real-time as possible. If I have a concern,
some praise, or anything else contextual, then I will make an effort to bring
you the feedback as quickly as possible. I am always on the lookout for feedback
for myself as well, so please feel comfortable in giving me feedback. I will
actively solicit it and hope you feel safe enough to give me said feedback.

If we’re in a group setting discussing some problem, some idea, some whatever,
then I will largely keep my opinions to myself for a few minutes if at all
possible. Even if it’s a subject which I have brought to the group, I tend
towards letting others speak first. As a manager and leader, I know that my
words can carry more weight than I intend. This is why I let others speak first
and let discussions get rolling first unless it is necessary that I jump in with
my opinion quickly. I don’t want to steer the conversation in a particular
direction, or to possibly discourage others from voicing their opinions if those
opinions happen to differ from mine.

## Cadences & Meetings

I am a creature of habit and repetition. I will settle into my patterns and
cadences and will be quite happy there. My morning routine includes making a
daily cup of French Press coffee (if possible), for example. Over time you’ll
likely come to learn my common patterns to things like emergencies cropping up
all the way to my vocabulary patterns. If you see me acting strangely, there is
likely a reason and if you’re interested, please ask.

In terms of meetings I aim to always be on time to a meeting. To me, it is rude
to be late to a meeting because there are likely others wasting their time
waiting for latecomers. If I am chairing a meeting, then I intend to end it
early enough for others to be on time to any meetings which immediately follow.
If a meeting I’m chairing has run its course in less time than allotted, then
I’ll typically call it early to respect the time of others.

I rely on my calendar to ensure I have my day organized. I generally expect you
to also have an accurate calendar, which helps me and others to know when you
are available.

## Learning & Improvement

I’m always on the hunt to learn something or otherwise improve myself and my own
performance. These days, here are some things I’ve been putting my mind towards:

* Amazon Web Services
* Other emerging technologies (for instance, I looked at the Rust programming
language recently)
* Leadership and management, typically via blogs and others in the Rands
Leadership Slack
* Home improvement

## Other

* I enjoy levity and jokes. My sense of humor is typically described as
“Dad”-like. I tend to bring my sense of humor to work.
* My vocabulary is a tricky thing. Occasionally I’ll add new fun/obscure words
to my everyday speech, such as superfluous and anachronistic. Other times I’ll
completely forget the right technical term or acronym for something. Please seek
clarity from me if my vocabulary leaves you confused.
* People getting distracted during a meeting (via phone, typing frantically on
their laptop, etc.) bothers me.
* I learned a few jobs ago that I really love to help people. I love helping my
coworkers get their jobs done more efficiently, and I love helping my direct
reports with their needs and wants as well.
* I enjoy playing indoor soccer and video games.
* In 2016 I came down with Ramsay-Hunt syndrome, which left the left side of my
face with minimal muscular control. I’ve regained some movement - but not much -
and do not expect to ever fully regain its use. So if it looks like I’m
constantly raising just one eyebrow in your direction, the other one is likely
raised “in spirit.”

repository: rfpludwick/leadership

branch_name: refs/heads/main

repo_name: rfpludwick/leadership


text:
---
layout: default
---

# 1996-11-30 - Re: IPG Algorith Broken!

## Header Data

From: Bryan Reece<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 17eaf1355f7c857d57e42f7e2ddbac3a5c6dde3e5415e776e583b36f09679653

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1996-11-30 19:19:16 UTC

Raw Date: Sat, 30 Nov 1996 11:19:16 -0800 (PST)

## Raw message

```
{% raw  %}From: Bryan Reece<EMAIL_ADDRESS>Date: Sat, 30 Nov 1996 11:19:16 -0800 (PST)
To<EMAIL_ADDRESS>Subject: Re: IPG Algorith Broken!
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

   From<EMAIL_ADDRESS>   Date: Sat, 30 Nov 1996 02:41:28 -0600 (CST)
   cc: Bill Frantz<EMAIL_ADDRESS>	   John Anonymous MacDonald<EMAIL_ADDRESS><EMAIL_ADDRESS>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Shannon proved that you cannot prove what the plaintext
   is for OTPs,

Let P, K, and C represent bit strings of equal length.  Given a
ciphertext C, for every plaintext P there exists a key K such that

  P XOR K = C.

This is true (K=P XOR C).

   or for the system we have developed either.

False.

Let P and C represent byte strings of equal (arbitrary) length and K
represent the key string of fixed length.

The IPG algorithm can be summarized

  C = P XOR PRNG(K)

where PRNG(K) is the output of the pseudo-random number generator with
seed K.  The details of the PRNG are unimportant for this argument.

For every ciphertext C longer than K, there exists a plaintext P such that
no K will satisfy

  C = P XOR PRNG(K).

Proof: There are 256^length(K) possible keys (roughly 10^34322).
There are therefore at most this many possible decryotions of the
given plaintext.  Since length(C) > length(K), there are more possible
plaintexts than possible decryptions.

Shannon's proof of the security of the OTP therefore doesn't
apply to IPG's cipher.

Assume that the PRNG is resistant to analysis. Given the size of the
keyspace, it is not feasible to search the whole keyspace hoping
something like a plaintext pops out.  However, it is easy to take a
key obtained through some other means and verify that the plaintext
makes sense.  Since the PRNG is assumed resistant to analysis, this
constitutes proof that the plaintext is correct (since it's infeasible
to find a key that decrypts the ciphertext to another plausible
plaintext).

Of course, all encryption algorithms short of the OTP allow an
attacker to prove a key correct, but most cryptographers don't claim
their algorithms to be as secure as OTPs.

{% endraw %}
```

## Thread

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

+ Return to "[Bryan Reece <reece@taz.nceye.net>](/authors/bryan_reece_reece_at_taz_nceye_net_)"
+ Return to<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)](/authors/dlv_at_bwalk_dm_com_dr_dimitri_vulis_kotm_)"
+ Return to<EMAIL_ADDRESS>(Bill Frantz)](/authors/frantz_at_netcom_com_bill_frantz_)"
+ Return to "[The Deviant <deviant@pooh-corner.com>](/authors/the_deviant_deviant_at_poohcorner_com_)"
+ Return to "[wichita@cyberstation.net](/authors/wichita_at_cyberstation_net)"

+ 1996-11-24 (Sat, 23 Nov 1996 18:42:02 -0800 (PST)) - [Re: IPG Algorith Broken!](/archive/1996/11/52071b20586e857f6639ea7fa73d63f9dc8ab7fbbfe52047d9022bad543ad186) -<EMAIL_ADDRESS>(Bill Frantz)_
  + 1996-11-24 (Sun, 24 Nov 1996 06:19:09 -0800 (PST)) - [Re: IPG Algorith Broken!](/archive/1996/11/9655cb43851d566e60f6ac6362c570eb6eba34095ccd59e20f2e18b6b17a7ee8) - _The Deviant<EMAIL_ADDRESS>    + 1996-11-30 (Sat, 30 Nov 1996 00:41:41 -0800 (PST)) - [Re: IPG Algorith Broken!](/archive/1996/11/78df59f10aaed27bc55b891f3090f3c9bf46d386f68828e569990d2827ccf582) -<EMAIL_ADDRESS>      + 1996-11-30 (Sat, 30 Nov 1996 08:10:53 -0800 (PST)) - [Re: IPG Algorith Broken!](/archive/1996/11/46cbf53b962f820913a4e8a1ee039f78e9274bb8e214cdc1c58acef224dd8857) -<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)_
      + 1996-11-30 (Sat, 30 Nov 1996 11:19:16 -0800 (PST)) - Re: IPG Algorith Broken! - _Bryan Reece<EMAIL_ADDRESS>  + 1996-11-30 (Sat, 30 Nov 1996 00:15:07 -0800 (PST)) - [Re: IPG Algorith Broken!](/archive/1996/11/cb2c8eddb82118d3725821b7666c88f94c3e941527214169d98f84320f456502) -<EMAIL_ADDRESS>


text:
# SavvyCAN
QT based cross platform canbus tool
(C) 2015 EVTV and Collin Kidder

A QT5 based cross platform tool which can be used to load, save, and capture canbus frames.
This tool is designed to help with visualization, reverse engineering, debugging, and
capturing of canbus frames.

Currently canbus capture requires a CANDue board from EVTV:
(http://store.evtv.me/proddetail.php?prod=ArduinoDueCANBUS&cat=23)

The CANDue board must be running the GVRET firmware which can also be found
within the collin80 repos.

repository: hermixy/SavvyCAN

repo_name: hermixy/SavvyCAN


text:
[![Coverage](https://sonarcloud.io/api/project_badges/measure?project=PInfo-2020_PInfo-3&metric=coverage)](https://sonarcloud.io/dashboard?id=PInfo-2020_PInfo-3) [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=PInfo-2020_PInfo-3&metric=alert_status)](https://sonarcloud.io/dashboard?id=PInfo-2020_PInfo-3) [![Build Status](https://travis-ci.com/PInfo-2020/PInfo-3.svg?branch=master)](https://travis-ci.com/PInfo-2020/PInfo-3)
# DIGESTEVE

Repository for PInfo-2020's team 3

## Team members:

* **Roxane Burri** - *Project Manager*
* **Luka Lukic** - *Developer*
* **Salma Ennaji** - *Developer*
* **Nathan Cohen** - *Developer*
* **Benjamin Fischer** - *Developer*
* **Elham Amin Mansour** - *System Administrator*

## How to set up your project:

Yoooou have two choices to set up your project:

- If you want to start from the project at [hostettler/microservices](https://github.com/hostettler/microservices), simply copy and paste the contents of the repository into your project (except for the `.git` folder and the `README.md`) and push everything to your repository. You will then modify the project as you advance in your work and replace the services in it.

- If you'd rather start a project from the ground up, you can simply delete all the contents of your repository after you've completed the TODO list below, and add your own microservices and web-ui to your project when you'll start working on them.

Below is the list of tasks you will need to complete to set up continuous integration and continuous deployment in your project:

1. As mentionned above, begin by copy-pasting the contents of [hostettler/microservices](https://github.com/hostettler/microservices) (except for the `README.md` and the `.git` folder) into your project.

2. Replace the title of the README.md with your project's name.

3. Replace the placeholders in the team members list with the real names and roles of the members in your team.

4. Travis CI is already configured to watch over your repository. It will execute whatever commands you put into your project's `.travis.yml` file. To see the result of Travis CI after you've pushed something on your repository, go to the [Travis CI website](https://travis-ci.org/) and sign in with your GitHub account. You might need to go to the `settings` page and add *PInfo-2020* to your list of authorized organizations. After you've pushed the microservices to your project, you should see a failed build. This is normal.

5. Go to the [Sonarcloud website](https://sonarcloud.io/) and sign in with GitHub. Again, you will need to add the *PInfo-2020* organization to your account. Once this is done, follow the instructions to set up the analysis for your project's repository.

6. Update the `.travis.yml` file with your own Sonarcloud project key, organization and login. Do the same in the `sonar-project.properties` file.

7. Go to the [DockerHub website](https://hub.docker.com/) and create an account for your team.

8. Go to your repository's settings on Github in the *secrets* tab, and add two new secrets called `DOCKER_USERNAME` and `DOCKER_PASSWORD` with your DockerHub's account name and password, respectively.

9. Replace `stevehostettler` with your DockerHub's account name in the `.travis.yml` file on the `docker tag ...` and `docker push ...` lines.

10. The last step is to set up the continuous deployment of the application on your team's server. Try to find how to do this ! Hint 1: Things should happen in the `.travis.yml` file. Hint 2: SSH is your friend. Hint 3: For the time being, you can just use docker-compose (you will see how to use Kubernetes later in the course). You might find some useful commands in the second blog post on hostettler.net.

Feel free to remove the steps above from your README.md once you're done with the set up.

branch_name: refs/heads/developer


text:
# AddPhoneticSymbolForArticel
a python program that add phonetic symbol to entire article for check prounciation errorr

## Environment
python: 3.5

## HOW TO USE

* copy and past your article to article.txt
* run: python NoteArticle.py
* result will be in outout.txt

## NOTE:

* some punctuation is not supported, I will add them when I encounter new punctation when I am using this program.


text:
# #648 P-40B Flying Tiger in 1:72

Building the most excellent Airfix P-40B H81-A2 1:72 in Flying Tigers livery.

No electronics in this one.

![Build](./assets/FlyingTigers_build.jpg?raw=true)

## Notes

The Hawk 81A-2 is an export version of the [P-40B](https://en.wikipedia.org/wiki/Curtiss_P-40_Warhawk_variants#P-40B),
with 110 aircraft produced for the RAF as Tomahawk Mk.IIs and Mk.IIAs.
Apparently some ended up with the [Flying Tigers](https://en.wikipedia.org/wiki/Flying_Tigers) in Kunming, China.

The aircraft depicted in this
[Airfix A01003 1:72 kit](https://www.scalemates.com/kits/airfix-a01003-curtiss-hawk-81-a-2--131395)
was flown by Flight Leader Charles H. Older,
Third Squadron, American Volunteer Group, Kunming, China, 1942.

It sports the roundels of the Republic of China, and a "Flying Tiger" insignia that was created by the Walt Disney Company.

### Paint Scheme

To the extent I kept track of this...

| Feature         | Color                                        | Recommended | Paint Used |
|-----------------|----------------------------------------------|-------------|------------|
| cockpit         | Pale Yellow                                  | Humbrol 81  | Vallejo 70.824 German Camo Orange Ochre |
| prop tips       | Matt Trainer Yellow                          | Humbrol 24  | 70.952 Lemon Yellow |
| lower fuselage  | Matt Camouflage Grey (approx DuPont 71-021)  | Humbrol 28  | 70.986 Deck Tan + 70.993 white grey ~4:1 |
|                 | Matt Black                                   | Humbrol 33  | |
| upper camo      | Matt US Dark Green (approx DuPont 71-013)    | Humbrol 116 | 70.893 US Dark Green |
| upper camo      | Matt US Light Earth (approx DuPont 71-009)   | Humbrol 119 | 70.921 English Uniform w/ 70.824 German Camo Orange Ochre ~ 3:1 |

### Build Log

I love the way Airfix designed the cockpit to be built up on the wing, with the fuselage fitting neatly over the top.

![build01a](./assets/build01a.jpg?raw=true)

I seem to have not taken any more WIP shots. So straight from painting and decaling:

![build02a](./assets/build02a.jpg?raw=true)

![build02b](./assets/build02b.jpg?raw=true)

![build02c](./assets/build02c.jpg?raw=true)

![build02d](./assets/build02d.jpg?raw=true)

With an antenna aerial rigged:

![build03a](./assets/build03a.jpg?raw=true)

![build03b](./assets/build03b.jpg?raw=true)

Although just simple decals, the cockpit dashboard is nicely visible through the canopy

![build03c](./assets/build03c.jpg?raw=true)

It does look quite menacing if you need to stare it down!

![build03d](./assets/build03d.jpg?raw=true)

The Airfix 1/72 Flying Tigers P-40B joins its little brother - [AFVClub 1/144](../AFVClub68).

![flying_tigers_2](./assets/flying_tigers_2.jpg?raw=true)

## Credits and References

* [this project on scalemates](https://www.scalemates.com/profiles/mate.php?id=74137&p=projects&project=127983)
* [Curtiss Hawk 81-A-2 Airfix No. A01003 1:72](https://www.scalemates.com/kits/airfix-a01003-curtiss-hawk-81-a-2--131395)
* [Curtiss P-40 Warhawk](https://en.wikipedia.org/wiki/Curtiss_P-40_Warhawk) - wikipedia
* [P-40B](https://en.wikipedia.org/wiki/Curtiss_P-40_Warhawk_variants#P-40B) - wikipedia
* [Flying Tigers](https://en.wikipedia.org/wiki/Flying_Tigers) - wikipedia
* [Curtiss-Wright Model 81-A2](https://www.thisdayinaviation.com/tag/curtiss-wright-model-81-a2/) - this day in aviation
* [BUILD JOURNAL Curtiss Hawk 81-A-2](https://luftraum72.com/curtiss-hawk-81-a-2-diary/) - luftraum72

repository: tardate/LittleArduinoProjects

repo_name: tardate/LittleArduinoProjects


text:
+++
# A Demo section created with the Blank widget.
# Any elements can be added in the body: https://sourcethemes.com/academic/docs/writing-markdown-latex/
# Add more sections by duplicating this file and customizing to your requirements.

widget = "blank"  # See https://sourcethemes.com/academic/docs/page-builder/
headless = true  # This file represents a page section.
active = true  # Activate this widget? true/false
weight = 15  # Order that this section will appear.
share = false
profile = false
date = "2020-06-23"

title = "V1.1"
subtitle = ""

[design]
  # Choose how many columns the section has. Valid values: 1 or 2.
  columns = "1"

[design.background]
  # Apply a background color, gradient, or image.
  #   Uncomment (by removing `#`) an option to apply it.
  #   Choose a light or dark text color by setting `text_color_light`.
  #   Any HTML color name or Hex value is valid.

  # Background color.
  # color = "white"

  # Background gradient.
  #gradient_start = "DarkGreen"
  # gradient_end = "ForestGreen"

  # Background image.
  # image = "image.jpg"  # Name of image in `static/img/`.
  # image_darken = 0.6  # Darken the image? Range 0-1 where 0 is transparent and 1 is opaque.

  # Text color (true=light or false=dark).
  # text_color_light = true

[design.spacing]
  # Customize the section spacing. Order is top, right, bottom, left.
  padding = ["20px", "0", "20px", "0"]

[advanced]
 # Custom CSS.
 css_style = ""

 # CSS class.
 css_class = ""
+++

The ACMUS-MIR V1.1 is a selection of music taken from the Músicas Regionales Archive in Medellin, Colombia.
The data set  contains a total of 419 segments of annotated music. The data set was compiled to support the development of computational methods for three main tasks:

The dataset has been published as a Zenodo repository [here](https://zenodo.org/record/3965447).

If you wish to use ACMUS_MIR V1.1, please use this [citation](../citev11.bib).

repository: ACMUS-MIR/academic-kickstart

repo_name: ACMUS-MIR/academic-kickstart


text:
#### class ClipperLibWrapper

A wrapper for the Native Clipper Library instance with all the operations available.

###### Properties

* **static readonly hiRange =<PHONE_NUMBER>740991 (Number.MAX_SAFE_INTEGER)**

    Max coordinate value (both positive and negative).

* **readonly instance: NativeClipperLibInstance**

    Native library instance.

* **readonly format: [NativeClipperLibLoadedFormat](../libInit/NativeClipperLibLoadedFormat.md)**

    Native library format.

* **[clipToPaths](../clipping/clipTo.md)(params: [ClipParams](../clipping/ClipParams.md)): [Paths](../shared/Paths.md) | undefined**
* **[clipToPolyTree](../clipping/clipTo.md)(params: [ClipParams](../clipping/ClipParams.md)): [PolyTree](../shared/PolyTree.md) | undefined**

    Performs a polygon clipping (boolean) operation, returning the resulting Paths/PolyTree or throwing an error if failed.
    See the method detailed [documentation](../clipping/clipTo.md) for more details.

* **[offsetToPaths](../offsetting/offsetTo.md)(params: [OffsetParams](../offsetting/OffsetParams.md)): [Paths](../shared/Paths.md) | undefined**
* **[offsetToPolyTree](../offsetting/offsetTo.md)(params: [OffsetParams](../offsetting/OffsetParams.md)): [PolyTree](../shared/PolyTree.md) | undefined**

    Performs a polygon offset operation, returning the resulting Paths/PolyTree or undefined if failed.
    See the method detailed [documentation](../offsetting/offsetTo.md) for more details.

* **area(path: [Path](../shared/Path.md)): number**

    This function returns the area of the supplied polygon. It's assumed that the path is closed and does not self-intersect. Depending on orientation,
       * this value may be positive or negative. If Orientation is true, then the area will be positive and conversely, if Orientation is false, then the
       * area will be negative.

* **cleanPolygon(path: [Path](../shared/Path.md), distance = 1.1415): [Path](../shared/Path.md)**
* **cleanPolygons(paths: [Paths](../shared/Paths.md), distance = 1.1415): [Paths](../shared/Paths.md)**

    Removes vertices:

    * that join co-linear edges, or join edges that are almost co-linear (such that if the vertex was moved no more than the specified distance the edges would be co-linear)
    * that are within the specified distance of an adjacent vertex
    * that are within the specified distance of a semi-adjacent vertex together with their out-lying vertices

    Vertices are semi-adjacent when they are separated by a single (out-lying) vertex.

    The distance parameter's default value is approximately √2 so that a vertex will be removed when adjacent or semi-adjacent vertices having their corresponding X and Y coordinates differing by no more than 1 unit. (If the egdes are semi-adjacent the out-lying vertex will be removed too.)

    ![image](https://user-images.githubusercontent.com/6306796/28290343-5dc75e46-6b46-11e7-83aa-4a387823d1a9.png)
    ![image](https://user-images.githubusercontent.com/6306796/28290361-69632726-6b46-11e7-880a-09b965dde079.png)

* **closedPathsFromPolyTree(polyTree: [PolyTree](../shared/PolyTree.md)): [Paths](../shared/Paths.md)**

    This function filters out open paths from the PolyTree structure and returns only closed paths in a Paths structure.

* **minkowskiDiff(poly1: [Path](../shared/Path.md), poly2: [Path](../shared/Path.md)): [Paths](../shared/Paths.md)**

    Minkowski Difference is performed by subtracting each point in a polygon from the set of points in an open or closed path. A key feature of Minkowski Difference is that when it's applied to two polygons, the resulting polygon will contain the coordinate space origin whenever the two polygons touch or overlap. (This function is often used to determine when polygons collide.)

    ![image](https://user-images.githubusercontent.com/6306796/28290392-8cd0af94-6b46-11e7-9bad-fd2e245cddc8.png)

    In the image above left the blue polygon is the 'minkowski difference' of the two red boxes. The black dot represents the coordinate space origin

* **minkowskiSumPath(pattern: [Path](../shared/Path.md), path: [Path](../shared/Path.md), pathIsClosed: boolean): [Paths](../shared/Paths.md)**
* **minkowskiSumPaths(pattern: [Path](../shared/Path.md), paths: [Paths](../shared/Paths.md), pathIsClosed: boolean): [Paths](../shared/Paths.md)**

    Minkowski Addition is performed by adding each point in a polygon 'pattern' to the set of points in an open or closed path. The resulting polygon (or polygons) defines the region that the 'pattern' would pass over in moving from the beginning to the end of the 'path'.

    ![image](https://user-images.githubusercontent.com/6306796/28290405-9636f11a-6b46-11e7-95e6-2e5cddb20789.png)

* **openPathsFromPolyTree(polyTree: [PolyTree](../shared/PolyTree.md)): [Paths](../shared/Paths.md)**

    This function filters out closed paths from the PolyTree structure and returns only open paths in a Paths structure.

* **orientation(path: [Path](../shared/Path.md)): boolean**
    Orientation is only important to closed paths. Given that vertices are declared in a specific order, orientation refers to the direction (clockwise or counter-clockwise) that these vertices progress around a closed path.

    Orientation is also dependent on axis direction:
    * On Y-axis positive upward displays, orientation will return true if the polygon's orientation is counter-clockwise.
    * On Y-axis positive downward displays, orientation will return true if the polygon's orientation is clockwise.

    ![image](https://user-images.githubusercontent.com/6306796/28290420-a1877378-6b46-11e7-9d29-37f6eebd7755.png)

    Notes:

    * Self-intersecting polygons have indeterminate orientations in which case this function won't return a meaningful value.
    * The majority of 2D graphic display libraries (eg GDI, GDI+, XLib, Cairo, AGG, Graphics32) and even the SVG file format have their coordinate origins at the top-left corner of their respective viewports with their Y axes increasing downward. However, some display libraries (eg Quartz, OpenGL) have their coordinate origins undefined or in the classic bottom-left position with their Y axes increasing upward.
    * For Non-Zero filled polygons, the orientation of holes must be opposite that of outer polygons.
    * For closed paths (polygons) in the solution returned by the clip method, their orientations will always be true for outer polygons and false for hole polygons (unless the reverseSolution property has been enabled).

* **pointInPolygon(point: [IntPoint](../shared/IntPoint.md), path: [Path](../shared/Path.md)): [PointInPolygonResult](../shared/PointInPolygonResult.md)**

    Returns *PointInPolygonResult.Outside* when false, *PointInPolygonResult.OnBoundary* when point is on poly and *PointInPolygonResult.Inside* when point is in poly.

    It's assumed that 'poly' is closed and does not self-intersect.

* **polyTreeToPaths(polyTree: [PolyTree](../shared/PolyTree.md)): [Paths](../shared/Paths.md)**

    This function converts a PolyTree structure into a Paths structure.

* **reversePath(path: [Path](../shared/Path.md)): void**

    Reverses the vertex order (and hence orientation) in the specified path.

* **reversePaths(paths: [Paths](../shared/Paths.md)): void**

    Reverses the vertex order (and hence orientation) in each contained path.

* **simplifyPolygon(path: [Path](../shared/Path.md), fillType: [PolyFillType](../shared/PolyFillType.md) = PolyFillType.EvenOdd): [Paths](../shared/Paths.md)**
* **simplifyPolygons(paths: [Paths](../shared/Paths.md), fillType: [PolyFillType](../shared/PolyFillType.md) = PolyFillType.EvenOdd): [Paths](../shared/Paths.md)**

    Removes self-intersections from the supplied polygon (by performing a boolean union operation using the nominated PolyFillType).
    Polygons with non-contiguous duplicate vertices (ie 'touching') will be split into two polygons.

    Note: There's currently no guarantee that polygons will be strictly simple since 'simplifying' is still a work in progress.

    ![image](https://user-images.githubusercontent.com/6306796/28290432-b2402dfe-6b46-11e7-8d1f-d9e7ad7c1770.png)

    ![image](https://user-images.githubusercontent.com/6306796/28290441-c55f97b2-6b46-11e7-8c14-ab667fb4003f.png)
    ![image](https://user-images.githubusercontent.com/6306796/28290451-cca90fee-6b46-11e7-90e8-a7a0b98e7ae5.png)

* **scalePath(path: [Path](../shared/Path.md), scale: number): [Path](../shared/Path.md)**

    Scales a path by multiplying all its points by a number and then rounding them.

* **scalePaths(paths: [Paths](../shared/Paths.md), scale: number): [Paths](../shared/Paths.md)**

    Scales all inner paths by multiplying all its points by a number and then rounding them.

repository: xaviergonz/js-angusj-clipper

repo_name: xaviergonz/js-angusj-clipper


text:
# wasm-pack-npm

[![NPM](https://nodei.co/npm/wasm-pack-npm.png)](https://nodei.co/npm/wasm-pack-npm/)

[![Build Status](https://travis-ci.org/robertohuertasm/wasm-pack-npm.svg?branch=master)](https://travis-ci.org/robertohuertasm/wasm-pack-npm)

Installs `wasm-pack` and all the needed dependencies so you can build `wasm` npm packages.

Check out the [wasm-pack documentation](https://rustwasm.github.io/wasm-pack/book/) if you want to know more.

## How to use it

Executing `npm i -g wasm-pack-npm` will automatically install `wasm-pack` and all the dependencies in your machine.

In case something goes wrong, you will be able to retry the installation by executing `wasm-pack-npm` in your terminal.

## Docker

If you plan to use it in `Docker` you'll have to set this in the `PATH`:

`export PATH=$HOME/.cargo/bin`

This is very important. If you don't use properly set the path the installation will fail.

In addition, `npm i -g wasm-pack-npm` seems to ignore the `PATH` setting, but it works if `wasm-pack-npm` is set as one of the `devDependencies` of your npm package.

## Development

While developing it is quite useful to use `npm start`. This will keep `tsc` compilling while you change the files.

## Tests

In order to execute the tests just run: `npm test`.

If you want to debug the tests and you're using `visual studio code` you'll find some `launch` settings that will help you with that:

- jest all: debugs all tests.
- jest current: only debugs the current selected test.

repository: robertohuertasm/wasm-pack-npm

gha_language: TypeScript

repo_name: robertohuertasm/wasm-pack-npm


text:
---
title: Dispatcher understanding caching
description: Understand how the Dispatcher module operates it's cache.
topic: Administration, Performance
version: 6.5
role: Admin
level: Beginner
thumbnail: xx.jpg
exl-id: 66ce0977-1b0d-4a63-a738-8a2021cf0bd5
---
# Understanding caching

[Table of Contents](./overview.md)

[<- Previous: Explanation of Configuration Files](./explanation-config-files.md)

This document will explain how Dispatcher caching happens and how it can be configured

## Caching Directories

We use the following default cache directories in our baseline installations

- Author
   - `/mnt/var/www/author`
- Publisher
   - `/mnt/var/www/html`

When each request traverses the Dispatcher the requests follow the configured rules to keep a locally cached version to response of eligible items

Note:

We intentionally keep published workload separate from the author workload because when Apache looks for a file in the DocumentRoot it doesn't know which AEM instance it came from. So even if you have cache disabled in the author farm, if the author's DocumentRoot is the same as publisher it will serve files from the cache when present. Meaning you'll serve author files for from published cache and make for a really awful mix match experience for your visitors.

Keeping separate DocumentRoot directories for different published content is also a very bad idea. You'll have to create multiple re-cached items that don't differ between sites like clientlibs as well as having to setup a replication flush agent for each DocumentRoot you setup. Increasing the amount of flush over head with each page activation. Rely on namespace of files and their full cached paths and avoid mutliple DocumentRoot's for published sites.

## Configuration Files

Dispatcher controls what qualifies as cacheable in the `/cache {` section of any farm file.
In the AMS baseline configuration farms, you'll find our includes like shown below:

```
/cache {
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }
```

When creating the rules for what to cache or not, please refer to the documentation [here](https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html?lang=en#configuring-the-dispatcher-cache-cache)

## Caching author

There are a lot of implementations we've seen where people don't cache author content.
They are missing out a huge upgrade in performance and responsiveness to their authors.

Let's talk about the strategy taken in configuring our author farm to cache properly.

Here is a base author `/cache {` section of our author farm file:

```
/cache {
    /docroot "/mnt/var/www/author"
    /statfileslevel "2"
    /allowAuthorized "1"
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }
    /invalidate {
        /0000 {
            /glob "*"
            /type "allow"
        }
    }
    /allowedClients {
        /0000 {
            /glob "*.*.*.*"
            /type "deny"
        }
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_invalidate_allowed.any"
    }
}
```

The important things to note here are that the `/docroot` is set to the cache directory for author.

Note:

Make sure your `DocumentRoot` in the author's `.vhost` file matches the farms `/docroot` parameter

The cache rules include statement includes the file `/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any` which contains these rules:

```
/0000 {
 /glob "*"
 /type "deny"
}
/0001 {
 /glob "/libs/*"
 /type "allow"
}
/0002 {
 /glob "/libs/*.html"
 /type "deny"
}
/0003 {
 /glob "/libs/granite/csrf/token.json"
 /type "deny"
}
/0004 {
 /glob "/apps/*"
 /type "allow"
}
/0005 {
 /glob "/apps/*.html"
 /type "deny"
}
/0006 {
 /glob "/libs/cq/core/content/welcome.*"
 /type "deny"
}
```

In an author scenario, content is changing all the time and on purpose. You only want to cache items that are not going to change frequently.
We have rules to cache `/libs` because they are part of the baseline AEM install and would change until you have installed a Service Pack, Cumulative Fix Pack, Upgrade, or Hotfix. So caching these elements make a ton of sense and really have huge benefits of the author experience of end users who use the site.

Note:

Keep in mind that these rules also cache `/apps` this is where custom application code lives. If you're developing your code on this instance then it will prove to be very confusing when you save your file and don't see if reflect in the UI due to it serving up a cached copy. The intention here is that if you do a deployment of your code into AEM it too would be infrequent and part of your deployment steps should be to clear the author cache. Again the benefit is huge making your cacheable code run faster for the end users.

## ServeOnStale (AKA Serve on Stale / SOS)

This is one of those gems of a feature of the Dispatcher. If the publisher is under load or has become unresponsive it will typically throw a 502 or 503 http response code. If that happens and this feature is enabled the Dispatcher will be instructed to still serve what ever content is still in the cache as a best effort even if it's not a fresh copy. It's better to serve something if you've got it rather than just showing an error message that offers no functionality.

Note:

Keep in mind that if the publisher renderer is having a socket timeout or 500 error message this feature will not trigger. If AEM is just unreachable this feature does nothing

This setting can be set in any farm but only makes sense to apply it on the publish farm files. Here is a syntax example of the feature enabled in a farm file:

```
/cache {
    /serveStaleOnError "1"
```

## Caching pages with Query params / Arguments

Note:

One of the normal behaviors of the Dispatcher module is that if a request has a query parameter in the URI (typically shown like `/content/page.html?myquery=value`) it will skip caching the file and go directly to the AEM instance. It's considering this request a dynamic page and shouldn't be cached. This can cause ill effects on cache efficiency.

See this [article](https://github.com/adobe/aem-dispatcher-optimizer-tool/blob/main/docs/Rules.md#dot---the-dispatcher-publish-farm-cache-should-have-its-ignoreurlparams-rules-configured-in-an-allow-list-manner) showing how important query parameters can affect your site performance.

By default you want to set the `ignoreUrlParams` rules to allow `*`.  Meaning that all query parameters are ignored and allow all pages to be cached regardless of the parameters used.

Here is an example where someone has built a social media deep link reference mechanism that uses the argument reference in the URI to know where the person came from.

Ignorable Example:

- https://www.we-retail.com/home.html?reference=android
- https://www.we-retail.com/home.html?reference=facebook

The page is 100% cacheable but doesn't cache because the arguments are present.
Configuring your `ignoreUrlParams` as a allow list will help fix this issue:

```
/cache {
    /ignoreUrlParams {
        /0001 { /glob "*" /type "allow" }
    }
```

Now when the Dispatcher sees the request it will ignore the fact that the request has the `query` parameter of `?` reference and still cache the page

Dynamic Example:

- https://www.we-retail.com/search.html?q=fruit
- https://www.we-retail.com/search.html?q=vegetables

Keep in mind that if you do have query parameters that make a page change it's rendered output then you'll need to excempt them from your ignored list and make the page un-cacheable again.  For example a search page that uses a query parameter changes the raw html rendered.

So here is the html source of each search:

`/search.html?q=fruit`:

```
<html>
...SNIP...
    <div id='results'>
        <div class='result'>
            Orange
        </div>
        <div class='result'>
            Apple
        </div>
        <div class='result'>
            Strawberry
        </div>
    </div>
</html>
```

`/search.html?q=vegetables`:

```
<html>
...SNIP...
    <div id='results'>
        <div class='result'>
            Carrot
        </div>
        <div class='result'>
            Cucumber
        </div>
        <div class='result'>
            Celery
        </div>
    </div>
</html>
```

If you visited `/search.html?q=fruit` first then it would cache the html with results showing fruit.

Then you visit `/search.html?q=vegetables` second but it would show results of fruit.
This is because the query parameter of `q` is being ignored in regards to caching.  To avoid this issue you'll need to take note of pages that render different HTML based on query parameters and deny caching for those.

Example:

```
/cache {
    /ignoreUrlParams {
        /0001 { /glob "*" /type "allow" }
        /0002 { /glob "q" /type "deny"  }
    }
```

Pages that use query parameters via Javascript will still fully function ignoring the paramters in this setting.  Because they don't change the html file at rest.  They use javascript to update the browsers dom realtime on the local browser.  Meaning that if you consume the query parameters with javascript it's highly likely you can ignore this parameter for page caching.  Allow that page to cache and enjoy the performance gain!

Note:

Keeping track of these pages does require some upkeep but is well worth the performance gains.  You can ask your CSE to run a report on your websites traffic to give you a list of all pages using query parameters over the last 90 days for you to analyze and make sure you know which pages to look at and which query paramters to not ignore

## Caching response headers

It's pretty obvious that the Dispatcher caches `.html` pages and clientlibs (i.e. `.js`, `.css`), but did you know it can also cache particular response headers along side the content in a file with the same name but a `.h` file extension. This allows the next response to not only the content but the response headers that should go with it from cache.

AEM can handle more than just UTF-8 encoding

Sometimes items have special headers that help control cache TTL's encoding details, and last modified timestamps.

These values when cached are stripped by default and the Apache httpd webserver will do it's own job of processing the asset with it's normal file handling methods, which normally is limited to mime type guessing based on file extensions.

If you have the Dispatcher cache the asset and the desired headers you can expose the proper experience and assure the all the details make it to the clients browser.

Here is an example of a farm with the headers to cache specified:

```
/cache {
 /headers {
  "Cache-Control"
  "Content-Disposition"
  "Content-Type"
  "Expires"
  "Last-Modified"
  "X-Content-Type-Options"
 }
}
```

In the example they have configured AEM to serve up headers the CDN looks for to know when to invalidate it's cache. Meaning now AEM can properly dictate which files get invalidated based on headers.

Note:

Keep in mind you cannot use regular expressions or glob matching. It's a literal list of the headers to cache. Only put in a list of the literal headers you want it to cache.

## Auto-Invalidate Grace Period

On AEM systems that have a lot of activity from authors that do alot of page activations you can have a race condition where repeat invalidations occur. Heavily repeated flush requests are un-necessary and you can build in some tolerance to not repeat a flush until the grace period has cleared.

### Example of how this works:

If you have 5 request to invalidate `/content/exampleco/en/` all happen within a 3 second period.

With this feature off you'd invalidate the cache directory `/content/exampleco/en/` 5 times

With this feature on and set to 5 seconds it would invalidate the cache directory `/content/exampleco/en/` once

Here is an example syntax of this feature being configured for 5 second grace period:

```
/cache {
    /gracePeriod "5"
```

## TTL Based Invalidation

A newer feature of the Dispatcher module was `Time To Live (TTL)` based invalidation options for cached items. When an item gets cached it looks for the presence of cache control headers and generates a file in the cache directory with the same name and a `.ttl` extension.

Here is an example of the feature being configured in the farm configuration file:

```
/cache {
    /enableTTL "1"
```

Note:
Keep in mind that AEM still needs to be configured to send TTL headers for Dispatcher to honor them. Toggling this feature only enables the Dispatcher to know when to remove the files that AEM has send cache control headers for. If AEM doesn't start sending TTL headers then Dispatcher won't do anything special here.

## Cache Filter Rules

Here is an example of a baseline configuration for which elements to cache on a publisher:

```
/cache{
    /0000 {
        /glob "*"
        /type "allow"
    }
    /0001 {
        /glob "/libs/granite/csrf/token.json"
        /type "deny"
    }
```

We want to make our published site greedy as possible and cache everything.

If there is elements that break the experience when cached you can add rules to remove the option to cache that item. As you see in the example above the csrf tokens shouldn't ever be cached and have been excluded. Further details on writing these rules can be found [here](https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html?lang=en#configuring-the-dispatcher-cache-cache)

[Next -> Using and Understanding Variables](./variables.md)

gha_language: SCSS


text:
# txp4
Trackmania Experience v4

## Preparation

* Install [Node.js](https://nodejs.org).
* Install [yarn](https://yarnpkg.com).

## Development

Run in separate terminals:

* rebuild application on change:
```
yarn build:watch
```

* restart application on change:
```
yarn start:watch
```

* lint your code:
```
yarn lint:watch
```

## Before first launch
Project requires working MongoDB database.
Open README_mongoDB.txt and follow the instructions.
Please also set up variable names:
ADMIN_AUTH_SECRET
SERVER_AUTH_SECRET
PORT

license: ISC