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

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

## [0.4.1] - 2021-07-30

### Added

- Added a `location` configuration option to the `render` method, which allows you to report the absolute URL where a snippet is being rendered.

### Fixed

- Fixed [#30](https://github.com/jahuty/jahuty-node/issues/30), where caching renders did not consider the content's version.

## 0.4.0 - 2021-04-30

### Added

- Added `preferLatest` flag to client and render methods. This option allows you to render a snippet's _latest_ content instead of the default _published_ content.

## 0.3.2 - 2021-04-23

### Fixed

- Fixed issue [#26](https://github.com/jahuty/jahuty-node/issues/26), where `render()` cached the `Promise`, not the `Render`.

## 0.3.1 - 2021-03-14

### Added

- Added support for zero and negative `ttl` values to disable cache.
- Added system tests for cached, parameterized, and tagged snippets.

### Fixed

- Fixed bad build in NPM because Jack forgot to build before release :(
- Fixed issue with the `allRenders()` method not sending query string parameters.

## 0.3.0 - 2021-03-13

- Fixed issue where the `render` method's `params` were not being json-encoded properly.
- Added support for caching. Supported cache implementations should implement a `get(key)` method, which returns a `Promise`, as well as a `set(key, value, ttl)` method. If no cache implementation argument is given, an in-memory cache will be used.
- Added collections via the `allRenders` method which retrieves a group of renders and caches them individually.

## 0.2.1 - 2021-02-27

- Change resources to accept and silently ignore unknown attributes returned by the API to permit API evolution.

## 0.2.0 - 2021-01-28

* Change from a static-based architecture (e.g., `Snippet.render(1)`) to an instance-based one (e.g., `jahuty.snippets.render(1)`) to make the library easier to develop, test, and use.
* Move web-based functionality to a separate repository to separate concerns.
* Change `.npmignore` to be a whitelist and reduce the files in the NPM package.
* Add [ESLint](https://eslint.org) static code analysis based on [AirBnb's JavaScript Style Guide](https://github.com/airbnb/javascript#table-of-contents).
* Add [Codecov](https://codecov.io/gh/jahuty/jahuty-node) code coverage analysis.

## 0.1.6 - 2020-11-02

* Update README with requirements, installation, usage, errors, and more.

## 0.1.5 - 2020-11-02

* Fix [#15](https://github.com/jahuty/jahuty-node/issues/15), fix `TypeError: (e.adapter || u.adapter) is not a function` error by targeting a node build.

## 0.1.4 - 2020-11-02

* Fix [#13](https://github.com/jahuty/jahuty-node/issues/13), stop swallowing exceptions during Axios request setup.

## 0.1.3 - 2020-09-26

* Fix [#11](https://github.com/jahuty/jahuty-node/issues/11), other classes than `Jahuty` not available.

## 0.1.2 - 2020-09-26

* Fix [#9](https://github.com/jahuty/jahuty-node/issues/9), `ReferenceError: window is not defined`.

## 0.1.1 - 2020-09-25

* Change webpack to output Jahuty as UMD, as advised by [authoring libraries](https://webpack.js.org/guides/author-libraries/#expose-the-library).
* Remove `dist` directory from git repository, as advised by [unpkg.com](https://unpkg.com).
* Add `pkg.modules` to enable Jahuty to be used as a ES2015 module.

## 0.1.0 - 2020-09-19

* Initial release.

repository: jahuty/jahuty-node

repo_name: jahuty/jahuty-node


text:
---
title: LitJSON v0.7.0 released
category: Release Notes
author: lbv
---

Version v0.7.0 of LitJSON has been released.

General changes and improvements:

* Simplified the building mechanism. Dropped the entire autotools
  infrastructure, and instead added a single Makefile to compile the project
  and run the tests with *GNU make*.

* Added `SkipNonMembers` property to `JsonReader`. When active, it allows to
  parse JSON data using `JsonMapper.ToObject<T>` and ignore any properties
  not available in the type `T`. Its default value is `true`.

* Started moving the documentation into Markdown format.

* Added a new section to the QuickStart Guide, regarding customisation of
  the library's behaviour.

Bug fixes:

* Convert `null` properties properly in `JsonData.ToJson`.

* Read nested arrays in `JsonMapper.ToObject` and `JsonMapper.ToObject<T>`
  correctly.

Contributors for this release:

  - [whoo24](https://github.com/whoo24)
  - Christopher Dummy

license: MIT

branch_name: refs/heads/develop

extension: md

gha_language: C#

gha_license_id: MIT

license_type: permissive


text:
# Mono code guidelines

This document is meant to capture guidelines for contributing code to
the [src/mono/mono/](../../src/mono/mono),
[src/native/public/mono](../../src/native/public/mono) areas of the
dotnet/runtime repo.

In general this guide does not apply to:

1. Shared native code in [src/native](../../src/native)
2. The Mono-specific C# code in [src/mono](../../src/mono) in System.Private.CoreLib or elsewhere

## Code style

Mono is written in C.

We follow the [Mono Coding guidelines](https://www.mono-project.com/community/contributing/coding-guidelines/) for the C code - in particular:

* tabs, not spaces
* space between a function name and the open parenthesis
* braces on the same line as `if`, `for`, `while` etc

## Naming

Mono reserves the following prefixes for symbols: `mono_`, `monovm_`, `m_`, `monoeg_` (used to remap [`eglib`](../../src/mono/mono/eglib)
functions which in source code have a `g_` prefix).

All non-`static` symbols should use one of these prefixes.  We generally use `mono_` for most
functions.  `m_` is used for some inline accessor functions and macros.  `g_` (`mono_eg_`) is used
for `eglib` functions.

Types in a single C file can use any name.  Types in a header should use a `Mono` (or sometimes
`mono_`) prefix.

Public API symbols and types *must* be prefixed.

For types Mono generally uses `typedef struct _MonoWhatever { ... } MonoWhatever`.  Opaque types may
define `typedef struct _MonoWhatever MonoWhatever` in a client header and define `struct
_MonoWhatever {...}` in an implementation header.  Occasionally we break `#include` cycles by adding
forward declarations for some types.

## Macros

Mono derives from an autotools-style project so we generally write `HOST_XYZ` for the machine on
which the runtime is executing (as opposed to the machine on which the runtime was compiled), and
`TARGET_XYZ` for the machine that will be targeted by the JIT and AOT compilers.  In the case of AOT
compilation host and target might be different: the host might be Windows, and the target might be
Browser WebAssembly, for example.

Macros generally use a `MONO_` prefix.  Macros in public API headers *must* use the prefix.

## Types

Prefer the standard C sized types `int32_t`, `intptr_t`, etc over the eglib types `gint32`, `gsize` etc.

One exception is `gboolean` is preferred over C `bool`.

There are actually three boolean types to keep in mind:

* `gboolean` used internally in the runtime
* `MonoBoolean` used as an interop type with C# bool in internal calls
* `mono_bool` used by the public C API - generally new code shouldn't use it except when adding a new public API function.

## Newer features of C11 and later

Mono is currently (2023) written in C11.

### Static asserts

Use `static_assert` liberally.  Include `<assert.h>`.  If you cannot include `<assert.h>` (for
example because it introduces conflicting symbols or macros), use `g_static_assert`.  Do not use
`_Static_assert` directly (see how `g_static_assert` is defined). Rationale: C23 deprecates
`_Static_assert`.

### Threads, locks, `call_once`

Due to mono's threading model and cooperative GC, using C threading and locking primitives directly
is not ok.  Prefer `MonoCoopMutex`, `MonoCoopCond` that have GC-aware locking/waiting operations.
If you need them, use `mono_mutex_t`, `mono_cond_t`, etc for cases where GC transitions are
prohibitively costly and you can guarantee that the lock will never be taken by a GC initiator or by
a mix of threads in GC cooperative and GC preemptive mode.

Using standard C threads and `call_once` in native library PInvokes outside the runtime is okay.

Using standard C mutexes and condition variables in native library PInvokes outside the runtime is
okay if the locks are not shared with the runtime internals.

### Thread locals

FIXME: no guidance yet

### Atomics

The C standard atomics are not guaranteed to be lock-free.  Use the mono `mono_atomic_` functions
(some of which may be implemented in terms of standard C atomics on some platforms).  We do not in
general want locking because it would not be GC aware and may deadlock the cooperative GC.

Using standard C atomics in native library PInvokes outside the runtime is okay provided the atomics
aren't also accessed inside the runtime internals.

### Generic operations

FIXME: no guidance for `_Generic` yet.

## Utility and platform abstraction functions

Mono generally tries to fill in POSIX-like abstractions on platforms that lack them (for example, Windows).
This is in contrast to the CoreCLR PAL which generally tries to add Windows API abstractions on top
of POSIX.

If an existing `eglib` utility function is available, it should be used.  New ones can be added.

Other platform specific code is in `src/mono/utils`

## Directory dependencies

For the code in `src/mono/mono`:

* `eglib` should not depend on other code from `src/mono`

* `utils` can depend on `eglib` and 3rd party code from `src/native/external`

* `sgen` depends on `eglib` and `utils`

* `metadata` depends on all of the above (but note that some Boehm-GC files in this directory should not depend on `sgen`)

* `mini` depends on all of the above

* `mini/interp` depends on all of the above

* `components` can use functions from all of the above provided they're marked with
  `MONO_COMPONENT_API`, see [../design/mono/components.md](../design/mono/components.md)

The main distinction between `metadata` and `utils` is that utils code should not assume that it is
part of an executing .NET runtime - anything that loads types, creates objects, etc does not belong
in utils but in metadata.

The `mini` directory contains execution engines.  If the execution engine has to provide some
functionality to `metadata` it generally does so by installing some callback that is invoked by
`metadata`.  For example, `mini` knows how to unwind exceptions and perform stack walks - while
`metadata` decides *when* to unwind or perform a stackwalk.  To coordinate, `metadata` exposes an
API to install hooks and `mini` provides the implementations.

## Error handling

New code should prefer to use the `MonoError` functions.

* A non-public-API function should take a `MonoError *` argument.
* In case of an error the function should call one of the `mono_error_set_` functions from [../../src/mono/mono/utils/mono-error-internals.h](../../src/mono/mono/utils/mono-error-internals.h)
* Inside the runtime check whether there was an error by calling `is_ok (error)`, `mono_error_assert_ok (error)`, `goto_if_nok` or `return_if_nok`/`return_val_if_nok`
* If there is an error and you're handling it, call `mono_error_cleanup (error)` to dispose of the resources.
* `MonoError*` is generally one-shot: after it's been cleaned up it needs to be re-inited with `mono_error_init_reuse`, but this is discouraged.
* Instead if you intend to deal with an error, use `ERROR_DECL (local_error)` then call the
  possibly-failing function and pass it `local_error`, then call `mono_error_assert_ok
  (local_error)` if it "can't fail" or `mono_error_cleanup (local_error)` if you want to ignore the
  failure.

## Managed Exceptions

New code should generally not deal with `MonoException*`, use `MonoError*` instead.

New code should avoid using `mono_error_set_pending_exception` - it affects a thread-local flag in
a way that is not obvious to the caller of your function and may trample existing in-flight
exceptions and make your code fail in unexpected ways.

There are two circumstances when you might need to call `mono_error_set_pending_exception`:

1. You're working with a public Mono API that sets a pending exception
2. You're implementing an icall, but can't use `HANDLES()` (see the [internal calls](#internal-calls) section below)

## Internal calls

Prefer P/Invokes or QCalls over internal calls.  That is, if your function only takes arguments that
are not managed objects, and does not need to interact with the runtime, it is better to define it
outside the runtime.

Internal calls generally have at least one argument that is a managed object, or may throw a managed exception.

Internal calls are declared in [`icall-def.h`](../../src/mono/mono/metadata/icall-def.h) See the comment in the header for details.

There are two styles of internal calls: `NOHANDLES` and `HANDLES`.  (This is a simplification as there
are also JIT internal calls added by the execution engines)

The difference is that `HANDLES` icalls receive references to managed objects wrapped in a handle
that attempts to keep the object alive for the duration of the internal call even if the thread
blocks or is suspended, while `NOHANDLES` functions don't.  Additionally `HANDLES` functions get a
`MonoError*` argument from the managed-to-native interop layer that will be converted to a managed
exception when the function returns.  `NOHANDLES` functions generally have to call
`mono_error_set_pending_exception` themselves.

## Suspend Safety

See [Cooperative Suspend at mono-project.com](https://www.mono-project.com/docs/advanced/runtime/docs/coop-suspend/) and the [mono thread state machine design document](../design/mono/mono-thread-state-machine.md)

In general runtime functions that may be called from the public Mono API should call
`MONO_ENTER_GC_UNSAFE`/`MONO_EXIT_GC_UNSAFE` if they call any other runtime API.  Internal calls are
already in GC Unsafe on entry, but QCalls and P/Invokes aren't.

When calling a blocking native API, wrap the call in `MONO_ENTER_GC_SAFE`/`MONO_EXIT_GC_SAFE`.

Prefer `mono_coop_` synchronization primitives (`MonoCoopMutex`, `MonoCoopCond`,
`MonoCoopSemaphore`, etc) over `mono_os_` primitives (`mono_mutex_t`, `mono_cond_t`).  The former
will automatically go into GC Safe mode before doing operations that may block.  The latter should
only be used for low-level leaf locks that may need to be shared with non-runtime code. You're
responsible for switching to GC Safe mode when doing blocking operations in that case.

## GC Memory Safety

We have explored many different policies on how to safely access managed memory from the runtime.  The existing code is not uniform.

This is the current policy (but check with a team member as this document may need to be updated):

1. It is never ok to access a managed object from GC Safe code.
2. Mono's GC scans the managed heap precisely.  Mono does not allow heap objects to contain pointers into the interior of other managed obejcts.
3. Mono's GC scans the native stack conservatively: any value that looks like a pointer into the GC
   heap, will cause the target object to be pinned and not collected.  Interior pointers from the
   stack into the middle of a managed object are allowed and will pin the object.

In general one of the following should be used to ensure that an object is kept alive, particularly
across a call back into managed from native, or across a call that may trigger a GC (effectively
nearly any runtime internal API, due to assembly loading potentially triggering managed callbacks):

* The object is pinned in managed code using `fixed` (common with strings) and the native code gets a `gunichar2*`
* a `ref` local is passed into native code and the native code gets a `MonoObject * volatile *` (the `volatile` is important)
* a `Span<T>` is passed into native code and the native code gets a `MonoSpanOfObjects*`
* an icall is declared with `HANDLES()` and a `MonoObjectHandle` (or a more specific type such as `MonoReflectionTypeHandle` is passed in).
* a GCHandle is passed in

Generally only functions on the boundary between managed and native should use one of the above
mechanisms (that is, it's enough that an object is pinned once). Callees can take a `MonoObject*`
argument and assume that it was pinned by the caller.

In cases where an object is created in native code, it should be kept alive:

1. By assigning into a `MonoObject * volatile *` (ie: use `out` or `ref` arguments in C#)
2. By creating a local handle using `MONO_HANDLE_NEW` or `MONO_HANDLE_PIN` (the function should then use `HANDLE_FUNCTION_ENTER`/`HANDLE_FUNCTION_RETURN` to set up and tear down a handle frame)
3. By creating a GCHandle
4. By assigning to a field of another managed object

In all cases, if there is any intervening internal API call or a call to managed code, the object
must be kept alive before the call using one of the above methods.

### Write barriers

When writing a managed object to a field of another managed object, use one of the
`mono_gc_wbarrier_` functions (for example, `mono_gc_wbarrier_generic_store`).  It is ok to call the write
barrier functions if the destination is not in the managed heap (in which case they will just do a normal write)

## Assertions

Mono code should use `g_assert`, `mono_error_assert_ok`, `g_assertf`, `g_assert_not_reached` etc.

Unlike CoreCLR, Mono assertions are always included in the runtime - both in Debug and in Release builds.

New code should try not to rely on the side-effects of assert conditions. (That is, one day we may want
to turn off assertions in Release builds.)

## Mono Public API

Mono maintains a public API for projects that embed the Mono runtime in order to provide the ability
to execute .NET code in the context of another application or framework.  The current Mono API is
`mono-2.0`.  We strive to maintain binary ABI and API stability for our embedders.

The public API headers are defined in
[`../../src/native/public/mono`](../../src/native/public/mono).  Great care should be taken when
modifying any of the functions declared in these headers.  In particular breaking the ABI by
removing these functions or changing their arguments is not allowed.  Semantic changes should be
avoided, or implemented in a way that is least disruptive to embedders (for example the runtime does
not support multiple appdomains anymore, but `mono_domain_get` continues to work).

### Hidden API functions

In practice certain functions have been tagged with `MONO_API` even if they are not declared in the
public headers.  These symbols have been used by projects that embed Mono despite not being in the
public headers.  They should be treated with the same care as the real public API.

### Unstable API functions

Functions declared in `mono-private-unstable.h` headers do not need to maintain API/ABI stability.
They are generally new APIs that have been added since .NET 5 but that have not been stabilized yet.

As a matter of courtesy, notify the .NET macios and .NET Android teams if changing the behavior of these functions.

### WASM

The WASM and WASI runtimes in [`src/mono/wasm/runtime`](../../src/mono/wasm/runtime) and
`src/mono/wasi` are effectively external API clients.  When possible they should use existing `MONO_API` functions.

As a matter of expedience, the wasm project has sometimes taken advantage of static linking by
adding declarations of internal Mono functions in `src/mono/wasm/runtime/driver.c` and directly
calling Mono internals.

In general new code should not do this.  When modifying existing code, mysterious WASM failures may
be attributed to symbol signature mismatches between WASM and the Mono runtime.

repository: dotnet/runtime

branch_name: refs/heads/main

repo_name: dotnet/runtime


text:
# Hockey India announces 33 players for Junior Men's National Coaching Camp

Published at: **2019-11-03T09:18:42+00:00**

Author: **Press Release**

Original: [SportsCafe](http://sportscafe.in/articles/hockey/2019/nov/03/hockey-india-announces-33-players-for-junior-mens-national-coaching-camp?utm_medium=rss)

        Hockey India has named a list 33 core probables list of players for the four-week National Coaching Camp that has been scheduled to take place at the Sports Authority of India, Bengaluru, from November 4. High Performance Director David John stated that the players needed to improve their passing.

New Delhi, 03 November 2019: Hockey India today named the 33 Core Probables list for the upcoming Indian Junior Men's National Coaching Camp scheduled to begin on Monday, 4 November 2019. Players will report at the Sports Authority of India, Bengaluru Campus for the four-week National Coaching Camp that concludes on 1 December 2019. The Indian Junior Men's Team put up a fantastic performance at the 9th Sultan of Johor Cup earlier this month, beating Malaysia, New Zealand and Australia in the competition. India finished runners-up after going down fighting against Great Britain in the Final.
The Core Probables list includes Goalkeepers Pawan, Prashant Kumar Chauhan and Sahil Kumar Nayak, Defenders Suman Beck, Pratap Lakra, Sanjay, Yashdeep Siwach, Mandeep Mor, Parampreet Singh, Dinachandra Singh Moirangthem, Nabin Kujur, Sharda Nand Tiwari, Niraj Kumar Waribam. The Midfielders called-up for the National Coaching Camp are Sukhman Singh, Gregory Xess, Ankit Pal, Akashdeep Singh Jr., Vishnu Kant Singh, Gopi Kumar Sonkar, Vishal Antil, Surya NM, Maninder Singh, and Rabichandra Singh Moirangthem.
Forwards Sudeep Chirmako, Rahul Kumar Rajbhar, Uttam Singh, S Karthi, Dilpreet Singh, Araijeet Singh Hundal, Amandeep Singh, Prabhjot Singh, Shivam Anand and Arshdeep Singh have also been asked to report for the National Coaching Camp.
The Indian Junior Men's Core Probable Group has been playing together for over a year now and they will certainly look to work on a few aspects of their game to become an even better side in the upcoming tournaments. "The Indian team played with a lot of heart at the 9th Sultan of Johor Cup. The players executed their plans well and showed a lot of discipline on the field. We were disappointed to finish runners-up, but this national coaching camp will give us a chance to focus on getting into good positions and creating goal-scoring opportunities. The group needs to improve on passing the ball and team coordination as well," said stated David John, High Performance Director, Hockey India.
CORE PROBABLES LIST:

        GOALKEEPERS

1 Pawan
2 Prashant Kumar Chauhan
3 Sahil Kumar Nayak

        DEFENDERS

4 Suman Beck
5 Pratap Lakra
6 Sanjay
7 Yashdeep Siwach
8 Mandeep Mor
9 Parampreet Singh
10 Dinachandra Singh Moirangthem
11 Nabin Kujur
12 Sharda Nand Tiwari
13 Niraj Kumar Waribam

        MID-FIELDERS

14 Sukhman Singh
15 Gregory Xess
16 Ankit Pal
17 Akashdeep Singh Jr.
18 Vishnu Kant Singh
19 Gopi Kumar Sonkar
20 Vishal Antil
21 Surya NM
22 Maninder Singh
23 Rabichandra Singh Moirangthem

        FORWARDS

24 Sudeep Chirmako
25 Rahul Kumar Rajbhar
26 Uttam Singh
27 S Karthi
28 Dilpreet Singh
29 Araijeet Singh Hundal
30 Amandeep Singh
31 Prabhjot Singh
32 Shivam Anand
33 Arshdeep Singh

license: Unlicense

repository: dsadlollioygjmzvcxv/tdc-exported

branch_name: refs/heads/master

repo_name: dsadlollioygjmzvcxv/tdc-exported


text:
---
id: how-to-build-shopware-extension-assets-faster
date: 2022-12-15T21:00:00
title: How to build your Shopware extension assets much faster
author: Shyim
author_title: Principal Software Engineer @ Shopware
author_url: https://github.com/shyim
author_image_url: https://avatars3.githubusercontent.com/u/6224096?s=460&u=18be3a2d46f07dd42fc2b6dee9b4b9b68bca28d2&v=4
tags: [shopware]
---

When you deliver your Shopware extension to a Shop owner, your extension must contain in `src/Resources/public` the build assets for the Administration and the Storefront.
We committed in the first plugins in [Frosh](https://github.com/FriendsOfShopware) all assets directly in Git.
But this led to annoying conflicts, or when you merged two pull requests at once, it didn't contain both changes.

So, for this reason, we removed the build files from all Git repositories again and used [shopware-cli](https://sw-cli.fos.gg) to build the files.

[shopware-cli](https://sw-cli.fos.gg) is a helper tool to manage your extensions locally and in your Shopware account or your project. Worth to check it out!

## Optimizing the current setup

So we call now on our cli `shopware-cli extension zip ~/my-extension`. What is now shopware-cli for us is doing:

- Determine using existing js files. Do we need to build Administration and or Storefront?
- Download Shopware (If no env `SHOPWARE_PROJECT_ROOT` exists)
- Install `node_modules` (other people also say the heaviest object in the universe)
- Run webpack

This process can take a while.
First, what we optimized is including all Shopware files in the Dockerfile and pointing using `SHOPWARE_PROJECT_ROOT` to a Shopware folder, not to download the repo always.

This change saves a little like 10 - 20 seconds, but let's try to optimize the bundling itself.

The Shopware Administration builds by default itself and the extensions. So [I added](https://github.com/shopware/platform/commit/bffa1d01b0bef7b6f792327d40b4603e68bf4662) for this an environment variable `SHOPWARE_ADMIN_BUILD_ONLY_EXTENSIONS` to produce only the extensions.

This change improves the build time from 2 minutes to 10 seconds.

So we went from like 6 minutes to 2 minutes (complete job). But still, I need to install a bunch of node_modules and need the Shopware source itself. So I looked more profoundly at what Webpack does to bundle our extension.

## What the Webpack in Administration does

The Webpack process in the Administration is using since Shopware <IP_ADDRESS>, a Webpack Multi Compiler.
The Multi Compiler itself isolates each entry, like your extension, to its Webpack instance. So when the Admin and your extension load the same file, it will be bundled into both files, and when the Admin changes something, your code does not break.

Additionally, the default Webpack config gives us stuff like:

- Sass compiling
- Typescript
- CSS
- Auto-copy files into our extension public folder

So when our extension is already isolated from the Administration itself, and we use anything from the `Shopware` global object, can we just use a different bundler?

## Combining ESBuild with shopware-cli

[ESBuild](https://esbuild.github.io/) is a fast bundler written in Go, and [shopware-cli](https://github.com/FriendsOfShopware/shopware-cli/) itself is also written in Go. So let's combine these tools to integrate them directly into shopware-cli instead of installing other stuff.

The result is that we can now enable esbuild with a config file `.shopware-extension.yml`

```yaml
build:
    zip:
        assets:
            enable_es_build_for_admin: true
            enable_es_build_for_storefront: true
```

This calls directly ESBuild in Go and copies the result to the location where Shopware expects it. As ESBuild is written in Pure Go, we don't need NodeJS. Only npm if we have a `package.json` in our extension to install additional packages.

So our build went from 2 minutes to 7 seconds. Most time, in this example, it takes composer and npm as the extension uses additional composer packages and npm packages.

![Compile Step](https://i.imgur.com/s4rBzX2.png)

The actual ESBuild took only 617ms. If you are interested how it works in detail, see [the following file](https://github.com/FriendsOfShopware/shopware-cli/blob/main/extension/asset_native.go).

### The differences between Webpack

In the Administration, when you want to add additional npm packages, you usually have to [adjust the webpack config](https://developer.shopware.com/docs/guides/plugins/plugins/plugin-fundamentals/using-npm-dependencies#adding-a-npm-package-to-the-administration-or-the-storefront). This variant of aliasing and forcing a specific folder does currently not work. ESBuild visits all parent's folders and looking into `node_modules`, so you don't need to create an alias for this method.

While in Administration, the build files are isolated. They are in the Storefront, not. [Some files](https://github.com/shopware/platform/blob/93283b9acef3ed1989dcba1565d289abd411d36a/src/Storefront/Resources/app/storefront/webpack.config.js#L251-L254) will always be loaded from the Shopware file itself.
The idea behind this is to generate the smallest possible file for the Storefront, but in some scenerios this can break as the hashes inside the file of Shopware changes.

As we execute ESBuild inside shopware-cli without sources, we have to build our Storefront JS isolated from the Storefront itself. But there is a rescue with a helper!

### Extracting Shopware Storefront components for Isolated build

Some classes, like the Plugin class, must have for Shopware Storefront development. To have them still accessible inside your extension, we published an npm package [shopware-storefront-sdk](https://github.com/FriendsOfShopware/shopware-storefront-sdk).

So instead of using regular files from the standard Storefront, we install this npm package to our extension and can still build plugins for the Storefront.

The idea is to provide only the nesscarry files and rely most time on Browser API directly. For example, instead of using [DomAccess helper](https://github.com/shopware/platform/blob/trunk/src/Storefront/Resources/app/storefront/src/helper/dom-access.helper.js), we just use document.querySelector

It also contains a [plugin.override](https://github.com/FriendsOfShopware/shopware-storefront-sdk/blob/main/src/plugin-system/plugin.override.ts) helper to allow multi-override methods of existing Storefront plugins. Basically, it's some kind of decoration of Symfony, so you don't have to extend and re-register it. The extends of the orginal class, adds the original also to your js bundle with Webpack.

Here is a small code snippet to illustrate what it can do:

```js
class BaseClass {
    public method() {
        return 'base';
    }
}

PluginOverride.overrideClass(BaseClass, {
    method() {
        return this.callParent('method', ...arguments) + '-override';
    }
})

PluginOverride.overrideClass(BaseClass, {
    method() {
        return this.callParent('method', ...arguments) + '-override2';
    }
})

const obj = new BaseClass();
expect(obj.method()).toBe('base-override-override2');
expect(obj.method()).toBe('base-override-override2');

// use override to override a registered class
PluginOverriede.override('CookiePermission', {
   ....
})
```

### Bonus Tip: ESBuild based Administration Watcher

The normal Administration Watcher has to compile the Administration and your extension to show you a result. The cli does support the Watching the extension, too, with ESBuild.

As the CLI is independent of Shopware, it doesn't have the JS/CSS files of the Administration. For this reason, we must pass a running Shopware Instance and our path to the plugin.

```bash
> shopware-cli extension admin-watch ~/my-plugin http://localhost
```

While the typical Administration Watcher needs 55 seconds to start, our ESBuild server starts within a second. It works by intercepting some API calls and injecting our Watcher JS additional to the normal Administration JS.

**HINT:** The target URL can also be a live shop so that you can develop/debug your extension code against the API and all other plugins.

When you change a JS file, the Administration reloads, but on SCSS changes, the CSS gets replaced without reloading.

### Conclusion

We went from 6 Minutes of building to 7 seconds using Isolated complete builds with ESBuild.
For me, it was worth investing time in digging into ESBuild to get rid of the Shopware source / node_modules while building my extension in the CI.

I can fully recommend anyone enabling ESBuild for the Administration in the shopware-cli config. It does not change a lot and works mainly without any changes.

The Storefront is a more significant change and needs the use of the SDK. The SDK is in the beginning. Let's evolve it together and decouple our plugins from the build Shopware version.

Don't hesitate to join the [Shopware Community Slack](https://slack.shopware.com) to the channel `#friendsofshopware` if you need help on this topic!

gha_language: HTML


text:
1. Connect the phone with USB cable to host running Android Studio
2. If there have been past issues, reset ADB server: adb kill-server
3. adb tcpip 5555
4. Find the phone IP address and check that it is ready for ADB: adb shell netcfg
5. adb connect xx.xx.xx.xx (such as <IP_ADDRESS>)
6. Disconnect the USB cable and start using wireless communication

repository: SwerveRoboticsTeams/SkyStone

branch_name: refs/heads/Teams

gha_language: Java

repo_name: SwerveRoboticsTeams/SkyStone


text:
# Cryptosense API Client

[![Build Status](https://travis-ci.com/cryptosense/api-client.svg?branch=master)](https://travis-ci.com/cryptosense/api-client)

## Usage

The Cryptosense API Client depends on libcurl.

### FAQ

#### How to find the ID of my project?

In the web interface, select your project by clicking it and copy the number after
`/projects/` in the URL.

#### How to upload to a local instance of Cryptosense Analyzer?

Use the `--api-base-url` parameter to point the CLI at your local instance.

If you are using self-signed certificates or a custom CA, you can provide a custom CA file
with the `--ca-file path/to/cabundle.pem` option.

#### HTTP Proxies

If you need to route your request through a proxy, set the `http_proxy` or `https_proxy`
environment variable to the URL of your proxy endpoint.

Note that, for now, the `--no-check-certificate` option has no effect on the checking of
the proxy certificate: it is always checked.

For more advanced configuration, please refer to the `curl` documentation.

## Development

* Install the binary client from source: `dune build @install && dune install`
* Run tests: `dune runtest`

## Release

* Create a tag:
  * `git tag --message 'Version 1.2.3' 1.2.3`
  * `git push --tags`
* Create a release on GitHub for the new tag.
* Run `./make_release.bash 1.2.3 .`
* Upload `cs-api-1.2.3.tar.gz` to the GitHub release.

repository: cryptosense/api-client

gha_language: OCaml

repo_name: cryptosense/api-client


text:
# protonenv
[![License](https://img.shields.io/badge/license-MIT-green)](https://opensource.org/licenses/MIT) [![Python](https://img.shields.io/badge/python-3.6-blue)](https://www.python.org/downloads/release/python-360/) [![Steam Proton](https://img.shields.io/badge/steam-proton-brightgreen?logo=steam)](https://github.com/ValveSoftware/Proton)

Simple Proton version and prefix management.

A simple tool to manage different Proton versions and prefixes through the command line. The interface is designed to be similar to virtualenv management tools for ease-of-use. This tool is geared for those who want to run Windows programs easily without bloating their system with Wine and its dependencies. Although Proton is usable from the Steam client, it's not convenient to use for most scenarios, especially when installations are required.

## Requirements

* Python >= 3.6
* Steam

## Installation
### PyPI (recommended)
```
pip install protonenv
```
### GitHub
#### Non-editable
```
pip install --upgrade git+https://github.com/rizkiarm/protonenv.git
```
You can upgrade the package by re-running the above command.
#### Editable
This option is recommended for development.

In the folder of your choosing, run the following command:
```
git clone https://github.com/rizkiarm/protonenv.git
cd protonenv/
pip install -e .
```
You can upgrade the package by running ``git pull`` from the ``protonenv`` folder.

## Usage
### Basic commands
```
protonenv versions
protonenv install {<version>,--list}
protonenv uninstall {<version>,<prefix>}
protonenv prefix <version> <prefix>
protonenv run <prefix> [command]
```
### Managing a prefix
```
protonenv default <prefix> --command <command> --flags <KEY1=VALUE1> [KEY2=VALUE2] ...
protonenv info <prefix>
protonenv directory <prefix> [--open]
```
The available flags (runtime config options) can be obtained from:
https://github.com/ValveSoftware/Proton#runtime-config-options
### More info
```
protonenv -h
protonenv -h {versions,install,uninstall,prefix,default,info,directory,run}
```

## Examples
### Basic example
Install Proton 5.0
```
protonenv install 5.0
```
An example of installing and running [INSIDE](https://en.wikipedia.org/wiki/Inside_(video_game)):
```
# Create a new prefix called "inside"
protonenv prefix 5.0 inside
# Run INSIDE's installer "Setup.exe" with prefix "inside"
protonenv run inside /path/to/INSIDE/Setup.exe
# Get the directory of drive C for prefix "inside"
DRIVE_C_DIR=$(protonenv directory inside | tail -1)
# Run INSIDE
PROTON_USE_WINED3D=1 protonenv run inside $DRIVE_C_DIR/path/to/INSIDE.exe
```
You can also set the flags and command as default for prefix "inside":
```
# Configure the default command and use wined3d environment variable by default
protonenv default inside --command $DRIVE_C_DIR/path/to/INSIDE.exe
protonenv default inside --flags PROTON_USE_WINED3D=1
# Run INSIDE
protonenv run inside
```
### Directly running a program
An example of running ``program.exe`` with Proton 5.0
```
protonenv run 5.0 /path/to/program.exe
```
This command will execute the program in a temporary prefix with the specified Proton version. This is ideal for a situation where you want to test a program or you simply don't want to retain the program configuration/files.
## Uninstallation
```
pip uninstall protonenv
rm -rf ~/.protonenv
```

repository: rizkiarm/protonenv

gha_language: Python

repo_name: rizkiarm/protonenv


text:
Build Status: [![mojito MyGet Build Status](https://www.myget.org/BuildSource/Badge/lemonade?identifier=69ce336f-efa7-4cea-894d-de9625199487)](https://www.myget.org/)

# Mojito
### Inverting Dependencies Since... 2016 ###

Mojito is another lightweight IoC framework.

You can get all you need to use Mojito from the nuget feeds at:

Mojito

repository: thesheps/mojito

repo_name: thesheps/mojito


text:
# Welcome to the Short Messages Web Api

This simple web API is designed for the course "Sicherheit von Netwerken und mobilen Applikationen"
on the University of Applied Sciences Technikum Wien.

You can reach the API at: [https://short-messages-web-api.azurewebsites.net](https://short-messages-web-api.azurewebsites.net)

Or you can view the API with Swagger: [https://short-messages-web-api.azurewebsites.net/swagger/](https://short-messages-web-api.azurewebsites.net/swagger)

## The API
The Web API provides two methods, get and post. A client can post one or
several ShortMessages via POST. Via GET he can access all his posted ShortMessages.
The API supports multiple clients with the consumer key.
When a client first posts a ShortMessage with a customer key and a customer secret, a single
list of ShortMessages is assigned to this client. Following ShortMessages with the same
combination of key and secret are added to the same list.

You can run sample request with postman:

[![Run in Postman](https://run.pstmn.io/button.svg)](https://app.getpostman.com/run-collection/0a26a4bf47d3c7eaa934)

In folder [/java](./java/)  You can find Java example classes for the use of this API with Retrofit and GSON.

### Get short messages for the consumer key
Returns [ShortMessages](./Models/ShortMessages.cs) for the passed `String consumerKey`

The url schema: `// GET api/ShortMessages/{consumerkey}`

### Post a new short message
You can post new short messages via this method. It expects a
[IncomingShortMessageModel](./Models/IncomingShortMessageModel.cs).
It returns the currently saved [ShortMessageModel](./Models/ShortMessageModel.cs).

The url schema: `// POST api/ShortMessages`

repository: philipphofmann/short-messages-web-api

repo_name: philipphofmann/short-messages-web-api


text:
# Prolog

Contains the available solutions in Prolog.

## Homework

| Number | Problem Description | Source Code        | SWISH             |
|--------|---------------------|--------------------|-------------------|
| 1      | [Hw1-LP1819][HW1]   | [Hw1-Prolog][HW1P] | [Hw1-SWISH][HW1S] |

[HW1]: https://github.com/wisn/programming-logic/blob/master/problems/Hw1-LP1819.pdf
[HW1P]: https://github.com/wisn/programming-logic/blob/master/prolog/homework/Hw1-Wisnu.pl
[HW1S]: http://swish.swi-prolog.org/?code=https://github.com/wisn/programming-logic/raw/master/prolog/homework/Hw1-Wisnu.pl&q=brother_in_law(james,hannah).

## Problem Set

| Number | Problem Description | Source Code        | SWISH             |
|--------|---------------------|--------------------|-------------------|
| 1      | [PS1-LP1819][PS1]   | [PS1-Prolog][PS1P] | [PS1-SWISH][PS1S] |
| 2      | [PS2-LP1819][PS2]   | [PS2-Prolog][PS2P] | [PS2-SWISH][PS2S] |
| 3      |                     |                    |                   |
| 4      | [PS4-LP1819][PS4]   | [PS4-Prolog][PS4P] | [PS4-SWISH][PS4S] |
| 5      | [PS5-LP1819][PS5]   | [PS5-Prolog][PS5P] | [PS5-SWISH][PS5S] |

[PS1]: https://github.com/wisn/programming-logic/blob/master/problems/PS1-LP1819.pdf
[PS1P]: https://github.com/wisn/programming-logic/blob/master/prolog/problem-sets/PS1-Wisnu.pl
[PS1S]: http://swish.swi-prolog.org/?code=https://github.com/wisn/programming-logic/raw/master/prolog/problem-sets/PS1-Wisnu.pl&q=married(anya,benjamin).
[PS2]: https://github.com/wisn/programming-logic/blob/master/problems/PS2-LP1819.pdf
[PS2P]: https://github.com/wisn/programming-logic/blob/master/prolog/problem-sets/PS2-Wisnu.pl
[PS2S]: http://swish.swi-prolog.org/?code=https://github.com/wisn/programming-logic/raw/master/prolog/problem-sets/PS2-Wisnu.pl&q=max3numbers(1,2,3).
[PS4]: https://github.com/wisn/programming-logic/blob/master/problems/PS1-LP1819.pdf
[PS4P]: https://github.com/wisn/programming-logic/blob/master/prolog/problem-sets/PS4-Wisnu.pl
[PS4S]: http://swish.swi-prolog.org/?code=https://github.com/wisn/programming-logic/raw/master/prolog/problem-sets/PS4-Wisnu.pl&q=addone([1,2,3,],L).
[PS5]: https://github.com/wisn/programming-logic/blob/master/problems/PS5-LP1819.pdf
[PS5P]: https://github.com/wisn/programming-logic/blob/master/prolog/problem-sets/PS5-Wisnu.pl
[PS5S]: http://swish.swi-prolog.org/?code=https://github.com/wisn/programming-logic/raw/master/prolog/problem-sets/PS5-Wisnu.pl&q=arithmetic([1,2,3]).

repository: wisn/programming-logic

repo_name: wisn/programming-logic


text:
# rollico
Rollico mission is to define a set of base styles on top of [normalizer](https://github.com/necolas/normalize.css)
to set default styles for project(s). It allows you to create opinionated
defaults, saving you from redefining those on every project. This becomes
particularly handy when creating react components, since you can import these
styles and only define the rules that override these ones inside the component.
Later you can import rollico in the app you will be using the components and
it will give you the same defaults.

It also allows you to define things like colors and sizes in just one place,
those are used to build rollico and are also available in other projects

You can build rollico and publish to npm and it will give you two files:
- **rollico.css** contains our default styles for standard html elements (also
  includes normalizer.css)
- **variables.js** extracted from rollico.css (or to be more exact from their
  source files) contains colors, spacing, typography... variables that we can
  reuse later in our components

We can later in our apps import 'rollico.css' and in our components just
variables.js, we can also use rollico.css during components development to see
which css attributes we need to override locally in a component.

## How to use:

1. Install rollico using yarn `yarn add @resmio/rollico` or `npm install @resmio/rollico`
2. To use the styles you have two options:

  A. If your are using css in javascript, import it in the Javascript entry point for your app or module `import @resmio/rollico`. This is
  the recommended way. 🤓

  B. You can put it in your html head using the path to your<EMAIL_ADDRESS>This can be tricky to find depending on your build process. We are planning to upload the css somewhere so you don't have to use npm or yarn to be able to get the benefits of rollico base styles.
3. To use the variables in your javascript you can do `import {colors} from '@resmio/rollico/dist'` then you can use it in the form `colors[colorName]`. You can look at the colors available [here](https://resmio.github.io/rollico/)

## How to build:
Rollico tries to be as simple as possible so you need to run
`yarn run build:css` yourself to generate the build.

 Add your changes to the staging area.
  2. Instead of doing `git commit` do `yarn run commit`
  3. Answer the questions on the terminal.
  4. `git push`
  5. Create the pull request on github
  6. After your branch is merged to master, the new version will be automatically published to [npmjs](https://www.npmjs.com/@resmio/rollico)

*About Normalizr version: Due to some [disagreements between maintainers](https://github.com/necolas/normalize.css/issues/664)
we are sticking to v5 until the waters are clear.*

repository: menor/rollico

repo_name: menor/rollico


text:
# BAMAZON

A terminal application which uses node js to establish a connection to a mysql database for a inventory mangagement system.

![animated gif showing start screen of app](demo.gif)

repository: sompaak/BAMAZON

repo_name: sompaak/BAMAZON


text:
---
title: pyhail
date: 2022-11-15
category: Projects
authors: bom
tags: project, devel
language: Python
---

# Python Hail Retrievals Package (pyhail)

## Quick description
This software provides Python functions for retrieving hail properties from weather radar data ingested via Py-ART. This includes the Maximum Estimated Size of Hail (MESH), Hail Accumulation (hAcc), Hail Differential Reflectivity (HDR) and the Hail Size Discrimination Algorithm (HSDA). MESH is implemented for both the Py-ART radar (ppi) and grid objects, and options are available for different fits of the SHI hail-size relationship. A notebook is provided to demonstrate how to call each retrieval.

![pyhail sample image](../images/pyhail_sample.png)

## Homepage
<https://github.com/joshua-wx/pyhail>

## Code Repository
<https://github.com/joshua-wx/pyhail>

## Software Documentation
<https://github.com/joshua-wx/pyhail>

## User group or forum page
N/A

## License model
MIT License

## Year of first release
2022

## Main programming laguage(s)
Python

## Supported platforms
Linux

## Type of software
API/Library

## Further details
For help see README.md file. For license see the LICENSE file

Installation
Make sure this directory is in your PYTHONPATH

Install Py-ART (<https://github.com/ARM-DOE/pyart>)

Install pyhail using pip

To use pyhail:
from pyhail import hdr, mesh_grid, mesh_ppi, hsda, hacc

Then you have access to the main() functions for each retreival

Obtaining the turbulence field for a volume can be as simple as:
import pyart
from pyhail import mesh_ppi
radar = pyart.io.read('YOUR_FILE_HERE')
meshppi_fields = mesh_ppi.main(radar, 'REFLECTIVITY_FIELD_NAME', levels=['0C_LEVEL', '-20C_LEVEL])
radar.add_field('mesh', meshppi_fields['mesh_mh2019_95'], replace_existing=True)

You will then have a field called 'mh2019_95' that can be plotted, analyzed, or saved to file like any other Py-ART radar field. The mesh field will use the default MESH formulation, mesh_mh2019_95, unless specified - see documentation for more details.

## References

- Hail Size Discrimination Algorithm - HSDA ([Ortega et al. 2016](https://journals.ametsoc.org/doi/10.1175/JAMC-D-15-0203.1))
- Hail Differential Reflectivity - HDR ([Depue et al. 2007](https://doi.org/10.1175/JAM2529.1))
- Maximum Expected Size of Hail - MESH witt1998 ([Witt et al. 1998](https://journals.ametsoc.org/doi/10.1175/1520-0434%281998%29013%3C0286%3AAEHDAF%3E2.0.CO%3B2))
- Maximum Expected Size of Hail - MESH mh2019_75/mh2019_95 ([Murillo and Homeyer 2019](https://journals.ametsoc.org/view/journals/apme/58/5/jamc-d-18-0247.1.xml))
- Accumulated Hail - hAcc ([Wallace et al. 2019](https://journals.ametsoc.org/view/journals/wefo/34/1/waf-d-18-0053_1.xml))


text:
## Info
This is a Garry's Mod addon that I've made a while ago. It simply defines playermodels to use in the "Trouble in Terrorist Town" gamemode.

## Features
- Random skin selection
- Add as many models as you want.
- Models automatically added to downloadlist.
- Models for detective and innocent/traitor roles.
- Configuration while Ingame (without restarting client/server and no there is no "ingame configuration menu")
- Support of all game hooks that the models stays anytime the same.

## Usage
When you fire up the addon the first time it will generate a new file.
You'll find it under 'garrysmod/data/ttt_custom_playermodels.txt' its written in JSON if you wanna now more about it then google it.

Example:
```
{
	"player1": "models/test/model.mdl",
	"player2": "models/test2/model2.mdl",
	"detective1": "models/test3/model3.mdl"
}
```

## See also
You can download the addon via the Steam Workshop
[Link](http://steamcommunity.com/sharedfiles/filedetails/?id=589400010)

Interactive editor [Link](https://tjark-kuehl.github.io/TTT-Custom-Playermodels/)

## License
[The MIT License](LICENSE).

repository: Tjark-Kuehl/TTT-Custom-Playermodels

gha_language: Lua

repo_name: Tjark-Kuehl/TTT-Custom-Playermodels


text:
# `glppl`

Translation of [`lppl`](https://davidrushingdewhurst.com/lppl/) probabilistic programs into directed graphical models.
Optionally, [transiation of graphical models](./generation/) into portable, memory-safe C99 code.

An `lppl` program to infer the posterior location and scale parameter of a normal distribution could look like this:
```cpp
double normal_model(record_t<Normal, Gamma>& r, double obs) {
    auto loc = sample(r, "loc", Normal(0.0, 1.0), rng);
    auto scale = sample(r, "scale", Gamma(1.0, 0.5), rng);
    return observe(r, "data", Normal(loc, scale), obs);
}
```
The `glppl` version of it looks like this:
```cpp
graph_node<Normal> normal_model(gr_pair<Normal, Gamma>& gr, double obs) {
    auto loc = sample_g<Normal>(gr, "loc", rng)(0.0, 1.0);
    auto scale = sample_g<Gamma>(gr, "scale", rng)(1.0, 0.5);
    return observe_g<Normal>(gr, "data", obs)(loc, scale);
}
```
In return for the miniscule amount of extra complexity, you get a graph data structure
suitable for static analysis, more specialized inference algorithms, and/or code generation.
You can still use any `glppl` program with `lppl` inference algorithms and queryers
by converting it to a pure sample-based program, e.g. `auto f = to_pp(g);`, where
`g` is a `glppl` program and `f` is an `lppl` program.

`glppl` is also useful for doing inference over open-universe probabilistic programs when you intend to deploy inferred models
for prediction or forecasting. Using `glppl`, you can infer the MLE, MAP, or full posterior over graph structures and choose one or
more of these structures to deploy. `glppl` contains *alpha* functionality to automatically translate your graph probabilistic program into
a bespoke memory-safe (zero dynamic allocation) C99 probabilistic graphical model library constructed from [`ccyan`](../ccyan/) primitives.

As always, read the [documentation](./docs/index.html), get the [source](https://gitlab.com/drdewhurst/lppl-graph), download [tagged versions](./distros/index.md).

## Install

You need to have a recent version of `lppl`. Running `setup.sh` from the directory into which you cloned
`glppl` will do the trick.

Copyright David Rushing Dewhurst, 2022 - present.


text:
# Proxy

This is a proxy base. What that means, is it's a small library to simplify making proxies.
An example is when building a microservice backend. The proxy can direct connections
to the correct places, adding in any authentication required.

There are a lot of reasons to use a system like this, and probably most of them
can be covered with Nginx. The purpose of this is to handle those situations
where that's not possible.

repository: whynotavailable/proxy

repo_name: whynotavailable/proxy


text:
---
title: 'Haudenosaunee Women’s Influence on The Women’s Rights Movement'
date: '2020-02-14'
tags: [writing, feminism, haudenosaunee, indigenous, matilda effect, womens suffrage]
permalink: /haudenosaunee-womens-influence-on-the-womens-rights-movement/

---
Join us March 9th at Ethical NYC for an evening with Gloria Steinem, Sally Roesch Wagner, Jeanne Shenandoah, & Gaeñ hia uh/Betty Lyons. This event features Indigenous women leaders and non-Native feminist activists highlighting the story of how the Haudenosaunee Confederacy served as the inspiration for early feminists. Speakers include the influential feminist author and activist Gloria Steinem. A fundraiser for the American Indian Law Alliance and the Matilda Joslyn Gage Foundation, the event launches the Gage Foundation’s “Matilda Effect Project”, writing women who have worked for peace and social justice back into history.

## OUR PANELISTS

*   Gloria Steinem, writer, lecturer, political activist, and feminist organizer.
*   Dr. Sally Roesch Wagner, Executive Director of the Matilda Joslyn Gage Foundation.
*   Jeanne Shenandoah, Onondaga Nation Eel Clan Traditional Medicine Keeper.
*   Gaeñ hia uh/Betty Lyons, Onondaga Nation, Snipe Clan, Executive Director of the American Indian Law Alliance.

### [EVENT DETAILS](https://www.matildaeffect.events/)

*   Date: March 9th, 2020
*   Time:
    *   VIP: 6:00-6:45PM
    *   Event: 7:00-9:00PM
*   Place: Ethical NYC, 2 West 64th Street New York, NY 10023
*   Tickets:
    *   [VIP $200](http://tickets.matildaeffect.events/)
    *   [Event & autographed copy of Sally Roesch Wagner's The Women's Suffrage Movement: $75](http://tickets.matildaeffect.events/)
    *   [Event: $50](http://tickets.matildaeffect.events/).

### SPONSORS

*   American Indian Law Alliance
*   American Indian Community House
*   Matilda Joslyn Gage Foundation

*   [➡ Visit Matilda Effect for more information](https://www.matildaeffect.events/).
*   [⬇ Download the event poster](/images/2020/02/Haudenosaunee-women-influence-web.jpg)

repository: adamdjbrett/aila-hylia

repo_name: adamdjbrett/aila-hylia


text:
## Optimizely Server Side

[![Code Climate](https://codeclimate.com/github/ankit8898/optimizely_config_provider/badges/gpa.svg)](https://codeclimate.com/github/ankit8898/optimizely_config_provider) [![Build Status](https://travis-ci.org/ankit8898/optimizely_server_side.svg?branch=master)](https://travis-ci.org/ankit8898/optimizely_server_side)
[![Gem Version](https://badge.fury.io/rb/optimizely_server_side.svg)](https://badge.fury.io/rb/optimizely_server_side)
[![Test Coverage](https://codeclimate.com/github/ankit8898/optimizely_config_provider/badges/coverage.svg)](https://codeclimate.com/github/ankit8898/optimizely_config_provider/coverage)

### What is Optimizely Server Side ?

This is a wrapper on top of [Optimizely's](https://app.optimizely.com/projects) ruby sdk called [optimizely-sdk](https://github.com/optimizely/ruby-sdk) . The sdk specializes in server side setup of A/B test . You can read more about it [here](http://developers.optimizely.com/server/introduction/index.html) .

### If we have original sdk why need this wrapper ?

This gem solves few things:

 - **Syncing A/B test config across different servers when you don't want to fetch config via REST endpoint or redis/memcache store**

  Yes, it's designed keeping performance in mind as we want to save a network overhead and a extra dependency.

  If you are using Optimizely you will be aware about the [datafile](http://developers.optimizely.com/server/reference/index.html#datafile). Once we make changes to the A/B test like change in percent distribution, start / pause a experiment this file get's updated.

  If you have 50 servers with 40 passenger / puma process each these process needs to be updated.  The Gem polls the config at regular interval and keeps the datafile cached across different process.

  The config is stored in **Memory Store** . We use [Activesupport memory store](http://api.rubyonrails.org/classes/ActiveSupport/Cache/MemoryStore.html) for same.

* **Helper methods to better handle test and variations and handling fallbacks and experiment pause**

  Optimizely ruby sdk provides us way to know which variation to show. But what happens when the experiment is paused ? Or there is a error happening in config.
  More details about this in below section of experiment config.

### Architecture

![alt Architecture](https://github.com/ankit8898/optimizely_server_side/blob/master/docs/general_architecture.png
 "Architecture")

### Getting Started

Add the gem in your Gemfile

```ruby
 gem 'optimizely_server_side'
```

and

```ruby
bundle install
```

Add an initializer in `config/initializers/optimizely_server_side.rb`

```ruby
#config/initializers/optimizely_server_side.rb
OptimizelyServerSide.configure do |config|
  config.config_endpoint  = 'https://cdn.optimizely.com/json/PROJECT_ID.json'
  config.cache_expiry     = 15 #(this is in minutes)
  config.event_dispatcher = MyEventDispatcher.new
end

```

_Config info_

- `config_endpoint` - This is the Datafile endpoint which returns JSON config. `PROJECT_ID` is a id of your  server side project at https://app.optimizely.com .
- `cache_expiry` - Time we want to keep the config cached in memory.
- `event_dispatcher` - Optimizely needs to track every visit. You can pass your own event dispatcher from here. Read [more](https://developers.optimizely.com/server/reference/index#event-dispatcher)
- `user_attributes` - Everything related to user is passed from here. The must have key is `visitor_id`. In the same hash you can pass other other custom attributes. eq

```
config.user_attributes = {'visitor_id' => 1234, 'device_type' => 'iPhone'}
```

Optimizely needs a `visitor_id` to track the unique user and server a constant experience.

In your Application controller

```ruby
class ApplicationController < ActionController::Base

  include OptimizelyServerSide::Support

  before_action :set_visitor_id

  def set_visitor_id
    cookies.permanent[:visitor_id] = '1234567' #some visitor_id

    # This links the browser cookie for visitor_id to
    # OptimizelyServerSide
    OptimizelyServerSide.configure do |config|
        config.user_attributes = {'visitor_id' => cookies[:visitor_id]}
    end
  end

```

### Example usage

#### In your html.erb

```ruby
# in any app/view/foo.html.erb
<%= experiment(EXPERIMENT_KEY) do |exp|

  exp.variation_one(VARIATION_ONE_KEY) do
    render partial: 'variation_one_experience'
  end

  exp.variation_default(VARIATION_DEFAULT_KEY, primary: true)
    render partial: 'variation_default_experience'
  end

<% end %>
```

#### In your model or any PORO

```ruby
class Foo

  include OptimizelyServerSide::Support

  # This method is responsible from getting data from
  # any other rest endpoint.
  # Suppose you are doing a AB test on a new endpoint / data source.
  def get_me_some_data
    data = experiment(EXPERIMENT_KEY) do |exp|

      exp.variation_one(VARIATION_ONE_KEY) do
        HTTParty.get('http://from_source_a.com/users')
      end

      exp.variation_default(VARIATION_TWO_KEY, primary: true) do
        HTTParty.get('http://from_source_b.com/users')
      end
    end

  end
end
```
#### Don't want to stick with variation_one, variation_two ?

You can call you own method names with `variation_` . Below i have `config.variation_best_experience` and `config.variation_pathetic_experience`.

```ruby
# in any app/view/foo.html.erb
<%= experiment(EXPERIMENT_KEY) do |exp|

  config.variation_best_experience(VARIATION_ONE_KEY) do
    render partial: 'variation_one_experience'
  end

  config.variation_pathetic_experience(VARIATION_DEFAULT_KEY, primary: true) do
    render partial: 'variation_default_experience'
  end

<% end %>

```
In the above examples:

`EXPERIMENT_KEY`: When you will set your experiment this key will be set up that time at https://app.optimizely.com.

`VARIATION_ONE_KEY`: Key for Variation one. This will be also set when setting up experiment.

`VARIATION_TWO_KEY`: Key for Variation two. This will be also set when setting up experiment.

`VARIATION_DEFAULT_KEY`: Key for default experience. This will be also set when setting up experiment

`primary: true` : If you see above some variations are marked with `primary: true`. This enables handling the fallback capabilities of optimizely_server_side. If there is any error pulling datafile or experiment is paused the `primary` experience is served.  Not setting primary won't give any experience during fallback times.  We encourage setting it up.

![alt Optimizely dashboard](https://github.com/ankit8898/optimizely_server_side/blob/master/docs/screenshot.png "Optimizely dashboard")

### Instrumentation

This is a trial feature and may or maynot exist in future version.

We have [ActiveSupport::Notifications](http://api.rubyonrails.org/classes/ActiveSupport/Notifications.html) hooked up for few places which are worth monitoring.

* When the datafile is fetched from cdn. In your application you can subscribe via below. This helps to monitor the time it takes from CDN fetch

```ruby
ActiveSupport::Notifications.subscribe "oss.call_optimizely_cdn" do |name, started, finished, unique_id, data|
  Rails.logger.info "GET Datafile from Optimizely CDN in #{(finished - started) * 1000} ms"
end
```
* Which variation is being served currently. In your application you can subscribe via below

```ruby

ActiveSupport::Notifications.subscribe "oss.variation" do |name, started, finished, unique_id, data|
  Rails.logger.info "GET Variation from OSS in #{(finished - started) * 1000} ms with variation key #{data[:variation]}"
end
```
### Testing

Gem uses rspec for unit testing

```ruby
$~/D/p/w/optimizely_server_side> rspec .
......................................................

Finished in 0.12234 seconds (files took 0.5512 seconds to load)
54 examples, 0 failures

```

### License

The MIT License

gha_language: Ruby


text:
---
layout: default
---

# 1997-05-23 - Re: New Chip Verifies Fingerprints (fwd)

## Header Data

From: Kent Crispin<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: f9ca111554f8235887b77702f1dc2733b014796d2e47536187e147e38b15a01d

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1997-05-23 06:36:57 UTC

Raw Date: Fri, 23 May 1997 14:36:57 +0800

## Raw message

```
{% raw  %}From: Kent Crispin<EMAIL_ADDRESS>Date: Fri, 23 May 1997 14:36:57 +0800
To<EMAIL_ADDRESS>Subject: Re: New Chip Verifies Fingerprints (fwd)
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

On Fri, May 23, 1997 at 12:27:28AM -0400, Decius 6i5 wrote:
> > Veridicom, a spinoff of Lucent Technologies, just demoed (at
[...]
>
> If I get mugged and the mugger wants access to my bank account all he has
> to do is chop off the relevant finger. Don't laugh. This *WILL* happen.
> Biometrics create an general economic incentive for maiming or murdering
> people.

I'm not so sure that this is realistic.  I have heard that earlier
fingerprint reading cards were very sensitive to size distortion --
that is, if you swung your arm in a circle to increase the blood
pressure in your hand, they would give a false reading, because of the
swelling in the fingers would be sufficient to throw off the
recognition software -- a smart card isn't *that* smart.  A problem
of false negatives.

 *When you implement a biometric system you
> are deciding that the value of that which is being protected is greater
> than the value of the lives of the people who have access to it.*
>
> This is obvious if you look at the trade-offs.  Obviously this
> will reduce your instances of fraud, as killing a person is more messy
> then hacking a pin code. However, because the cost of killing someone is
> smaller than the value of the object being protected, there are going to
> be losses. You have to decide that you are capable of swallowing those
> losses. You have to decide that the value of the decrease in fraud over
> a non-biometric system is greater than that of the lives of the people who
> are lost when fraud does occur. This is a despicable situation, but don't
> think you won't see it. It is probably inevitable now.

You don't have to kill or maim some to induce cooperation, and
biometric devices can be designed to pretty much require that the
subject be living.  Extortion or seduction are both quite viable, and
work with any security system.  Biometrics don't really add
anything.

Your point is just as meaningful for cryptography.  All strong crypto
does is move the weak spot around.

Incidentally, I have heard (from a probably reliable source) that the
best biometric is a retina scan -- very reliable, hard to spoof,
*very* few false negatives.  [False positives are real bad for any
security system, of course.  False negatives are why you want back up
modes of access.]

--
Kent Crispin				"No reason to get excited",
<EMAIL_ADDRESS>	the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

{% endraw %}
```

## Thread

+ Return to [May 1997](/archive/1997/05)

+ Return to<EMAIL_ADDRESS>(Decius 6i5)](/authors/decius_at_ninja_techwood_org_decius_6i5_)"
+ Return to<EMAIL_ADDRESS>(Mikolaj J. Habryn)](/authors/dichro_at_yodel_iinet_net_au_mikolaj_j_habryn_)"
+ Return to "[Kent Crispin <kent@songbird.com>](/authors/kent_crispin_kent_at_songbird_com_)"

+ 1997-05-23 (Fri, 23 May 1997 12:50:03 +0800) - [New Chip Verifies Fingerprints (fwd)](/archive/1997/05/b15e54e358638ea3405ff626a51dd37b0d192ba3da374cabcd0af826ec302af6) -<EMAIL_ADDRESS>(Decius 6i5)_
  + 1997-05-23 (Fri, 23 May 1997 14:36:57 +0800) - Re: New Chip Verifies Fingerprints (fwd) - _Kent Crispin<EMAIL_ADDRESS>  + 1997-05-23 (Fri, 23 May 1997 14:42:55 +0800) - [Re: New Chip Verifies Fingerprints (fwd)](/archive/1997/05/4a57eb9f9d99299b7a5a6878d1b12c9098fa367ca71358f625ba9999a53c58c3) -<EMAIL_ADDRESS>(Mikolaj J. Habryn)_


text:
---
title: MySqlConnectionStringBuilder.TlsCipherSuites property
---

# MySqlConnectionStringBuilder.TlsCipherSuites property

The TLS cipher suites which may be used during TLS negotiation. The default value (the empty string) allows the OS to determine the TLS cipher suites to use; this is the recommended setting.

```csharp
public string TlsCipherSuites { get; set; }
```

## See Also

* class [MySqlConnectionStringBuilder](../../MySqlConnectionStringBuilderType/)
* namespace [MySqlConnector](../../MySqlConnectionStringBuilderType/)
* assembly [MySqlConnector](../../../MySqlConnectorAssembly/)

<!-- DO NOT EDIT: generated by xmldocmd for MySqlConnector.dll -->

repository: mysql-net/MySqlConnector

repo_name: mysql-net/MySqlConnector


text:
# HotSpotMap
A Python-based temperature (thermal) maps generation tool for HotSpot-6.0 (http://lava.cs.virginia.edu/HotSpot/)

This tool uses Python's Turtle library to generate publication-quality floor-plan images and thermal maps for 2D and 3D systems.

It can generate:
1) Floor-plan images (using floor-plan files)
2) Thermal maps (using floor-plan file and steady temperature file)
3) Fine-grained thermal maps (using floor-plan file and grid steady temperature file)

Generated images are in `.eps` and `.pdf` format.

If you are using this tool, please cite our GitHub link: https://github.com/bucaps/HotSpotMap

Please submit a pull request for any enhancements or contributions.

## Requirements
1) Python version `3.5`
2) Tkinter version `8.6`
3) `pdfjam`

## Setup
Clone the tool using:
```
git clone https://github.com/bucaps/HotSpotMap.git
```

## Examples
- `example-2d` folder in this repository contains a sample floor-plan (`ev6.flp`), steady temperature file (`gcc.steady`), and grid steady temperature file (`gcc.grid.steady`).
- `example-3d` folder in this repository contains a example 3D system and the associated `lcf` (layer configuration file), floor-plan files and temperature files.

These files are also included in the `HotSpot-6.0` distribution at: https://github.com/uvahotspot/hotspot

## Usage: 2D systems

### To generate floor-plan image:

```
# This will generate ev6-flp.eps and ev6-flp.pdf in the example-2d directory
python3.5 HotSpotMap.py -a flp -f example-2d/ev6.flp -o ev6 -z 30000 -fts 7 -d example-2d -pcd
```

- `-a` : action {`flp` or `steady` or `grid-steady`}
- `-f` : path to the floor-plan file
- `-o` : prefix for output file
- `-z` : zoom level
- `-fts` : font size
- `-d` : output directory
- `-pcd` : print chip's width and height

### To generate a thermal map using a steady temperature file:

```
# This will generate ev6-steady.eps and ev6-steady.pdf in the example-2d directory
python3.5 HotSpotMap.py -a steady -f example-2d/ev6.flp -t example-2d/gcc.steady -o ev6 -z 30000 -fts 7 -d example-2d
```

- `-t` : path to steady temperature file

### To generate a fine-grained thermal map using grid steady temperature file:

```
# This will generate ev6-grid-steady.eps and ev6-grid-steady.pdf in the example-2d directory
python3.5 HotSpotMap.py -a grid-steady -f example-2d/ev6.flp -t example-2d/gcc.grid.steady -r 64 -c 64 -o ev6 -z 30000 -fts 7 -d example-2d
```

- `-t` : path to grid steady temperature file

## Usage: 3D systems

### To generate floor-plan image:

```
# This will generate .eps and .pdf file for each layer in specified in the lcf, and combine them into a single pdf file `ev6-3D-concat.pdf`
python3.5 HotSpotMap.py -a flp -3D -f example-3d/ev6_3D.lcf -o ev6_3D -z 30000 -fts 7 -d example-3d -pcd -concat
```

- `-3D` : enable 3D system
- `-f` : path to the `lcf` file (layer configuration file)
- `-concat`: combines the floor-plans of all the layers into a single single pdf

Using `-concat` will combine images of layers from `lcf` which have power dissipation.

### To generate a thermal map using a steady temperature file:

```
# This will generate ev6-steady.eps and ev6-steady.pdf in the example-2d directory
python3.5 HotSpotMap.py -a steady -3D -f example-3d/ev6_3D.lcf -t example-3d/ev6_3D.steady -o ev6_3D -z 30000 -fts 7 -d example-3d -pcd -concat
```

- `-t` : path to steady temperature file

### To generate a fine-grained thermal map using grid steady temperature file:

```
# This will generate ev6-grid-steady.eps and ev6-grid-steady.pdf in the example-2d directory
python3.5 HotSpotMap.py -a grid-steady -3D -f example-3d/ev6_3D.lcf -t example-3d/ev6_3D.grid.steady -r 64 -c 64 -o ev6_3D -z 30000 -fts 7 -d example-3d -pcd -concat
```
- `-t` : path to grid steady temperature file

#### Format of grid steady file for 3D systems
Grid temperatures of each layer should be followed by the layer number as shown below:

```
layer_0
0 341.14
1 341.18
2 341.24
3 341.32
...
...
```

This can be achieved by simplifying modifying `dump_top_layer_temp_grid()` function in `temperature_grid.c` file in `HotSpot 6.0` to print out grid temperatures for
all the layers as follows:

```c
  int l;
  for(l=0;  l < model->n_layers; l++){
     fprintf(fp, "layer_%d\n", l);
     for(i=0; i < model->rows; i++){
         for(j=0; j < model->cols; j++){
             fprintf(fp, "%d\t%.2f\n", i*model->cols+j,
                     model->last_steady->cuboid[l][i][j]);
         }
         fprintf(fp, "\n");
     }
     fprintf(fp, "\n");
  }
```

### Important Note
- You can try out various levels of zoom `-z` and font-size `-fts` until you find a combination that suits your chip floor plan.
- For generating thermal maps using grid steady temperature file, you need to specify rows (`-r`) and columns (`-c`) used in the HotSpot's grid model.

### Full list of options
To get a complete list of available options, type:
```
python3.5 HotSpotMap.py -h
```

Currently, supported options are:
```
  -h, --help            show this help message and exit
  -a {flp,steady,grid-steady}, --action {flp,steady,grid-steady}
                        Action type
  -3D, --model-3D       To indicate a 3D system
  -f FLOOR_PLAN, --flp FLOOR_PLAN
                        Floor-plan file
  -t TEMPERATURE_FILE, --temperature TEMPERATURE_FILE
                        Steady temperature file or Grid steady temperature
                        file based on action
  -r GRID_ROWS, --row GRID_ROWS
                        Number of rows in grid-steady model
  -c GRID_COLS, --col GRID_COLS
                        Number of columns in grid-steady model
  -ft FONT, --font FONT
                        Font family
  -fts FONT_SIZE, --font-size FONT_SIZE
                        Font size
  -ftw FONT_WEIGHT, --font-weight FONT_WEIGHT
                        Font weight
  -o OUTPUT_FILE, --output-file OUTPUT_FILE
                        Output file name prefix
  -d OUTPUT_DIR, --output-directory OUTPUT_DIR
                        Output directory
  -hn, --hide-names     Hide names on floor-plan
  -z ZOOM_BY, --zoom-by ZOOM_BY
                        Zoom factor
  -pcd, --print-chip-dim
                        Draw chip' width and height scale
  -concat, --concat-3D  Combines the images generated for all layer into a
                        single PDF
  -pa, --print-area     Print unit's area (mm2) alongside its name, rounded to
                        three decimal places
```

### License
This project is licensed under MIT License -  refer to the [LICENSE.md](LICENSE.md) file for details.

### Author
- Gaurav Kothari
- Email<EMAIL_ADDRESS>


text:
# NDEX Alpha Version instructions

## Preface

 Ndex alpha version access address：[http://beta.nervedex.com](http://beta.nervedex.com)

 The full name of ndex is nerve decentralized exchange, and the transaction process is completely controlled by the decentralized node. Therefore, it is different from the conventional centralized transaction. Users should pay attention to the following points when using it:
 - The transaction account is the blockchain account address, so the user needs to save the private key or keystore of the account
 - There is no concept of recharging or withdrawing the assets of the transaction account, only the transfer with the same address as the normal blockchain account
 - Both the registration and cancellation are initiated a transaction, so the transaction fee is required to be paid. Currently, it is 0.001nvt
 - Since both the registration and cancellation are transactions initiated, it is necessary to enter a password to sign the transaction when the registration and cancellation are conducted (the developer will consider the following optimization to improve the experience of everyone's transaction)
 Ndex is now in the * * alpha * * test stage. Welcome to the community user experience and feedback questions. There are two feedback channels:

 1 Discord test support：[https://discord.gg/PBkHeD7](http://beta.nervedex.com)

 2 Github：[https://github.com/NerveNetwork/nerve/issues](http://beta.nervedex.com)

 ## Get assets

 #### Test NVT
 Visit [forum test currency application post] (https://bbs.nuls.io/t/nuls-neve/134) and leave your own nuls test network address. Our developers will transfer the test currency to your address

 #### Test NULS
 Visit the wallet of nuls test network: https://beta.wallet.nuls.io/ to enter the [transfer] page, fill in the address of the nerve network in the [collection address], and then transfer the nuls of the test network to the nerve network through the cross chain
 ![](./g_dex/1.jpg)

 #### Nuls test network nrc20
 Users can transfer nrc20 of nuls network to the nerve network through cross chain, and conduct transactions on ndex (if the transaction pair of nrc20 has been opened)

 [View cross chain nrc20 tutorial](/zh/Guide/c_nrc20.html)

 [see how to open the nrc20 transaction pair](./g_nrc_dex.md)

 ## Make a deal
 #### Transaction pair
 After obtaining the test token, you can enter the [trading page] of ndex (http://beta.nervedex.com/trading/index) for trading. At present, we have opened the following trading pairs:
 - NVT/BTC
 - NULS/BTC
 - TPU/BTC
 - TPU/USDI
 - NVT/USDI
 - NULS/USDI
 - BTC/USDI

 In addition, it is worth mentioning that in the beta version, we will open the functions of [issue assets] and [apply for transaction pairs] on the nerve. Please look forward to
 ####  List type
 Currently, we only support price limit list

 ![](./g_dex/2.jpg)

 ## Service Charge
    There are 4 places where handling fees will be generated when trading on Dex
 - Maker: 0.01% of turnover
 - Taker: 0.01% of turnover
 - Registration form: 0.001nvt
 - Cancellation: 0.001nvt

 ## View transaction details
    Ndex is equipped with corresponding browser, which supports query of all transaction details on DEX: http://explorer.nervedex.com/

repository: NerveNetwork/nerve-docs

gha_language: Shell

repo_name: NerveNetwork/nerve-docs


text:
bitcoin-seeder
==============

Bitcoin-seeder is a crawler for the eCash network, which exposes a list
of reliable nodes via a built-in DNS server. It is derived from Pieter Wuille's
bitcoin-seeder, modified for use on the eCash network.

Features:
* regularly revisits known nodes to check their availability
* bans nodes after enough failures, or bad behaviour
* uses the eCash Magic when establishing connections
* keeps statistics over (exponential) windows of 2 hours, 8 hours,
  1 day and 1 week, to base decisions on.
* very low memory (a few tens of megabytes) and cpu requirements.
* crawlers run in parallel (by default 24 threads simultaneously).

REQUIREMENTS
------------

    sudo apt-get install build-essential libboost-dev libssl-dev

USAGE
-----

Assuming you want to run a dns seed on dnsseed.example.com, you will
need an authoritative NS record in example.com's domain record, pointing
to for example vps.example.com:

    dig -t NS dnsseed.example.com

    ;; ANSWER SECTION
    dnsseed.example.com.   86400    IN      NS     vps.example.com.

On the system vps.example.com, you can now run bitcoin-seeder:

    ./bitcoin-seeder -host=dnsseed.example.com -ns=vps.example.com

If you want the DNS server to report SOA records, please provide an
e-mail address (with the `@` part replaced by `.`) using `-mbox`.

TESTING
-------

It's sometimes useful to test `bitcoin-seeder` locally to ensure it's giving good
output (either as part of development or sanity checking). You can inspect
`dnsseed.dump` to inspect all nodes being tracked for crawling, or you can
issue DNS requests directly. Example:

$ dig @:: -p 15353 dnsseed.example.com
       ^       ^    ^
       |       |    |__ Should match the host (-h) argument supplied to bitcoin-seeder
       |       |
       |       |_______ Port number (example uses the user space port; see below)
       |
       |_______________ Explicitly call the DNS server on localhost

RUNNING AS NON-ROOT
-------------------

Typically, you'll need root privileges to listen to port 53 (name service).

One solution is using an iptables rule (Linux only) to redirect it to
a non-privileged port:

    iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-port 15353

If properly configured, this will allow you to run bitcoin-seeder in userspace, using
the `-port=15353` option.

Generate Seed Lists
-------------------

Bitcoin-seeder is also be used to generate the seed lists that are compiled
into every Bitcoin ABC release. It produces the `dnsseed.dump` files that are
used as inputs to the scripts in [contrib/seeds](/contrib/seeds) to generate
the seed lists. To generate seed lists, the seeder should be run continuously
for 30 days or more.

repository: Bitcoin-ABC/bitcoin-abc

repo_name: Bitcoin-ABC/bitcoin-abc


text:
# lobotjr
LobosJR's channel bot. This repository contains the code used to power many of lobotjr's functions as well as the Wolfpack RPG.

2.0 Introduces new commands, aswell as supplementary 'op' commands for mostly custom commands but also to provide information on static commands.

Summary Command List:
OP Commands
-Add
-Cancel
-Delete
-Edit
-Info
General Commands
-Uptime
-Time
-Playlist
-Opinion
-Pun
-Quote
-Raffle
RPG Commands
-Stats
-Inventory
-Item
-Equip
=Unequip
-Shop
-Class
-Gloat
-Respec
-Daily
-Queue
-Create Party
-Add To Party
-Pending Invite
-Leave Party
-Kick Player
-Promote Player
-Start
Wolfpack Leader Commands
-Add Player XP
-Add Player Coin
-Set Player Level

OP Commands: [broadcaster/mod only] (PRIVMSG & WHISPER)

Add:
!op add cd=10(optional) ut=moderator|broadcaster(optional) !example 'example value' - This operation adds a new custom command. Add commands can include optionally cooldowns (cd) and user types (ut). Cooldowns are in seconds and not setting it will default to 1 second
cooldown.

Cancel:
!op cancel '!commandToCancel' - This will call the cancel operation on the command. This only effects a small number of commands that
have a time based operation or is flagged based, can be turned on or off. For example the Raffle command can be cancelled using this
operation.

Delete:
!op delete '!commandToDelete' - This will delete the command if it is a custom command, static commands cannot be deleted. DELETE IS FINAL AND CANNOT BE UNDONE!

Edit:
!op edit cd=10(optional) ut=moderator|broadcaster(optional) '!commandToEdit' 'new value' - This operation follows the same syntax as the add command, however not setting the cooldown or user types will result in the current values being retained. The value of the command does have to be changed.
!set='!commandToEdit' 'new value' - This is a shortcut version of the above edit when the cooldown and user types don't need changing and only the command value needs changing.

Info:
!op info '!command' - This will return via whisper to the caller the information regarding the command. This information includes the
name, cooldown, user types, custom or not, raw value, syntax(if applicable), current values. This command is very helpful for mods or broadcasters to be reminded of the correct syntax for each command.

General Commands: (PRIVMSG ONLY, not case sensitive)

Uptime:
!uptime - returns the amount of time the stream has been live, technically this returns the amount of time since
'!broadcasting on' was called. If the broadcasting is set to off then a not live message will show.

Time:
!time - returns current Local time in "HH:mm tt" format. Example: 6:33 PM.

Playlist:
!playlist - returns a link to a spotify playlist.

Opinion:
!opinion - returns a link to a image.

Pun:
!pun - returns a random pun from a local file.

Quote:
!quote - returns a random quote from a list of added quotes.
[broadcaster/mod only] !quote 'quote value' - Adds this quote to the list of quotes available for !quote.

Raffle: [broadcaster only]
!raffle 'keyword' - Starts a time based raffle where viewers are instructed to type in the given keyword. The timer is defaul on this call and after the timer has finished the winner is shown in chat and the winner is also whispered to the channel owner.
!raffle 'keyword' 'delay in mins' - This is the same as above, however the timer is now explicitly set to the given delay.
!raffle winner - If a raffle is currently running this will stop the raffle prematurely and pick a winner.

RPG Commands/ General: (PRIVMSG ONLY, not case sensitive)

Broadcasting: [broadcaster/mod only]
Replaces the need for calling two commands at the start of a stream. Previously this would require !on and !xpon commands to be called, and from experience this always happens together and they are also turned off together.
!broadcasting on - This notifies the uptime command on the start time of the stream, it also starts the viewer reward system for the
wolfpack rpg.
!broadcasting off - This notifies the uptime command that streaming has stopped, it also stops the viewer reward system for the wolfpack
rpg.

RPG Commands: (WHISPER ONLY, not case sensitive)

Stats:
!stats - returns the players current wolfcoins and level, this also includes the xp gained and how much till the next level (TNL).
!stats 'username' - returns the stats of another player, this does cost wolfcoins and the cost can be found by using the !shop command.

Inventory:
!inventory - returns items in the players inventory as well as listing all equipped items.

Item:
!item 'itemid' - returns the respective item's details.

Equip:
!equip 'itemid' - This will equip the respective item to the correct equipment slot, if the player does not own the item then this will do nothing. If the player already has another item equipped this command will unequip the current item and place it in the players inventory automatically, a message will be returned to this effect.

Unequip:
!unequip 'itemid' - This will unequip the respective item, if the player does not own the item; this command will do nothing.

Shop:
!shop - returns: "Whisper me '!stats <username>' to check another users stats!  (Cost: /d coins)", where /d would indicate the current numeric amount.

Class:
Once a player hits level 3, they are notified that they can now pick a class. The options are provided in this message and they are
prompted to use the !class command with their choosen class name. Using the command at any other time will do nothing. Players wanting
to change their class after this choice need to use the !respec command.
!class 'classname' - if the above requirements are met then this will change the players class.

Gloat:
!gloat - returns a response based on the player's current level, the cost of the command can be found by using the !shop command.

Respec:
Respec cost is based on player level.
!respec 'classname' - returns the cost of changing class and prompting the player to return !respec yes or !respec no if they wish to continue.
!respec yes - confirms the respec cost, if the player has not called the previous respec command this will do nothing.
!respec no - cancels the respec.

Daily:
!daily - returns the time remaining till the players next daily bonus.

Queue:
Queue commands are to add players to the group finder, if players don't meet requirements for any dungeons then they are not added to the group finder and error message is returned.
The group finder will find players that can run the same dungeons and group them together, the group finder will not duplicate classes
to avoid the penalty that occurs with this.
[non-party]
!queue - This will add the player to the group finder. Once a party is found then a dungeon that matches the requirements of the party is picked at random, this will not pick the dungeon that provides the player with the most xp by default.
!queue 'id#1 id#2 id#3 id#4' - This will add the player to the group finder but only for the specified dungeons, therefore the player can always run a specific dungeon if they only choose to provide one id.

[party]
When a party queues the lowest level player is choosen to be the sync for the party, this means that every other member is capped to this level, equipped items are not removed when this occurs however their stats are adjusted to match the current sync level.
!queue - This will add the party to the group finder. If the party meets a dungeon requirement already then they will quickly skip the queue and the adventure will start.
!queue 'id#1 id#2 id#3 id#4' - This is similar to above however the party is choosing specific dungeons to run, therefore a party can always run a specific dungeon if they only choose to provide one id.

Create Party:
!createparty - Creates a manual party which you become the leader of allowing you to add specific users to your party.

Add To Party: [Party Leader Only]
!add 'player' - This will send an invite to the other player, which they are then prompted to either accept or decline. The party leader
is notified when this occurs.

Pending Invite:
!pendinginvite accept - This will accept the pending invite, if no invite is pending then this command will do nothing.
!pendinginvite decline - This will decline the pending invite, if no invite is pending then this command will do nothing.

Leave Party:
!leaveparty - This allows the player to leave the party at anytime.

Kick Player: [Party Leader Only]
!kick 'player' - The party leader can kick any member of their party using this command, if the player is not in the party this command does nothing.

Promote Player: [Party Leader Only]
!promote 'player' - The party leader can promote another member of their party using this command, if the player is not in the party this command does nothing.

Start: [Party Leader Only]
Start command is similar to the queue command, however it allows the party to ignore the restrictions and does not impose the level sync. Players can use this feature by simply creating a new party and then using the start command. The requirements that are checked when using the start command are the cost and the minimum level.
!start - Starts a random dungeon, where the few requirements above are met.
!start 'id#1 id#2 id#3 id#4' - Starts a dungeon, if more then one option is provided then this is randomly choosen. This will return an error if the party does not meet the minimum requirements for the dungeons.

Wolfpack Leader Commands: [Broadcaster Only] (WHISPER ONLY)

Add Player XP:
!addplayerxp 'player' 'xp' - This adds the respective xp amount to the player.

Add Player Coin:
!addplayercoin 'player' 'coin' - This adds the repsecitive coin amount to the player.

Set Player Level:
Setting players level when they are deprived can only be maxed to level 3, the player would then need to choose a class then the level could be set up to the max level cap. Therefore setting a level 1 player to level 20 would only result in them recieving notification on reaching level 3 and asking them to choose a class.
!addplayerlevel 'player' 'level' - This sets the players level respecitive to the level amount.

repository: MaraKorvus/lobotjr

repo_name: MaraKorvus/lobotjr


text:
config-value-getopt
===================

The config-value-getopt package allows GetOpt[1] specified options
to be loaded from a configuration file in the config-value[2] format.

* config-value section names are matched against the "long" option names
in GetOpt.
* Argument values can be provided as strings or numbers
* An option will be omitted if its value is set to `no`
* An option's argument will be omitted if its value is set to `yes`

Example:

```
address:       "::"
port:          9000
no-access-log: yes
hostname:      no
```

translates to

```
--address="::" --port="9000" --no-access-log
```

1. https://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/System-Console-GetOpt.html
2. https://hackage.haskell.org/package/config-value

repository: GaloisInc/config-value-getopt

repo_name: GaloisInc/config-value-getopt


text:
## CAN Library for ESP32

### ACAN_ESP32 library description
ACAN_ESP32 is a driver for the CAN module built into the ESP32 microcontroller.

The driver supports many bit rates, as standard 62.5 kbit/s, 125 kbit/s, 250 kbit/s, 500 kbit/s, and 1 Mbit/s. An efficient CAN bit timing calculator finds settings for them, but also for an exotic bit rate as 842 kbit/s. If the wished bit rate cannot be achieved, the `begin` method does not configure the hardware and returns an error code.

> The library is in the `ACAN_ESP32` directory. Driver API is fully described by the PDF file in the `ACAN_ESP32/extras` directory.

### Demo Sketch

> The demo sketch is in the `ACAN_ESP32/examples/LoopBackDemo` directory.

> Note the driver required name is `ACAN_ESP32::can`; you cannot use an other name.

Configuration is a four-step operation.

1. Instanciation of the `settings` object : the constructor has one parameter: the wished CAN bit rate. The `settings` is fully initialized.
2. You can override default settings. Here, we set the `mRequestedCANMode` property to `ACAN_ESP32_Settings::LoopBackMode`, enabling to run self reception of sent frame. **Unlike other microcontrollers, this mode requires the connection of a transceiver.** We can also for example change the receive buffer size by setting the `mReceiveBufferSize` property.
3. Calling the `begin` method configures the driver and starts CAN bus participation. Any message can be sent, any frame on the bus is received. No default filter to provide.
4. You check the `errorCode` value to detect configuration error(s).

```cpp
void setup () {
  Serial.begin (9600) ;
  Serial.println ("Hello") ;
  ACAN_ESP32_Settings settings (125 * 1000) ; // 125 kbit/s
  settings.mRequestedCANMode = ACAN_ESP32_Settings::LoopBackMode ;
  const uint32_t errorCode = ACAN_ESP32::can.begin (settings) ;
  if (0 == errorCode) {
    Serial.println ("Can ok") ;
  }else{
    Serial.print ("Error Can: 0x") ;
    Serial.println (errorCode, HEX) ;
  }
}
```

Now, an example of the `loop` function. As we have selected loop back mode, every sent frame is received.

```cpp
static uint32_t gBlinkLedDate = 0 ;
static uint32_t gReceivedFrameCount = 0 ;
static uint32_t gSentFrameCount = 0 ;

void loop () {
  CANMessage frame ;
  if (gBlinkLedDate < millis ()) {
    gBlinkLedDate += 500 ;
    digitalWrite (LED_BUILTIN, !digitalRead (LED_BUILTIN)) ;
    const bool ok = ACAN_ESP32::can.tryToSend (frame) ;
    if (ok) {
      gSentFrameCount += 1 ;
    }
  }
  while (ACAN_ESP32::can.receive (frame)) {
    gReceivedFrameCount += 1 ;
  }
}
```
`CANMessage` is the class that defines a CAN message. The `message` object is fully initialized by the default constructor. Here, we set the `id` to `0x542` for sending a standard data frame, without data, with this identifier.

The `ACAN_ESP32::can.tryToSend` tries to send the message. It returns `true` if the message has been sucessfully added to the driver transmit buffer.

The `gBlinkLedDate ` variable handles sending a CAN message every 500 ms.

`ACAN_ESP32::can.receive` returns `true` if a message has been received, and assigned to the `message`argument.