text:
# Symbols as WeakMap keys

Stage 1

**Coauthors/champions**:

- Robin Ricard (@rricard)
- Rick Button (@rickbutton)
- Daniel Ehrenberg (@littledan)

[Spec text](https://arai-a.github.io/ecma262-compare/?pr=2038)

---

This proposal aims to solve a problem space introduced by the [Record & Tuple Proposal][rtp]; how can we reference and access non-primitive values in a primitive?

tl;dr We see Symbols, dereferenced through WeakMaps, as the most reasonable way forward to reference Objects from Records and Tuples, given all the constraints raised in the discussion so far.

There are some open questions as to how this should they work exactly, and also valid ergonomics/ecosystem coordination issues, which we hope to resolve/validate in the course of the TC39 stage process. We'll start with an understanding of the problem space, including why Records and Tuples are a good first step without this feature. Then, we'll examine various possible solutions, with their pros and cons,

----

[Records & Tuples][rtp] can't contain objects, functions, or methods and will throw a `TypeError` when someone attempts to do it:

```js
const server = #{
    port: 8080,
    handler: function (req) { /* ... */ }, // TypeError!
};
```

This limitation exists because the one of the **key goals** of the [Record & Tuple Proposal][rtp]  is to have deep immutability guarantees and structural equality _by default_.

The userland solutions mentioned below provide multiple methods of side-stepping this limitation, and `Record and Tuple` is viable and useful without additional language support for boxing objects. This proposal attempts to describe solutions that complement the usage of these userland solutions with `Record and Tuple`, but is not a prerequisite to landing `Record and Tuple` in the language.

## Userland solutions

You can already escape the aforementioned constraints without additional language features.

Instead of directly storing objects in a record or tuple, you can instead store some application domain specific information that can be used somewhere else to perform the desired action. For example, instead of embedding an `execute` function in an object like this example:

```js
const object = {
    execute() {
        console.log("foo");
    },
};
object.execute();
```

You can instead store an `action` that gets consumed by another function when needed:
```js
const record = #{
    action: "foo",
};

function execute(record) {
    if (record.action === "foo") {
        console.log("foo");
    }
}

execute(record);
```

As another example, if you want to store an object containing primitives in a record, you can store the individual properties themselves instead with the spread operator:

Instead of:
```js
const object = { foo: "bar" };
const record = #{ object: object }; // TypeError
```

Try this:
```js
const object = { foo: "bar" };
const record = #{ object: #{ ...object } };
```

#### Centralizing references to objects

If you can't convert everything to primitives, Records and Tuples directly, then a separate mapping, implemented in JavaScript, could be used to explain how some primitives should be interpreted in terms of objects. You can think of this as generalizing the interpretation of the action strings above.

For example, a simple Array of references could be passed around, in parallel to a Record, and certain numbers in the Record could be treated as indices into that Array when needed.

```js
const server = (() => {
    const handlerRef = 0;
    function handler(req) { /* ... */ }
    const structure = #{
        port: 8080,
        handler: handlerRef,
    };
    const references = [];
    references[handlerRef] = handler;
    return {
        structure,
        references,
    };
})();
server.references[server.structure.handler]({ /* ... */ });
```

To access, explicit reference to the Array needs to be made. These references could be encapsulated in a bookkeeper class, to assist with dereferencing:

```js
class RefBookkeeper {
    #references = [];
    ref(obj) {
        const idx = this.#references.length;
        this.#references[idx] = obj;
        return idx;
    }
    deref(sym) { return this.#references[sym]; }
}

// Usage
const server = (() => {
    const references = new RefBookkeeper();
    const structure = #{
        port: 8080,
        handler: references.ref(function handler(req) { /* ... */ }),
    };
    return {
        structure,
        references,
    };
})();
server.references.deref(server.structure.handler)({ /* ... */ });
```

You might want to reuse the same `RefBookkeeper` object across multiple server instances, so you don't have as much to keep track of for each instance:

```js
globalThis.refs = new RefBookkeeper();

// Usage
const server = #{
    port: 8080,
    handler: refs.ref(function handler(req) { /* ... */ }),
};
refs.deref(server.handler)({ /* ... */ });
```

See also [a larger worked example](https://github.com/rricard/proposal-refcollection/issues/5#issuecomment-619104173) demonstrating the kinds of code patterns where you'd want to be able to use a RefBookkeeper across several functions.

However, this pattern would lead to some memory management issues: As the program runs, more and more things might get added to `refs`, the Array just gets longer and longer, and all of the entries in the Array have to be held in memory just in case someone calls `deref` to get them, even if no one is actually going to do that. But really, we should avoid referencing things that are no longer needed anymore, so the garbage collector can reclaim memory. There are two ways to do this:
- If we reuse one global `RefBookkeeper` everywhere, then we need to manually delete unused entries when we're done with them, with an extra `delete` method added to the class, allowing the index to be reused. (We can't use FinalizationRegistry for this, since Numbers are never really dead.)
- Otherwise, we could avoid using a global RefBookkeeper, and instead use smaller local ones, which we pass around in parallel to the Record/Tuple, as in the previous examples.

Both of these are a bit unfortunate; it would be nice if you didn't have to worry about deleting entries from `RefBookkeeper`, and if you didn't have to pass it around in parallel with Records and Tuples. Further, it's not really optimal ergonomics to have to call `refs.deref(idx)` all the time, and to have to remember which numbers serve as an index into the RefBookkeeper and which are just meant to be numbers.

# Boxing objects to place in Records and Tuples while avoiding bookeeping

Overall, with the patterns described above, Records and Tuples can work with JavaScript objects in a variety of ways, such that many different problems can be solved with them directly. We don't believe that any additions are *needed* to make Records and Tuples significantly useful. However, to improve ergonomics further, this proposal exists to discuss various mechanisms to make simple, flexible references to JavaScript objects.

### The `box` primitive type

This potential solution introduces a new primitive type called `box`. These primitives can be constructed with `Box(obj)`, and the object can be retrieved with `box.deref()`, which would return `obj`.

#### Examples

```js
const obj = { hello: "world" };
const box = Box(obj);
assert(typeof box === "box", "boxes are a new primitive type");
assert(obj !== box, "boxes are not their boxed object");
assert(obj.hello === box.deref().hello, "boxes can deref props");
assert(obj === box.deref(), "boxes can deref the full object");
```

```js
const server = #{
    port: 8080,
    handler: Box(function handler(req) { /* ... */ }),
};
server.handler.deref()({ /* ... */ });
```

#### Semantics

##### Boxing the same object gives the same box

```js
const obj = {};
const box1 = Box(obj);
const box2 = Box(obj);
assert(box1 === box2);
```

##### Boxes remove the need for bookkeeping

There's no need to pass around any kind of `RefBookkeeper` object; just call `.deref()` directly on the box that's in the Record or Tuple.

JS's built-in garbage collector understands boxes, so you don't have to worry about keeping track of a separate reference to the object, or nulling that reference out when it's no longer needed. As long as you can access a box, calling `.deref()` on the box will give you access to the object it was created with.

##### Edge case: Calling `.deref()` on a Box when passed to a separate global object (Realm)

When working in the context of multiple JS global objects (e.g., with a same-origin iframe, or the Node.js vm module), if a box is passed from one global object to another, then calling the `.deref()` method in the context of that other global object would lead to behavior as if the box is unrecognized (either returning `undefined` or throwing; bikeshedding welcome).

It's possible to get around this by passing `Box.prototype.deref()` to that other global object. This method "grants the right" to dereference boxes created in the context of that global object. In this way, different global objects are a little bit isolated from each other, when it comes to `Box`.

##### Formalization of Box semantics

Data model
- Each Box has an associated [[Id]]
- Each Realm has an associated weak mapping [[Id]] -> Boxed object

API
- Box(obj)
    - Create a new [[Id]], and write [[Id]] -> obj into the Realm's mapping
    - Return a Box value with an associated [[Id]]
- Box.prototype.deref
    - If this Realm's mapping contains an entry for this.[[Id]]
        - Return the associated object
    - Else, return undefined

###### Sharing and isolating with Boxes

`Box.prototype.deref` is the only way to get at that Realm's mapping of [[Id]] to objects. Two different Realms cannot see into each other's Boxes, unless one Realm gives the other Realm a reference to its `Box.prototype.deref` method. A Realm can pull off its `deref`, delete it, etc, to control access to the mapping.

If using membrane-based isolation within a Realm, `Box()` + `Box.prototype.deref` bypasses the membrane. To preserve the membrane, the feature must be disabled early, by
```js
delete Box.prototype.deref
```
Some committee members want all TC39 features to be available within a single (potentially frozen) Realm, membrane-isolated world. This goal makes the Box proposal inviable.

<details>
Our hope was that, the fact that object operations are used to access and call `Box.prototype.deref`, and this can be membrane-wrapped, would imply that the Box system would work great for membrane-based security--just run each membrane-enclosed piece of code in a separate Realm, and you can safely share Boxes, granting or denying access based on the access to the `Box` constructor or `deref` method.

However, in systems which want to use membrane-based isolation *within* the same Realm, the whole feature would have to be turned off. This is to prevent boxes from "piercing" through membranes: a box primitive could be passed from one side of the membrane to the other (the membrane has no chance to intervene since boxes are not objects), and then it can simply be dereferenced. This would constitute an unmediated cross-membrane communication channel, going against the goals of the membrane system.

All access to the contents of boxes goes through `Box.prototype.deref`. A Realm's `Box.prototype` is ambiently available within that Realm, since it's referenced from ToObject, as long as you have a box. Although it is possible to turn off this feature from JavaScript by removing that function, this seems unfortunate for two reasons:
- If the Realm is already deeply frozen, it's no longer possible to mutate `Box.prototype`
- It'd be unfortunate to lose the functionality!
</details>

### BoxMakers to avoid Realm-wide communication channels

> Boxmaker, boxmaker, plan me no plans.
>
> I’m in no rush. Maybe I’ve learned
>
> Playing with boxes a girl can get burned.
>
> -- [A musical](http://www.exelana.com/lyrics/MatchmakerMatchmaker.html), probably

Ultimately, what we want is, a way to construct and dereference boxes, without being attached to the Realm. It could be used something like this:

```js
const Box = new BoxMaker();

const obj = { hello: "world" };
const box = Box(obj);
assert(typeof box === "box", "boxes are a new primitive type");
assert(obj !== box, "boxes are not their boxed object");
assert(obj.hello === Box.deref(box).hello, "boxes can deref props");
assert(obj === Box.deref(box), "boxes can deref the full object");
```

```js
const server = #{
    port: 8080,
    handler: Box(function handler(req) { /* ... */ }),
};
Box.deref(server.handler)({ /* ... */ });
```

This is definitely a bit uglier--it's annoying to have to instantiate your own `Box` constructor, call out to it explicitly to call `deref` as opposed to using method chaining, and to coordinate all your code to use the same `Box`. Still, if you  reuse the same `Box` constructor across all your functions, they interact "for free" without any manual bookkeeping or passing around of auxiliary structures, as described with `RefBookkeeper` above.

The need for a `Box`/`BoxMaker` separation is a direct consequence of the goal to avoid membranes within the same Realm that can use this feature.

#### Another way to look at it: RefCollection

Our initial attempt to provide a solution for this problem space was [RefCollection](https://github.com/rricard/proposal-refcollection), which is basically the same as `BoxMaker`, except that it uses Symbols instead of Box primitives.

When you call the Symbol constructor, you get a new Symbol; ultimately it can serve just as well to reference the Object as a Box primitive does. The RefCollection API allocates the Symbol for you, just like `Box.ref` creates a box. They're quite similar, when it comes down to it!

RefCollection is a bit simpler since it doesn't create a new primitive type, just reusing what we have. However, it's not possible to polyfill RefCollection without something new in the language: we run into the exact problem described with RefBookkeeper above, where it can fill up with junk that's not relevant anymore, if the same RefCollection keeps getting reused. (Refer to [this example](https://github.com/rricard/proposal-refcollection/issues/5#issuecomment-619104173) to see how you might want to continue using a RefCollection over time.)

There was a bit of debate about the details of the API surface of RefCollection, e.g., as it would relate to reusable templates. This seems to point towards exposing a low-level primitive that could address these memory management issues, leaving JavaScript libraries and frameworks to develop the best API surface.

### `symbol` as `WeakMap` keys

We propose to make `WeakMap` accept `symbol` as keys. This would allow JavaScript libraries to implement their own RefCollection-like things which could be reusable (avoiding the need to pass around the mapping all over the place, using a single global one, and just passing around Records and Tuples) while not leaking memory over time.

```js
class RefBookkeeper {
    #references = new WeakMap();
    ref(obj) {
        // (Simplified; we may want to return an existing symbol if it's already there)
        const sym = Symbol();
        this.#references.set(sym, obj);
        return sym;
    }
    deref(sym) { return this.#references.get(sym); }
}
globalThis.refs = new RefBookkeeper();

// Usage
const server = #{
    port: 8080,
    handler: refs.ref(function handler(req) { /* ... */ }),
};
refs.deref(server.handler)({ /* ... */ });
```

See [earlier discussion](https://github.com/tc39/ecma262/issues/1194) on Symbols as WeakMap keys--it remains controversial and not currently supported.

Some questions to discuss about Symbols as WeakMap keys:
- Can registered symbols be used as WeakMap keys? Some TC39 delegates have argued strongly in either direction. We see both "allowing" and "disallowing" as acceptable options.
    - Allowing registered symbols doesn't seem so bad, since registered Symbols are analogous to Objects that are held alive for the lifetime of the Realm. In the context of a Realm that stays alive as long as there's JS running (e.g., on the Web, the Realm of a Worker), things like `Symbol.iterator` are analogous to primordials like `Object.prototype` and `Array.prototype`, and registered `Symbol.for()` symbols are analogous to properties of the global object, in terms of lifetime. Just because these will stay alive doesn't mean we disallow them as WeakMap keys.
    - Prohibiting registered symbols doesn't seem so bad, since it's already readily observable whether a Symbol is registered, and it's not very useful to include these as WeakMap keys. Therefore, it's hard to see what practical or consistency problems the prohibition would create, or why it would be surprising (if there's a meaningful error message).
- We could support Symbols in WeakRefs and FinalizationRegistry, or not. It's not clear what the use cases are, but it would seem consistent with adding them as WeakMap keys.

As starting points, we propose that all Symbols be allowed as WeakMap keys, WeakSet entries, and in WeakRefs and FinalizationRegistry.

## Summing up

We think that adding Symbols as WeakMap keys is a useful, minimal primitive enabling Records and Tuples to reference Objects while respecting the constraints imposed by the goal to support membrane-based isolation within a single Realm. At the same time, the userspace solutions seem sufficient for many/most use cases; we believe that Records and Tuples are very useful without any additional mechanism for referencing objects from primitives, and therefore makes sense to proceed with Records and Tuples independently of this proposal.

[rtp]: https://github.com/tc39/proposal-record-tuple
[rcp]: https://github.com/rricard/proposal-refcollection


text:
## ISS Pointer Requirements Sheet
Ben Andrews | Jared Dupont
CS 466 Course Project
2018-3-1

#### Overview
This is a purely entertainment project. The purpose it to point an indicator at the International Space Station (ISS).

#### Top Level Functional Description
When the device is powered on it will enter a startup phase where it will receive an IP address and find out its coordinates based off it. Then it will continually point at the International Space Station until power is cut or it is switched into calibration mode.  It should update every couple of seconds as the ISS moves quickly.
The device should be approximately 8-12 inches squared as to fit on a desktop

There will be a button or a switch to toggle modes. The primary mode will have the device point at the ISS. The secondary mode is a calibration mode where the device can be pointed North.

#### Top Level Non-functional Requirements
The software must fit on one Arduino Uno.

#### Detailed System Requirements
* Point at the ISS with ≈5° of accuracy
* Updates once every 1 to 5 seconds
* Self calibrate to find GPS position

#### Extensions and Stretch Goals
* Use a magnetometer to find North and calibrate automatically
* Display on LCD actual lat and long and status changes

license: Unlicense

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
1. Presentations from group 1, 2, 3 . 1.5 hours
2. Introduction of Data Analysis Final Project
  Data sets.
   Pro Publica police misconduct
   Wapo homicides
   Wapo police shootings

GROUP 1
* Great explainer
* Looked great overall, but problems on q 4

GROUP 2
* Great present

GROUP 3
* Great present

GROUPS

1.  Review what's due this week
  * No lab, therefore no in-class assignment
  * Concentrate on getting your work and presentations done.
  * Two readings this week.
2.  Review what's due next week.
  *  GROUPS 1, 2, and 3 next week
  *  REVIEW what's due.
3. Presentations.
  * Where your data request stands. Have you obtained the data? If not, why?
  * Tell us a brief story about a single part of the data acquisition process, and the lesson you learned from it that you think is worth sharing from the class.
4. Set up meetings for long term.

https://github.com/BuzzFeedNews/2020-06-leso-1033-transfers-since-ferguson/blob/master/data/all.xlsx

https://oversight.house.gov/sites/democrats.oversight.house.gov/files/USPS%20FY20Q2-FY21Q1TD%20Weekly%20Service%20Performance%20%E2%80%93%20First%20class%20mail%20Through%20Week%2010-10%20district.pdf

As part of a new investigative series, the Center for Public Integrity and Stateline have published a dataset of polling places during the 2012–18 US general elections for 30 states (and plan to add more states “in the coming weeks”). To assemble the dataset, reporters filed 1,200 records requests, and then converted the disparate files they received into standardized CSVs listing each polling place’s county, precinct, name, and address.	"https://publicintegrity.org/topics/politics/elections/ballotboxbarriers/
https://publicintegrity.org/
https://www.pewtrusts.org/en/research-and-analysis/blogs/stateline
https://github.com/PublicI/us-polling-places
https://publicintegrity.org/politics/elections/ballotboxbarriers/data-release-sheds-light-on-past-polling-place-changes"

On Friday, the Washington Post released several datasets and computer scripts from its Pulitzer Prize–winning series, “2°C: Beyond the Limit,” which examined how “extreme climate change has arrived in America.” The data files — derived from NOAA’s nClimDiv and nClimGrid climate datasets — contain the annual average temperatures and seasonal temperature changes for each state and county in the contiguous US.	"https://www.washingtonpost.com/climate-environment/2020/08/07/how-use-posts-climate-data-analysis/
https://github.com/washingtonpost/data-2C-beyond-the-limit-usa/
https://www.pulitzer.org/winners/staff-washington-post
https://www.washingtonpost.com/graphics/2019/national/climate-environment/climate-change-america/
https://data.nodc.noaa.gov/cgi-bin/iso?id=gov.noaa.ncdc:C00005
https://data.nodc.noaa.gov/cgi-bin/iso?id=gov.noaa.ncdc:C00332"

https://www.splcenter.org/20190201/whose-heritage-public-symbols-confederacy#Download%20the%20data

For several years, the Southern Poverty Law Center’s “Whose Heritage?” project has been gathering and mapping information on “public symbols of the Confederacy,” such as monuments, place names, official holidays, commemorative license plates, and municipal seals. For each of the 1,800+ entries, the project’s dataset indicates the type of monument/symbol, its location, sponsor, year dedicated, and (if applicable) year removed. [h/t Gita Jackson + Dan Brady]	"https://www.splcenter.org/
https://www.splcenter.org/data-projects/whose-heritage
https://www.splcenter.org/20190201/whose-heritage-public-symbols-confederacy
https://docs.google.com/spreadsheets/d/17ps4aqRyaIfpu7KdGsy2HRZaaQiXUfLrpUbaR9yS51E/edit"

The Foreign Service Act of 1980 requires US presidents to provide Congress a “report on the demonstrated competence” for each ambassadorial nominee. In 2014, the government began disclosing these records, which had long been held secret. But the government’s policy applied only to new nominees. Law professor Ryan Scoville, however, used the Freedom of Information Act to pry loose the rest — more than three decades of concise biographies — and, earlier this year, put them online, accompanied by a dataset that describes the nominees’ qualifications and political contributions. Related: “Unqualified Ambassadors,” Scoville’s Duke Law Journal article on the topic, and his summary in Lawfare. [h/t u/smurfyjenkins]	"https://www.state.gov/resources-bureau-of-human-resources/
https://ryanscoville.com/about/
https://ryanscoville.com/2019/02/13/certificates-of-competency-for-nominees-to-be-chiefs-of-mission-1980-2014/
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3333988
https://www.lawfareblog.com/troubling-trends-ambassadorial-appointments-1980-present"

license: MIT


text:
# Translatir

## Demo

![screenshot](screenshot.png)

Check out the [live demo](https://translatir.netlify.app/) (if it dosen't work, I have ran out of Azure credits)

## Requirements

- Node.js
- Yarn
- An Azure subscription

## Getting started

1. Install [Node.js](https://nodejs.org/en/)
2. Install yarn by running `npm install -g yarn`
3. Setup Microsoft Translator with [this quickstart guide](https://docs.microsoft.com/en-us/azure/cognitive-services/Translator/quickstart-translator?tabs=csharp)
4. Clone this repo using `git clone --depth=1 https://github.com/MaximilianHagelstam/translatir.git <YOUR_PROJECT_NAME>`
5. Move to the appropriate directory: `cd <YOUR_PROJECT_NAME>`.
6. Create a `.env` file in the root of your project and fill in as per `.env.example`.
7. Run `yarn install` to install dependencies.
8. Run `yarn build` to compile the example app.
9. Run `yarn start` to start the example app.

## License

This project is licensed under the terms of the [MIT](https://choosealicense.com/licenses/mit/) license.

repository: MaximilianHagelstam/translatir

branch_name: refs/heads/main

repo_name: MaximilianHagelstam/translatir


text:
[![Build Status](https://travis-ci.org/piranna/easy-coveralls.svg?branch=master)](https://travis-ci.org/piranna/easy-coveralls)
[![Coverage Status](https://coveralls.io/repos/github/piranna/easy-coveralls/badge.svg?branch=master)](https://coveralls.io/github/piranna/easy-coveralls?branch=master)

# easy-coveralls
Easily configure a npm module to generate and upload tests coverage statistics
to [Coveralls.io](https://coveralls.io/). This module is focused for projects
based on `mocha` as test library, pull-requests to add support for other testing
libraries are welcome.

And of course, it's executed against itself! :-D

## How to use `easy-coveralls` in 5 steps

1. be sure your tests are passing on your CI server and that you has enabled
   your project on [Coveralls.io](https://coveralls.io/).

2. add the `easy-coveralls` dependency to your project:
   ```sh
   npm install --save-dev easy-coveralls
   ```

3. add a script entry on your project `package.json` file for the test
   coverage:
   ```json
   {
     "scripts": {
       "coveralls": "easy-coveralls"
     }
   }
   ```

4. configure your CI server to exec `easy-coveralls`.
   * For `TravisCI` add to your project `.travis.yml` file:
   ```yaml
   after_script:
   - npm run coveralls
   ```
   * For `SemaphoreCI` just set `npm run coveralls` as a Post-Thread script.

5. there's no fifth step. Ta-Da! :-D

## Configuration options

Easy-coveralls will by default use the `main` entry in `package.json`or `index.js` in the project root to do coverage on. You can override this default by calling `easy-coveralls` with the `--main` or `-m` option:

`--main src/index.js` or `-m src/index.js`

The script entry used to detemine the command is by default `test`. You can override this by setting the `--script` or `-s` option.

`-s test:mocha`

The command executed is by default the `script['test']` entry of `package.json`. You can override this by setting the `--command` or `-c` option

`-c "junit test"`

Full config example:

`easy-coveralls -m src/index.js -s test:mocha`

You may even run coverage stats for different testing engines:

  ```json
   {
     "scripts": {
       "coveralls:mocha": "easy-coveralls -m src/index.js -s test:mocha",
       "coveralls:karma": "easy-coveralls -m src/index.js -s test:mocha"
     }
   }
  ```

## How it works

`easy-coveralls` internally do several tasks. First it creates an instrumented
version of your module or library and swap it with the original one. Later it
exec the tests as usual generating a `lcov` compatible report in the case your
tests works just by executing the `mocha` command and update the coverture
statistics to `Coveralls.io`, and finally it delete the instrumented library
and restore your original one. No less, no more.

license: ISC

repository: kristianmandrup/easy-coveralls

repo_name: kristianmandrup/easy-coveralls


text:
# flextest

A flexible test runner for JavaScript, highly inspired by [React Hooks](https://reactjs.org/docs/hooks-intro.html) for state management. Targeted at fundamental building parts of a test framework.

- tests are normal JavaScript files that can be run directly
- no built-in assertion library, but have pluggable support for assertions
- a modular design, which can be consumed by upper libraries
- a Hook-like syntax for declaring tranditional `before` and `after`

## Introduction

The library only introduces three functions, with which the all essential parts of a test library can be achieved.

### `test`

Use `test` to declare a test case.

```ts
test("a + b", () => {
  assert(1 + 2 === 3);
});
```

Test cases can be nested.

```ts
test("a + b", () => {
  assert(1 + 2 === 3);
  test("NaN", () => {
    assert(1 + NaN === NaN);
  });
  test("undefined", () => {
    assert(1 + undefined === undefined);
  });
});
```

### `hook`

Use hook to declare state to setup and teardown test environments. There are three main usages of `hook` function.

First, `hook` can be used as a simple setup function with return value.

```ts
const value = hook(() => {
  return 1;
});
// value === 1
```

As functions without returning value can be considered as returning `undefined`, `hook` in this way can also be used as a one-shot setup function.

Second, if a function returning another function is passed to `hook`, then the returned function will be considered as a teardown function.

```ts
hook(() => {
  console.log("setup");
  return () => {
    console.log("teardown");
  };
});
/*
 * This will output:
 * setup
 * teardown
 */
```

The setup part will run immediately, while teardown part will run after the surrounding test case finished.

Finally, the function may return `[value, teardown]` to combine the first part and the second part.

```ts
const value = hook(() => {
  console.log("setup");
  return [1, () => console.log("teardown")];
});
```

### `finish`

Waits for all async tests to complete, and generates report to the console. It can be directly called.

```ts
finish();
```

## License

The MIT License

    Copyright 2020 xfoxfu

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

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

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

repository: xfoxfu/flextest

gha_language: TypeScript

gha_license_id: MIT

repo_name: xfoxfu/flextest


text:
# Tic Tac Toe

This is a terminal based implementation of the popular Tic Tac Toe game.

### File Setup

Make sure t3.c, t3.h, and Makefile are all in
the same directory and all named appropriately. To compile,
type 'make' into the terminal, there should be no errors or warnings.
You can start the game by typing './t3' into the command line.

## Playing The Game

```
./t3
```

### Local Game

The goal is to get 3 across, 3 down, or 3 diagonal. If the board fills
up before that happens, then the game ends in a draw. The controls are pretty
simple, just type the number where you want to place your game piece that turn.
You will get to retry if your initial move is invalid.

### Nonlocal Game

I made this is as a way to learn sockets, so I plan on updating the game with
networking capabilities.

## Troubleshooting

Make sure the program is compiled and all files have their original
names (as listed above). If you are still having issues, feel free to
email me at<EMAIL_ADDRESS>Thanks for playing!


text:
shuttle-esb
===========

[Shuttle ESB Documentation](http://shuttle.github.io/shuttle-esb/)

[Have a look at our YouTube channel](http://www.youtube.com/user/shuttleservicebus)

getting started with the source
===============================

A free .NET open-source enterprise service bus.

Once you have downloaded the source you need to initialize your environment by executing the `initialize-environment.msbuild` file.

> Open a Visual Studio Command Prompt

> cd {extract-folder}\build\\{relevant-version}\

> msbuild initialize-environment.msbuild

You will be prompted for your sql data source.  If you wish to keep the default (.\sqlexpress) or you you would want to check this out later simply press enter.

This makes changes w.r.t. the paths in some pertinent files will also call an msbuild task for `complete-build.debug.msbuild` to build the debug development environment.

repository: jessezhao/shuttle-esb

repo_name: jessezhao/shuttle-esb


text:
# BotMan with Facebook Messenger

### Preparation

**Note:** Facebook Messenger requires a valid URL in order to set up webhooks. If you are using Laravel Valet, you can get an external URL for testing using the `valet share` command.

This URL needs to validate itself against Facebook. When you create the webhook on the Facebook developer website, you have to choose a unique
verify token, which you can check against in your verify controller.

BotMan comes with a method to simplify the verification process. Just place this line after the initialization:

```php
$botman->verifyServices('MY_SECRET_VERIFICATION_TOKEN');
```

To connect BotMan with your Facebook Messenger Bot, you first need to follow the [official quick start guide](https://developers.facebook.com/docs/messenger-platform/guides/quick-start) to create your Messenger Bot and retrieve an access token.

Once you have obtained the page access token, place it in your BotMan configuration.

If you want BotMan to automatically verify each incoming Facebook webhook, you can optionally place your app secret in the BotMan configuration array.

### Laravel

For Laravel, the page access token needs to be in your `config/services.php` file

```php
    'botman' => [
    	'facebook_token' => 'YOUR-FACEBOOK-PAGE-TOKEN-HERE',
    	'facebook_app_secret' => 'YOUR-FACEBOOK-APP-SECRET-HERE', // Optional - this is used to verify incoming API calls
    ],
```

### Generic

If you don't use Laravel, you can pass the page access token to the `BotManFactory` upon initialization.

```php
$botman = BotManFactory::create([
    'facebook_token' => 'YOUR-FACEBOOK-PAGE-TOKEN-HERE',
    'facebook_app_secret' => 'YOUR-FACEBOOK-APP-SECRET-HERE',
]);
```

And that's it - you can now use BotMan with your Facebook bot!

repository: sbilly/botman

repo_name: sbilly/botman


text:
# hangman-game

Repository of the first project of the Let's Code Data Science course whose objective is to develop a hangman game

## Main commands

### Install venv

```
# In src directory
python3 -m venv venv
```

### Activate venv

```
source venv/bin/activate
```

### Install dependencies

```
pip install -r requirements.txt
```


text:
# gopherlyzer-GoScout

Prototype implementation for our analysis described in [Trace-Based Run-time Analysis of Message-Passing Go Programs](https://www.home.hs-karlsruhe.de/~suma0002/publications/go-trace-based-run-time-analysis.pdf).

We support all of Go's message-passing features (details for our
treatment of buffered channels, select with default/timeout and
closing channels can be found in the appendix).
Our current prototype only supports the instrumentation of programs
consisting of a single file and reports the
set of alternative communications on the command line.

## Description

We consider the task of analyzing message-passing programs by observing their run-time behavior.
We introduce a purely library-based instrumentation method to trace communication events
during execution. A model of the dependencies among events can be constructed to identify  potential bugs.
Compared to the vector clock method, our approach is much simpler and
has in general a significant lower run-time overhead.
A further advantage is that we also trace events
that could not commit. Thus, we can infer more alternative communications.
This provides the user with additional information to identify potential bugs.
We have fully implemented our approach in the Go programming language
and provide a number of examples to substantiate our claims.

## How to use

Example:

### Instrumentation

cd traceInst

go run main -in ../Tests/newsReader.go -out ../Tests/newsReaderInst.go

Open newsReaderInst.go and add

import "../traceInst/tracer"

after the package declaration.

Add tracer.Start() at the beginning of the main function and tracer.Stop at the end.

### Run

Running the instrumented code with

go run newsReaderInst.go

will produce a trace.log file in the same folder.

### Verification

cd traceVerify

go run main.go -plain -trace ..\Tests\trace.log

The result could look like the following:

```diff
Alternatives for fun14,[(2(0),?,P,go-examples\newsReader.go:25)]
+        bloomberg32,[(2(0),!,P,go-examples\newsReader.go:12)]
Alternatives for bloomberg32,[(2(0),!,P,go-examples\newsReader.go:12)]
-        fun15,[(2(0),?,P,go-examples\newsReader.go:25)]
+        fun14,[(2(0),?,P,go-examples\newsReader.go:25)]
Alternatives for fun03,[(1(0),?,P,go-examples\newsReader.go:21)]
+        reuters20,[(1(0),!,P,go-examples\newsReader.go:7)]
Alternatives for reuters20,[(1(0),!,P,go-examples\newsReader.go:7)]
-        fun06,[(1(0),?,P,go-examples\newsReader.go:21)]
+        fun03,[(1(0),?,P,go-examples\newsReader.go:21)]
Alternatives for fun15,[(2(0),?,P,go-examples\newsReader.go:25)]
-        bloomberg32,[(2(0),!,P,go-examples\newsReader.go:12)]
Alternatives for fun06,[(1(0),?,P,go-examples\newsReader.go:21)]
-        reuters20,[(1(0),!,P,go-examples\newsReader.go:7)]
Alternatives for newsReader41,[(4(0),?,P,go-examples\newsReader.go:28)]
+        fun03,[(4(0),!,P,go-examples\newsReader.go:21)]
Alternatives for fun03,[(4(0),!,P,go-examples\newsReader.go:21)]
+        newsReader41,[(4(0),?,P,go-examples\newsReader.go:28)]
Alternatives for main,[(3(0),?,P,go-examples\newsReader.go:28)]
+        fun14,[(3(0),!,P,go-examples\newsReader.go:25)]
Alternatives for fun14,[(3(0),!,P,go-examples\newsReader.go:25)]
+        main,[(3(0),?,P,go-examples\newsReader.go:28)]
```

repository: KaiSta/gopherlyzer-GoScout

gha_language: Go

repo_name: KaiSta/gopherlyzer-GoScout


text:
# Change Log

Each change log are assumed to be accompanied by associated unit test and documentation updates.

## master

- removed requirement of needing nagInputElement controller to access model controller

## 0.6.0

- converted to using svg helper instead of nag-svg directive
- simplified match validator
- split input-element into 2 directive (input-element and input-element-validation)
- switched input validation to use ngMessages
- now requires angular 1.3+
- added .editorconfig file

## 0.5.0

- initial release with change log file

repository: nucleus-angular/form

repo_name: nucleus-angular/form


text:
# Group Meeting
There is a mandatory 1 hr group meeting that occurs approximately every two weeks. At group meeting, one of the group members will give a talk on their research. You will be placed on a rotating [schedule](https://sites.google.com/a/lbl.gov/perssongroup/group-meeting) that will have you present your work about every 1 year.

---

# Subgroup Meetings
Given our new additions and growth, we have decided to implement new subgroups, associated leaders, and members. Undergraduate students are welcome to join any subgroup they want, but be aware that subgroup meetings probably can't be moved around to fit undergraduate members' schedules.

The responsibility of subgroup leads is to find a slot where everyone can make bi-weekly meetings and send out calendar calls and reminders. The current subgroups are (leads are in bold):

** NOTE: These subgroup assignments are out of date. **

# Subgroups

Materials Project
> **Donny Winston**, Shyam Dwaraknath, Patrick Huck, John Dagdelen, David Mrdjenovich, Matthew Horton

Spectroscopy
> **Shyam Dwaraknath**, Handong Ling, Matthew McDermott

Materials Design (photocatalysts, magnetocalorics, piezoelectrics, TCOs, etc):
> **Joey Montoya**, Shyam Dwaraknath, Rachel Woods-Robinson, Matthew Horton, Jordan Burns, Handong Ling

Electrodes
> **Jimmy Shen**, Eric Sivonxay, Jianli Cheng, Ann Rutt, Jordan Burns, Matthew Horton

Synthesis
> **John Dagdelen**, Rebecca Stern, David Mrdjenovich, Matthew McDermott, Matthew Horton

Electrolytes
> **Trevor Seguin**, Julian Self, Tingzheng Hou, Sam Blau, Kara Fong

SEI
> **Sam Blau**, Julian Self, Tingzheng Hou, Trevor Seguin, Kara Fong

repository: kmu/handbook

repo_name: kmu/handbook


text:
# Paul's Reading Notes

## Code 201

### Class 4: HTML Links, CSS Layout, JS Functions

**Reading Material for the Assignment**
1. Duckett: HTML & CSS
- Chapter 4: Links (pages 74-93)
- Chapter 15: Layout (pages 358-404; focus on pages 358-404)
- - [HTML Chapter 15 Website](http://htmlandcssbook.com/code-samples/chapter-15/)
2. Duckett: JavaScript & jQuery
- Chapter 3: Functions, Methods, and Objects (first part: pages 86-99)
3. Article
- [6 Reasons for Pair Programming](https://www.codefellows.org/blog/6-reasons-for-pair-programming/)

#### Duckett: HTML & CSS

##### Chapter 4: Links (pages 74-93)
Links are a defining feature of HTML and now websites in general.  Links can go to other websites, help the user navigate to other pages of the current website, autoscroll to a position on the current website, and open an email to send.  Links URLs can be given as a relative link if it is in close proximity within the website's directory.

*Link Syntax*
'titleToShowReader'

#### Chapter 15: Layout (pages 358-404; focus on pages 358-404)
Websites can be viewed on a variety of devices and a large range of screen sizes.  All of this must be considered when designing a webpage and establishing its layout.  *Liquid layouts* improve the attractiveness of a webpage by adjusting the layout to the screen, unlike *fixed width layouts*.

*Positioning Schemes*
- Normal Flow
- Relative Positioning
- Absolute Positioning

*Box Offset*
- Fixed Positioning
- Floating Elements

#### Duckett: JavaScript & jQuery

##### Chapter 3: Functions, Methods, and Objects (first part: pages 86-99)
**Functions** are a code block consisting of related statemetns that have been grouped together because they have a common objective.  This code block is given a name so that it can be referenced elsewhere and used again.  Functions are usually made of code blocks that must be repeated frequently on a website.

Functions must be declared and then seperately called.  Syntax for this can be found on page 90 and 91.

Functions can accept a single input, multiple inputs, or no inputs to use within their code block.  Likewise, functions can output a single value, multiple values, or no values.  However, functions can only write to one variable.  Therefore, if you would like to get multiple values out of a funciton, you must use an array.

#### Article on Pair Programming
Website is currently down.

***References***
- [Website that accompanies the HTML Textbook regarding Chapter 15](http://htmlandcssbook.com/code-samples/chapter-15/)
- [6 Reasons for Pair Programming](https://www.codefellows.org/blog/6-reasons-for-pair-programming/)

[Return to Table of Contents for Paul's Reading Notes](https://paul-leonard.github.io/reading-notes/ "Go back to find more notes!")

---

Thank you for visiting my page of notes.  I hope they were helpful to you.  Please also check out [my GitHub portfolio page](https://github.com/paul-leonard "Paul's GitHub Portfolio").

repository: paul-leonard/reading-notes

repo_name: paul-leonard/reading-notes


text:
# go-github-actions

A collection of [GitHub Actions](https://github.com/features/actions) for use in [Golang](https://golang.org/) projects.

## Actions

### gofmt

Runs `gofmt` on files in the directory. Fails if any file is not properly formatted.

```hcl
action "gofmt" {
  uses    =<EMAIL_ADDRESS>  needs   = "previous-action"
  secrets = ["GITHUB_TOKEN"]

  env {
    GO_WORKING_DIR = "./path/to/go/files"
  }
}
```

To learn more about `gofmt`, visit the [official docs](https://golang.org/cmd/gofmt/).

### golint

Runs `golint` on files in the directory. Failes if any file fails lint checks.

```hcl
action "golint" {
  uses    =<EMAIL_ADDRESS>  needs   = "previous-action"
  secrets = ["GITHUB_TOKEN"]

  env {
    GO_WORKING_DIR = "./path/to/go/files"
    GO_LINT_PATHS  = "./pkg/... ./cmd/..."
  }
}
```

To learn more about `golint`, see the [golint repository](https://github.com/golang/lint/).

repository: leosunmo/go-github-actions

repo_name: leosunmo/go-github-actions


text:
# KatOS

Welcome to the KatOS repo, where build scripts for making core parts of KatOS are stored.
KatOS is a modern and lightweight operating system for server systems.

# Directory Structure
- Core - Core parts of the KatOS system
- Root - Basic rootfs for installed system.
- Installer - Build scripts for installer iso.
- Source - Packaged files used in KatOS.

# Building
- To build all parts of KatOS, type `./buildall.sh` in your terminal.
- To clean all binaries from your build directory, type `./clean.sh` in your terminal (reccomended when you are updating/modifying core components).

# Running
To run KatOS in a VM or on a PC, download the repo and build an iso file, or download a precompiled release from the releases page. Make sure that your system can meet the minimum requirements for KatOS, and that your chosen hardware can run Linux 4.x kernels properly. When installed, root:toor is the default login. Note that changing your password and possibly adding a non-administrator account is reccomended after installation.

# Minimum requirements
- Any x86_64 CPU
- 128 MB of RAM
- ~512 MB of storage space
- 64-bit EFI/UEFI motherboard (must be able to load startup.nsh)

# Recommended requirements
- AMD or Intel x86_64 CPU, running at 512MHz or higher.
- 256 MB of RAM
- 1GB of storage space
- 64-bit EFI/UEFI motherboard (must be able to load startup.nsh)

# More info
Have extra questions, or want to help contribute?
Join the KatOS Discord server at https://discord.gg/qsXJS6m for that and lots more!
If you would like to contact me directly, send an email to<EMAIL_ADDRESS>Replies to emails often take 2-7 days, so please use GitHub issues instead for bug reports.


text:
# Contributing to LokiDB

We would love for you to contribute to LokiDB and help make it even better than it is
today! As a contributor, here are the guidelines we would like you to follow:

 - [Code of Conduct](#coc)
 - [Question or Problem?](#question)
 - [Issues and Bugs](#issue)
 - [Feature Requests](#feature)
 - [Submission Guidelines](#submit)
 - [Coding Rules](#rules)
 - [Test LokiDB](#develop)

##  Code of Conduct
Help us keep LokiDB open and inclusive. Please read and follow our [Code of Conduct][coc].

##  Got a Question or Problem?

Please ask your questions tagged with `lokidb` at [Stack Overflow][stackoverflow].

If you would like to chat about the questions in real-time, you can reach out via [our gitter channel][gitter].

##  Found a Bug?
If you find a bug in the source code, you can help us by
[submitting an issue](#submit-issue) to our [GitHub Repository][github]. Even better, you can
[submit a Pull Request](#submit-pr) with a fix.

##  Missing a Feature?
You can *request* a new feature by [submitting an issue](#submit-issue) to our GitHub
Repository. If you would like to *implement* a new feature, please submit an issue with
a proposal for your work first, to be sure that we can use it.

##  Submission Guidelines

###  Submitting an Issue

Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.

We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. In order to reproduce bugs we will systematically ask you to provide a minimal reproduction scenario using http://plnkr.co. Having a live, reproducible scenario gives us wealth of important information without going back & forth to you with additional questions like:

- version of LokiDB used
- 3rd-party libraries and their versions
- and most importantly - a use-case that fails

A minimal reproduce scenario using http://plnkr.co/ allows us to quickly confirm a bug (or point out coding problem) as well as confirm that we are fixing the right problem. If plunker is not a suitable way to demonstrate the problem (for example for issues related to our npm packaging), please create a standalone git repository demonstrating the problem.

We will be insisting on a minimal reproduce scenario in order to save maintainers time and ultimately be able to fix more bugs. Interestingly, from our experience users often find coding problems themselves while preparing a minimal plunk. We understand that sometimes it might be hard to extract essentials bits of code from a larger code-base but we really need to isolate the problem before we can fix it.

Unfortunately we are not able to investigate / fix bugs without a minimal reproduction, so if we don't hear back from you we are going to close an issue that don't have enough info to be reproduced.

You can file new issues by filling out our [new issue form][new-issue].

###  Submitting a Pull Request (PR)
Before you submit your Pull Request (PR) consider the following guidelines:

* Search [GitHub][pulls] for an open or closed PR that relates to your submission. You don't want to duplicate effort.
* Create your patch, **including appropriate test cases**.
* Follow our [Coding Rules](#rules).
* Run the full LokiDB test suite, as described in the [developer documentation][dev-doc],
  and ensure that all tests pass.
* Commit your changes using a descriptive commit message that follows our
  [commit message conventions](#commit). Adherence to these conventions
  is necessary because release notes are automatically generated from these messages.
* In GitHub, send a pull request to `LokiDB:master`.
* If we suggest changes then:
  * Make the required updates.
  * Re-run the LokiDB test suites to ensure tests are still passing.

That's it! Thank you for your contribution!

##  Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you are working:

* All features or bug fixes **must be tested** by one or more specs (unit-tests).
* All public API methods **must be documented**. (Details TBC).
* We use a consistent code formatting. An automated formatter is available, see the [developer guideline][dev-doc].

##  Commit Message Guidelines

We have very precise rules over how our git commit messages can be formatted.  This leads to **more
readable messages** that are easy to follow when looking through the **project history**.  But also,
we use the git commit messages to **generate the LokiDB change log**.

### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
format that includes a **type**, a **scope** and a **subject**:

```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```

The **header** is mandatory and the **scope** of the header is optional.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on GitHub as well as in various git tools.

Footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.

Samples: (even more [samples][commits])

```
docs(changelog): update change log to beta.5
```
```
fix(release): need to depend on latest rxjs and zone.js

The version in our package.json gets copied to the one we publish, and users need the latest of these.
```

### Revert
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.

### Type
Must be one of the following:

* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* **docs**: Documentation only changes
* **feat**: A new feature
* **fix**: A bug fix
* **perf**: A code change that improves performance
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* **test**: Adding missing tests or correcting existing tests

### Scope
The scope should be the name of the npm package affected (as perceived by person reading changelog generated from commit messages.

The following is the list of supported scopes:

* **loki**: The LokiDB database.
* **partitioning-adapter**: The partitioning adapter.
* **local-storage**: The local storage adapter.
* **indexed-storage**: The indexed db storage adapter.
* **fs-storage**: The file system storage adapter.
* **memory-storage**: The in-memory storage adapter.
* **full-text-search**: The full-text search engine.
* **full-text-search-language**: The language analyzer utility package.
* **full-text-search-language-de**: The german language analyzer.
* **full-text-search-language-en**: The english language analyzer.

There are currently a few exceptions to the "use package name" rule:

* **packaging**: used for changes that change the npm package layout in all of our packages, e.g. public path changes, package.json changes done to all packages, d.ts file/format changes, changes to bundles, etc.
* none/empty string: useful for `style`, `test` and `refactor` changes that are done across all packages (e.g. `style: add missing semicolons`)

### Subject
The subject contains succinct description of the change:

* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end

### Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
The body should include the motivation for the change and contrast this with previous behavior.

### Footer
The footer should contain any information about **Breaking Changes** and is also the place to
reference GitHub issues that this commit **Closes**.

**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.

[coc]: https://github.com/LokiJS-Forge/LokiDB/blob/master/CODE_OF_CONDUCT.md
[dev-doc]: https://github.com/LokiJS-Forge/LokiDB/blob/master/DEVELOPER.md
[github]: https://github.com/LokiJS-Forge/LokiDB
[new-issue]: https://github.com/LokiJS-Forge/LokiDB/issues/new
[pulls]: https://github.com/LokiJS-Forge/LokiDB/pulls
[commit]: https://github.com/LokiJS-Forge/LokiDB/commits/master
[gitter]: https://gitter.im/techfort/LokiDB
[plunker]: http://plnkr.co/edit
[stackoverflow]: http://stackoverflow.com/questions/tagged/lokidb?sort=newest

repository: LokiJS-Forge/LokiDB

gha_license_id: NOASSERTION

repo_name: LokiJS-Forge/LokiDB


text:
# Bookmarks

Blazor Wasm app to manage bookmarks centrally.
App hosted as static web site in Azure Blobstorage and bookmarks fed from Azure Functions.

https://pmario71.github.io/Bookmarks/

## Build Status
![.NET Core](https://github.com/pmario71/Bookmarks/workflows/.NET%20Core/badge.svg)

## Next Steps

### Publish to Gitub Pages

* Use example
  https://github.com/fernandreu/blazor-pages

## Libraries used

* https://www.matblazor.com/
* bootstrap


text:
shopping-cart
=============

![CI Status](https://github.com/gvolpe/pfps-shopping-cart/workflows/Build/badge.svg)
[![MergifyStatus](https://img.shields.io/endpoint.svg?url=https://gh.mergify.io/badges/gvolpe/pfps-shopping-cart&style=flat)](https://mergify.io)
[![Scala Steward badge](https://img.shields.io/badge/Scala_Steward-helping-brightgreen.svg?style=flat&logo=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAQCAMAAAARSr4IAAAAVFBMVEUAAACHjojlOy5NWlrKzcYRKjGFjIbp293YycuLa3pYY2LSqql4f3pCUFTgSjNodYRmcXUsPD/NTTbjRS+2jomhgnzNc223cGvZS0HaSD0XLjbaSjElhIr+AAAAAXRSTlMAQObYZgAAAHlJREFUCNdNyosOwyAIhWHAQS1Vt7a77/3fcxxdmv0xwmckutAR1nkm4ggbyEcg/wWmlGLDAA3oL50xi6fk5ffZ3E2E3QfZDCcCN2YtbEWZt+Drc6u6rlqv7Uk0LdKqqr5rk2UCRXOk0vmQKGfc94nOJyQjouF9H/wCc9gECEYfONoAAAAASUVORK5CYII=)](https://scala-steward.org)

⚠ **IMPORTANT NOTICE** If you are reading the first edition of [Practical FP in Scala](https://leanpub.com/pfp-scala), go to the [master](https://github.com/gvolpe/pfps-shopping-cart/tree/master) branch. You're now on the `second-edition` branch, which is the new default. ⚠

## Components Overview

Here's an overview of the different components that make this application.

![components](./app.png)

- Both **Services** and **Authentication** are *algebras*. The latter are mainly dependencies for some of the services.
- Programs shows **Checkout**, the business logic that combines most of the services.
- Effects show our custom interfaces required implicitly.
- The lines connecting services to Redis and PostgreSQL show which ones access which storage.
- The HTTP layer shows the client and the different routes.
- At the very end, we have both the modules and the entry point to the application.

## Authentication Data

For didactic purposes, this is made available but in a real application **THIS SHOULD NEVER BE MADE PUBLIC**.

For Admin users, the following environment variables are needed:

- `SC_JWT_SECRET_KEY`
- `SC_JWT_CLAIM`
- `SC_ADMIN_USER_TOKEN`

For access token (manipulation of the shopping cart):

- `SC_ACCESS_TOKEN_SECRET_KEY`

For password encryption:

- `SC_PASSWORD_SALT`

See the files [docker-compose.yml](app/docker-compose.yml) or [.env](./.env) for more details.

### Generate your own auth data

In order to generate a valid JWT token, you need a *secret key*, which can be any String, and a *JWT Claim*, which can be any valid JSON. You can then generate a token, as shown below:

```scala
val claim = JwtClaim(
  """
    {"uuid": "6290c116-4153-11ea-b77f-2e728ce88125"}
  """
)

val secretKey = JwtSecretKey("any-secret")

val algo = JwtAlgorithm.HS256

val mkToken: IO[JwtToken] =
  jwtEncode[IO](claim, secretKey, algo)
```

In our case, our claim contains a UUID, which is used to identify the Admin Id. In practice, though, a JWT can be any valid JSON.

Take a look at the [TokenGenerator program](https://github.com/gvolpe/pfps-shopping-cart/tree/master/modules/core/src/main/scala/tokens/generator.scala) to learn more.

## Tests

To run Unit Tests:

```
sbt test
```

To run Integration Tests we need to run both `PostgreSQL` and `Redis`:

```
docker-compose up
sbt it:test
docker-compose down
```

### Access Redis & Postgres

We can interact with both servers directly using the following commands:

```
$ docker-compose exec Redis /usr/local/bin/redis-cli
$ docker-compose exec Postgres usr/local/bin/psql -d store -U postgres
```

## Build Docker image

```
sbt docker:publishLocal
```

Our image should now be built. We can check it by running the following command:

```
> docker images | grep shopping-cart
REPOSITORY                    TAG                 IMAGE ID            CREATED             SIZE
shopping-cart                 latest              646501a87362        2 seconds ago       138MB
```

To run our application using our Docker image, run the following command:

```
cd /app
docker-compose up
```

## Payments Client

The configured test payment client is a fake API that always returns 200 with a Payment Id. Users are encouraged to make modifications, e.g. return 409 with another Payment Id (you can create one [here](https://www.uuidgenerator.net/api/version1/1)) or any other HTTP status to see how our application handles the different cases.

This fake API can be modified at: [https://beeceptor.com/console/payments](https://beeceptor.com/console/payments)

## HTTP API Resources

If you use the [Insomnia](https://insomnia.rest/) REST Client, you can import the shopping cart resources using the [insomnia.json](insomnia.json) file.

## LICENSE

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this project except in compliance with
the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.

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

repository: gvolpe/pfps-shopping-cart

branch_name: refs/heads/second-edition

gha_language: Scala

repo_name: gvolpe/pfps-shopping-cart


text:
Aplikasi Indo News

Aplikasi pusat berita indonesia terlengkap akurat dan terpercaya, dari berita trending, entertain, olahraga, ataupun bisnis semua ada di aplikasi ini

* Version 1.0.0
* Android Target SDK Version 29
* Built with Kotlin 1.3.72
* Using MVVM pattern
* Fully using Android Jetpack Component

### Screenshot

### List Libraries Used in this Project
* [Coroutine](https://github.com/Kotlin/kotlinx.coroutines)
* [Hilt DI](https://dagger.dev/)
* [Paging 3](https://developer.android.com/topic/libraries/architecture/paging/v3-overview)
* [OkHttp](https://square.github.io/okhttp/)
* [Lottie](https://github.com/airbnb/lottie-android)
* [Glide](https://github.com/bumptech/glide)
* [Retrofit](https://github.com/square/retrofit)
* [SDP](https://github.com/intuit/sdp)
* [SSP](https://github.com/intuit/ssp)

## 👤  Contact me

Farhan Roy
  - Facebook: [farhansekargadung](https://web.facebook.com/farhansekargadung)
  - Github: [@farhan-roy](https://github.com/farhanroy)

## License
```
                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

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

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

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.
```

repository: farhanroy/Indo-News

repo_name: farhanroy/Indo-News


text:
# puppet-module-kernel

[![Build Status](https://travis-ci.org/treydock/puppet-module-kernel.png)](https://travis-ci.org/treydock/puppet-module-kernel)

####Table of Contents

1. [Overview](#overview)
2. [Usage - Configuration options](#usage)
3. [Reference - Parameter and detailed reference to all options](#reference)
4. [Limitations - OS compatibility, etc.](#limitations)
5. [Development - Guide for contributing to the module](#development)
6. [TODO](#todo)
7. [Additional Information](#additional-information)

## Overview

The kernel Puppet module allows for managing the kernel packages and the default GRUB kernel.

## Usage

### kernel

The default behavior of this module is to ensure the kernel package is present.

    class { 'kernel': }

This is an example of ensuring a specific version of the kernel is installed and set as the default in GRUB.

    class { 'kernel'
      version => '2.6.32-431.23.3.el6'
    }

## Reference

[http://treydock.github.io/puppet-module-kernel/](http://treydock.github.io/puppet-module-kernel/)

## Limitations

This module has been tested on:

* CentOS 6 x86_64

## Development

### Testing

Testing requires the following dependencies:

* rake
* bundler

Install gem dependencies

    bundle install

Run unit tests

    bundle exec rake test

If you have Vagrant >= 1.2.0 installed you can run system tests

    bundle exec rake beaker

## TODO

## Further Information

repository: treydock/puppet-module-kernel

gha_language: Ruby

repo_name: treydock/puppet-module-kernel


text:
# HopeBox - Bash Scripts

Use the following scripts to setup the system as a whole.  Each section can be setup individually.

* `functions.sh` - bash functions used by other scripts.
* `install.sh` - install required libraries and updates for the system.

repository: pagarba/hope-box

gha_language: C

repo_name: pagarba/hope-box


text:
# speccer - a CLI tool for specs
[HTML](http://rawgithub.com/metakeule/speccer/master/spec/spec.html)
[Text (Markdown)](http://rawgithub.com/metakeule/speccer/master/spec/spec.md)
[JSON](http://rawgithub.com/metakeule/speccer/master/spec/spec.json)

PARENT <http://rawgithub.com/metakeule/speclib/master/spec/spec.html>

PROJECT `speclib`
COMPANY `Know GmbH`

PERSONS

- `Marc René Arns<EMAIL_ADDRESS>(mra)

REQUESTED_BY

- mra

## OVERVIEW

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-11` ESTIMATEDHOURS `0`

[*speccer*](https://github.com/metakeule/speccer) is a CLI tool for dealing with specs.

It is a frontend to the [speclib](https://github.com/metakeule/speclib).

## SCENARIO 1 Create Specification

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Mike wants to create a specification. He gets a clean
starting point with `speccer`.

******

## SCENARIO 2 Add comments

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Mike receives comments for his specification.
He wants to add them without hassle.

******

## SCENARIO 3 See and update specification

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Mike wants to update his specification with is
editor.

******

## SCENARIO 4 Script

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Gill wants to change specifications with a script.

******

## SCENARIO 5 Import and export

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Gill wants to read import and export specifications
from different places.

******

## SCENARIO 6 View as HTML and markdown

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Sue wants to read the specifications in HTML and
be able to mail them as markdown.

******

## SCENARIO 7 Filter for documentation

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Peter wants to create a documentation from the spec and
wants the unneccessary informations to be filtered.

******

## SCENARIO 8 Filter for implementation

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Anne wants to implement parts of the specification.
She just wants to read the parts that are ready
to be implemented.

## NONGOAL 1 No GUI

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

To have a GUI would be a project on its own.
However such a project could also be external and be built upon speccer.

******

## NONGOAL 2 No Database

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

`speccer` will operate on plain text json files only.
There will be no way to have a database and search.
A database could however exchange data with `speccer`
via json files.

******

## NONGOAL 3 No versioning

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

`speccer` will not do any backups or have versions.
You are advised to use a version control system to save your
specs or make backups by a backup tool.

******

## NONGOAL 4 No editing

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

`speccer` will have any functionality of an editor.
You may however replace parts of the spec by exporting them
to your favourite editor and reimport them when you are finished.

******

## NONGOAL 5 No merging of specs

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

`speccer` won't provide any mechanism to merge specs.
Since you can export and import parts of the specs in
plain text or markdown, it is not hard to merge by hand.

******

## NONGOAL 6 No copying of specs

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

`speccer` won't help you copying specs, since you can simply
copy the json files yourself and then edit the copy.

******

## NONGOAL 7 No rights management

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

`speccer` won't have any rights management baked in.
You could manage the viewing and changing rights for
a single spec by the filesystem.

If you need finer control, you need to write a wrapper
around `speccer` or the `speclib`.

******

## NONGOAL 8 No multiple comments per author and paragraph

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

With `speclib` (and therefor `speccer` too),
a single author can only have one comment per paragraph.

We consider this a good thing, since it forces the spec
to be split up in several paragraphs if they get too many
comments. The spec will benefit from it.

Also it is possible to have comments of arbitrary length.

******

## NONGOAL 9 No 'threads'

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Again this is a decision by `speclib` and considered a good
thing. There should not be comments on comments and endless
discussions. Instead the comments should be directed to a
paragraph and decision should be made soon.

Then the different topics should seperate into the different
sections like 'UNDECIDED', 'CONTRADICTIONS', 'DEFINITIONS',
'FEATURES' etc. and there should be multiple paragraphs
which may each have their own state of consense and comments.

******

## NONGOAL 10 No order of comments

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Again this is a decision by `speclib`.
Since each author may just have one comment per paragraph,
there is no point in have an order for comments.

However their is an order of paragraphs and that could
be changed.

******

## NONGOAL 11 No text generation

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Since the specs format is based on json, it is very easy
and flexible to have own templates and copy them.

******

## NONGOAL 12 No PDF export

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

There are great tools to convert from HTML to PDF, like `wkhtmltopdf` and
also markdown to pdf converter like `pandoc`. Since `speccer` exports
to HTML and markdown you should be able to use these tools to generate
PDFs.

******

## NONGOAL 13 No Translations for SPECS

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

There is rudimentary support for translations of key words that
are automatically inserted via `speclib`.

If your language is not supported, it is very easy to translate
on your own. A simple bash-script will do. You only have to
replace the keys as they are in the translations folders.

You might also contribute your translations to the project.

However for the main text of the specs they should be translated
by creating a new spec of each language and telling the other
specs of the translation in the TRANSLATIONS section of the specs.

******

## NONGOAL 14 No time tracking

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Each paragraph has a field ESTIMATEDHOURS that could be used to
do basic scheduling.

An external tool could then collect the estimated hours and compare
them to the real time to drive conclusions about the schedule.

More time tracking functionality is not part of this project.

******

## NONGOAL 15 No shortcuts for commands or presets

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Some commands and options are hard to remember.
But instead of bake new options into `speccer` we
deliver an alias file you could use in your bash or zsh shell.

Have a look at it to see how easy you could do one on your own.
In the alias you could also set defaults for responsibles etc.

******

## NONGOAL 16 No translation of options

RESPONSIBLE `mra`
STATE `APPROVED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

In order to be able to associate the wordings of the options
to the corresponding keys in the json file and the untranslated
specs the options will not be translated.

## CONTRADICTION 1 Rights Management vs responsible

RESPONSIBLE `mra`
STATE `OBSOLET` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-11` ESTIMATEDHOURS `1`

Rights Management is a Non Goal but on the other hand we have
persons responsible for paragraphs.

If anyone may edit any paragraph, then the responsibility
must constantly change (and is worthless) or it is false.

> `mra`
>
> Yes the responsability should change often in order to request feedback.
> If multiple persons work on a spec, the spec is considered teamwork
> and the people should work together.
>
> Only one person is responsible for each paragraph at a single point in
> time. This could be enforced by external tools as well as rights management
> if necessary. Although with version control it should not be necessary.

## UNDECIDED 1 It is not really clear how the linefeed is

RESPONSIBLE `mra`
STATE `OBSOLET` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-11` ESTIMATEDHOURS `1`

exported in markdown and json.
See the linefeed paragraph

> `mra`
>
> No longer an issue. Every import and export replaces
> to `\n` only. Editors should be able to handle it,
> otherwise other tools would be needed to convert
> before editing.

## DEFINITION 1 All definitions of the `speclib` apply

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

******

## DEFINITION 2 -name

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

The parameter passed via `-name` is the name of a spec property (like
`TRANSLATIONS` with the command `property`) or the name of a paragraph
property (like `STATE` with the command `meta`).

******

## DEFINITION 3 -usage

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

The parameter passed via `-usage` is the name of a filter provided by
`speccer` for typical usage scenarios.

There are currently:

- **documentation** filters
  - PROPERTIES
  - META
  - COMMENTS
  - NONGOALS
  - CONTRADICTIONS
  - UNDECIDED
  - SPEC_END
  - RESOURCES
  - PLANNING
  - APPROVED
  - PARTLY_IMPLEMENTED
  - OBSOLET
- **approval** filters
  - META
  - COMMENTS
  - CONTRADICTIONS
  - UNDECIDED
  - SPEC_END
  - RESOURCES
  - PLANNING
  - OBSOLET
- **discussion** filters
  - OVERVIEW
  - APPROVED
  - PARTLY_IMPLEMENTED
  - OBSOLET
  - SPEC_END
- **implementation** filters
  - UNDECIDED
  - PLANNING
  - FULLY_IMPLEMENTED
  - OBSOLET

******

## DEFINITION 4 Current Spec

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-13` ESTIMATEDHOURS `1`

The current spec is the spec that is loaded from a special file
in the current directory (`pwd`).

If the `-language` option is set, the spec is loaded from the file
`spec_[language].json`, e.g.

    spec_en_US.json

Otherwise it is looking for any files matching the regular expression

    spec*.json

If there is just one file matching, the spec is loaded from this file.
Otherwise an error is thrown mentioning that the language option should
probably be set.

## FEATURE 1 create a new spec

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that should contain your spec and run

    speccer -cmd create

Creates a file `spec.json` in the current folder and exports it
as `spec.md` (Markdown) and `spec.html` (HTML).

If the `-language` parameter is set (to e.g. `en_US`) it creates
the following files instead:

- `spec_en_US.json`
- `spec_en_US.md`
- `spec_en_US.html`

Be aware that the new spec is not valid since there are missing
properties. You can validate a spec to see them:

    speccer -cmd validate

******

## FEATURE 2 validate a spec

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec and run

    speccer -cmd validate

It it returns nothing your spec is valid.

 The properties are
all written in high caps and defined in `speclib`.

******

## FEATURE 7 set property of spec

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec and run

    speccer -cmd property -name COMPANY -set acme

to set the `COMPANY` property to `acme`. The properties are
all written in high caps and defined in `speclib`.

******

## FEATURE 8 unset property of spec

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-12`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec and run

    speccer -cmd property -name PARENT -uset

to unset the `PARENT` property. Only the following properties can
be unset:

- REQUESTEDBY
- RELATED
- TRANSLATIONS
- SUPERSEDEDBY
- RESOURCES
- PARENT
- PERSONS

******

## FEATURE 9 add markdown text to a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec and write your text
into a file, let's say `new.md`.

Put the title of the paragraph in the first line
and the body in the next lines.
Then run

    speccer -cmd add -sec SCENARIO -resp 'Your Name' -set new.md

to add title and body to the SCENARIO sections.
The available sections are defined in the `speclib`.

******

## FEATURE 10 show list of paragraphs of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec and run

    speccer -cmd positions -sec SCENARIO

to see a list of all paragraphs of the SCENARIO section.
Each paragraph has the first line printed preceeded by
a number indicating the position of the paragraph inside
the section. This position can be used to print or change
the paragraph.

******

## FEATURE 11 show content of a paragraphs of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.
You will need to know the position of the paragraph
you want to see. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd text -sec SCENARIO -at 3

to see the text for the 3rd paragraph in the
SCENARIO section.

If you want to include comments and meta data, run

    speccer -cmd text -sec SCENARIO -at 3 -with-comments -with-meta

******

## FEATURE 12 change content of a paragraph of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.
You will need to know the position of the paragraph
you want to see. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd text -sec SCENARIO -at 3 > temp.md

to save the current text and comments for the 3rd paragraph in the
SCENARIO section to the file `temp.md`.

Now fire up your editor to change the content. Then run

    speccer -cmd text -sec SCENARIO -at 3 -set temp.md

to set the text of the 3rd paragraph in the SCENARIO section.

The comments and meta data (including the title) of the 3rd paragraph are not modified by this operation. So you may want to change them too.

******

## FEATURE 13 see, add and change comment to a paragraph of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.
You will need to know the position of the paragraph
you want to see. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd comment -sec SCENARIO -at 3

to see the current comments for the 3rd paragraph in the
SCENARIO section.

Now if the author of your comment already made a comment to
this paragraph and if you want to append to this old comment,
you first have to save the old one.

To do this, run

    speccer -cmd comment -sec SCENARIO -at 3 -author Jim > temp.md

to save the comment of `Jim` to the file `temp.md`. Then you can edit this
file. If you just want to remove the old comment or if there was no
comment you may simply start with an empty file `temp.md`.

After you edited the file, run

    speccer -cmd comment -sec SCENARIO -at 3 -author Jim -set temp.md

to set the comment of `Jim` on the 3rd paragraph of the SCENARIO section
to the content of the file `temp.md`.

******

## FEATURE 14 move a paragraph of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.
You will need to know the position of the paragraph
you want to move. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd move -sec SCENARIO -at 3 -to 1

to move the 3rd paragraph in the SCENARIO section to be the first.

******

## FEATURE 15 delete a paragraph of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.
You will need to know the position of the paragraph
you want to delete. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd rm -sec SCENARIO -at 3

to remove the 3rd paragraph in the SCENARIO section.

******

## FEATURE 16 see and change meta data of a paragraph of a section

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-12` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.
You will need to know the position of the paragraph
you want to see the meta data. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd meta -sec SCENARIO -at 3

to see all meta data of the 3rd paragraph in the SCENARIO section.

If you want to change a datum you will have to pass the name:

    speccer -cmd meta -sec SCENARIO -at 3 -name RESPONSIBLE -set Jim

******

## FEATURE 17 shortcuts

RESPONSIBLE `mra`
STATE `FULLY_IMPLEMENTED` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-13` ESTIMATEDHOURS `1`

To use the `bash` / `zsh` shortcuts, copy the `aliases.sh`
into your home directory

    cp aliases.sh ~/.speccer_aliases.sh

and write the following into your `.bashrc`

    . ~/.speccer_aliases.sh

Then you will have access to the following shortcuts
(in bold is an example input to put after the alias).

Each paragraph should hold its title inside its first line
and should end with a line containing `***`.

Then run

    speccer -cmd add-multi -sec SCENARIO -resp Jim -set new.md

to add multiple paragraphs to the SCENARIO section as defined in
`new.md` with all having the responsible set to Jim.

******

## FEATURE 19 setting multiple comments to a paragraph in one go

RESPONSIBLE `benny`
STATE `PLANNING` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-13` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.

Create a new file (e.g. `new.md`) and write the comments
into this file.

Each comment should hold its author inside the first line
and should end with a line containing `***`

You will need to know the position of the paragraph
you want to set the comments to. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd comment-multi -sec SCENARIO -at 3 -set new.md

to set multiple comments to the 3rd paragraph of the SCENARIO section as defined in `new.md`.

******

## FEATURE 20 packing multiple paragraphs to one single paragraph

RESPONSIBLE `benny`
STATE `PLANNING` LASTUPDATE `2013-11-13`
DEADLINE `2013-11-13` ESTIMATEDHOURS `1`

Go into a folder that contains your spec.

You will need to know the positions of the paragraph you want
to pack. Therefor you might want to first
print all positions of the section (here SCENARIO)
with

    speccer -cmd positions -sec SCENARIO

then you can run

    speccer -cmd pack -sec SCENARIO -packing '[3,4,5]' -resp Jim -title 'all together'

to pack the paragraphs no 3,4 and 5 of the SCENARIO section into a
new paragraph with the title 'all together' and the responsible 'Jim'.
The previous titles are inserted as subheadings and the previous paragraphs
are deleted.

# SPEC_END

repository: metakeule/speccer

repo_name: metakeule/speccer


text:
# Lastfm Archive [![Build Status](https://github.com/boonious/lastfm_archive/actions/workflows/elixir.yml/badge.svg)](https://github.com/boonious/lastfm_archive/actions/workflows/elixir.yml) [![Hex pm](http://img.shields.io/hexpm/v/lastfm_archive.svg?style=flat)](https://hex.pm/packages/lastfm_archive) [![Coverage Status](https://coveralls.io/repos/github/boonious/lastfm_archive/badge.svg)](https://coveralls.io/github/boonious/lastfm_archive?branch=master)

A tool for extracting and archiving Last.fm music listening data - [scrobbles](https://www.last.fm/about/trackmymusic).

**Note**: previous analytics features have been migrated to [coda](https://github.com/boonious/coda).
This includes the [on this day Livebook](https://github.com/boonious/coda#livebook-analytics).
Please check out [coda](https://github.com/boonious/coda) for more Last.fm listening data analytics
in the future.

## Usage

Download and create a file archive of Lastfm scrobble tracks via an [Elixir](https://elixir-lang.org)
application or [interactive Elixir](https://elixir-lang.org/getting-started/introduction.html#interactive-mode)
by invoking `iex -S mix` command line action while in software home directory.

```elixir
  # archive all data of a default user specified in configuration
  LastfmArchive.sync # subsequent calls download only latest scrobbles

  # archive all data of any Lastfm user
  # the data is stored in directory named after the user
  LastfmArchive.sync("a_lastfm_user")
```

You can also deploy and use the tool in [Livebook](https://livebook.dev), check out:
- [Guides for archiving and data transforms](#livebook-guides)

Scrobbles are downloaded via the Last.fm API and stored in the file archive on demand
and on a daily basis. The software has a built-in cache to remember
and resume from the previous downloads. It skips already downloaded scrobbles and
does not make further requests to the API.

The stored data is in a raw Last.fm `recenttracks` JSON format,
chunked into 200-track (max) `gzip` compressed pages and stored within directories
corresponding to the days when tracks were scrobbled. The file archive in a main
directory specified in configuration - see below.

### Transform into columnar storage formats
You can transform the file archive into other common storage formats such as CSV and
columnar data structure such as [Apache Parquet](https://parquet.apache.org).
These formats facilitate data interoperability, as well as
[OLAP](https://www.snowflake.com/guides/olap-vs-oltp), analytics use cases.

```elixir
# transform the file archive into columnar Apache Parquet files
LastfmArchive.transform("a_lastfm_user", format: :parquet)

# to columnar Apache Arrow IPC files
LastfmArchive.transform("a_lastfm_user", format: :ipc_stream)

# CSV format also available
LastfmArchive.transform("a_lastfm_user", format: :csv)
```

Available formats:
- CSV (tab-delimited)
- [Apache Arrow](https://arrow.apache.org) columnar format
- [Apache Parquet](https://parquet.apache.org) columnar format

See [`transform/2`](https://hexdocs.pm/lastfm_archive/LastfmArchive.html#transform/2).

### Read archive

The tool provides a [`read/2`](https://hexdocs.pm/lastfm_archive/LastfmArchive.html#read/2)
function for retrieving data from the archive. It mainly relies on
[Elixir Explorer](https://github.com/elixir-explorer/explorer) data frame mechanisms
to underpin further data i/o, manipulation, analytics and visualisation.

The function returns a lazy `t:Explorer.DataFrame.t/0`.

#### From raw data file archive

Scrobbles stored in the file archive can be read
with a `day` or `month` option:

```elixir
# read a single-day scrobbles for the configured default user
LastfmArchive.read(day: ~D[2022-12-31])

# read a single-month scrobbles for a user with an arbitrary day of a month
LastfmArchive.read("a_lastfm_user",  month: ~D[2022-12-01])
```

#### From columnar archive for analytics

More data can be loaded from existing columnar archive.
[`read/2`](https://hexdocs.pm/lastfm_archive/LastfmArchive.html#read/2) can be used to
return a single-year or all scrobbles, i.e. **the entire dataset**.
A `columns` option is available to retrieve only a column subset.

```elixir
# load all 2023 data from a Parquet archive
LastfmArchive.read("a_lastfm_user", format: :parquet, year: 2023)

# load all data from an Arrow IPC archive
LastfmArchive.read("a_lastfm_user", format: :ipc_stream)

# load data from specific columns
LastfmArchive.read("a_lastfm_user", format: :parquet, columns: [:id, :artist, :album])
```

See [`read/2`](https://hexdocs.pm/lastfm_archive/LastfmArchive.html#read/2).

## Livebook guides

`LastfmArchive` also provides the following [Livebook](https://livebook.dev) interactive and step-by-step guides:
  - [Creating a file archive](https://hexdocs.pm/lastfm_archive/archiving.html) guide for creating a local file archive consisting data fetched from the Last.fm API. It provides a heatmap and count visualisation for checking ongoing archiving status.

    [![Run in Livebook](https://livebook.dev/badge/v1/blue.svg)](https://livebook.dev/run?url=https%3A%2F%2Fraw.githubusercontent.com%2Fboonious%2Flastfm_archive%2Fmaster%2Flivebook%2Fguides%2Farchiving.livemd)

    ![archiving progress visualisation](assets/img/livebook_heatmap.png)
  - [Columnar data transforms](https://hexdocs.pm/lastfm_archive/transforming.html) guide for transforming the local file archive to columnar data formats (Arrow, Parquet). It demonstrates how `read/2` can be used to load single-year single-column data, as well as an entire dataset into data frame for various analytics.

    [![Run in Livebook](https://livebook.dev/badge/v1/blue.svg)](https://livebook.dev/run?url=https%3A%2F%2Fraw.githubusercontent.com%2Fboonious%2Flastfm_archive%2Fmaster%2Flivebook%2Fguides%2Ftransforming.livemd)

    ![unique tracks by artists analytics](assets/img/livebook_unique_tracks_analytics.png)

## Other usage
To load all transformed CSV data from the archive into Solr:

```elixir
  # define a Solr endpoint with %Hui.URL{} struct
  headers = [{"Content-type", "application/json"}]
  url = %Hui.URL{url: "http://localhost:8983/solr/lastfm_archive", handler: "update", headers: headers}

  LastfmArchive.load_archive("a_lastfm_user", url)
```

The function finds CSV files from the archive and send them to
Solr for ingestion one at a time. It uses `Hui` client to interact
with Solr and the `t:Hui.URL.t/0` struct for Solr endpoint specification.

## Requirement

This tool requires Elixir and Erlang, see [installation](https://elixir-lang.org/install.html) details
for various operating systems or [Livebook](https://livebook.dev).

## Installation

`lastfm_archive` is [available in Hex](https://hex.pm/packages/lastfm_archive),
the package can be installed by adding `lastfm_archive`
to your list of dependencies in `mix.exs`:

```elixir
  def deps do
    [
      {:lastfm_archive, "~> 1.0"}
    ]
  end
```

Documentation can be found at [https://hexdocs.pm/lastfm_archive](https://hexdocs.pm/lastfm_archive).

## Configuration
Add the following entries in your config - `config/config.exs`. For example,
the following specifies an Lastfm `user` and a main file location for
multiple user archives, `./lastfm_data/` relative to the software home directory.

You also need to specify an `lastfm_api_key` in the config, so that the application can
[access Lastfm API](https://www.last.fm/api/authentication).

```elixir
  config :lastfm_archive,
    user: "default_user", # the default user
    data_dir: "./lastfm_data/", # main directory for multiple archives
    lastfm_api_key: "api_key_provided_by_lastfm",
    per_page: 200, # 200 is max no. of tracks per call permitted by Lastfm API
    interval: 1000 # milliseconds between requests cf. Lastfm's max 5 reqs/s rate limit

  # optional: Solr endpoint for Lastfm data loading
  config :hui, :lastfm_archive,
    url: "http://localhost:8983/solr/lastfm_archive",
    handler: "update",
    headers: [{"Content-type", "application/json"}]

```

See [`sync/2`](https://hexdocs.pm/lastfm_archive/LastfmArchive.html#sync/2)
for other configurable archiving options, e.g. `interval`, `per_page`.

See [`Hui`](https://hexdocs.pm/hui/readme.html#content) for more details on Solr configuration.

An `api_key` must be configured to enable Lastfm API requests,
see [https://www.last.fm/api](https://www.last.fm/api) ("Get an API account").

gha_language: Elixir


text:
#Install to Project Repo
A Python script for easily installing libraries to an in-project Maven repository. It creates a repository in the root folder of the project complete with poms, checksums and metadata. It also outputs the appropriate dependencies xml to be inserted in your `pom` file.

##What it does
* When run in standard mode it looks for jars in the `lib` folder having name of Eclipse standard and ignores all files that don't match it. The Eclipse naming standard has the following format:

        groupId.artifactId[.source]_version[.SNAPSHOT].jar

* When run in interactive mode (`-i`) it asks you to choose from the possible variants of name resolution. In this mode you can parse files of different naming standards.

* When run with `-d` modifier it removes all successfully installed jars from the `lib` folder.

* After successful installation of all jars it prints out all according dependencies for your `pom`.

##Using

Just run it from the folder containing your lib folder.

After the script is complete copy-paste the generated dependencies xml to your `pom` under `dependencies` tag and add the following under the `repositories` tag:

    <repository>
      <id>project</id>
      <url>file://${project.basedir}/repo</url>
    </repository>

For more details please read [this StackOverflow answer](http://stackoverflow.com/a/7623805/485115).

* This version was updated to support apache libraries formats e.g. mysql-connector-java-5.1.22.jar.  The --help option describes in more detail.

repository: javadba/install-to-project-repo

repo_name: javadba/install-to-project-repo


text:
This document will give you an overview of the software.
There are guides on how to compile, configure and use the software from a general point of view.
Specific configuration options are documented in the repositories of the [individual plugins](../README.md#Plugins-for-CosmoScout-VR).

### General Information
* [Code of Conduct](code_of_conduct.md)
* [Changelog](changelog.md)
* [How to cite CosmoScout VR](citation.md)
* [Release Management](release-management.md)
* [Software Architecture](architecture.md)
* [Complete List of Dependencies](dependencies.md)

### Getting Started
* [Build Instructions](install.md)
* [Using CosmoScout VR](using.md)
* [Configuring CosmoScout VR](configuring.md)

### Next Steps
* [Contributing to the Project](contributing.md)

repository: bernstein/cosmoscout-vr

repo_name: bernstein/cosmoscout-vr


text:
## RackHD/OnRack Deployment Scripts

These scripts are to be used to deploy RackHD or OnRack onto a test 'stack'.
A 'stack' is a full test bed configuration that has a minimum of one server and one node.
Stacks are defined in the 'stack_config.json' file in the config directory.
Deployments must be run from a third party Ubuntu Linux test host with network access to the stack.

A stack deployment can come in several 'flavors':
- esxi: a stack conforming to the 'OnRack Reference Configuration' (server is a VM under ESXi)
- linux: a stack where the server is running under bare Linux
- docker: a stack where the server is running the Docker implementation

## Requirements and Setup

Python 2.7x is required for all FIT tests.
ESXi installation requires 'ovftool'.

Load the virtual environment on the Linux test host:

    virtualenv .venv
    source .venv/bin/activate
    pip install -r requirements.txt

## Wrapper scripts

Scripts starting with 'run_' are wrapper scripts which are used to sequence deployment steps.
Python 'nosetests' runs tests in alpha order which can be difficult to ensure proper sequencing of scripts.
A wrapper script can run scripts in sequence by calling them from numbered methods.
The installation and test suites are run from wrapper scripts.

Example for running RackHD installation:

    python run_tests.py -stack stack1 -test deploy/run_rackhd_installer.py


text:
# FTPGrab v4.0 to v4.1

Since the project has been renamed `ftpgrab`, some changes have to be made.

```shell
# Rename files and folders
mv /opt/ftp-sync/ /opt/ftpgrab
mv /var/log/ftp-sync/ /var/log/ftpgrab
mv /var/run/ftp-sync/ /var/run/ftpgrab
mv /opt/ftpgrab/ftp-sync.conf /opt/ftpgrab/ftpgrab.conf
mv /etc/init.d/ftp-sync /etc/init.d/ftpgrab

# Download the latest script and dist config
wget https://raw.github.com/crazy-max/ftpgrab/master/ftpgrab.sh -O /etc/init.d/ftpgrab --no-check-certificate
chmod +x /etc/init.d/ftpgrab
wget https://raw.github.com/crazy-max/ftpgrab/master/ftpgrab.conf -O /opt/ftpgrab/ftpgrab.conf --no-check-certificate
```

If you have a cron, do not forget to change the script's name :

```text
0 4 * * * cd /etc/init.d/ && ./ftpgrab seedbox.conf >/dev/null 2>&1
```

repository: crazy-max/ftpgrab

repo_name: crazy-max/ftpgrab