text:
---
layout: post
title: Leetcode Problem 7 Summary
date: 2016-08-18
categories: blog
tags: [study]

---

# 题目

Reverse digits of an integer.

Example1: x = 123, return 321
Example2: x = -123, return -321

click to show spoilers.

Have you thought about this?
Here are some good questions to ask before coding. Bonus points for you if you have already thought through this!

If the integer's last digit is 0, what should the output be? ie, cases such as 10, 100.

Did you notice that the reversed integer might overflow? Assume the input is a 32-bit integer, then the reverse of<PHONE_NUMBER> overflows. How should you handle such cases?

For the purpose of this problem, assume that your function returns 0 when the reversed integer overflows.

Update (2014-11-10):
Test cases had been added to test the overflow behavior.

# 我的算法

考察严谨性， reverse 后可能溢出？

# 代码

{% highlight java %}
public class Solution {
    public int reverse(int x) {
        long sum = 0;

        while (x != 0) {
            int digit = x % 10;
            sum = sum * 10 + (long)digit;
            x /= 10;
        }

        if (sum > Integer.MAX_VALUE || sum < Integer.MIN_VALUE) return 0;
        return (int)sum;
    }
}
{% endhighlight %}


text:
# Config File Challenge

## Task

- Read AppSettings or Connection Strings
- **BONUS** - Read All AppSettings or Connection Strings
- **BONUS** - Add New AppSetting or Connection String
- **BONUS** - Only Add if Settings doesn't exist yet.

## Output

AppSettings Demo
![output1](./output1.gif)

Connection Demo
![output1](./output2.gif)

## Notes

- Clearly, I went **OVERBOARD** but I'm proud of what I did 😂
- I found out that EF caches connection string, so there isn't no method to force a refresh. (For Now)

## Sources

- [Challenge Video](https://www.youtube.com/watch?v=8BFIT29asSY&list=PLLWMQd6PeGY1VcJGocm1wwtFCZUrh2sc9&index=5)

license: MIT

path: /tc_weekly_challenges/5 - Config File/README.md

branch_name: refs/heads/main

extension: md

gha_language: C#

license_type: permissive


text:
# Fabric API development guidelines

This document describes the development guidelines for Fabric API. It may be amended at any time. Therefore you should refer to the development guidelines when working on any contributions.

Following these guidelines should ensure your contributions to Fabric API are quick to review, consistent with other code in Fabric API and well thought out. This document should not be seen completely as a strict ruleset but instead the thought process that a Fabric team member would consider during the design, implementation and review of contributions to Fabric API.

Old code or parts thereof might not yet be up to the standards defined by these guidelines. When working with old code, try to adhere to these guidelines, but don't bulk update legacy code to match them. The team will handle updating older code to match the newer standards when appropriate.

## Scope

In order to retain maintainability, portability and discoverability, Fabric API only targets features that are important to a broader set of mods. Whether an addition is desirable is a balance between its
- usefulness,
- complexity,
- inherent necessity for compatibility,
- performance impact,
- continued support by the authors or other interested parties.

Fabric API generally is not meant for bugfixes, performance improvements or gameplay changes, and exceptions need careful evaluation.

It is highly recommended that an issue be opened or a message be posted in the official Discord server, to discuss whether a feature is in scope, before it is designed or implemented. Design choices may also warrant prior discussion to avoid wasting time.

## Structure of the guidelines

The rest of this document is split in the following categories:

- [**General design considerations**](#general-design-considerations): Broad guidelines to keep in mind when writing APIs for Fabric.
- [**API conventions**](#api-conventions): Guidelines for common API patterns.
- [**Implementation guidelines**](#implementation-guidelines): Guidelines to keep in mind when writing implementation code.
- [**Documentation**](#documentation): Guidelines for writing documentation. Extensive documentation of the offered features is essential for usability.
- [**Structure of Fabric API**](#structure-of-fabric-api): Organization of code within Fabric API.
- [**Code formatting**](#code-formatting): Specific Java code formatting standards.
- [**Testing**](#testing): Guidelines for writing testmod code. Tests showing that the submitted feature is working should be included in the PR.
- [**Pull Request checklist**](#checklist-before-submitting-a-pull-request): Smaller things to keep in mind when submitting a Pull Request.

## General design considerations

When designing an API addition, the following goals should be kept in mind:
- Simplicity: Additions should be
    - easy to use,
    - inherently hard to misuse or protected against misuse,
    - reasonably self contained,
    - sufficiently capable, yet not excessively loaded with niche features,
    - suitable for simple implementations,
    - not overly abstract.
- Familiarity: Additions should reuse or extend existing designs/patterns in other parts of Fabric API or vanilla.
- Extensibility: Additions should be open for future expansion without needing to deprecate anything.
- Portability: Additions should not be too closely coupled with specific vanilla code. They should
    - avoid exposure of unimportant aspects,
    - project into the future and consider potential future vanilla development,
    - avoid auxiliary libraries,
    - be portable for the sake of simplicity and extensibility.
- Performance: Additions should
    - be fast to initialize and execute,
    - have low or zero allocation rate,
    - have low resident memory use,
    - keep extreme uses in mind (nuke, bulk command execution, spamming etc).

One important consideration when designing an API is spending some time thinking about the API in isolation without any influence from underlying implementation and vanilla code. Considering the API as a single entity rather than a part of a larger implementation, akin a regular user of the API may help find missing coverage, bad return values or parts of the API that could be improved.

Additionally, any feature provided by Fabric API should be fully usable by mods without mixins or reflection. Helper methods may be used to bridge these gaps.

It can be assumed that nothing other than Fabric API itself accesses non-api packages directly, regardless of their visibility. Reflection doesn't have to be accounted for anywhere.

## API conventions
This section covers Fabric API guidelines for common patterns.

### Backwards compatibility
Fabric API makes strong backwards compatibility guarantees, by which contributors must abide. **Modders should not need to update their source code when they update Fabric API**, with the following exceptions:

- APIs might be broken due to **related** changes in Minecraft updates.
    - Preserving backwards compatibility in these cases will be considered if possible.
        - Deprecated code will usually be removed if it requires non-trivial updates.
    - This is limited to code directly affected by the Minecraft version update. Minecraft making breaking changes in some areas of its API is not a reason to break unrelated parts of Fabric API.
- Experimental modules might be broken if necessary.
    - Changes that affect compilation but not the resulting bytecode are allowed in experimental modules, for example some generic changes.
    - Even if an API is marked as experimental, avoid breaking the ecosystem of mods using it.
        - Changes that will cause hard crashes in many mods when they are released should be delayed until the next majorly breaking Minecraft version update.
- There might not be a way around a breaking change.
    - If a major oversight is noticed in an API, it might be broken to address the oversight. Such cases require careful consideration, and should always be discussed with the team beforehand.
    - Remember that deprecating code is always an option.

### Targeted Minecraft versions
- Fabric API does not have strict Minecraft version support policies, but rather supports what is feasible and what the community is interested in.
    - In particular, the latest stable Minecraft version and the latest subsequent snapshot or pre-release version are always supported.
    - Which features go in older stable versions is a tradeoff between how easy it is, how many mods are still using that version, and what the community is willing to contribute.
- New features can be targeted at any supported version.
    - Maintainers will take care of cherry-picking the feature to the other branches when applicable.
    - In doubt, prefer PR'ing to newer stable versions.
- Backporting PRs for older versions will generally be accepted, depending on how many changes were required.

### Discouraged API design patterns

- Avoid the old `Api.INSTANCE` pattern in favor of static methods.
    - This pattern may be used if the backing implementation may be changed by another mod (such as the renderer api). Even then there should be static methods to access the standard api facilities.
- Avoid unnecessary use of generics.
    - Unless Vanilla Minecraft mandates the use of generics, or a good reason exists to use generics.
- Avoid optionals in return values, fields and parameters.
    - Where possible, you should prefer a `@Nullable T`.
    - If vanilla exposes optionals in return types, then returning an optional is fine.
- Avoid requiring the user to cast to a subtype if possible.
    - Adding methods to vanilla types can be done via interface injection.

### API design patterns to consider

- Transitive Access Wideners (TAWs) should be used to expose access to private or protected members in vanilla classes.
    - Most TAWs should go in the dedicated `fabric-transitive-access-wideners-v1` module.
        - Remember to add the `transitive-` prefix, otherwise dependent mods will not see the access modifications.
        - Some TAWs such as Block subclass constructors are automatically generated. Make sure that you don't edit the `.accesswidener` file in `src` directly. Rather edit the template file (`template.accesswidener`) and run the `gradlew generateAccessWidener` task to update the generated file.
        - Large amounts of TAWs for a specific purpose can be included in another module, as is the case for the data generation API, for example.
    - Do **not** expose TAWs for functions that take a `String` identifier.
        - This makes it too easy to forget the mod ID namespace, so the identifier would often end up in the vanilla `minecraft` namespace.
    - In general, keep the API guidelines in mind when deciding whether something should be a TAW.
- Interface injection (i.e. making a minecraft class or interface extend a Fabric interface) should be considered over separate static helpers.
    - Interface injection requires both a `fabric.mod.json` custom value to make it visible in Minecraft source code, and a mixin to actually implement the interface at runtime.
    - Injected interfaces should have **no abstract methods**.
        - Methods that are guaranteed to be implemented via a mixin to a vanilla class should contain a default body that throws an error.
          Otherwise, the compiler will complain when it can't find the implementation of an interface method on a class.
          For example:
        ```java
        default void injectedMethod() {
            throw new UnsupportedOperationException("Implemented via mixin");
        }
        ```
        - Never use interface injection to add methods that modders must implement. Rather define a subclass or subinterface in Fabric API.
- Builders can be used instead of constructors or factory methods with large amounts of parameters.

### API class modifiers and member visibility

- Classes in Fabric API should be `final` classes unless the class exposed in the API is explicitly meant for extension.
- `private` constructors should be used in API classes unless the class is explicitly meant to be instantiated.
    - This only applies to modder-facing classes, i.e. classes in the `net.fabricmc.fabric.api` subpackage. See below for package structure.
    - They should be placed at the very bottom or top of the class to not hurt readability.
- Access modifiers for fields and methods should be as strict as possible.
    - If a method is intended to only be for use by mods implementing an api, a `protected` method should suffice.

### Annotations
- Nullable members, parameters or return values must be annotated with the `@Nullable` annotation.
    - Any member, parameter or return value that is not marked as nullable can be assumed to be nonnull. The `@NotNull` annotation should never be used, it is implicit.
    - Introducing custom types might be appropriate (no need to specify `List<@Nullable String>` everywhere).
- Deprecated API members should have the `@Deprecated` annotation.
    - Avoid specifying `forRemoval = true`, the functionality will be supported as long as possible.
        - Exceptions are made for experimental APIs, where deprecated for removal functionality might be removed after sufficient time has passed.
    - A javadoc `@deprecated` comment should be added to deprecated members with migration instructions.
- Experimental API classes should all have the<EMAIL_ADDRESS>annotation.
    - The annotation is not required on individual members, unless the class itself is not experimental.
-<EMAIL_ADDRESS>should be used for API interfaces or classes that modders must not implement or override, but can't be `final` for some reason.
    - Adding methods to such interfaces or classes is not a breaking change.
-<EMAIL_ADDRESS>is automatically applied to all implementation packages to avoid IDE autocompletion suggesting them. There should be no need for internal methods or classes in the public API package.

### Naming
- All names should follow the [Yarn naming standards](https://github.com/FabricMC/yarn/blob/HEAD/CONVENTIONS.md).
- If a class only contains getter methods, the `get` prefix may be omitted for methods. The `get` prefix may also be omitted where it is not appropriate.
- Accessor mixins should be named **Target**Accessor, other mixins should be named **Target**Mixin, where `Target` is the target class name. More details in the mixin section below.

### Events

- Events should not be used if there is only one subscriber, like a handler in a registered unique namespace.
- Events should be produced and fully usable with minimal object allocation.
  - In particular, avoid data holder objects for inputs, but rather pass them as separate parameters.
- Events should use dedicated callback interfaces.
    - Callback interfaces should be `@FunctionalInterface`s.
    - Callback methods should be uniquely named such that a handler can implement multiple at once.
        - Avoid words that are already clear from the parameters. For example, prefer `onStartTick(MinecraftServer)` over `onStartServerTick(MinecraftServer)`. The interface should still be named `StartServerTick` if "server" is not already implied by the containing class.
    - Callback signatures should use the most specific type, if appropriate. E.g. `WorldChunk` over `Chunk`.
    - Callback signatures should pass context that the listener might be expected to use, without excess. For example:
        - Events involving a `MinecraftServer` directly should consider passing a `MinecraftServer` parameter.
            - If the server is easily available via the other context parameters (for example a `ServerWorld`), passing it explicitly is unnecessary.
        - Consider passing the `MinecraftClient` instance as a parameter if it makes sense.
- `Event<>` objects should be in the class declaring the event field or getter.
    - Usually, an event will be a stored in a `public static final` field.
    - Sometimes an event might be specific to a class instance. In that case, there should be static methods that return event instances. One example of this is an event specific to a registry.
    - Related callbacks and events should be grouped in classes.

Example:
```java
public final class FooEvents {
    public static final Event<Allow> ALLOW = ...;
    public static final Event<Before> BEFORE = ...;
    public static final Event<After> AFTER = ...;

    @FunctionalInterface
    public interface Allow {
        boolean allowFoo(/* relevant parameters */);
    }

    @FunctionalInterface
    public interface Before {
        void beforeFoo(/* relevant parameters */);
    }

    @FunctionalInterface
    public interface Two {
        void afterFoo(/* relevant parameters */);
    }

    // Holder class is not meant for instantiation.
    private ExampleEvents() {
    }
}
```

#### Event naming

- Callback interfaces:
    - Callback interfaces should be named using present tense. For example, `ChunkUnload` and not `ChunkUnloaded`.
    - The methods should be named in line with the action of the event, such as `entryAdded(...)`.
    - Method names for notification events should be prefixed with `on`.
      For example, a `DataLoad` event would have an `onDataLoad` method.
    - Events that may allow or block some action should start with `Allow`. For example, an event to cancel player death might be called `AllowPlayerDeath`, with method name `allowDeath`.
- `Event<>` fields and methods:
    - The field or method exposing the `Event<>` object should be named similarly to the callback interface.
- The `fabric-lifecycle-events-v1` module is a good example of event naming standards.

#### Event ordering

- Processes happening in multiple steps should use multiple events.
    - While Fabric provides an event phase system, purpose-driven events should always be preferred.
    - For example, an event that both cancels and notifies of an action will produce false notifications (notified but later canceled). It would be preferable to have an `AllowXxx` event for cancellation, and then a `BeforeXxx` event for notification.

## Implementation guidelines

### Simplicity

- Simple code that is easy to debug and reason about is generally preferable to the shortest possible implementation.
- Limited duplication can be better than indirection, unless the code is complex or used several times.
- Indirections might make the code harder to read, and should be weighed against their benefits. Examples include:
    - Lambda methods (`forEach`, streams).
    - Method splitting.
    - Recursion.
    - Complex class hierarchies.
- Functional operators (i.e. interfaces) should be designed for maximal readability, and only used when necessary.
    - Ask for concrete objects if applicable.
    - Don't include superfluous methods. For example, replace `shouldApply`+`apply` with a single `apply` that returns success.
    - Consider having the user implement a larger interface as a class.
    - Consider using a custom interface if it is beneficial for comprehension or documentation.
- The overall complexity of a module shouldn't be ignored in favor of the simplicity of each individual piece. Similarly, the overall complexity of one small piece shouldn't be ignored in favor of the simplicity of the module as a whole.

### Code quality
- Strongly validate inputs to detect misuse.
    - Exceptions should be thrown in the first method that can reasonably detect misuse.
    - Precondition assertions such as `Objects.requireNonNull` for non-null parameters are strongly encouraged.
    - This might apply to other cases, such as strong JSON validation.
- Use the weakest suitable interface or class when exposing anything without harming expected uses.
    - However, prefer `Collection` over `Iterable`.
- Non-trivial reused (directly or derived) inline constants should be moved to static final fields.
- Javac shouldn't produce any warnings in its default configuration.

### Thread safety

Since Minecraft has two primary threads, the render and server threads, APIs dealing with shared state need to consider thread safety. This will usually require consideration on a case-by-case basis.

- A registry shared between the render and the server threads may for example wish to use locking for infrequent accesses, or otherwise a copy-on-write strategy to ensure lock-free reads and thread-safe writes.
- Lazily initialized caches accessed from multiple threads require `volatile`. Use an intermediate variable to only have one volatile read:
```java
private volatile Stuff cachedStuff = null;

private Stuff stuff() {
    Stuff stuff = this.cachedStuff;

    if (stuff == null) {
        this.cachedStuff = stuff = compute();
    }

    return stuff;
}
```
- Read-only access from multiple threads does not need synchronization.

## Documentation

- Every API class should carry a Javadoc comment explaining its purpose and reference related classes. Example code in the primary class of any major feature should outline the use, including related vanilla invocations/registrations/etc as applicable to provide an idea of how to start.
    - Parameters, implementation bodies, etc... may be omitted as appropriate, since the examples are not meant as to be fully working implementations.
    - The examples should be more akin to pseudocode with a checklist for the process and pointers to everything needed.
    - These examples should be written for developers that have a knowledge of Java and basic knowledge of the Minecraft codebase.
- A brief description belongs in the 1st paragraph, with further paragraphs separated by blank lines and starting with `<p>`. Javadoc for methods may follow with another blank line before describing parameters, return values and exceptions with the appropriate tags. All accessible members should be described appropriately.
- Good documentation doesn't only explain what something is, but (as appropriate) why it exists, what are the intended use cases, what use cases something is not suitable for and any semantics that need to be kept in mind.
    - In particular, tricky implementation details should be explained by a few comments when appropriate.
- Direct references to classes or members should use the `@link` and `@linkplain` tags, unspecific further reading elsewhere may use `@see`.
- Deprecated elements should describe and reference the replacement or alternative in Javadoc `@deprecated`. The `@deprecated` tag has to be last, everything else may be removed while adding it.
- The Fabric Wiki is the proper place for additional in-depth documentation and how-tos. Examples are not necessary for simple events.

## Structure of Fabric API
Fabric API is organized in different modules. Each module is located in a specific folder matching the module id. For example under `fabric-item-api-v1/` for the Item API (v1).

### Module naming conventions
- Module names should be named after the exposed functionality.
    - Consider future developments when naming a module: they might later be expanded.
- Module names should usually be suffixed by `-api`.
    - Modules whose primary purpose is not interaction with their API do not need this suffix. For example, `fabric-transitive-access-wideners-v1` or `fabric-convention-tags-v1`.
    - Event modules should have the `-events` suffix instead.
- Module names should always be suffixed by a major version (`-v1`, `-v2`, etc).
    - The major version starts at `v1` for new functionality, unless they replace a module with equivalent functionality, in which case the version is incremented.
    - `vn` and `vn+1` module names need not match exactly. For example, `fabric-loot-tables-v1` was replaced by `fabric-loot-api-v2`.

### Deprecated modules
Modules that are entirely deprecated are in the `deprecated/` folder. All of their API classes should be deprecated, and their `fabric.mod.json` should have the deprecated lifecycle marker. (See PR checklist below).

A module may only be deprecated if all of its functionality is also provided by a non-deprecated module or vanilla Minecraft itself.

### Experimental modules
Modules whose design is hard to evaluate might go through an experimental phase, allowing for relaxed backwards compatibility requirements, as described in the Backwards compatibility section.

Writers of experimental modules need to consider the following additional requirements:
- All API classes should be marked as<EMAIL_ADDRESS>Do not use `@Deprecated` to generate compiler and IDE warnings for experimental modules.
- All API classes should carry a javadoc comment, worded similarly to the following example:
  ```java
  /**
   * (normal javadoc here)
   *
   * <p><b>Experimental feature</b>, may be removed or changed without further notice.
   */
  ```
- The module's `fabric.mod.json` should have the experimental lifecycle marker. (See PR checklist below).
- Note that experimental modules should be in the root folder of the Fabric API repository, as they are expected to be stabilized eventually.

### Versioning, dependencies

The initial version of a module should **always** be `1.0.0`, never 0.x for non-legacy modules.
Do not increment versions when writing a pull request. Version increments will be applied by maintainers after the pull request is merged.

Every module should in its `fabric.mod.json` declare dependencies for:
- `"fabricloader": ">=x.y.z"`, where `x.y.z` is the version used at the time the module is added.
- Other used modules, for example `"fabric-api-base": "*"` if events are used. No explicit version needs to be specified.
- Minecraft and Java version dependencies do not need to be specified.
- In general, version ranges in module dependencies should be optimistic, omitting an upper bound until it is known.

### Packages

Each module contains various sourcesets in the `src` folder:
- `src/client`: Code for client-only additions such as rendering hooks.
- `src/main`: Code for additions that are available on both the client and the server.
- `src/testmod`: Testing code.

Inside the relevant sourceset, all Fabric API code should be in a subpackage of `net.fabricmc.fabric`.
- Add `.api`, `.impl` and `.mixin` for public-facing API, implementation details, and mixins respectively.
- Add `.client` or `.server` for client-only or dedicated server-only code respectively. Common code requires no additional folder.
- Add module name subpackage. It might contain multiple parts separated by `.`.
- For API only: add the module major version with a v prefix, for example `.v1`
- Further subpackages can be added as needed, all singular.

A good example is the Lifecycle Events (v1) module.

### Mixins

These guidelines should be followed with regards to a mixin's visibility and naming:

|            | Accessors          | Mixin                                                                      |
|------------|--------------------|----------------------------------------------------------------------------|
| Naming     | **Target**Accessor | **Target**Mixin (May include `Client/Server` or `Legacy` prefix if needed) |
| Visibility | public             | package-private*                                                           |

\* A mixin may be public if a subclass extends a super mixin in a different package. Example: `abstract class ServerWorldMixin extends WorldMixin`

The organization of mixins with a package is dependent on the type of module.
- Generally if there are a small amount of mixins, then having all mixins in the same package is fine.
- Client only and dedicated server only mixins should be moved into `client/server` subpackages.
- If a module is generally complex or has multiple distinct parts, multiple mixins for each class target may exist assuming said mixins are separated into subpackages by feature.

## Code formatting

Formatting should be consistent with the remainder of Fabric API.

The general code formatting is as follows:
- Single tabs per indentation level, 2 extra tabs for continued lines.
- Blank line between block statements within the same indentation level (unless adjacent to if, else, do etc).
- No blank lines at the start or end of a block, i.e. no blank line after `{` or before `}`.
- Blank line after input (parameter) validation, if present.
- New line after `{` unless empty  (`{}` or `{ }`), never before.
- Line length usually below 120 columns, sometimes up to 160 if beneficial for readability.
- Single space after `if`, `for`, `do`, `break` unless followed by `;`.
- No space after `(` or before `)`.
- Statements should use the block form except for single-line if statements that use a short condition and nothing else.
- Ternary operator use only within a single line total.

Fabric API uses the Gradle checkstyle plugin. If you run `gradle check` any style errors will be logged in the output. The style errors can also be viewed in a generated webpage by the Gradle task.

### Style guidelines

These are less strict guidelines for the code style, but you should generally obey these:

- No redundant static access qualifiers.
  - For example if you call `ClassHere.staticThing()` inside of another method in `ClassHere`, you should avoid fully qualifying the static access to `staticThing()`.
- The use of the `this` qualifier is optional. You may need to use it in order to avoid shadowing variables but its general use elsewhere is fine.
  - Generally keep consistent with the current standard inside of the class you are editing.

## Testing
Including testing code when submitting new features is essential, both to demonstrate the feature, and to ensure that it works correctly.
Testing code should not be in the regular source sets, it belongs to so-called "test mods".

- Test mods are located in the `testmod` source set. Example: `fabric-lifecycle-events-v1/src/testmod/`
- Test mods should provide the necessary content to debug an issue with the api manually.
  - Test mods can also be helpful in order to illustrate how to use a module as a fallback for wiki pages that have yet to be written.
- If a test mod can be partially automated then it is encouraged to implement an automatically failing test if something goes wrong.
  - This allows issues with the implementation or porting issues to be detected immediately.
  - For example, if a test mod checks if commands are registered on the server and the commands are not on the `CommandDispatcher` then the test should fail.
  - Good places to run the automated checks include:
    - The mod initializer if applicable.
    - In a listener for `ServerLifecycleEvents.SERVER_STARTED` if a server instance is required.
    - A game test.
  - Test failures should always throw an `AssertionError` explaining what condition was not met during the test.

Fabric API pull requests should be tested in the dev environment and in production (on both a client and dedicated server).
The `gradlew build` command can be used to produce the Fabric API fatjar, located in `builds/libs/`.

#### Common mistakes
One highly likely cause of a production failure is the use of `remap=false` in a mixin. If `remap=false` is used, you need to verify the mixin works in dev and production. Most likely the mixin will not work in production.

## Checklist before submitting a pull request

### Apply license headers
There is a Gradle task that can automate this for you. Simply run `gradlew spotlessApply`.

### Run checks
- The `gradlew check` task runs all the style checks and game tests.
- Code style can be checked with the faster `gradlew checkstyleMain checkstyleTestmod`.

### Any new modules/newly deprecated modules need to specify the correct module lifecycle.
If you have created a new module you need to specify the module lifecycle. The `gradlew check` task will pick up any missing module lifecycles for you and tell you the subproject it is missing in. The module lifecycle is specified in the `fabric.mod.json`.

**Example:**

```json=
"custom": {
    "fabric-api:module-lifecycle": "<ModuleLifecycle>"
}
```

The supported values for the `ModuleLifecycle` are:
- `"stable"`
- `"experimental"`
- `"deprecated"`

### Testing
See the Testing section above. Make sure to describe in the pull request body how you tested your code, and include relevant test mod code with your pull request.

repository: FabricMC/fabric

gha_language: Java

repo_name: FabricMC/fabric


text:
# Cat Fanciers

_Angular Extended JS Independent Project for Epicodus, 08.25.2017_

By _Calla Rudolph_ [(e-mail me<EMAIL_ADDRESS>
This website has been deployed for easy viewing: https://cat-fanciers.firebaseapp.com

## Description

This Angular 2 app was created as a portal for members to belong to the Cat Fanciers group. The app keeps a directory of all members by utilizing Firebase.
  * Members are stored with their name, bio, number of cats owned, a picture, and location.
  * Each member's profile can be viewed through a dynamic route.
  * The admin section allows for new members to be entered, and each member can be individually edited or deleted, with changes saved directly to Firebase and immediately viewable on the page.
  * There is a Messages component for users to leave and delete messages.
  * A counter on the navbar displays the total number of members, messages, and cats that the members own. The footer displays the current day of the week.

_***Take a look at planning.md to see the foundation for this app!***_

_This project was generated with [Angular CLI](https://github.com/angular/angular-cli) version 1.0.0._

![Preview of Group Members](src/assets/img/screen.png)
_This image is a screenshot of the Group Members component_

## Prerequisites

You will need the following things properly installed on your computer:
* [Git](https://git-scm.com/)
* [Node.js](https://nodejs.org/) (with NPM)
* [Angular](https://cli.angular.io/) (in Terminal: $ npm install -g<EMAIL_ADDRESS>* [TypeScript](https://www.typescriptlang.org/) (from NPM in Terminal: $ npm install typescript -g)
* [Bower](https://bower.io/)
* You will need Firebase to clone this project. Make a free account at [Firebase](https://firebase.google.com/)
  * Once logged in to Firebase, select `Create a New Project` and give the project a name.
  * In the Overview section, select `Add Firebase to your web app`. Keep this modal handy for use in just a moment.

## Installation

* Open Github site in your browser: https://github.com/CallaRudolph/cat-fanciers
* Select green drop-down box to Clone or Download
* Open Terminal on your computer and follow these steps:
  * `$ cd desktop`
  * `$ git clone <paste repository-url>`
  * `$ cd cat-fanciers`
  * `$ npm install`
  * `$ bower install`
  * `$ ng build`
  * `$ touch src/app/api-keys.ts`
* In your text editor, go to the api-keys file you just made, and paste in this information:
  ````
  export var masterFirebaseConfig = {
    apiKey: "xxxx",
    authDomain: "xxxx.firebaseapp.com",
    databaseURL: "https://xxxx.firebaseio.com",
    storageBucket: "xxxx.appspot.com",
    messagingSenderId: "xxxx"
  };
  ````
* Return to the Firebase modal, copy your project information, and paste the corresponding info into the `xxxx` spaces in the api-keys file. Your file should have your specific Firebase credentials and other information here, instead of `xxxx`.

## Development server

Run `ng serve` for a dev server. Navigate to `http://localhost:4200/` in your browser. The app will automatically reload if you change any of the source files.

## Technologies Used

Angular 2 CLI, Firebase, TypeScript, Node.js, Bower, Bootstrap, CSS, HTML

## License

Copyright © 2017 Calla Rudolph

_Please email me at the above address with any comments or improvements you have found!_

This software is licensed under the MIT license.
______________________________________

## Code scaffolding

Run `ng generate component component-name` to generate a new component. You can also use `ng generate directive/pipe/service/class/module`.

## Build

Run `ng build` to build the project. The build artifacts will be stored in the `dist/` directory. Use the `-prod` flag for a production build.

## Running unit tests

Run `ng test` to execute the unit tests via [Karma](https://karma-runner.github.io).

## Running end-to-end tests

Run `ng e2e` to execute the end-to-end tests via [Protractor](http://www.protractortest.org/).
Before running the tests make sure you are serving the app via `ng serve`.

## Further help

To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI README](https://github.com/angular/angular-cli/blob/master/README.md).

repository: CallaRudolph/Cat-Fanciers

branch_name: refs/heads/master

repo_name: CallaRudolph/Cat-Fanciers


text:
## Enabling the study of Academic Performance through Machine Learning Techniques

Goal of this project is to create a functional website that can recommend technical courses to students based on multiple parameters using machine learning techniques.

The proposed system gets various inputs from the user which are used in a machine learning model. The machine learning models consists of a classification algorithm in which the best results for a certain input is mapped called training data. The output from the machine learning is accurate and based on the result the user is recommended a technical course that is best suited to them along with tips on how to pursue the course.

This project uses the Flask microframework to host the machine learning model on the web. Packages such as scikitlearn and pandas are used to create and manipulate the machine learning classifier.

The file "classifier.py" is used to create a machine learning classifier in the form of a pickle file named "NBClassifier.pkl".

The "NBClassifier.pkl" pickle file is then imported into the flask project to be used on the web. This is dont to ensure that the system doest take excess time to classify the data everytime a user wants a recommendation.

The data in the Final Dataset are the numerical iterpretation of the data that has been extracted from the " [Stackoverflow Developer Survey 2019](https://insights.stackoverflow.com/survey/2019) "

Requirements =>

Flask 1.0.2
Flask-Bootstrap <IP_ADDRESS>
Scikit-learn 0.19.1
Pandas 0.23.4


text:
# DFFML Operations for GitHub

![Tests](https://github.com/pdxjohnny/dffml-operations-github/workflows/Tests/badge.svg?branch=master&event=push)

## License

dffml-operations-github is distributed under the [MIT License](LICENSE).

repository: pdxjohnny/dffml-operations-github

repo_name: pdxjohnny/dffml-operations-github


text:
# ziplineaqm

## To install:

```shell
$ pip install git+https://github.com/magnumjoseph/ziplineaqm.git
```

**Note:** In order to use this library, you also need to download
the most updated version of ``lib/commonalgo``.

## To use:

```python
from zipline.finance import commission, slippage

context.set_commission(commission.PerTransaction())
context.set_slippage(slippage.AQMVolumeShareSlippage(price_impact=0, volume_limit=1))
```

Currently the ``PerTransaction`` model only handles ``commission_type=1, 2``;
for other cases, you need to overwrite the model accordingly (an example):

```python
class MyPerTransaction(commission.PerTransaction):
	def __init__(self):
		super(MyPerTransaction, self).__init__()

	def calculate(self, order, transaction):
		"""
        Specify my own commission model.
        """
		commission = transaction.commission
		commission_type = transaction.commission_type
		price = transaction.price
		amount = transaction.amount
		if commission_type == float(1):  # cost per dollar
			return abs(amount) * price * commission * 0.0001
		elif commission_type==float(2): # cost per lot
			return abs(amount) * commission
		else: # take care of all other commission types
			return 0.0
```

repository: magnumjoseph/ziplineaqm

gha_language: Python

repo_name: magnumjoseph/ziplineaqm


text:
# Chip Gaines on the importance of spreading kindness: 'I don’t want to leave a world like this to my children'

Published at: **2019-11-07T00:43:20+00:00**

Author: **Nate Day**

Original: [Fox News](https://www.foxnews.com/entertainment/chip-joanna-gaines-spreading-kindness)

Even "Fixer Upper" stars Chip and Joanna Gaines can feel the weight of the world.
In an interview with People magazine published on Wednesday, the Gaines opened up about their worries stemming from mass shootings, climate change and more.
“All these terrible things that have happened just really shocked my system,” Chip, 45, said. “I started talking to Jo like, ‘What can we do?’ I don’t want to leave a world like this to my children.”

          JOANNA AND CHIP GAINES OPEN UP ABOUT EXPANDING THEIR FAMILY

“We started wrestling with the thought of simply paying for a stranger’s meal or calling an old friend -- just a little token,” Chip said. “It evolved from there.”
Then the idea of Kindness Flyers was born.
The flyers encourage people to take one of the tear-away tabs off the flyer and fulfill the act of kindness printed on it. Acts include mowing a neighbor's lawn or volunteering at a local charity.
“It got really personal for me,” Chip said. “Obviously I want to do a whole lot more than print out flyers and staple them around people’s neighborhoods, but if this is where we can start, I’m honored to give it a try.”

          EMMA WATSON ADMITS SHE'S 'STRUGGLED' WITH FAME, FELT 'GUILTY' ABOUT SUCCESS

“We were hoping that it would resonate with people," said Joanna, 41. "Little things that wouldn’t feel like a stretch and are good for your soul.”
There is also a version of the flyers for kids, which Joanna has found particularly successful, she said. The kids' flyers contain tasks such as picking flowers and giving them to a parent.
“For me, the schools are where it starts,” Joanna sad. “That’s the generation we are raising up. Every day we try to teach our own kids to be kind to themselves, to each other, to neighbors and especially to those who look like they are alone.”
The idea extends into their own home life, as well, the couple said.

          CLICK HERE TO GET THE FOX NEWS APP

“We try to be conscious of what we hear [our kids] say to each other and how they say it,” Joanna said. “I know the kind words that were spoken to me as a kid that were really impactful -- but also the negative words that I had to work through up until my 20s and 30s."
"We try to teach our kids that their words really matter," she added.

license: Unlicense

repository: dsadlollioygjmzvcxv/tdc-exported

repo_name: dsadlollioygjmzvcxv/tdc-exported


text:
# Changelog

## v0.8.8 (2023-08-30)

### Fixes

* Avoid Logger.warn deprecation warning on recent Elixir versions

## v0.8.7 (2023-05-31)

### Fixes

* Compatibility with Elixir 1.15

## v0.8.6 (2023-04-04)

### Fixes

* Compatibility with Erlang/OTP 25.3

## v0.8.5 (2022-05-25)

### Fixes

* [X509.Test.Server] Use `:ssl.handshake/3` if available

## v0.8.4 (2022-03-01)

### Fixes

* [X509.RDNSequence] Fix handling of surname attribute

## v0.8.3 (2021-06-07)

### Enhancements

* [X509.PublicKey] Support 'engine' reference for private keys in `derive/1`
* [X509.CSR] Support 'engine' reference for private keys in `new/2,3`
* [X509.CSR] Add `:public_key` option for `new/3`

## v0.8.2 (2020-11-05)

### Fixes

* Support for Elixir v1.11

## v0.8.1 (2020-02-29)

### Fixes

* [X509.Certificate] Support both 'plain' and 'otp' `rdnSequence` records
* [X509.CSR] Support both 'plain' and 'otp' `rdnSequence` records

## v0.8.0 (2019-12-09)

### Enhancements

* [X509.CSR] Add support for extension requests

## v0.7.0 (2019-07-15)

### Enhancements

* [X509.Certificate.Template] Add OCSP responder template
* [X509.Certificate.Extension] Add support for Authority Information Access
  and OCSP Nocheck extensions

### Fixes

* [X509.RDNSequence] Handle `teletexString` encoding (7-bit only, for now)
* [X509.PrivateKey] Documentation fixes

## v0.6.0 (2019-06-18)

### Enhancements

* [X509.PrivateKey] Allow encryption of PEM output
* [X509.Test.Suite] Include 'localhost' in all certifictes
* [X509.Test.Suite] Generate client certificate and associated key
* [X509.Test.Server] Add 'client-cert' endpoint for testing with client
  certificate
* [`x509.gen.suite` Mix task] Add --force option
* [`x509.gen.suite` Mix task] Add --password option
* [`x509.gen.suite` Mix task] Generate 'ca_and_chain.pem' file
* [`x509.gen.selfsigned` Mix task] Add --force option

## v0.5.4 (2019-04-15)

### Enhancements

* [X509.RDNSequence] Relax length restriction on `countryName` attribute

## v0.5.3 (2019-03-14)

### Fixes

* [X509.RDNSequence] Support more attribute types in `to_string/1`

## v0.5.2 (2019-02-21)

### Enhancements

* [X509.Certificate] Add `version/1`, `subject/2` and `issuer/2`
* [X509.RDNSequence] Add `get_attr/2`

## v0.5.1 (2019-01-03)

### Fixes

* [X509.Certificate.Validity] The record type returned for GeneralizedTime,
  used for dates from 2050 forward, was not recognized by OTP, causing
  certificate creation and encoding to fail (#24)

## v0.5.0 (2018-11-27)

### Enhancements

  * [X509.CRL] New module for generating and parsing Certificate Revocation
    Lists (CRLs)
  * [X509.CRL.Entry] New module: CRL entries
  * [X509.CRL.Extension] New module: CRL extensions
  * [X509.Certificate.Extension] Add support for the CRL Distribution Point
    extension
  * [X509.Test.Suite] New module for generating test suites for TLS client
    testing
  * [X509.Test.Server] New module: simple server for hosting test suites
  * Add `x509.gen.suite` Mix task
  * Add `x509.test_server` Mix task

### Fixes

  * [X509.Certificate.Validity] The `days_from_now/2` function used to
    calculate the `not_after` timestamp relative to the `not_before` value
    (including the `backdate_seconds` shift); it is now set relative to the
    current time

## v0.4.0 (2018-10-19)

### Breaking changes

All `from_der` and `from_pem` functions now return an `:error` tuple on failure
instead of `nil`, and wrap their result in a `:ok` tuple in case of success.
The only exception is the `from_pem` function in X509, which returns a
(possibly empty) list.

  * [X509] Removed `to_der/1`, `to_pem/1` and `from_der/2`
  * [X509.Certificate] Changed the return values of `from_der/1` and
    `from_pem/1,2`, as described above

### Enhancements

  * Add `x509.gen.selfsigned` Mix task
  * The various `from_pem` and `from_pem!` functions are now more lenient: they
    scan for the first PEM entry of an appropriate type instead of requiring
    that it be the only entry
  * [X509.Certificate] Add `serial/1` to extract a certificate's serial number
  * [X509.Certificate.Template] The length of randomly generated serial numbers
    can now be specified using a `{:random, n}` tuple in the `:serial` field,
    where `n` is the length in bytes; the default is `{:random, 8}`, equivalent
    to the previous default

### Fixes

  * [X509.Certificate] Fixed the typespec for second parameter of
    `from_der!/2`, `from_der/2`, `from_pem!/2` and `from_pem/2`
  * [X509.Certificate] Extract the correct RDN from issuer certificate (#13)
  * [X509.Certificate.Extensions] `subject_key_identifier/1` returned an AKI
    record rather than SKI record for ECC keys (#10)
  * [X509.PublicKey] Documentation: corrected the default value for the
    `wrap` option for RSA keys in `to_der/1` and `to_pem/1`

## v0.3.0 (2018-09-22)

This release paves the way for some changes in the way PEM and DER
decoding works. Eventually there will be six functions in each module, as
implemented in `X509.CSR` in this version. The generic functions in the `X509`
module will eventually be removed, with the exception of the`X509.from_pem/2`
function, which returns a (possibly filtered) list of entities found in the
PEM string.

In the next version, all `from_der` and `from_pem` functions (except for the
one in `X509`) will return `:ok` / `:error` tuples, so please update existing
code to use the new `from_der!` and `from_pem!` functions instead: their return
value on success will always be just the module's primary record type.

### Breaking changes

  * [X509.Certificate] `from_der/2` and `from_pem/2` now return `nil` in case
    of failure, for consistency with the current behaviour of other modules;
    use the new `from_der!/2` and `from_pem!/2` to get the old behaviour of
    raising an exception

### Enhancements

  * [X509.Certificate] Add `from_der!/2` and `from_pem!/2`
  * [X509.CSR] Add `to_der/1`, `to_pem/1`, `from_der!/1`, `from_der/1`,
    `from_pem!/1` and `from_pem/1`
  * [X509.PrivateKey] Add `from_der!/2` and `from_pem!/2`
  * [X509.PublicKey] Add `from_der!/2` and `from_pem!/2`
  * Support Elixir v1.7 and ExDoc v0.19

### Deprecations

The `to_der`, `to_pem` and `from_der` functions in the X509 top-level module
have been deprecated. Please use their entity-specific functions in the
appropriate module instead. The deprecated functions will be removed in an
upcoming release, prior to v1.0.

## v0.2.0 (2018-07-24)

### Breaking changes

  * [X509.Certificate] Primary type has been changed from `:Certificate` to `:OTPCertificate`; the `new/[4,5]` and `self_signed/[2,3]` functions now return an `:OTPCertificate` record

### Enhancements

  * [X509] `to_der` and `to_pem` now delegate now support `:OTPCertificate` records, by delegating to `X509.Certificate`
  * [X509.Certificate] Added certificate-specific implementations of `to_der`, `to_pem`, `from_der` and `from_pem`

## v0.1.0 (2018-07-02)

First public release

gha_language: Elixir


text:
---
title: Introduction
---

Fable.Form allows you to build forms that are:

- **Composable:** they can be extended and embedded into other forms
- **Type safe:** makes the most of F# compiler to tie everything together
- **Scalable:** you don't need a `Msg` for each field neither repeat your `view` code
- **Terse:** your field logic is defined in a single place
- **Modular:** you can create your own fields and customize how existing fields are rendered

```fsharp
let form : Form.Form<Values, Msg> =
    let emailField =
        Form.textField
            {
                Parser =
                    fun value ->
                        if value.Contains("@") then
                            Ok value
                        else
                            Error "The e-mail address must contain a '@' symbol"
                Value =
                    fun values -> values.Email
                Update =
                    fun newValue values ->
                        { values with Email = newValue }
                Error =
                    fun _ -> None
                Attributes =
                    {
                        Label = "Email"
                        Placeholder =<EMAIL_ADDRESS>                    }
            }

    let passwordField =
        Form.passwordField
            {
                // ...
            }

    let onSubmit =
        fun email password ->
            LogIn (email, password)

    Form.succeed onSubmit
        |> Form.append emailField
        |> Form.append passwordField
```

gha_license_id: NOASSERTION


text:
# AutoGraph

**NOTE: As tensorflow.contrib is being
[deprecated](https://github.com.cnpmjs.org/tensorflow/community/pull/18), AutoGraph is
moving into TensorFlow core.

The new code location is `tensorflow/python/autograph`. Please refer to the
README.md file in that directory.
**

repository: BingyangWu/Antman

repo_name: BingyangWu/Antman


text:
# sorting-visualization

[![GoDoc](https://godoc.org/github.com/invzhi/sorting-visualization?status.svg)](https://godoc.org/github.com/invzhi/sorting-visualization)
[![Go Report Card](https://goreportcard.com/badge/github.com/invzhi/sorting-visualization)](https://goreportcard.com/report/github.com/invzhi/sorting-visualization)
[![license](https://img.shields.io/github/license/invzhi/sorting-visualization.svg)](LICENSE)

Inspired by [FishyMcFishFace](https://imgur.com/t/rainbow/RM3wl) on [Hacker News](https://news.ycombinator.com/item?id=15423202).

repository: invzhi/sorting-visualization

repo_name: invzhi/sorting-visualization


text:
# SymbioSound

This web app was designed as a creative hub and collaborative network for artists to get paid for their skills, and also receive services based on their musical needs.

## Usage

Run shotgun to access the website in your local server.

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/kpobrien4/sinatra-portfolio-project.

##Author
Kevin O'Brien

##Acknowledgements
Enoch Griffith

##License
The gem is available as open source under the terms of the MIT License - see the LICENSE.md file for details

gha_language: Ruby

gha_license_id: MIT


text:
# rpctocli
Use 'go generate' to transform your net/rpc into codegangsta/cli (sub)commands

## installation
simply use `go get`:

```
go get github.com/advanderveer/rpctocli
```

repository: advanderveer/rpctocli

repo_name: advanderveer/rpctocli


text:
---
title: "Golang Note Three"
date: "2015-05-05"
template: "post"
draft: false
slug: "golang-note-three"
category: "golang"
tags:
  - "golang"
description: ""
socialImage: ""
---

### Methods

- Go does not have classes. However, you can define methods on struct types.
- The `method receiver` appears in its own argument list between the func keyword and the method name.
- You can declare a method on any type that is declared in your package, not just struct types.
- You cannot define a method on a type from another package (including built in types).
- Methods can be associated with a named type or a pointer to a named type.
  - There are two reasons to use a pointer receiver.
  - Avoid copying the value on each method call (more efficient if the value type is a large struct)
  - The method can modify the value that its receiver points to.

### Interfaces

- An interface type is defined by a set of methods.
- A value of interface type can hold any value that implements those methods.
- One of the most ubiquitous interfaces is `Stringer` defined by the `fmt` package.
- A Stringer is a type that can describe itself as a string.

```go
type Stringer interface {
    String() string
}
```

### Errors

- Go programs express error state with error values.
- The `error` type is a built-in interface simliar to `fmt.Stringer`

```go
type error interface {
    Error() string
}
```

- Functions often return an `error` value, and calling code should handle errors by testing whether the error equals `nil`.

```go
i, err := strconv.Atoi("42")
if err != nil {
    fmt.Printf("couldn't convert number: %v\n", err)
}
fmt.Println("Converted integer:", i)
```

### Readers

- The `io` package specifies the `io.Reader` interface, which represents the read end of a stream of data.

```go
func (T) Read(b []byte) (n int, err error)
```

`Read` populates the given byte slice with data and returns the number of bytes populated and an error value. It returns an `io.EOF` error when the stream ends.

### Web servers

- Package `http` serves HTTP requests using any value that implements `http.Handler`

```go
package http

type Handler interface {
    ServeHTTP(w ResponseWriter, r *Request)
}
```

repository: anggao/myblog

gha_language: JavaScript

repo_name: anggao/myblog


text:
# Flights-dataset
Analysis of a dataset of flights, using the SparkSQL framework and extra web scraping techniques

## Project overview
### What is the project for
The goal of this demo is to massively use the SparkSQL framework functionalities to perform a dataset analysis. In this example, the dataset represents the home US flights for the year 1994.

In the final section of the project, in order to understand if flight delays were related to wheater conditions, web scraping techniques have been applied. In this way, we have enough data to perform the analysis.

### How to access the project files
You can find the Python Notebook exported as an HTML file, that is more portable in terms of readability.

## Technical details
### Apache Spark
As said before, we used SparkSQL to query the database and analyse its content.

### Data Science Python libraries
We have decided to use some of the most famous available Python libraries:
- Pandas and Numpy: data processing and analysis
- Matplotlib and Seaborn: data visualization
- UrlLib and BS4: web scraping for the weather conditions

## Special thanks
We want to thank you our teacher, Michiardi Pietro, who has realized the baseline for the notebook and has guided us during its realization, teaching us all the techniques presented here.

## Credits
ANGIUS Marco and AVALLE Giorgio - Ⓒ2017


text:
### [CVE-2021-22020](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22020)
![](https://img.shields.io/static/v1?label=Product&message=VMware%20vCenter%20Server%2C%20VMware%20Cloud%20Foundation&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=Denial%20of%20service%20vulnerability&color=brighgreen)

### Description

The vCenter Server contains a denial-of-service vulnerability in the Analytics service. Successful exploitation of this issue may allow an attacker to create a denial-of-service condition on vCenter Server.

### POC

#### Reference
- https://www.vmware.com/security/advisories/VMSA-2021-0020.html

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

repository: trickest/cve

gha_language: HTML

repo_name: trickest/cve


text:
# flutter_map_dragmarker

A drag marker for [flutter_map](https://github.com/fleaflet/flutter_map/).

See the [example/lib/main.dart](example/lib/main.dart) for usage, but the
included example below in this file should show pretty much everything.

[![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/F1F8E2YBE)

## Usage

- This layer should probably be the last layer so IF it needs to be dragged
  (otherwise why would you use this :)). If not, other layers may intercept
  the gestures.
- `offset` and `dragOffset` are there for tweaking icon/images if they should
  not get displayed centered.
- `height` is mainly for `Images`, use `Icon(..., size: ...)`, but be aware
  internal calculations are based on size.
- `rotateMarker` toggles the markers' rotation on and off. True keeping markers
  upright.
- Use `scrollMapNearEdge` if the map should scroll when a marker is dragged
  near the edge.
- Enable `useLongPress` if you want to enable dragging after a long press

```dart
  FlutterMap(
    options: MapOptions(center: LatLng(45.5231, -122.6765), zoom: 9),
    children: [
      TileLayer(
        urlTemplate: 'https://tile.openstreetmap.org/{z}/{x}/{y}.png',
      ),
      DragMarkers(
        markers: [
          DragMarker(
            point: LatLng(45.535, -122.675),
            offset: const Offset(0.0, -8.0),
            builder: (ctx) => const Icon(Icons.location_on, size: 50),
            onDragUpdate: (details, latLng) => print(latLng),
          ),
        ],
      ),
    ],
  ),
```

## Further notes
It may be interesting to move the map alternately to marker, too. So the marker
stays in place, but then technically you aren't dragging anymore, so thoughts
welcome.


text:
# Professional README Generator Node.js HW 9

## Table of Contents
* Description
* Usage
* Installation
* License
* Contributors
* Tests
* Questions

## Description
This command-line application dynamically gernerates a professional README.md file from a user's input using the Inquirer package.

## Usage
This application allows a project creator to quickly generate a professional README so that they can devote more time to working on a project.

## Installation
The user will need to install the Inquirer package on Node. The application will be invoked using the command "node index.js".

## License
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

## Contributors
Janée Artis

## Tests
false

## Questions? Contact Me:
* GitHub: [Github Profile](https://github.com/janeeart)
* Email<EMAIL_ADDRESS>
## Demo Video
https://drive.google.com/file/d/141DJN5FQeKvoN0h3aztFsbY3lUXWPJI6/view


text:
frequently tcpdump commands
===========================

1. Filter by host/port/protocol

    parameters:

    * `-n`: Don't convert addresses (i.e., host addresses, port numbers, etc.) to names
    * `-X`: in addition to printing the headers of each packet, print the data of each packet in hex and ASCII

    ```shell
    # filter by host
    $ tcpdump -i eth1 -n -X src host <IP_ADDRESS>

    # filter by port
    $ tcpdump -i eth1 -n -X src host <IP_ADDRESS> and dst port 80

    # filter by protocol
    $ tcpdump -i eth1 -n -X src host <IP_ADDRESS> and dst port 80 and tcp

    # capture all HTTP GET requests
    $ tcpdump -i eth1 -n -A src host <IP_ADDRESS> and dst port 80 and tcp[20:4]=0x47455420
    ```

    Reference [tcpdump：理论、自动抓包及业务架构树的生成](http://www.yunweipai.com/archives/7981.html).

# Reference

1. [tcpdump：理论、自动抓包及业务架构树的生成](http://www.yunweipai.com/archives/7981.html)

repository: sachin-net/cheat-sheets

repo_name: sachin-net/cheat-sheets


text:
---
title:  "Network(12) -- DNS"
tags: Network
---

### DNS caching

DNS extensively exploits DNS caching in order to improve the delay performance and to reduce the number of DNS messages

In fact, because of caching, root servers are bypassed for all but a very small fraction of DNS queries.

### DNS Records and Messages

resource records (RRs)

A resource record is a four-tuple that contains the following fields:

(Name, Value, Type, TTL)

* If Type=A , then Name is a hostname and Value is the IP address for the hostname.
* If Type=NS , then Name is a domain (such as foo.com ) and Value is the hostname of an authoritative DNS server that knows how to obtain the IP addresses for hosts in the domain.
* If Type=CNAME , then Value is a canonical hostname for the alias hostname Name .
* If Type=MX , then Value is the canonical name of a mail server that has an alias hostname Name .

DNS Messages

* The first 12 bytes is the header section, which has a number of fields.
* The question section contains information about the query that is being made.
* In a reply from a DNS server, the answer section contains the resource records for the name that was originally queried.
* The authority section contains records of other authoritative servers.
* The additional section contains other helpful records.

# Peer-to-Peer File Distribution

Dcs >= Max{NF/us,Fdmin}

Dp2p = Max{F/us,F/dmin,NF/(us + ΣuN)}

In deciding which chunks to request, Alice uses a technique called rarest first.

Alice gives priority to the neighbors that are currently supplying her data at the highest rate. Specifically, for each of her neighbors, Alice continually measures the rate at which she receives bits and determines the four peers that are feeding her bits at the highest rate.


text:
# Introduction
This is a graphical and collaborative semantic anotation supporting tool to create semantic web services according to SAWSDL.

# Getting Started
TODO: Guide users through getting your code up and running on their own system. In this section you can talk about:
1.	Build the whole solution using Visual Studio
2.	Run both the Grasews.API and the Grasews.Web projects
3.	Open the Grasews.Web URL in a browser

# Demo
1. Basic usage of Grasews for semantic annotation : https://youtu.be/judKxqu2fpw
2. Working with Issues and Tasks : https://youtu.be/Nj6_LSy6qDc
3. Notifications for Issues and Tasks : https://youtu.be/-96vLq_ak14
4. Adding comments to a task : https://youtu.be/ka7wmLFY290

repository: mlcalache/grasews

repo_name: mlcalache/grasews


text:
# Trapeliopsis wallrothii (Flörke) Hertel & Gotth. Schneid. SPECIES

#### Status
ACCEPTED

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

#### Published in
in Schneider, Biblthca Lichenol. 13: 153 (1980)

#### Original name
Lecidea wallrothii Flörke

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
# How to write node.js modules using C++

This is a tutorial for writing [node.js](http://nodejs.org/) modules in C++. It is the base and reference for my talk on writing node.js modules with V8 at [JSConf 2011 in Berlin](http://jsconf.eu/2011).

Further references:

* [V8 Doxygen](http://izs.me/v8-docs/main.html)
* [uv.h](https://github.com/joyent/libuv/blob/master/include/uv.h)
* [An introduction to libuv](http://nikhilm.github.com/uvbook/)
* [v8 Cookbook](http://create.tpsitulsa.com/wiki/V8_Cookbook)
* [Google's C++ style guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml)

repository: xavierjs/helicojs

repo_name: xavierjs/helicojs


text:
# EIR Operations

The following are all of the various operations that are defined by the EIR
dialect.

## Calls

### call

    eir.call @fn(%arg1, .., %argN) : fnTy

### indirect_call

    eir.indirect_call %fn(%arg1, .., %argN) : fnTy

NOTE: Indirect calls may not always know the return type, but for Erlang
applications we know that any call must result in either termination of
the process, or returning a Term. In such cases where the callee is unknown,
we assume that the return type is thus `!eir.term`

## Control Flow

### br

An unconditional branch instruction. This is a terminator operation.

    eir.br ^block(...)

This basically mirrors the standard `br` operation, but is kept in EIR dialect
to differentiate between control flow from EIR, and control flow introduced by
code generation.

Primarily meant for lowering EIR calls which refer to a block for control flow,
rather than a function.

### if_bool

A conditional branching construct. This is a terminator operation.

    eir.if_bool %selector, ^true(...), ^false(...), ^else(...)

If `^else` is not provided, then it is assumed that such a branch is unreachable.

### if_type

A conditional branch instruction based on whether the type of the selector
matches the specified type. This is a terminator operation.

    eir.if_type<"T"> %selector, ^true(...), ^false(...)

Syntactically, this operates in the same fashion as `eir.is_type`. See the notes
about that operation for details on type conversion rules.

If the selector matches the given type, control branches to the `^true` block,
and the selector is passed as the first argument, followed by any specified
arguments. Importantly, the selector is also cast to the specified type before
passed to the successor block, if necessary. This allows one to write optimized
paths for cases where types match.

If the selector does not match, control branches to the `^false` block, and the
selector is passed as the first argument, followed by any specified arguments.
The selector is passed along as-is in this case.

### match

A richer and more dynamic form of conditional branching. Like `if_bool`, this is
a terminator operation.

    eir.match %selector, (branch to ^block(...))+

NOTE: Block arguments may be given and will be appended after any arguments
resulting from the type of match.

`branch` is defined as:

    branch ::= match-kind
    match-kind ::= value-match
                | type-match
                | wildcard-match
                | tuple-match
                | cons-match
                | map-entry-match
                | binary-match
    value-match     ::= 'value'(ssa-id)
    type-match      ::= 'type'(type-id)
    wildcard-match  ::= 'any'
    tuple-match     ::= 'tuple'(arity:integer-literal)
    cons-match      ::= 'cons'
    map-entry-match ::= 'map_entry'(key:ssa-id, value:ssa-id)
    binary-match    ::= 'binary'(size:ssa-id, selector+)
                     |  'binary'(selector+)
    selector ::= unit-type
              | signedness
              | endianness
              | 'unit'(integer-literal)
    unit-type ::= 'integer'
               | 'float'
               | 'bytes'
               | 'bits'
               | 'utf8'
               | 'utf16'
               | 'utf32'
    signedness ::= 'signed' | 'unsigned'
    endianness ::= 'native' | 'big' | 'little'

Some restrictions/addendums to the above apply:

- The `size` argument to the binary match type may not be given if any of the
  `utf` unit types are given. They are incomptabile.
- The signedness defaults to `unsigned`, and can only be given if `integer` is
  given
- The endianness defaults to `big`, and can only be given if one of `integer`, `float`,
  `utf16`, or `utf32` unit types are given.
- `unit` cannot be given if any `utf` unit type is given
- If `size` and `unit` is omitted, then:
  - unit is assumed to be 1 for `integer`, `float` and `bits`, 8 for `bytes`
  - size is assumed to be 8 for `integer`, 64 for `float` and the entire
    binary/bitstring for `bytes`/`bits` respectively

## Error Handling

### capture_trace

Captures the current stack trace and returns a reference to it as an SSA value

    %trace_ref = eir.capture_trace

### get_trace

Access the stack trace previously captured by `capture_trace`, and returns it as
an SSA value.

    %trace_ref = eir.get_trace

## Data

### box

Given a reference, produces a boxed value that can be passed to the runtime.

    %boxed = eir.box(%val : !eir.ref<T>) : !eir.box<T>

### unbox

The inverse of `box`, extracts a reference contained in the boxed value.

    %ref = eir.unbox(%val : !eir.box<T>) : !eir.ref<T>

### is_type

A dynamic type checking operation.

    %result : i1 = eir.is_type<"T"> %selector

In the above, `T` is a placeholder for a type signature. While this is really
intended specifically for EIR types, it is possible to specify arbitrary types
here, but during lowering, an assertion will be thrown if there is no supported
conversion to an EIR type. See the `eir.cast` notes for more details.

If you want to branch on type, and use the typed value, use `eir.if_type` instead, as it
combines type checking and casting the value in one combined operation, which is
more efficient when the typed value is needed. This operation is intended as a
more primitive operation consumed by other operations like `match`, where type
checking is required, but the value is not required to be cast to the matched type.

### cast

A dynamic cast operation.

    %result = eir.cast %value:inTy to outTy

This operation performs a cast from `inTy` to `outTy`, if supported. In most
cases, this will be used to cast an opaque type to a more concrete type, i.e.
converting `eir.term` to `eir.fixnum` or `eir.box<T>`. However, it may also be
used to convert from EIR types to standard types, e.g. `eir.fixnum` to `i32`.
Some casts are not supported, such as an EIR type to memref. It is also not
supported to cast between other dialect types; an EIR type must be either the
source or target type.

The various supported implicit casts are below:

- `iX` from `eir.fixnum`, where X is the bit width the value must fit in
  - this is done by stripping the tag bits from the fixnum
- `eir.fixnum` from `iX`, as long as X is less than or equal to the bit width of
  the maximum fixnum width.
  - this is done by sign-extending the iX, clearing the tag bits or shifting,
    then adding the fixnum tag
- `i1` from `eir.boolean`
  - this is done by stripping the tag bits from the boolean atom; 'false' is 0,
    and 'true' is 1
- `eir.boolean` from `i1`
  - this is done by zero-extending the i1, and adding the atom tag
- `index` from `eir.fixnum` when the value is unsigned and fits in a
  pointer-width integer
- `eir.fixnum` from `index` when the value fits in the fixnum width
- `f64` from `eir.float`
  - on x86_64, this is just a bitcast
  - on other platforms, we don't use `eir.float`
- `eir.float` from `f64`
  - per the above, this is just a bitcast
- `f64` from `eir.float.packed`
  - this is done by loading the f64 directly from the boxed term
  - once unpacked, we do not repack unless necessary
  - NOTE: we do _not_ support conversions to `eir.float.packed`, instead a new
    packed float must be allocated/constructed from the `f64` value
- `eir.ref<T>` from `eir.box<T>`
  - i.e. extract the pointer from the box, this delegates to the `eir.unbox` operation
- `eir.box<T>` from `eir.ref<T>`
  - i.e. box the pointer, this delegates to the `eir.box` operation
- `vector<NxT>` for `eir.tuple` of `N` arity, where `T` is a word-sized EIR type
  - this is essentially a bitcast, which takes the address of the first element
    of the tuple and uses that as the base address for the vector
  - this conversion takes advantage of the fact that our tuple layout and a
    vector layout are 1:1, but this only holds when the vector elements are all
    word-sized, i.e. `eir.term`, `eir.fixnum`, `eir.boolean`, `eir.atom`,
    `eir.nil`, and the other immediates.

This operation is a primitive meant to be used by higher-level operations, i.e.
`if_type` will check the type with `is_type`, cast with `cast`, then branch with
`br`. Later passes will then optimize series of instructions like these to avoid
any duplicate work they may do internally.

### map_insert

Inserts a key/value pair into the given map, and jumps to either the success or
failure block based on the result of the operation. This is a terminator operation.

    eir.map_insert(%map, %key, %value, ^success(...), ^failure(...))

NOTE: The updated map will be given as the first block argument to `^success`.
Failure of the operation can occur if `%map` is not a map term, or if `%key`
already exists in `%map`.

### map_update

Has almost the same semantics as `map_insert`, but rather than expecting the key
to not exist, it expects the key to exist.

    eir.map_update(%map, %key, %value, ^success(...), ^failure(...))

### map_get

Extracts the value with the given key from a map.

    %value = eir.map_get(%map, %key)

NOTE: Can only be used when `%map` is known to be a map and `%key` is a term.

### extract_element

Extracts an element from a tuple, by zero-based index.

Think of this as a higher-level version of LLVM's `extractelement`.

    %element = eir.extract_element(%tuple, %index)

NOTE: Can only be used when `%tuple` is known to be a tuple and `%index` is an
integer value.

### update_element

Destructively updates (i.e. in-place) an element in a tuple, by zero-based index.

Think of this as a higher-level version of LLVM's `insertelement`.

    eir.update_element(%tuple, %index, %value)

NOTE: Can only be used when `%tuple` is known to be a tuple and `%index` is an
integer value; in addition, `%value` must be a valid word-sized EIR type.

### head

Like `extract_element`, but for cons cells, and specifically extracts the head
element.

    %head = eir.head(%cons)

NOTE: Can only be used when `%cons` is known to be a cons cell.

### tail

Like `extract_element`, but for cons cells, and specifically extracts the tail
element.

    %tail = eir.tail(%cons)

NOTE: Can only be used when `%cons` is known to be a cons cell.

### binary_push

Used during binary construction, this operation appends a new value to the given
binary, using the given binary specifier. Once complete, control branches to
either the success or failure block based on the result of the operation. This
is a terminator operation.

    eir.binary_push(%bin, %val, binary-spec, ^success(...), ^failure(...))

Where `binary-spec` is defined as:

    binary-spec ::= binary(size:ssa-id, specifier+)
                 |  binary(specifier+)

    specifier ::= see definition of `branch` in `eir.match` operation

NOTE: This uses the same specifier syntax as `eir.match`. In the success case,
the new binary is passed as a block argument to the success block. Failure can
occur if `%bin` is not a binary term, `%val` is invalid for the given binary
spec, or due to allocation failure (either on heap or stack).

## Miscellaneous

### unreachable

Semantically identical to the standard `unreachable`, but is preserved for our
own analyses in case we later decide to handle them differently.

    eir.unreachable

## Intrinsics

### intrinsic<"name">

A generalized intrinsic, which unless otherwise handled during lowering, will be
lowered as a function call to a runtime function of the same name.

Syntactically, this takes essentially the same form as a function call:

    %ret = eir.intrinsic<"name">(%arg1, .., %argN) : fnTy

repository: shaneutt/lumen

branch_name: refs/heads/develop

repo_name: shaneutt/lumen


text:
# Passing and Sharing References

Reference capabilities make it safe to both __pass__ mutable data between
actors and to __share__ immutable data amongst actors. Not only that, they make
it safe to do it with no copying, no locks, in fact no runtime overhead at all.

## Passing

For an object to be mutable, we need to be sure that no _other_ actor can read
from or write to that object. The three mutable reference capabilities (`iso`,
`trn`, and `ref`) all make that guarantee.

But what if we want to pass a mutable object from one actor to another? To do
that, we need to be sure that the actor that is _sending_ the mutable object
also _gives up_ the ability to both read from and write to that object.

This is exactly what `iso` does. It is _read and write unique_, there can only
be one reference at a time that can be used for reading or writing. If you send
an `iso` object to another actor, you will be giving up the ability to read
from or write to that object.

__So I should use `iso` when I want to pass a mutable object between actors?__
Yes! If you don't need to pass it, you can just use `ref` instead.

## Sharing

If you want to __share__ an object amongst actors, then we have to make one of
the following guarantees:

1. Either _no_ actor can write to the object, in which case _any_ actor can
read from it, or
2. Only _one_ actor can write to the object, in which case _other_ actors can
neither read from or write to the object.

The first guarantee is exactly what `val` does. It is _globally immutable_, so
we know that _no_ actor can ever write to that object. As a result, you can
freely send `val` objects to other actors, without needing to give up the
ability to read from that object.

__So I should use `val` when I want to share an immutable object amongst
actors?__ Yes! If you don't need to share it, you can just use `ref` instead,
or `box` if you want it to be immutable.

The second guarantee is what `tag` does. Not the part about only one actor
writing (that's guaranteed by any mutable reference capability), but the part
about not being able to read from or write to an object. That means you can
freely pass `tag` objects to other actors, without needing to give up the
ability to read from or write to that object.

__What's the point in sending a tag reference to another actor if it can't then
read of write the fields?__ Because `tag` __can__ be used to __identify__
objects and sometimes that's all you need. Also, if the object is an actor you
can call behaviours on it even though you only have a `tag`.

__So I should use `tag` when I want to share the identity of a mutable object
amongst actors?__ Yes! Or, really, the identity of anything, whether it's
mutable, immutable, or even an actor.

## Reference capabilities that can't be sent

You may have noticed we didn't mention `trn`, `ref`, or `box` as things you can
send to other actors. That's because you can't do it. They don't make the
guarantees we need in order to be safe.

So when should you use those reference capabilities?

* Use `ref` when you need to be able to change an object over time. On the
other hand, if your program wouldn't be any slower if you used an immutable
type instead, you may want to use a `val` anyway.
* Use `box` when you don't care whether the object is mutable or immutable. In
other words, you want to be able to read from it, but you don't need to write
to it or share it with other actors.
* Use `trn` when you want to be able to change an object for a while, but you
also want to be able to make it _globally immutable_ later.

repository: nerdatmath/pony-tutorial

repo_name: nerdatmath/pony-tutorial


text:
# Pixel Stream Information Transfer (PXIT)

### Description
Pixel stream information transfer is a telecommunications technique for sending digital information using a stream of video images.

The technique involves:

1. Converting a set of files into video images
2. Broadcasting the images as part of a television program
3. Receiving the images and recovering the set of files

### Table of Contents
1. pxit-encoder - converts files into a sequence of images
2. targa2video.sh - converts the images into a video file
3. Procedure for broadcasting and receiving video
4. pxit-decoder -converts received video into files
5. pxit-scope - a debugging tool to extract data from images created by pxit-encoder

### Installation
The software was built and tested on Arch Linux. To build the executables pxit-encode, pxit-decode, and pxit-scope
you should obtain [the software](https://github.com/pxitgit/pxit-tools.git), uncompress the zip file, switch to the directory containing the source code, and type 'make' on the command line.  Make will write the output programs into a subdirectory named bin.

repository: pxitgit/pxit-tools

repo_name: pxitgit/pxit-tools


text:
# Akka Streams SNS Connector

The AWS SNS connector provides an Akka Stream Flow and Sink for push notifications through [Amazon Simple Notification Service (SNS)](https://aws.amazon.com/sns).

## Producer

Sources provided by this connector need a prepared `IAmazonSimpleNotificationService` to publish messages to a topic.

```C#
var credentials = new BasicAWSCredentials("x", "y");
var snsService = new AmazonSimpleNotificationServiceClient(credentials);
```

### Publish messages to a SNS topic
Now we can publish a String message to any SNS topic where we have access to by providing the topic ARN to the `SnsPublisher` Flow or Sink factory method.

### Using a Flow

```C#
Task flow = Source
    .Single("message")
    .Via(SnsPublisher.PlainFlow("topic-arn", snsService))
    .RunWith(Sink.Ignore<PublishResponse>(), _materializer);
```

As you can see, this would publish the messages from the source to the specified AWS SNS topic. After a message has been successfully published, a `PublishResponse` will be pushed downstream.

```C#
Task sink = Source
    .Single("message")
    .RunWith(SnsPublisher.PlainSink("topic-arn", snsService), _materializer);
```
As you can see, this would publish the messages from the source to the specified AWS SNS topic.

repository: akkadotnet/Alpakka

branch_name: refs/heads/dev

repo_name: akkadotnet/Alpakka


text:
## Renode performance measurements {% if data["model_name"] %} for {{data["model_name"]}}{% endif %}

{%- if 'instrbarpath' in data %}
### Count of instructions used during inference

```{figure} {{data["instrbarpath"]}}
---
name: {{basename}}_instrbarplot
alt: Count of used instructions during inference
align: center
---

Count of used instructions during inference
```

{%- if 'vectorinstrbarpath' in data %}
```{figure} {{data["vectorinstrbarpath"]}}
---
name: {{basename}}_vectorinstrbarplot
alt: Utilization of V-Extension instructions during inference
align: center
---

Utilization of V-Extension instructions during inference
```
{%- endif %}
{%- endif %}

{%- if 'executedinstrplotpath' in data %}
### Executed instructions counters

{%- for cpu, plotpath in data['executedinstrplotpath'].items() %}
```{figure} {{plotpath['persec']}}
---
name: {{basename}}_{{cpu}}_executedinstrplotpath
alt: Count of executed instructions per second for {{cpu}}
align: center
---

Count of executed instructions per second for {{cpu}} during benchmark
```

```{figure} {{plotpath['cumulative']}}
---
name: {{basename}}_{{cpu}}_executedinstrplotpath
alt: Cumulative count of executed instructions for {{cpu}}
align: center
---

Cumulative count of executed instructions for {{cpu}} during benchmark
```
{%- endfor %}
{%- endif %}

{%- if 'memoryaccessesplotpath' in data %}
### Memory access counters
{%- if 'read' in data['memoryaccessesplotpath'] %}
```{figure} {{data['memoryaccessesplotpath']['read']['persec']}}
---
name: {{basename}}_memoryreadsplotpath
alt: Count of memory reads per second
align: center
---

Count of memory reads per second during benchmark
```

```{figure} {{data['memoryaccessesplotpath']['read']['cumulative']}}
---
name: {{basename}}_memoryreadsplotpath
alt: Cumulative count of memory reads
align: center
---

Cumulative count of memory reads during benchmark
```
{%- endif %}

{%- if 'write' in data['memoryaccessesplotpath'] %}
```{figure} {{data['memoryaccessesplotpath']['write']['persec']}}
---
name: {{basename}}_memorywritessplotpath
alt: Count of memory writes per second
align: center
---

Count of memory writes per second during benchmark
```

```{figure} {{data['memoryaccessesplotpath']['write']['cumulative']}}
---
name: {{basename}}_memorywritessplotpath
alt: Cumulative count of memory writes
align: center
---

Cumulative count of memory writes during benchmark
```
{%- endif %}
{%- endif %}

{%- if 'peripheralaccessesplotpath' in data %}
### Peripheral access counters

{%- for peripheral, plotpath in data['peripheralaccessesplotpath'].items() %}
```{figure} {{plotpath['read']['persec']}}
---
name: {{basename}}_{{peripheral}}_peripheralreadsplotpath
alt: Count of {{peripheral}} reads per second
align: center
---

Count of {{peripheral}} reads per second during benchmark
```

```{figure} {{plotpath['read']['cumulative']}}
---
name: {{basename}}_{{peripheral}}_peripheralreadsplotpath
alt: Cumulative count of {{peripheral}} reads
align: center
---

Cumulative count of {{peripheral}} reads during benchmark
```

```{figure} {{plotpath['write']['persec']}}
---
name: {{basename}}_{{peripheral}}_peripheralwritesplotpath
alt: Count of {{peripheral}} writes per second
align: center
---

Count of {{peripheral}} writes per second during benchmark
```

```{figure} {{plotpath['write']['cumulative']}}
---
name: {{basename}}_{{peripheral}}_peripheralwritesplotpath
alt: Cumulative count of {{peripheral}} writes
align: center
---

Cumulative count of {{peripheral}} writes during benchmark
```
{%- endfor %}
{%- endif %}

{%- if 'exceptionsplotpath' in data %}
### Exceptions counters

```{figure} {{data['exceptionsplotpath']['persec']}}
---
name: {{basename}}_exceptionsplotpath
alt: Count of raised exceptions per second
align: center
---

Count of raised exceptions per second during benchmark
```

```{figure} {{data['exceptionsplotpath']['cumulative']}}
---
name: {{basename}}_exceptionsplotpath
alt: Cumulative count of raised exceptions
align: center
---

Cumulative count of raised exceptions during benchmark
```
{%- endif %}

repository: antmicro/kenning

repo_name: antmicro/kenning


text:
# WordCreationPuzzle
## Assumptions
1.  The only way to build bigger words was to start with the smallest valid word and then add letters.
  1a.  If the smallest word was only one letter that wasn't in other words in the list the largest list would be just that word. {c} for {c, ab, bbb, bbbb}

2. The smallest word shouldn't appear in a new word more than once.  For example if the shortest word was "a", "bab" would be okay but not "baba".

repository: rmhwow/WordCreationPuzzle

repo_name: rmhwow/WordCreationPuzzle


text:
# LinguAdde
Java CLI for adding translations from a CSV to JSON and XLIFF files.

LinguAdde is currently at version `1.0`.

## Requirements

The only requirement is `Java SE Runtime Environment 8` or higher.

## Install

The latest release of this project can be found at [releases](https://github.com/Theyssen/LinguAdde/releases)
or can be run from source.

## Usage

Use `java -jar LinguAdde-1.0.jar help` to see the usage information.

```bash
usage: java -jar LinguAdde-1.0.jar -c <file> [-d <delimiter>] -t <folder>
Add translations in data files

 -c,--csv-file <file>         CSV file with translationdata
 -d,--delimiter <delimiter>   CSV delimiter Default: ;
 -t,--target <folder>         Target translation files
```

| Option | Long option | Argument | Required | Description |
| --- | --- | --- | --- | --- |
| c | csv-file | file | yes | CSV file with translationdata _**Important:**_ This file has to be encoded in `UTF-8` |
| d | delimiter | char | no | CSV delimiter **_Default:_** `;` |
| t | target | folder | yes | Target translation files _**Important:**_ The files in this folder have to be encoded in `UTF-8` |

## Example

```bash
java -jar LinguAdde-1.0.jar -c translations.csv -t results
```

## Author

Christophe Theyssen

[Github](https://github.com/Theyssen)
[Bitbucket](https://bitbucket.org/Theyssen/)
[Linkedin](https://be.linkedin.com/in/christophe-theyssen-39779487)

## License

MIT

repository: Theyssen/LinguAdde

repo_name: Theyssen/LinguAdde


text:
Stash tools
===========

Go package of Stash tools

## Installation

```bash
make
```

## Usage

```bash
go get github.com/xoom/stash

import "github.com/xoom/stash"
```

### Stash Rest API Documentation

* [Rest APIs](https://developer.atlassian.com/stash/docs/latest/reference/rest-api.html)

### NewClient

```go
stashClient := stash.NewClient("stash_user", "stash_pwd", "http://stash-url.local:7990")
```

### CreateRepository

```go
repository, err := stashClient.CreateRepository("PROJ", "slug")
```

### GetRepositories

```go
repository, err := stashClient.GetRepository("PROJ", "slug")
```

### GetBranches

```go
branches, err := stashClient.GetBranches("PROJ", "slug")
```

### GetRepository

```go
repository, err := stashClient.GetRepository("PROJ", "slug")
```

### CreateBranchRestriction

```go
branchRestriction, err := stashClient.CreateBranchRestriction("PROJ", "slug", "develop", "user")
```

### GetBranchRestrictions

```go
branchRestrictions, err := stashClient.GetBranchRestrictions("PROJ", "slug")
```

### DeleteBranchRestriction

```go
err := stashClient.DeleteBranchRestriction("PROJ", "slug", branchRestriction.Id)
```

### GetPullRequests

```go
// get all pull requests
pullRequests, err := stashClient.GetPullRequests("PROJ", "slug", "")

// get pull request by state
state := "OPEN"
pullRequests, err := stashClient.GetPullRequests("PROJ", "slug", state)
```

### CreatePullRequest

```go
title     := "A Title"
des       := "A Description"
from      := "feature/file1"
to        := "develop"
reviewers := []string{"bob", "bill"}

pullRequest, err := stashClient.CreatePullRequest("PROJ", "slug", title, desc, from, to, reviewers)
```

### GetRawFile

```go
filePath := "foo/bar"
branch   := "develop"

data, _ := stashClient.GetRawFile("PRJ", "slug", filePath, branch)

fmt.Println(string(data))
```

### stash

## Development

### Local stash instance

Download and run a development instance of stash via a
[docker image](https://www.docker.com/).

```bash
# pick a directory where to save the data generated by the container
export STASH_DATA="${HOME}/stash/data"

# for a linux host
$ docker run -u root -v $STASH_DATA:/var/atlassian/application-data/stash atlassian/stash chown -R daemon  /var/atlassian/application-data/stash

$ docker run -v $STASH_DATA:/var/atlassian/application-data/stash --name="stash" -d -p 7990:7990 -p 7999:7999 atlassian/stash

# for a MacOs Host via 'boot2docker'
$ docker run -u root -v $STASH_DATA:/var/atlassian/application-data/stash --name=stash -d -p 7990:7990 -p 7999:7999 atlassian/stash
```

Open your browser to `http://localhost:7990` and follow the setup instructions.

** If your are using boot2docker get your IP via `boot2docker ip`

repository: anthonydahanne/stash

repo_name: anthonydahanne/stash


text:
# waapi-python-tools

This repository is a collection of tools to be used inside Audiokinetic Wwise. The tools use WAAPI (Wwise Authoring API) and Python to perform several automated tasks.

## Requirements
* Python 3.6+
* Running instance of Wwise.exe with the Wwise Authoring API enabled (Project > User Preferences... > Enable Wwise Authoring API)
* waapi-client python project installed

## Setup

For compatibility with Python 2 on Windows, it is recommended to use the Python Launcher for Windows which is installed with Python 3 from python.org.

### Install Python 3.6

* Install Python 3.6 from: https://www.python.org/downloads/

### Install waapi-client

* **Windows**: `py -3 -m pip install waapi-client`
* **Other platforms**: `python3 -m pip install waapi-client`

Additional instructions can be found at:
https://pypi.org/project/waapi-client/

## Running the script

* **Windows**: `py -3 <tool-name>`
* **Other platforms**: `python3 <tool-name>`

Replace `<tool-name>` by the name of the folder you want to use.

## Setup a menu or command from Wwise

TBD...

repository: decasteljau/waapi-python-tools

repo_name: decasteljau/waapi-python-tools


text:
# Smart Commons
A nodejs package that monitors a series of sensors attached to a C.H.I.P. board and reports space usage to a database behind a REST API.

## Installation
To get the software up and running, connect to the C.H.I.P. via serial or ssh and run:

`cd`

`git clone https://github.com/VTUL/smart-commons.git`

`cd smart-commons`

`cp config.js.example config.js`

`nano config.js`

Change the values in the config.js file to match those for your project. You'll need urls where your database API is located and an API key (if you're using one); region name, a uuid, and major identifiers for your beacons; and a name for that module.

`npm install`

`sudo node index.js`

## Usage

This project requires creating one of the Smart Commons modules and connecting it to a C.H.I.P. controller. The wiring schematic for the module is provided below:

![module schematic](https://github.com/VTUL/smart-commons/raw/master/schematics/smart-commons-V1.1.png "Smart Commons Module Schematic")

## History
The Smart Commons started as a project in the Virginia Tech University Libraries. The aim is to add sensors to furniture around the spaces in order to collect anonymous usage data and ultimately improve user experience of the spaces.

## Credits
This project relies on the [Johnny-Five](http://johnny-five.io/) and [chip-io](https://github.com/sandeepmistry/node-chip-io) repositories.

## License
MIT

repository: VTUL/smart-commons

repo_name: VTUL/smart-commons


text:
# Attributary

Like `ActiveModel::Attributes` or `Virtus` but not. No dependencies.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'attributary'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install attributary

## Usage

```Ruby
class Character
  include Attributary::DSL
  include Attributary::Initializer

  attribute :age, :integer
  attribute :description, :string, :validate => :check_description
  attribute :gender, :string, :collection => ['male', 'female', 'other']

  # if you don't need to initialize anything yourself, you can omit this
  def initialize(name, options = {})
    @name = name
    attributary_attributes(options)
  end

  private

  def check_description
    description.length <= 1024
  end
end

character = Character.new("Tommy", :age => 16, :description => "Hi I am Tommy", :gender => 'male')
character.age # 16
character.description # Hi I am Tommy
character.gender # male

character.age = 18
character.age # 18
```

Lots more info on the [Wiki](https://github.com/joshmn/attributary/wiki)

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/joshmn/attributary

repository: zyamtorres/attributary

repo_name: zyamtorres/attributary


text:
---
layout: post
title: "Event Reminder: ARThouse 2015 - 26 June to 5 July 2015"
permalink: /archives/2015/06/event_reminder_arthouse_2015_26_june_to_5_july_201.html
commentfile: 2015-06-25-event_reminder_arthouse_2015_26_june_to_5_july_201
category: around_town
date: 2015-06-25 22:57:45
image: "/assets/images/2015/arthouse_2015_thumb.jpg"
excerpt: |
    Runs over the weekends of 26 to 28 June and 3 to 5 July 2015 all over Richmond Borough,

    ARThouse is a celebration of the wealth of creative talent that exists within the borough of Richmond upon Thames. Artists join together and exhibit their work across two summer weekends, providing visitors the chance to see the unique environment in which their art is created, celebrate local artists and buy work directly from the creator themselves.

---

[Runs over the weekends of 26 to 28 June and 3 to 5 July 2015 all over Richmond Borough,](/directory/art/201006031129)

ARThouse is a celebration of the wealth of creative talent that exists within the borough of Richmond upon Thames. Artists join together and exhibit their work across two summer weekends, providing visitors the chance to see the unique environment in which their art is created, celebrate local artists and buy work directly from the creator themselves.

ARThouse 2015 will be the borough's 20th open studios festival, coordinated by Richmond Arts Service. Over 500 local artists will welcome visitors over the festival weekends, exhibiting a wonderfully diverse range of artwork including painting and photography; stained glass and woodwork; sculpture and ceramics; to jewellery, bag design, furniture and upholstery!

repository: pmahnke/stmgrts

repo_name: pmahnke/stmgrts


text:
You don't need to do it manually before `serverless deploy`. Once the plugin is installed it will happen automatically. *The plugin works with Serverless Framework version 1.52 and above.*

### [dev.to: A better way of deploying Go services with Serverless Framework](https://dev.to/mthenw/a-better-way-of-deploying-go-services-with-serverless-framework-41c4)

![output](https://user-images.githubusercontent.com/455261/73918022-fb952e00-48c0-11ea-9120-a7f34ad1ae55.gif)

## Features

- Concurrent compilation happens across all CPU cores.
- Support for both `serverless deploy` and `serverless deploy function` commands.
- Support for `serverless invoke local` command.
- Additional command `serverless go build`.

## Install

1. Install the plugin

    ```
    npm i --save-dev serverless-go-plugin
    ```

1. Add it to your `serverless.yaml`

    ```
    plugins:
      - serverless-go-plugin
    ```

1. Replace every Go function's `handler` with `*.go` file path or a package path. E.g.

    ```
    functions:
      example:
        runtime: go1.x
        handler: functions/example/main.go # or just functions/example
    ```

## Configuration

Default values:

```
custom:
  go:
    baseDir: . # folder where go.mod file lives, if set `handler` property should be set relatively to that folder
    binDir: .bin # target folder for binary files
    cgo: 0 # CGO_ENABLED flag
    cmd: GOOS=linux go build -ldflags="-s -w"' # compile command
    monorepo: false # if enabled, builds function every directory (useful for monorepo where go.mod is managed by each function
```

## How does it work?

The plugin compiles every Go function defined in `serverless.yaml` into `.bin` directory. After that it internally changes `handler` so that the Serverless Framework will deploy the compiled file not the source file. The plugin compiles a function only if `runtime` (either on function or provider level) is set to Go (`go1.x`).

For every matched function it also overrides `package` parameter to

```
individually: true
exclude:
  - `./**`
include:
  - `<path to the compiled file and any files that you defined to be included>`
```

repository: syllogy/serverless-go-plugin

repo_name: syllogy/serverless-go-plugin