text:
+++
title = "MySQL"
weight = 91
app_library = "default"
app_category = "Services"
app_typ = "default"
app_ns = "Bench"
app_id = "Bench.MySQL"
app_version = "5.7.17"
app_categories = ["Services"]
app_libraries = ["default"]
app_types = ["default"]
+++

**ID:** `Bench.MySQL`
**Version:** 5.7.17
<!--more-->

[Back to all apps](/apps/)

## Description
According to Oracle:
MySQL Community Edition is the freely downloadable version
of the world's most popular open source database.

The MySQL data is stored in `%USERPROFILE%\mysql_data`.
You can start the MySQL server by running `mysql_start` in the _Bench_ shell.
You can stop the MySQL server by running `mysql_stop` in the _Bench_ shell.
The initial password for _root_ is `bench`.

## Source

* Library: [`default`](/app_libraries/default)
* Category: [Services](/app_categories/services)
* Order Index: 91

## Properties

* Namespace: Bench
* Name: MySQL
* Typ: `default`
* Website: <http://www.mysql.com/>
* Responsibilities: [PHP Development](/apps/Bench.Group.PHPDevelopment)


text:
---
layout: default
---

# 1996-06-21 - Re: Federal Key Registration Agency

## Header Data

From: Michael Froomkin<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: c290ebecbdfee3b2c6436311058275809451b8142f6cf3285f1bee1437a8bfd4

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1996-06-21 06:57:40 UTC

Raw Date: Fri, 21 Jun 1996 14:57:40 +0800

## Raw message

```
{% raw  %}From: Michael Froomkin<EMAIL_ADDRESS>Date: Fri, 21 Jun 1996 14:57:40 +0800
To<EMAIL_ADDRESS>Subject: Re: Federal Key Registration Agency
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

I have seen the text of the speech.  The wire service accounts wildly,
wildly exaggerate.  This is a non-story...except for AG Reno's assertion
that it would take the government a year to break one DES message with a
"supercomputer".  She presumably believes this.  We know the number for
known plaintext attacks, but assuming you don't have a known plaintext,
what's a more reasonable assumption?

[This message may have been dictated with Dragon Dictate 2.01.
Please be alert for unintentional word substitutions.]

A. Michael Froomkin        | +1<PHONE_NUMBER>; +1<PHONE_NUMBER> (fax)
Associate Professor of Law |
U. Miami School of Law     |<EMAIL_ADDRESS>P.O. Box 248087            | http://www.law.miami.edu/~froomkin
Coral Gables, FL 33124 USA | It's hot here.  And humid.

{% endraw %}
```

## Thread

+ Return to [June 1996](/archive/1996/06)

+ Return to "[Carl Ellison <cme@ACM.ORG>](/authors/carl_ellison_cme_at_acm_org_)"
+ Return to "[Michael Froomkin <froomkin@law.miami.edu>](/authors/michael_froomkin_froomkin_at_law_miami_edu_)"
+ Return to "["Perry E. Metzger" <perry@piermont.com>](/authors/perry_e_metzger_perry_at_piermont_com_)"
+ Return to "[Raph Levien <raph@cs.berkeley.edu>](/authors/raph_levien_raph_at_cs_berkeley_edu_)"
+ Return to "[s1113645@tesla.cc.uottawa.ca](/authors/s1113645_at_tesla_cc_uottawa_ca)"
+ Return to "[William Knowles <erehwon@c2.org>](/authors/william_knowles_erehwon_at_c2_org_)"

+ 1996-06-20 (Thu, 20 Jun 1996 20:07:52 +0800) - [Re: Federal Key Registration Agency](/archive/1996/06/4313ee9583701c6723f14cdb1c8bf8984eb3859de92d74dfb0f7891118964de4) - _William Knowles<EMAIL_ADDRESS>  + 1996-06-20 (Fri, 21 Jun 1996 07:23:49 +0800) - [Re: Federal Key Registration Agency](/archive/1996/06/d8fa3b07d49ec401ce0b0f5c87fa30dfcf91b0ea5e9ade122c94fdaaa59ef083) -<EMAIL_ADDRESS>    + 1996-06-21 (Fri, 21 Jun 1996 14:57:40 +0800) - Re: Federal Key Registration Agency - _Michael Froomkin<EMAIL_ADDRESS>      + 1996-06-21 (Sat, 22 Jun 1996 05:40:52 +0800) - [Re: Federal Key Registration Agency](/archive/1996/06/8899f3debde98d882f263d4e8a228672069a2af51a3fc49ae2a4835d07f7f9fd) - _"Perry E. Metzger"<EMAIL_ADDRESS>      + 1996-06-22 (Sat, 22 Jun 1996 12:23:58 +0800) - [Re: Federal Key Registration Agency](/archive/1996/06/f9048c3fe62c9d19057dd45e1da25356cd5fe64580482cb658c23c1028ffdc10) - _Raph Levien<EMAIL_ADDRESS>    + 1996-06-24 (Mon, 24 Jun 1996 08:34:38 +0800) - [Re: Federal Key Registration Agency](/archive/1996/06/892c8c65324c2f9df99d889d4694106d188d82553cc8cd17d6c13ae513d8959a) - _Carl Ellison<EMAIL_ADDRESS>

license: MIT

branch_name: refs/heads/master

extension: md

gha_license_id: MIT

license_type: permissive


text:
# Getting started

Tez is a simple pytorch trainer to make your life easy. It comes with some useful dataset classes and callbacks.

Instead of inheriting from nn.Module, we inherit from tez.Model.

``` python
import tez

class MyModel(tez.Model):
   def __init__(self):
      super().__init__()
      # do something here

   def forward(self, arg1, arg2):
      # do something here
      return outputs, loss, metrics
```
In Tez, the dataset class and model’s forward function are closely related. The output names from dataset class must be same as the input arguments in forward function of the model.

## example

```python
import tez

class MyModel(tez.Model):
   def __init__(self):
      super().__init__()
      .
      .
      # tell when to step the scheduler
      self.step_scheduler_after="batch"

   def monitor_metrics(self, outputs, targets):
      outputs = torch.sigmoid(outputs).cpu().detach().numpy() >= 0.5
      targets = targets.cpu().detach().numpy()
      accuracy = metrics.accuracy_score(targets, outputs)
      return {"accuracy": accuracy}

   def fetch_scheduler(self):
      # create your own scheduler

   def fetch_optimizer(self):
      # create your own optimizer

   def forward(self, ids, mask, token_type_ids, targets):
      _, o_2 = self.bert(ids, attention_mask=mask, token_type_ids=token_type_ids)
      b_o = self.bert_drop(o_2)
      output = self.out(b_o)

      # calculate loss here
      loss = nn.BCEWithLogitsLoss()(output, targets)

      # calculate the metric dictionary here
      metric_dict = self.monitor_metrics(output, targets)
      return output, loss, metric_dict

```

repository: misalraj/tez

branch_name: refs/heads/main

repo_name: misalraj/tez


text:
# Node Relative Loader

Yet another native node addon loader. The project is an enhanced version inspired by [node-addon-loader](https://github.com/ushu/node-addon-loader) and [node-native-loader](https://github.com/smt116/node-native-ext-loader).

## Why relative loader is created?

In electron-based applications generally use asar to pack resources and if there are node addon which depends on other native modules like dlls on Windows or so on Linux/Mac, the .node module should be unpacked, but any existed loader could not work with this condition. Relative loader is born to solve this issue.

## Installation

Add the package to the development dependencies:

```bash
# using npm:
$ npm install relative-loader --save-dev

# using yarn:
$ yarn add --dev relative-loader
```

## Usage

Update rules entry in the Webpack configuration file:

```js
module: {
  rules: [
    {
      test: /\.node$/,
      loader: "relative-loader"
    }
  ];
}
```

## Options

Options are configurable using `options` hash:

**unlike [node-native-loader](https://github.com/smt116/node-native-ext-loader) options is required!**

```js
module: {
  rules: [
    {
      test: /\.node$/,
      loader: "relative-loader",
      options: {
        relativePath: "/../../"
      }
    }
  ];
}
```
### `relativePath`

It allows to set an relative paths to node addon files.

*Attention* Please make sure the `relativePath` starts and ends with `slash` or `backslash` (*MAKE SURE* Windows `\\\\` not `\\`)

repository: universeroc/relative-loader

repo_name: universeroc/relative-loader


text:
## Connector

[Database](../Database.md) and [Administrator](../Administrator.md) are static classes, and you usually save, retrieve and query objects with a certain level of ignorance of how the database looks ([Schema](../Schema.md)), or where it is physically located (connection string).

Not having to pass the connectionString and the `Schema` as a parameter all the time doesn't mean that you don't have the flexibility to change it when you think it is necessary. In order to change the connection in a block of your code just use `Connector.Override`.

### Connector class
You can think in a Connector class like the container that has all the information to access a specific database in a DBMS:

* The `connectionString`.
* The `Schema`.

Internally, Connection class is also the only gateway to access the database, it's not intended to be used by client code. [Executor](Executor.md) static class is what should be used if you want low-level ADO.Net access through the current connection.

You can also think of Connector class as a abstract factory of Connections:

* **Connector:** abstract base class,
	* **SqConnector:** The only supported implementation, works with Microsoft SQL Server. Contains:
		* `ConnectionString`: The connection string that will be used to create the connection.
		* `CommandTimeout`: Default timeout, optional.
		* `IsolationLevel`: Default IsolationLevel, optional.
	* **SqlCeConnector:** incomplete prototype
	* ... maybe more in the future?

### Connector.Default and Connector.Override

Typically, you application has just one main `Connector` and is set using `Connector.Default`.

`Connector.Default = new SqlConnector(connectionString, sb.Schema);`

`Connector` class has a static `Override` method that returns a `IDisposable` and let you switch `Connector.Current` to be something different to `Connector.Default` in a region of code.

```C#
public static IDisposable Override(Connector connection)
```

**Note:** It's uncommon to use more than one `Connector` using Signum.Engine for something different that simple loading scenarios. Don't expect every module to work as expected using a non-default `Connector`.

### Connector.CommandTimeoutScope

`Connector` class has a static `CommandTimeoutScope` method that returns a `IDisposable` and let you override the default `CommandTimeout` in a region of code.

```C#
public static IDisposable CommandTimeoutScope(int? timeoutMilliseconds)
```

Example:

```C#
using(Connector.CommandTimeoutScope(3 * 60 * 1000)) // 3 mins
{
   // slow query here
}
```

repository: signumsoftware/framework

gha_language: C#

repo_name: signumsoftware/framework


text:
# Code Generation

Occasionally it's preferable to use a tool to generate source code,
rather than manually write it. Bob has a few module types that support
generating code at compile time (the collection of module types that
do this are referred to as generators). In all cases generator output
is placed in an intermediate directory specific to the module.

```
bob_generate_source {
    name: "wayland_custom_protocol_code",
    srcs: ["custom_protocol.xml"],
    outs: ["code/wayland_server_custom_protocol.c"],

    args: ["code"],
    cmd: ["wayland-scanner ${args} ${in} ${out}"],
}

bob_static_library {
    name: "wayland_custom_protocol",
    generated_sources: ["wayland_custom_protocol_code"],
}
```

This calls `wayland-scanner` (which should be available in your
`PATH`) to generate `code/wayland_server_custom_protocol.c` from
`custom_protocol.xml`. The `generated_sources` property indicates that
the non-header outputs of `wayland_custom_protocol_code` should be
passed to the compiler to create the static library.

In the `cmd` and `args` properties a number of variables are available
to be used (see [reference
documentation](../module_types/common_generate_module_properties.md)).

Note that the above module does not create a dependency on
`wayland-scanner`, in the same way that dependencies are not created
on the compilers and linkers used in C compilation.

When scripts within the project are used to generate code, use the
`tools` property to add a dependency on the script.

```
bob_generate_source {
    name: "wayland_custom_protocol_code",
    srcs: ["custom_protocol.xml"],
    outs: ["code/wayland_server_custom_protocol.c"],

    tools: ["gen_wayland.py"],
    args: ["code"],
    cmd: ["${tool} ${args} ${in} ${out}"],
}

bob_static_library {
    name: "wayland_custom_protocol",
    generated_sources: ["wayland_custom_protocol_code"],
}
```

Similarly, if a compiled executable must be run to generate code, then
use the `host_bin` property.

```
bob_binary {
    name: "code_generator",
    srcs: ["code_generator/main.c"],
    host_supported: true,
    target_supported: false,
}

bob_generate_source {
    name: "source_code",
    srcs: ["templates/source.in"],
    outs: ["source.c"],

    host_bin: "code_generator",
    cmd: ["${host_bin} -o ${out} ${in}"],
}

bob_static_library {
    name: "libsource",
    generated_sources: ["source_code"],
}
```

When generating header files use `export_gen_include_dirs` to indicate
the directories within the output tree that will contain the
headers. These directories will be added to the include search path of
users.

Generators can output a mix of source code and headers. If only the
headers from the generator need to be used, use `generated_headers` to
pick them up. `generated_sources` picks up the headers, and compiles
the source code.

```
bob_generate_source {
    name: "wayland_custom_client_interface",
    srcs: ["custom_protocol.xml"],
    outs: ["inc/wayland_server_custom_protocol.h"],

    export_gen_include_dirs: ["inc"],

    args: ["client"],
    cmd: ["wayland-scanner ${args} ${in} ${out}"],
}

bob_static_library {
    name: "wayland_custom_client",
    srcs: ["wayland_client.c"],
    generated_headers: ["wayland_custom_client_interface"],
}
```

## Implicit inputs and outputs

Normally a command will mention one input file, and produce one output
file. If in doubt, stick to this pattern.

Bob needs to know about all input and output files so that
dependencies can be appropriately set up. This allows incremental
builds to work correctly.

Commands that have multiple inputs/outputs are expected to be able to
identify the inputs and outputs on the command line. i.e. for multiple
inputs a command might look like `${tool} -o ${out} ${in}` where
`${in}` ends up being more than one file; similarly for multiple
outputs `${tool} -i ${in} ${out}`; for multiple inputs _and_ multiple
outputs `${tool} -i ${in} -o ${out}` can work, as long as the tool is
taught to parse the command line appropriately.

Commands that use specific flags to identify a particular output are
not well catered for. For inputs, the template `{{match_srcs \"file.txt\"}}` can be used to name a particular file from the
module's `src` list.

The `${in}` variable contains all source files from `srcs` and
`generated_sources`. The `${out}` variable contains all the outputs
from `outs`. These are known as explicit inputs and explicit outputs
respectively, as the files are explicitly mentioned on the command
line.

If you need to name a source file that you don't want to see in
`${in}`, use `implicit_srcs`. If you need to identify an output file
that you don't want to see in `${out}`, use `implicit_outs`. These
files that do not appear on the command line are known as implicit
inputs and implicit outputs.

## Many input files with common command

`bob_generate_source` runs the given command once to produce all the
outputs from the named inputs. In the situation where you have many
input files and need to run the same command on each input file to
generate a corresponding output, use the `bob_transform_source`
module.

```
bob_transform_source {
    name: "secret_sauce",
    srcs: [
        "src/a.cpp.source",
        "src/b.cpp.source",
        "inc/a.hpp.source",
        "inc/b.hpp.source",
    ],
    outs: {
        match: "(.*)\.source",
        replace: "$1",
    },

    export_gen_include_dirs: ["inc"],

    tools: ["obfuscate.py"],
    cmd: "${tool} -o ${out} ${in}",
}

bob_static_library {
    name: "libsecret",
    generated_sources: ["secret_sauce"],
}
```

This will run the following 4 commands. The output filenames are
derived from the input filenames according to the regular expression
replacement defined by the `match` and `replace` properties. The
output is always placed in module specific intermediate directories.

```sh
obfuscate.py -o ${gen_dir}/src/a.cpp ${src_dir}/src/a.cpp.source
obfuscate.py -o ${gen_dir}/src/b.cpp ${src_dir}/src/b.cpp.source
obfuscate.py -o ${gen_dir}/inc/a.hpp ${src_dir}/inc/a.hpp.source
obfuscate.py -o ${gen_dir}/inc/b.hpp ${src_dir}/inc/b.hpp.source
```

## Generating binaries

To create binaries and libraries from arbitrary commands, the module
types `bob_generate_binary`, `bob_generate_static_library` and
`bob_generate_shared_library` should be used. These can be referenced
in the same places where the equivalent `bob_binary`,
`bob_static_library` and `bob_shared_library` module types are used.

One use for these module types is to extract a library from a
compressed archive with `tar` or a similar command.

```
bob_generate_shared_library {
    name: "libfoo",
    srcs: "libfoo.tar.bz2",
    headers: ["include/libfoo.h"],

    export_gen_include_dirs: ["include"],

    args: [
        "--strip-components=1",
        "-C",
        "${gen_dir}",
        "-xj",
    ],
    cmd: "tar ${args} -f ${in}",
}
```

Note that with binary generators, the name of the generated output
file is derived from the name of the module. The derived output
filename is treated as an explicit output and is available as
`${out}`. These generators may also create header files to go with the
library; these should be listed with the `headers` property. The
headers are implicit outputs and will not appear in `${out}`.

## Discovered dependencies

The dependencies of a given command may change when the input file is
changed. This happens with C source files and their header
dependencies. Bob's generators support discovering these dependencies
by using Makefile fragments that list the dependencies. The fragment
needs to be produced by the command that is generating the output, and
the `depfile` property lets Bob know to expect it.

The format of the Makefile is as follows. The dependencies can be
listed on a single line (just remove all line continuations `\`).

```Makefile
outputfile: \
 dependency1 \
 dependency2 \
 dependency3 \
 ...
 dependencyn
```

```
bob_generate_source {
    name: "wayland_custom_protocol_code",
    srcs: ["custom_protocol.xml]"
    outs: ["code/wayland_server_custom_protocol.c"],
    depfile: true,

    tools: ["gen_wayland.py"],
    args: [
        "code",
        "-d",
        "${depfile}",
    ],
    cmd: ["${tool} ${args} ${in} ${out}"],
}

bob_static_library {
    name: "wayland_custom_protocol",
    generated_sources: ["wayland_custom_protocol_code"],
}
```

`depfile` property has the same effect for `bob_transform_source`.

```
bob_transform_source {
    name: "secret_sauce",
    srcs: [
        "src/a.cpp.source",
        "src/b.cpp.source",
        "inc/a.hpp.source",
        "inc/b.hpp.source",
    ],
    outs: {
        match: "(.*)\.source",
        replace: "$1",
    },
    depfile: true,
    export_gen_include_dirs: ["inc"],

    tools: ["obfuscate.py"],
    cmd: "${tool} -d ${depfile} -o ${out} ${in}",
}

bob_static_library {
    name: "libsecret",
    generated_sources: ["secret_sauce"],
}
```

## Chained generators

The output of a generator can be used by another generator. There are
a few different ways to specify this depending on what needs to be used
from the output.

Use `generated_sources` when every output of a generator should be used as
an input in the next generator.

Use `generated_deps` when you only want to use certain outputs from the
earlier generator. The command(s) have access to the output directory
of the earlier generator.

The following example uses `generated_sources` to pass a generated source
file through a `bob_transform_source` as well.

```
bob_generate_source {
    name: "wayland_custom_protocol_code",
    srcs: ["custom_protocol.xml"],
    outs: ["code/wayland_server_custom_protocol.c"],

    args: ["code"],
    cmd: ["wayland-scanner ${args} ${in} ${out}"],
}

bob_transform_source {
    name: "secret_sauce",
    srcs: [
        "src/a.cpp.source",
        "src/b.cpp.source",
        "inc/a.hpp.source",
        "inc/b.hpp.source",
    ],
    generated_sources: ["wayland_custom_protocol_code"],
    outs: {
        match: "(.*)\.source",
        replace: "$1",
    },
    depfile: true,
    export_gen_include_dirs: ["inc"],

    tools: ["obfuscate.py"],
    cmd: "${tool} -d ${depfile} -o ${out} ${in}",
}

bob_static_library {
    name: "wayland_custom_protocol",
    generated_sources: ["secret_sauce"],
}
```

The next example shows how `generated_deps` might be used. For each
module named in `generated_deps` there is a variable to get the
outputs for that module. The variable is `${mod_outs}` where `mod` is
the module name. For compatibility with Soong, it is not possible to
get the intermediate output directory for the module, to prevent
modules using undeclared outputs. This forces the script to do some
filtering to find the desired input.

```
bob_generate_source {
    name: "templates",
    srcs: ["module.tar.bz2"],
    outs: [
        "x.in",
        "y.in",
        "z.in",
    ],

    args: [
        "--strip-components=1",
        "-C",
        "${gen_dir}",
        "-xj",
    ],
    cmd: "tar ${args} -f ${in}",
}

bob_generate_source {
    name: "x_code",
    generated_deps: ["templates"],
    outs: [
        "src/x.cpp",
        "inc/x.h",
    ],

    tools: ["x_generator.py"],
    cmd: "${tool} -c ${gen_dir}/src/x.cpp -h ${gen_dir}/src/x.h ${templates_out} --use x.in",
}

bob_generate_source {
    name: "y_code",
    generated_deps: ["templates"],
    outs: [
        "src/y.cpp",
        "inc/y.h",
    ],

    tools: ["y_generator.py"],
    cmd: "${tool} -c ${gen_dir}/src/y.cpp -h ${gen_dir}/src/y.h ${templates_out} --use y.in",
}

bob_static_library {
    name: "libstuff",
    generated_sources: [
        "x_code",
        "y_code",
    ],
}
```

Here's an example of encapsulating headers generated by LLVM's tblgen
in different modes.

```
bob_generate_source {
    name: "backend_emitter",
    srcs: ["src/backend.td"],
    out: ["inc/emitter.hpp"],

    export_gen_include_dir: ["inc"],
    depfile: true,

    args: [
        "-gen-emitter",
        "-d",
        "${depfile}",
    ],
    cmd: "tblgen ${args} -o ${out} ${in}",
}

bob_generate_source {
    name: "backend_registers",
    srcs: ["src/backend.td"],
    out: ["inc/registers.hpp"],

    export_gen_include_dir: ["inc"],
    depfile: true,

    args: [
        "-gen-register-info",
        "-d",
        "${depfile}",
    ],
    cmd: "tblgen ${args} -o ${out} ${in}",
}

bob_generate_source {
    name: "backend_instructions",
    srcs: ["src/backend.td"],
    out: ["inc/intructions.hpp"],
    depfile: true,

    export_gen_include_dir: ["inc"],

    args: [
        "-gen-instr-info",
        "-d",
        "${depfile}",
    ],
    cmd: "tblgen ${args} -o ${out} ${in}",
}

bob_generate_source {
    name: "backend_interface",
    srcs: ["src/backend.td"],
    out: ["inc/disassembler.hpp"],
    depfile: true,

    export_gen_include_dir: ["inc"],

    args: [
        "-gen-disassembler",
        "-d",
        "${depfile}",
    ],
    cmd: "tblgen ${args} -o ${out} ${in}",
}

bob_shared_library {
    name: "libbackend",
    srcs: ["src/backend.cpp"],
    generated_headers: [
        "backend_emitter",
        "backend_instructions",
        "backend_interface",
        "backend_registers",
    ],
}
```

### Referencing C flags

A generator's command may need to use the same compiler flags that
have been used to compile a library. An example of this is if the
generator were to invoke another build system, and wanted to pass
through the same `CFLAGS`. The `flag_defaults` property can be used to
reference a `bob_default` module where the common flags are specified.

```
bob_defaults {
    name: "build_flags",
    asflags: ["-g"],
    cflags: [
        "-g",
        "-DDEBUG=1",
    ],
    cxxflags: ["--fno-rtti"],
}

bob_generate_library {
    name: "libz",
    srcs: [
        "*.c",
        "*.cpp",
        "Makefile",
    ],
    flag_defaults: ["build_flags"],
    target: "host",

    args: [
        "-C",
        "${gen_dir}",
        "ASFLAGS=${asflags}",
        "CFLAGS=${cflags}",
        "CXXFLAGS=${cxxflags}",
    ],
    cmd: "cmake ${module_dir} --build ${gen_dir} ; make ${args}",
}
```

Note that the above is not a recommendation for using Bob to invoke
other build systems. This should be avoided, as the best way to ensure
consistent builds is for the build system to be aware of the full
dependency tree.

### Long command lines

Generator modules with lots of input or output files may sometimes exceed the
command line length limit. One way to work around this is with RSP ("response")
files. These allow parts of the command line to be written to a file instead,
where the size limit does not apply.

To use this, set the `rsp_content` field on a generator module to contain the
arguments causing the limit overrun. The build system will expand the
expression and write the result to a file just before the generator command is
run. The command can then access the file via the name stored in the
`${rspfile}` variable.

In the following example, we use an RSP file to avoid passing the list of input
files on the command line:

```
bob_generate_source {
    name: "combine_multiple_files",
    srcs: ["file1.in", ..., "file999.in"],
    generated_sources: ["module_generating_many_files"],
    out: ["combined.c"],
    tools: ["combine.sh"],
    rsp_content: "${in}",
    cmd: "${tool} --input_list ${rspfile} --out ${out}",
}
```

repository: ARM-software/bob-build

gha_language: Go

repo_name: ARM-software/bob-build


text:
# jsonbuilder for Kotlin

`jsonbuilder` is a small artifact that serves a single purpose: It allows to create json using an idiomatic [kotlin](https://kotlinlang.org/) builder DSL.

## Example

```
val myJson = json {
        "size" to 0
        "array" to arrayOf(1,2,3)
        "aggs" to {
            "num_destinations" to {
                "cardinality" to {
                    "field" to "DestCountry"
                }
            }
        }
    }
```

which will result in the following json structure:
```
{
  "size": 0,
  "array": [
    1,
    2,
    3
  ],
  "aggs": {
    "num_destinations": {
      "cardinality": {
        "field": "DestCountry"
      }
    }
  }
}
```

Both arrays and nested elements are supported without additional functions/constructs.

Installation
------------

To get started simply add it as a dependency in your `build.gradle`:
```
compile "com.github.holgerbrandl:jsonbuilder:0.6"
```

Note: Until bintray has approved the inclusion into jcenter you'll need to add the following repo
```
maven { url "https://dl.bintray.com/holgerbrandl/github" }
```

You can also use [JitPack with Maven or Gradle](https://jitpack.io/#holgerbrandl/jsonbuilder) to build the latest snapshot as a dependency in your project.

```groovy
repositories {
    maven { url 'https://jitpack.io' }
}
dependencies {
        compile 'com.github.holgerbrandl:krangl:-SNAPSHOT'
}
```

To build and install it into your local maven cache, simply clone the repo and run
```bash
./gradlew install
```

Documentation
-------------

This `README.md`. Feel welcome to file tickets about missing pieces in the docs.

How to contribute?
------------------

Feel welcome to post ideas, suggestions and criticism to our [tracker](https://github.com/holgerbrandl/jsonbuilder/issues).

We always welcome pull requests. :-)

You could also show your spiritual support by just upvoting `jsonbuilder` here on github.

# References

* https://stackoverflow.com/questions/41861449/kotlin-dsl-for-creating-json-objects-without-creating-garbage
* https://github.com/SalomonBrys/Kotson

repository: AlexCzar/jsonbuilder

repo_name: AlexCzar/jsonbuilder


text:
# cppstarter

This template provides a quick starter way of starting a new project
using the GoogleTest testing framework.

Every project should be started with writing tests first, followed by
the actual code.

## Setup

### Download

1. Automatic setup procedure

```
git clone https://github.com/breiting/cppstarter.git --recursive
```

2. Manual setup procedure

```
git clone https://github.com/breiting/cppstarter.git
git submodule update --init --recursive
```

### Compilation

Take a look at the top level CMakeLists.txt file and modify it to fit your
project's needs.

```
cd cppstarter
mkdir build
cd build
cmake ..
make
make test
```

### Requirements

* CMake version 2.8 or higher
* C++ compiler (e.g. gcc or clang)

repository: breiting/cppstarter

repo_name: breiting/cppstarter


text:
# Welcome to Spektral
Spektral is a Python library for graph deep learning, based on the Keras API and TensorFlow 2.
The main goal of this project is to provide a simple but flexible framework for creating graph neural networks (GNNs).

You can use Spektral for classifying the users of a social network, predicting molecular properties, generating new graphs with GANs, clustering nodes, predicting links, and any other task where data is described by graphs.

Spektral implements some of the most popular layers for graph deep learning, including:

- [Graph Convolutional Networks (GCN)](https://arxiv.org/abs/1609.02907)
- [Chebyshev convolutions](https://arxiv.org/abs/1606.09375)
- [GraphSAGE](https://arxiv.org/abs/1706.02216)
- [ARMA convolutions](https://arxiv.org/abs/1901.01343)
- [Edge-Conditioned Convolutions (ECC)](https://arxiv.org/abs/1704.02901)
- [Graph attention networks (GAT)](https://arxiv.org/abs/1710.10903)
- [Approximated Personalized Propagation of Neural Predictions (APPNP)](https://arxiv.org/abs/1810.05997)
- [Graph Isomorphism Networks (GIN)](https://arxiv.org/abs/1810.00826)
- [Diffusional Convolutions](https://arxiv.org/abs/1707.01926)

and many others (see [convolutional layers](https://graphneural.network/layers/convolution/)).

You can also find [pooling layers](https://graphneural.network/layers/pooling/), including:

- [MinCut pooling](https://arxiv.org/abs/1907.00481)
- [DiffPool](https://arxiv.org/abs/1806.08804)
- [Top-K pooling](http://proceedings.mlr.press/v97/gao19a/gao19a.pdf)
- [Self-Attention Graph (SAG) pooling](https://arxiv.org/abs/1904.08082)
- Global pooling
- [Global gated attention pooling](https://arxiv.org/abs/1511.05493)
- [SortPool](https://www.cse.wustl.edu/~muhan/papers/AAAI_2018_DGCNN.pdf)

Spektral also includes lots of utilities for representing, manipulating, and transforming graphs in your graph deep learning projects.

See how to [get started with Spektral](https://graphneural.network/getting-started/) and have a look at the [examples](https://danielegrattarola.github.io/spektral/examples/) for some templates.

The source code of the project is available on [Github](https://github.com/danielegrattarola/spektral).
Read the documentation [here](https://graphneural.network).

If you want to cite Spektral in your work, refer to our paper:

> [Graph Neural Networks in TensorFlow and Keras with Spektral](https://arxiv.org/abs/2006.12138)

> Daniele Grattarola and Cesare Alippi

## Installation
Spektral is compatible with Python 3.6 and above, and is tested on the latest versions of Ubuntu, MacOS, and Windows.
Other Linux distros should work as well.

The simplest way to install Spektral is from PyPi:

```bash
pip install spektral
```

To install Spektral from source, run this in a terminal:

```bash
git clone https://github.com/danielegrattarola/spektral.git
cd spektral
python setup.py install  # Or 'pip install .'
```

To install Spektral on [Google Colab](https://colab.research.google.com/):

```
! pip install spektral
```

## New in Spektral 1.0

The 1.0 release of Spektral is an important milestone for the library and brings many new features and improvements.

If you have already used Spektral in your projects, the only major change that you need to be aware of is the new `datasets` API.

This is a summary of the new features and changes:

- The new `Graph` and `Dataset` containers standardize how Spektral handles data.
**This does not impact your models**, but makes it easier to use your data in Spektral.
- The new `Loader` class hides away all the complexity of creating graph batches.
Whether you want to write a custom training loop or use Keras' famous model-dot-fit approach, you only need to worry about the training logic and not the data.
- The new `transforms` module implements a wide variety of common operations on graphs, that you can now `apply()` to your datasets.
- The new `GeneralConv` and `GeneralGNN` classes let you build models that are, well... general. Using state-of-the-art results from recent literature means that you don't need to worry about which layers or architecture to choose. The defaults will work well everywhere.
- New datasets: QM7 and ModelNet10/40, and a new wrapper for OGB datasets.
- Major clean-up of the library's structure and dependencies.
- New examples and tutorials.

## Contributing
Spektral is an open-source project available [on Github](https://github.com/danielegrattarola/spektral), and contributions of all types are welcome.
Feel free to open a pull request if you have something interesting that you want to add to the framework.

The contribution guidelines are available [here](https://github.com/danielegrattarola/spektral/blob/master/CONTRIBUTING.md) and a list of feature requests is available [here](https://github.com/danielegrattarola/spektral/projects/1).

repository: danielegrattarola/spektral

gha_language: Python

repo_name: danielegrattarola/spektral


text:
---
title: "Zipkin"
date: 2019-02-13T22:23:58-08:00
logo: /img/zipkin-logo.jpg
---

- [Introduction](#introduction)
- [Configuration](#configuration)
    - [Format](#format)
    - [Example](#example)
    - [Notes](#notes)
- [End to end example](#end-to-end-example)
    - [Running ocagent](#running-ocagent)
    - [Running Application Code](#running-application-code)
- [Results](#results)
    - [All traces](#all-traces)
    - [Single trace](#single-trace)
    - [Trace detail](#trace-detail)
- [References](#references)

### Introduction

ocagent allows one to export traces to Zipkin
![](/images/ocagent-exporter-zipkin-all-schematics.png)

### Configuration

In the ocagent's YAML configuration file, under section "exporters" and sub-section "zipkin" configure fields:

#### Format
```yaml
exporters:
  zipkin:
    service_name: "<service_name>"
    endpoint: "<endpoint_url_of_the_zipkin_server>"
    local_endpoint: "<local_endpoint_url with scheme>"
    upload_period: "<batching time as a string e.g. ms, s, m, h, d>"
```

#### Example
```yaml
# Saved in oca.yaml
exporters:
  zipkin:
    service_name: "agent_1"
    endpoint: "http://localhost:9411/api/v2/spans"
    upload_period: 4s
    local_endpoint: "localhost:5544"
```

### Notes
{{% notice warning %}}
* Please ensure that `endpoint` DOES NOT point to the same address as that of the [Zipkin receiver](/agent/receivers/zipkin/#format)
{{% /notice %}}

### End to end example

In this end-to-end example, we'll have ocagent running and a couple of Go applications
that use the [Go ocagent-exporter](/exporters/supported-exporters/go/ocagent)
to send over traces to ocagent and then to Zipkin.

### Running Zipkin
Firstly we need to get Zipkin running

{{% notice tip %}}
For assistance setting up Zipkin, [Click here](/codelabs/zipkin) for a guided codelab.
{{% /notice %}}

With Zipkin running, we are ready to proceed with running the demo.

### Running ocagent

ocagent will run with Zipkin as the only exporter, but receive traffic from ocagent-exporter-using applications.

On starting ocagent with the configuration below:
```yaml
# Saved in oca.yaml
exporters:
  zipkin:
    service_name: "agent_1"
    endpoint: "http://localhost:9411/api/v2/spans"
    upload_period: 4s
    local_endpoint: "localhost:5544"

receivers:
  opencensus:
    address: "localhost:55678"
```

On running ocagent:

```shell
$ ./bin/ocagent_darwin --config zipkin.yaml
{"level":"info","ts":1550128147.9330611,"caller":"config/config.go:424","msg":"Trace Exporter enabled","exporter":"zipkin"}
2019/02/13 23:09:08 Running OpenCensus Trace and Metrics receivers as a gRPC service at "localhost:55678"
2019/02/13 23:09:08 Running zPages at ":55679"
```

#### Running Application Code

And then running the `ocagent-go-exporter` [main.go](/exporters/supported-exporters/go/ocagent/#end-to-end-example) application

```shell
$ GO111MODULE=on go run example/main.go
Latency: 861.160ms
#0: LineLength: 432By
#1: LineLength: 366By
#2: LineLength: 765By
Latency: 11551.507ms
#0: LineLength: 920By
#1: LineLength: 921By
Latency: 7655.319ms
#0: LineLength: 558By
#1: LineLength: 725By
#2: LineLength: 508By
Latency: 651.339ms
```

### Results

On navigating to the Zipkin UI at http://localhost:9411/zipkin

####  All traces
![](/images/ocagent-exporter-zipkin-all-traces.png)

#### Single trace
![](/images/ocagent-exporter-zipkin-single-trace.png)

#### Trace detail
![](/images/ocagent-exporter-zipkin-trace-detail.png)

### References

Resource|URL
---|---
Zipkin project home|https://zipkin.io/
Go ocagent-exporter demo|[ocagent-demo](/exporters/supported-exporters/go/ocagent/#end-to-end-example)


text:
# ViscousFlow.jl

*a framework for simulating viscous incompressible flows*

The objective of this package is to allow easy setup and fast simulation of incompressible
flows, particularly those past bodies in motion. The package provides
tools for
- constructing grids and body shapes,
- specifying the relevant parameters and setting their values,
- solving the problem, and finally,
- visualizing and analyzing the results.

The underlying grids are uniform and Cartesian, making use of the [CartesianGrids](https://github.com/JuliaIBPM/CartesianGrids.jl) package. This package allows the use of the lattice
Green's function (LGF) for inverting the Poisson equation; the diffusion operators are
solved with the integrating factor (Liska and Colonius [^2]). Many of the core aspects
of the fluid-body interaction are based on the Method of Immersed Layers [^1], [ImmersedLayers](https://github.com/JuliaIBPM/ImmersedLayers.jl), which is
an extension of the immersed boundary projection method [^3]. The solver is implemented with the [ConstrainedSystems](https://github.com/JuliaIBPM/ConstrainedSystems.jl) package. Tools for creating bodies and their motions are based on the [RigidBodyTools](https://github.com/JuliaIBPM/RigidBodyTools.jl) package.

![](https://github.com/JuliaIBPM/ViscousFlow.jl/raw/master/cylinderRe400.gif)

## Installation

This package works on Julia `1.4` and above and is registered in the general Julia registry. To install from the REPL, type
e.g.,
```julia
] add ViscousFlow
```

Then, in any version, type
```julia
julia> using ViscousFlow
```

The plots in this documentation are generated using [Plots.jl](http://docs.juliaplots.org/latest/).
You might want to install that, too, to follow the examples.

## References

[^1]: Eldredge, J. D. (2021) "A method of immersed layers on Cartesian grids, with application to incompressible flows," arXiv:2103.04521.

[^2]: Liska, S. and Colonius, T. (2017) "A fast immersed boundary method for external incompressible viscous flows using lattice Green's functions," *J. Comput. Phys.*, 331, 257--279.

[^3]: Taira, K. and Colonius, T. (2007) "The immersed boundary method: a projection approach," *J. Comput. Phys.*, 225, 2118--2137.

[^4]: Wang, C. and Eldredge, J. D. (2015) "Strongly coupled dynamics of fluids and rigid-body systems with the immersed boundary projection method," *J. Comput. Phys.*, 295, 87--113. [(DOI)](https://doi.org/10.1016/j.jcp.2015.04.005).

gha_language: Julia

gha_license_id: NOASSERTION


text:
RedisAssist - Easy Redis Backed Object Modeling
==============================================

RedisAssist is a Persistant Object Model backed by Redis for Ruby.

Store and Fetch data of any type in Redis with as little friction as possible. RedisAssist lets you back simple or complex Object Models with Redis while giving you a convenient interface interact with it.

In progress RDoc: http://www.rubydoc.info/github/endlessinc/redis_assist/frames

## Getting Started
In your Gemfile:

    gem "redis_assist"

Create a model:

    class Person < RedisAssist::Base
      attr_persist :name
      attr_persist :birthday,     as: :time
      attr_persist :meta_info,    as: :json
      attr_persist :created_at,   as: :time # Magic date fields just like ActiveRecord.

      def validate
        add_error(:name, "Albert Einstein is dead.") if name.eql?('Albert Eintein')
      end
    end

## Saving
    person = Person.new(name: 'Albert Hoffman', birthday: Time.parse('1/11/1906'), meta_info: { profession: 'Scientist' })
    person.new_record?  # => true
    person.name         # => "Albert Hoffman"
    person.save         # => #<Person:0x007f88341662a0>
    person.new_record?  # => false

## Creating
    person = Person.create(name: 'Albert Hoffman', birthday: Time.parse('1/11/1906'), meta_info: { profession: 'Scientist' })

## Updating
With an instance

    person = Person.find(1)
    person.name = 'Hubble Love'
    person.save

Skip callbacks / validations

    person.update_columns(name: 'Tyler Love', birthday: Time.parse('1/11/1908'))

With only an id, this will hit callbacks and validations

    Person.update(1, name: 'Tyler Love')

## Validating
    person = Person.new(name: 'Albert Einstein', birthday: Time.parse('1/11/1906'), meta_info: { profession: 'Scientist' })
    persin.valid?       # => false
    persin.errors       # => [{name: "Albert Einstein is dead."}]

## Finding
Find by id

    person = Person.find(1)

Find an array of people

    # returns an array of people
    people = Person.find([1, 2])

Find the last people

    # Finds the last person created
    people = People.last

    # Finds the last 10 people created
    people = People.last(10)

    # Find 10 people, offset from the end of the id index by 30
    people = People.last(10, 30)

Find the first people

    # Finds the first person created
    people = People.first

    # Finds the first 10 people created
    people = People.first(10)

    # Find 10 people offset from the beginning of the id index by 30
    people = People.first(10, 30)

Find all of the people.
WARNING: If you have large data sets, you should use `find_in_batches` instead.

    people = Person.all

## Find in batches
Works just like the ActiveRecord `find_in_batches`. The most performant way to iterate over large data sets

    # Supports options
    # `batch_size` the amount of records to find in each batch. Default is `500`
    # `offset` offset from the begining of the `id` index

    People.find_in_batches do |people|
      people.each do |person|
        # do something with a person
      end
    end

## Deleting
Deletes all the persisted attributes from redis.

    person = Person.find(1)
    person.delete       # => true

A soft delete feature is built into RedisAssist. Simply add a deleted\_at attribute to your model.

    attr_persist :deleted_at, as: :time

You can fetch soft deleted records by setting a `deleted` property when calling `#find`

    Person.find(1, deleted: true)

## Callbacks
RedisAssist supports callbacks through a Rails like interface.

    before_save :titleize_blog_title
    after_create :send_to_real_time_sphinx_index
    after_update :update_in_realtime_sphinx_index

    after_delete do |record|
      record.cleanup!
    end

    def titleize_blog_title
      blog_title.titleize!
    end

    def send_to_realtime_sphinx_index
      ...
    end

    def update_in_realtime_sphinx_index
      ...
    end

## Relationships
Experimental support for has_many and belongs_to relationships.

    class Person < RedisAssist::Base
      attr_persist  :name
      has_many      :pets
    end

    class Pet < RedisAssist::Base
      attr_persist  :name
      belongs_to    :person
    end

    person = Person.create(name: 'Tyler Love')
    person.add_pet Pet.new('Hubble Love')
    person.add_pet Pet.new('Oliver Love')
    person.save

    person.pet_ids      # => [1,2]
    person.pets         # => [..pets..]

    pet = Pet.find(1)
    pet.person

## Helpful methods

The Redis client used for the class

    client = People.redis

Rename an attribute

    RedisAssist::Utils.rename_attribute(model: Person, from: :name, to: :full_name)

## Transforms
Since Redis only supports string values RedisAssist provides an interface for serialization in and out of Redis.

Currently RedisAssist natively supports the following types.

* String `default`
* Boolean
* Float
* Integer
* JSON
* Time
* list *native redis list data type*
* hash *native redis hash data type*

RedisAssist also provides an elegant API for defining custom transforms.

    # Serialize/Deserialize objects with the MessagePack gem
    class MessagePackTransform < RedisAssist::Transform
      def self.to(val)
        val.to_msgpack
      end

      def self.from(val)
        MessagePack.unpack(val)
      end
    end

To use the MessagePackTransform we just defined

    attr_persist :really_long_biography, as: :message_pack

## Useful Info

RedisAssist takes advantage of redis hashes to store each persisted attribute. Using the `Person` module as an example, the fields will be stored as a Redis Hash with the key `person:[id]:attributes`. Several other design approaches were considered. This method was selected because 1) it keeps the underlying data structures flat and normalized in Redis 2) Offers Redis Hash performance benefits, as outlined here: http://redis.io/topics/memory-optimization

Hundreds of millions of RedisAssist creates, updates, finds, and saves are called on bustle.com every month.

## In the works
* Refactor an internal API to add more robust support for native Redis data types. Currently there is basic support for lists and hashes. We intend to add advanced support for all Redis data types.
* Refactoring relationship support. RedisAssist relations are not an attempt to recreate SQL joins. The goal is to provide a convenient API for ordering, sorting, iterating over your data sets. It will never do everything a SQL `JOIN` will do, but it introduces many other practical ways of organizing, reading, and writing your data sets.
* Cleanup and 1.0
* Utilities to help with data migrations.
* `redis_assist_index` a seperate gem that adds native support for storing your redis models in Sphinx real-time indexes. Full super advanced full-text search, facets, sorting, etc. Hit me up at<EMAIL_ADDRESS>if you're interested.

## Requirements

    redis-rb

## Configuration
You can configure RedisAssist with your own redis client

    RedisAssist::Config.redis = Redis.new([connection settings...])


text:
# Azure Functions - Hello world

This example demonstrates how to write a simple echo function in Azure Functions.

In Ballerina, triggers are represented by listeners. When the `af:HttpListener` gets attached to the service, it implies that the function is an HTTP Trigger. The resource method behaves exactly the same as a service written from `ballerina/http`. It supports the `http:Payload` and `http:Header` annotations for parameters. Input binding annotations can be used to annotate parameters to make use of external services in Azure. If no annotations are specified for a parameter, it is identified as a query parameter.

Output bindings are defined in the return type definition. For services with the `HttpListener` attachment, `HttpOutput` is the default output binding. You can override the default behavior by specifying them explicitly in the return type.

In the code sample shown above, it has an empty service path and resource path named `hello`. The accessor is `get`. It expects a request with a query parameter for the field name. The required artifact generation and data binding will be handled by the `ballerinax/azure_functions` package automatically.

For more information, see the [Azure deployment guide](https://ballerina.io/learn/azure-functions/).

## Set up the prerequisites

For instructions, see [Set up the prerequisites](https://ballerina.io/learn/azure-functions/#set-up-the-prerequisites).

## Write the function

Follow the steps below to write the function.

1. Execute the command below to create a new Ballerina package.

::: out bal_new.out :::

2. Replace the content of the generated Ballerina file with the content below.

::: code azure-functions-hello-world.bal :::

## Build the function

Execute the command below to generate the Azure Functions artifacts.

::: out bal_build.out :::

## Deploy the function

Execute the Azure CLI command given by the compiler to create and publish the functions by replacing `<function_app_name>` with your respective function app name.

::: out az_deploy.out :::

## Invoke the function

Execute the command below to invoke the function by replacing `<function_app_name>` with your respective function app name.

::: out execute_function.out :::

gha_language: Java


text:
# parsind
![Travis](https://img.shields.io/travis/ramhejazi/parsind.svg)
[![npm](https://img.shields.io/npm/v/parsind.svg?style=flat-square)](https://www.npmjs.com/package/parsind)
 [![npm](https://img.shields.io/npm/dt/parsind.svg?style=flat-square)](https://www.npmjs.com/package/parsind)
 ![Coveralls github](https://img.shields.io/coveralls/github/ramhejazi/parsind.svg)

A simple JavaScript library for defining RESTful HTTP verbs and binding their router handlers automagically!
It works with any [express](http://expressjs.com/)-like routers.

**Why?** Setting HTTP route handlers and loading controllers in complex web applications with many resources can be very tiring, error-prone and repetitive process. _parsind_ tries to facilitate this process.

## Table of Contents:
- [Installation](#installation)
- [Example](#example)
- [How it works](#how-does-it-work)
  - [Parsing rules](#1-parsing-rules)
  - [Autoloading controllers](#2-autoloading-controllers)
  - [Binding route handlers](#3-binding-route-handlers)
- [Documentation](#documentation)
- [How-tos](#how-tos)
- [Terminology](#terminology)

## Installation
```
$ npm i parsind
```

## Example:
```
application_directory
├── app.js
└── controllers
    ├── indexController.js
    ├── authors
    │   ├── booksController.js
    ├── authorsController.js
    ├── books
    │   ├── authorsController.js
    │   └── tagsController.js
    ├── booksController.js
    ├── tags
    |   ├── booksController.js
    ├── tagsController.js
```

```javascript
// app.js
const express = require('express')
const path = require('path')
const parsind = require('parsind')

const app = express()

const routeParser = parsind({
  controllersDir: path.join(__dirname, 'controllers'),
  router: express.Router(),
  routes: {
    '/': 'indexController#welcome',
    'POST /foo': 'indexController#postFoo',
    'authors': ['books'],
    'books': ['authors', 'tags'],
    'tags': ['books']
  }
});

app.use('/api', routeParser.getRouter())
app.listen(3000)

```
## How does it work?
_parsind_ accepts simple JavaScript data structures (e.g. a parsed JSON string) as
a list of HTTP resources. And it then:

1. Parses the data for generating a list of HTTP routes for each resource.
2. Autoloads a controller file for each resource.
3. Uses methods of controllers for setting HTTP route handlers on the passed router.

### 1. Parsing Rules
The `routes` option can be any structure that consists of (nested) object literals and arrays.
The structure is iterated _recursively_.

#### Object literals
##### Resources
Each object key that has either an object or an array value is considered a _resource_:
```
{
  'resource_name1': [],
  'resource_name2': {},
}
```
The key, as a resource name, is used for generating several routes.
As an example, for a property that has `bars` key, by default the following routes are generated:

| HTTP verb  | URL            |
| ---------- |--------------- |
| `GET`        | `/bars`          |
| `POST`       | `/bars`          |
| `GET`        | `/bars/:bar_id`  |
| `PUT`        | `/bars/:bar_id`  |
| `PATCH`      | `/bars/:bar_id`  |
| `DELETE`     | `/bars/:bar_id`  |

The generated routes are concatenated with the parent resource's _item route_ URL.
As an example, when the parent resource's item route is `/foos/:foo_id`, then the final routes will be:

| HTTP verb  | URL                         |
| ---------- |---------------------------- |
| `GET`        | `/foos/:foo_id/bars`          |
| `POST`       | `/foos/:foo_id/bars`          |
| `GET`        | `/foos/:foo_id/bars/:bar_id`  |
| `PUT`        | `/foos/:foo_id/bars/:bar_id`  |
| `PATCH`      | `/foos/:foo_id/bars/:bar_id`  |
| `DELETE`     | `/foos/:foo_id/bars/:bar_id`  |

##### Routes

Each object key that has a `string` value is considered a route.
This syntax allows you to define _special routes_.

The key is the _route_'s URL and it's value is the _route handler_.
The key can contain a HTTP verb (in uppercase or in lowercase) .e.g. `GET /foo` or `post /bar`.
When there is no HTTP verb, the route is set as a `GET` request, e.g. `/foo`.

The value of the property refers to a method name (e.g. `getHandler`) of a controller object that should be set as the route handler.

The value can also contain a name of the controller. `#` character should be used for separating controller name and it's property name, e.g. `indexController#getHandler`.

#### Arrays
Array properties can have several elements. Each array can have many `string` or `object`
elements. A `string` element is considered a _resource_
and an `object` element is parsed according to "Object literals" rules.

The key of a property that has the array as it's value is the parent resource of array's elements.

### 2. Autoloading Controllers
#### Resources
For each resource a controller is loaded (required) on the fly.

By default, the resource controller's name is the combination of camelCased resource name and `'Controller.js'` string.
For example, for a resource that has `foo_bars` name, the module expects to find a file that has `fooBarsController.js` filename. The file's path is generated relatively to the parent resource's directory.
Parent resource's directory name of a resource is simply the name of the parent resource.
Consider this example:

```javascript
// ...
const routeParser = parsind({
  controllersPath: '/controllers',
  // other options...
  routes: {
    'books': ['authors', 'tags']
  }
});
```
The filename of `books` resource's controller should be `booksController.js`.
The file should exist in the `/controllers` directory, so the file's path is: `/controller/booksController.js`.
The `books` has 2 child resources: `authors` and `tags`. The controller name of these resources should be
`authorsController.js` and `tagsController.js`.
These 2 files must exist in their parent resource directory, i.e. the `books` directory,
so for these resources, parsind expect you to have this directory structure:

```
/controllers
├── books
│   ├── authorsController.js
│   └── tagsController.js
└── booksController.js
```
#### Special routes
As it was states previously, you can set special routes for each resource and
the value of a route key:value pair which is used for defining a route can contain
either a method name or a combination of a controller name and it's method as the route handler.

Consider this example:
```javascript
{
  'foos': {
    '/bar': 'getFoo',
    'POST /baz': 'controllerName#bazHandler'
  }
}
```
The `foos` resource has 2 child routes. In this case the `getFoo` method should be method
of the `foos` resource's controller, i.e. `foosController#getFoo`.
The `controllerName` which is specified as the controller for `POST /baz` route
should exist in the `foos` resource directory, so parsind expect you to have this directory structure:

```
/controllers
├── foos
│   └── controllerName.js
└── foosController.js
```
### 3. Binding Route Handlers
After parsing routes and loading controller file, the generated routes are set on the router.

#### Resources
By default, 6 routes for each resource is generated (configurable). The HTTP verbs of these routes are mapped to the resource controller's methods/properties.

| HTTP verb  | URL                     | Method        |
| ---------- | ----------------------- | --------------|
| `GET`        | `/resource`               | `index`         |
| `POST`       | `/resource`               | `store`         |
| `GET`        | `/resource/:resource_id`  | `show`          |
| `PUT`        | `/resource/:resource_id`  | `update`        |
| `PATCH`      | `/resource/:resource_id`  | `patch`         |
| `DELETE`     | `/resource/:resource_id`  | `destroy`       |

Each route is set on the router only when the resource controllers have the corresponding method.
For example, if the resource controller has only 2 methods named `index` and `show` then only the following routes are set:

```javascript
router.get('/resource', controller.index);
router.get('/resource/:resource_id', controller.show);
```
Any other method/property of the controller that doesn't have `index`, `store`, `show`, `update`, `patch` or `destroy` key is ignored. The value of these properties can be any value that router supports.
For example, Express framework's router allows you pass a function or an array of functions
as the route middlewares/handlers. So the controller files can have these properties:

```js
// anExampleController.js

// ...
module.exports = {
  index(req, res, next) {
      res.send('...');
  },
  // ...
  update: [validationMiddleware, function(req, res, next) {
      res.send('...');
  }]
}
```
#### Special routes
Special routes are set similar to resource routes, but the specified methods _must_ exist.

## Documentation
### Syntax
`parsind(settings)`

### Prameters
**settings**

type: _object_

A set of key/value pairs.
  - **baseRoute** (default: `"/"`)

    type: _string_

    A base route that is prepended to all generated routes.
  - **controllersDir**

  type: _string_

  The _absolute_ path of controllers directory.

  Example: `__dirname + "/controllers"`.
  - **controllersCase** (default: `"camel"`)

  type: _string_

  The case of controllers' name.
  Value can be `"camel"` for _camelCase_, `"pascal"` for _PascalCase_ or `"snake"` for _snake_case_.
  - **controllersSuffix** (default: `"controllers"`)

  This option is used for generating controller name for a resource. It can be any strings, including an empty string.
  - **controllerMethods** (default: `"{"entrance":{"get":"index","post":"store"},"item":{"get":"show","put":"update","patch":"patch","delete":"destroy"}}"`)

  type: _object_

  This option accepts an object with 2 object properties: `entrance` and `item`.
  These properties are used for setting route handlers for a resource by using properties of the resource's controller.
  `entrance` keys are used for setting routes for _resource's entrance_ URL and `item` keys are used for setting routes for resource's _item route_ URL.
  - **router**

  type: _object_

  A router object which is used for setting routes. If you are using Express framework you can pass the return value of
  `require("express")` or `require("express').Router"` function.
  - **routes**

  type: _object_ or _array_

  A list of resources. Read the "How does it work?" section.

### Return value
`parsind` is a factory function. The returned value is an instance of an ES2015 class. Each instance has the following APIs:

- #### `.addRoutes(routes)`
  Add new routes to the router.
  ###### Parameters
  - **routes**

    type: _object_ or _array_

    Check the **routes** setting.

- #### `.getRouter()`
  Get the _router_ option.

- #### `.getBoundRoutes(prettify)`
  Get the list of [successfully] bound routes.
  ###### Parameters
  - **prettify** (default: `false`)

    type: _boolean_

    Make the output more readable.

  ###### Return value
  Returns an array of bound routes. Each route is an object that has the following properties:
  - **verb**: HTTP verb of route.
  - **route**: Route's path.
  - **controller**: Controller object.
  - **method**: Name of the controller's property which has been used for setting the router handler.

- #### `.getMissingHandlers(prettify)`
  Get the list of missing route handlers.
  ###### Parameters
  - **prettify** (default: `false`)

    type: _boolean_

    Make the output more readable.

  ###### Return value
  Returns an array of missing handlers. Each route is an object that has the following properties:
  - **verb**: HTTP verb of route.
  - **route**: Route's path.
  - **controller**: Controller object.
  - **method**: Name of the controller's missing property.

## How-tos
### How to use express middlewares
Express middlewares can be set normally [by using express APIs](http://expressjs.com/en/guide/using-middleware.html):
```js
const express = require('express')
const parsind = require('parsind')

const app = express()
const router = express.Router()

// A general router-level middleware
router.use(function(req, res, next) {
  console.log('an express middleware!')
  next()
});

const routeParser = parsind({
  // ...
  router,
  routes: {
    ...
  }
});

app.use('/', routeParser.getRouter())
app.listen(3000)
```
In case that you want to add a middleware for specific resources, you can code:

```js
const express = require('express')
const parsind = require('parsind')

const app = express()
const router = express.Router()

// A general router-level middleware
// the middleware is called for both /tags... and /books... resources
router.use(function(req, res, next) {
  console.log('an express middleware!')
  next()
});

const routeParser = parsind({
  // ...
  router,
  routes: ['tags']
});

// this middleware is called only for /books... resource
router.use(function(req, res, next) {
  console.log('an express middleware!')
  next()
});

routeParser.addRoutes(['books']);

app.use('/', routeParser.getRouter())
app.listen(3000)
```
### How to extract routes' named parameters
_parsind_ uses _singular form of a resource name_ + _`_id` string_ for generating resources' _item route_. For getting these named parameters without the `_id` string you can use the following snippet (a middleware):

```js
/
/**
 * Get the route's named parameters without the `_id` segments
 * @return {array}
 */
function getNamedParametersMiddlware(req, res, next) {
    let re = /\/:(.*?)_id/g;
    req.resourceNames = [];
    let _res;
    while ((_res = re.exec(req.route.path)) !== null) {
        req.resourceNames.push(_res[1]);
    }
    next();
}
```
## Terminology
- **Resource**:
A `string` which is used for generating several _routes_.
- **Resource's entrance**:
A resource entrance URL. For example `bars` resource has `/bars` resource entrance URL.
- **Route**:
A HTTP verb + URL.
- **Item route**:
A URL that has an ID placeholder for an individual items of a resource. For example,
`bars` resource has `/bars/:bar_id` item route which is used for setting routes for reading, updating and deleting individual resource's items.
- **Special route**:
A route that is not set for each _resource_ by default.
- **Controller**
A controller is simply an object, exported in a JavaScript file that _should_ or _can_ have some methods.
The module expects you to have a controller file for each resource, even if it doesn't have any manually exported object.

## License
MIT © Ram Hejazi

repository: ramhejazi/parsind

repo_name: ramhejazi/parsind


text:
---
title: Tradeshift Makerdao Reference

language_tabs: # must be one of https://git.io/vQNgJ
  - javascript

toc_footers:
  - Sign Up for a Developer Key
  - Documentation Powered by Slate

includes:
  # - errors

search: true
---

# Getting Started

## Get the code and install dependencies
`git clone https://github.com/Tradeshift/ts-cash-js `

`git checkout develop-clean   `

`curl https://dapp.tools/install | sh  `

`git submodule update --init --recursive `

`npm install`

Now install the private npm package for Tradeshift
In the consumer project folder:
`npm login your_username  `

`npm install '@makerdao/ts-cash-js' `

Now you can run the tests. In the library folder:

`npm run test `

This will start a testnet running locally using ganache-cli

# Code Example

Here a Maker object is instantiated, and a FactorService object using the invoiceFactoring service is created. This object acts as a bridge for function calls to the Ethereum network.

```javascript
// in the index.js file
import Maker, { InvoiceFactoringService, InvoiceMarketService } from '@makerdao/ts-cash-js';

const maker = await Maker.create('test', {
    additionalServices: [
      'invoiceFactoring',
      'invoiceMarket'
    ],
    invoiceFactoring: [InvoiceFactoringService],
    invoiceMarket: [InvoiceMarketService],
    … other settings …
  });

Const factorService = maker.service('invoiceFactoring');
Get address and call
// then run node ./index.js
```

# How Maker is Initialized

The Maker object is the first object instantiated, and is the pathway to instantiate all other services.

```javascript
Import Maker, { InvoiceFactoringService, InvoiceMarketService, contracts, networks } from ‘@makerdao/ts-cash-js’;
  const mapping = networks.find(m => m.name === 'test');
  const maker = Maker.create('test', {
    additionalServices: [
      'invoiceFactoring',
      'invoiceMarket'
    ],
    invoiceFactoring: [InvoiceFactoringService],
    invoiceMarket: [InvoiceMarketService],
    smartContract: {
      addContracts: {
        [contracts.SAI]: {
          address: mapping.addresses.SAI[0].address,
          abi: mapping.addresses.SAI[0].abi
        },
        [contracts.TS_AUTH]: {
          address: mapping.addresses.TS_AUTH[0].address,
          abi: mapping.addresses.TS_AUTH[0].abi
        },
        [contracts.TS_ADMIN]: {
          address: mapping.addresses.TS_ADMIN[0].address,
          abi: mapping.addresses.TS_ADMIN[0].abi
        },
        [contracts.TS_INVESTOR]: {
          address: mapping.addresses.TS_INVESTOR[0].address,
          abi: mapping.addresses.TS_INVESTOR[0].abi
        }
      }
    }
  });
  ```

# Use Case Scenarios

 > The same private key should be used for all use case scenarios.

## Initial Contract Setup
User: Tradeshift
Assumptions: Maker object constructed (documentation), imported from ts-cash-js
Conventions
Auth = TradeshiftAuthority
User = TradeshiftUsers
Admin = TradeshiftAdmin
Investor = TradeshiftInvestor

```javascript
//Deploy contract
Auth( )
// Deploy contract
Admin(Auth address)
//Deploy contract
Investor( )
//Call contract function -
Auth.setOwner(Admin address)
//Call contract function -
Admin.setTradeshiftApproved(Investor, true)
//OR
//Approve investor contract
await maker.service(‘invoiceFactoring’).approveInvestorContract( ... )
```

repository: seanwbren/slate

repo_name: seanwbren/slate


text:
# time-radians

Convert hours/minutes/seconds to clock hand angles.

## Install

`$ npm install --save time-radians`

## Usage

```js
let timeRadians = require('time-radians');

let now = new Date();

let hoursAngle = timeRadians.hoursHand(now.getHours(), now.getMinutes(), now.getSeconds());
let minutesAngle = timeRadians.minutesHand(now.getMinutes(), now.getSeconds());
let secondsAngle = timeRadians.secondsHand(now.getSeconds());

// render clock
```

## API

`let timeRadians = require('time-radians');`

### timeRadians.hoursHand(hours, minutes = 0, seconds = 0)

Hours can be 12-hour or 24-hour.

Returns angle for hours hand, in radians.

### timeRadians.minutesHand(minutes, seconds = 0)

Returns angle for minutes hand, in radians.

### timeRadians.secondsHand(seconds)

Returns angle for seconds hand, in radians.

## Rendering tip

Assuming your clock's center looks like

```js
var center = {
  x: 100,
  y: 200
};
```

use this to figure out where to render clock hands

```js
function endPoint(center, length, radians) {
  return {
    x: center.x + (length * Math.cos(radians)),
    y: center.y - (length * Math.sin(radians))
  };
}
```

## License

MIT

repository: psalaets/time-radians

repo_name: psalaets/time-radians


text:
# ONNX_custom_layer
Guide on how to convert custom PyTorch layers when using ONNX.

##### _ADDING CUSTOM LAYERS_
For custom layers, basically, if we could trace the model/graph in pytorch using torch.jit, we could export the model to ONNX models.
Nodes in ONNX graphs do not need registering, they are simply dicts that store information. Refer to: https://pytorch.org/docs/stable/onnx.html and https://blog.csdn.net/u012436149/article/details/78829329
for more information. Also, you can refer to custom_example.py, which implements a ReLU and should export a custom layer (MyReLU) as following.

Basically, first thing you need to do is, re-write your custom layer to turn it from a legacy function to non-legacy function (which
means your custom layer is now a nn.module object, so it could be traced, if you understand Chinese, https://blog.csdn.net/u012436149/article/details/78829329). Then, modify symbolic function, what inputs to feed and what parameters to pass. Here, we do not modify symbolic.py, but keep the symbolic function inside the class, to make it more trackable. When you modify symbolic.py, or the symbolic function within the custom layer, refer to the example.

##### TO-DO
Btw, symbolic.py is a hugely useful file when converting models. So I uploaded my own version of it. Actually, ONNX supports multiple
libraries, so they are trying to support as many parameters from as many libraries (tensorflow, PyTorch, Caffe and etc.) as possible. But
if you are doing a specific conversion (for me it is Pytorch2Caffe), you do not need that many generic support. ONNX is trying to add layers
in order to support more parameters (use dynamic constant layer to store the parameter values and a "empty" layer that denotes the parameter
name), which is good, but for a specific task, quite cumbersome. Try comment out some sections in symbolic.py for better support. Do not worry
about registry stuff, every converted op is simply a dict. Just store enough useful info in the dict would be good.
- [ ] Write a blog post about symbolic.py and ONNX custom layer conversion details

```python
class MyReLUFunction(Function):

    @staticmethod
    def symbolic(g, input):
        return g.op('MyReLU', input)

    @staticmethod
    def forward(ctx, input):
        ctx.input = ctx
        return input.clamp(0)

    @staticmethod
    def backward(ctx, grad_output):
        grad_input = grad_output.clone()
        grad_input.masked_fill_(ctx.input < 0, 0)
        return grad_input

class MyReLU(nn.Module):

    def forward(self, input):
        return MyReLUFunction.apply(input)
```

```shell
graph(%0 : Float(10, 1, 3, 3)
      %1 : Float(1, 1, 3, 3)
      %2 : Float(1)) {
  %3 : Float(10, 1, 1, 1) = onnx::Conv[dilations=[1, 1], group=1, kernel_shape=[3, 3], pads=[0, 0, 0, 0]
, strides=[1, 1]](%0, %1, %2), scope: Sequential/Conv2d[0]
  %4 : Float(10, 1, 1, 1) = onnx::MyReLU(%3), scope: Sequential/MyReLU[1]
  return (%4);
}
```


text:
# Travel API Solution

### A C# website by David Sterry, Chelsea Becker, Taylor Delph
Initialized on 01/19/21
Last updated on 01/21/21

## **Project Description**
An API that allows users to GET and POST reviews about various travel destinations around the world.

## **User Stories**

As a user, I want to GET and POST reviews about travel destinations.
As a user, I want to GET reviews by city.
As a user, I want to see the most popular travel destinations by overall rating.
As a user, I want to PUT and DELETE reviews

## **Required for Use**
* C# and .Net Core installed on your local machine. Download .Net Core [Here](https://dotnet.microsoft.com/download) Follow the instructions to install on your machine
* Console/Terminal access.
* Code Editor like VSCode download [Here](https://code.visualstudio.com/) Follow the instructions to install on your machine
* MySQL Community Server download [Here](https://dev.mysql.com/downloads/mysql/) Follow the instructions to install on your machine
* MySQL Workbench [Here](https://www.mysql.com/products/workbench/) Follow the instructions to install on your machine
* Postman download [Here](https://www.postman.com/downloads/)Follow the instructions to set up an account and install on your machine
* Swashbuckle follow the setup tutorial [here](https://docs.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-2.2&tabs=visual-studio-code)
* An internet browser of your choice; I prefer Chrome

## **How to get this project**

### Download from Github:
1. Use the browser navigate to my GitHub page [respository](https://github.com/Dave-Sterry/TravelAPI)
2. Click the Green **Code** button and select **Download Zip**

### Alternatively clone from Github via Gitbash:
1. In your terminal, navigate to the folder where you would like to clone the project too
2. Clone this repo to your chosen folder using "git clone https://github.com/Dave-Sterry/TravelAPI in terminal

## **Installation Instructions**
### **Setup Database Connection**

AppSettings
* This project requires an AppSettings file. Create your `appsettings.json` file in the main `TravelAPI` directory.
* Format your `appsettings.json` file as follows including your unique password that was created at MySqlWorkbench installation:

```
{
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*",
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Port=3306;database=travel_api;uid=root;pwd=epicodus;"
  }
}

```
* Update the Server, Port, and User ID as needed with your own

Import Database using Entity Framework Core
* Navigate to TravelAPI.Solution/TravelAPI and type `dotnet ef database update` into the terminal. This will update the existing migrations

Launch the API
1. Navigate to TravelAPI.Solution/TravelAPI and type `dotnet run` into the terminal.

## API Documentation
Explore our API endpoints with Swagger Documentation:
* After launching the API, use a browser to navigate to `http://localhost:5000/swagger/`

## Endpoints
Base URL: `https://localhost:5000`

Http Request Structure

```
GET /api/{component}
POST /api/{component}
GET /api/{component}/{id}
PUT /api/{component}/{id}
DELETE /api/{component}/{id}
```
### Example Query
```
https://localhost:5000/api/cities/2
```
### Sample JSON Response
```
{
  "Id": 1,
  "Name": "Renton",
  "Rating": 9,
  "Attraction": "Boeing",
  "Review": "Some hot tubs
}
```
### Cities
Access information on cities people have reviewed

```
GET /api/cities
POST /api/cities
GET /api/cities/{id}
PUT /api/cities/{id}
DELETE /api/cities/{id}
```

#### Path Parameters
| Parameter | Type | Default | Required | Description |
| :---: | :---: | :---: | :---: | --- |
| Name | string | none | true | Return matches by city name.
| Attraction | string | none | true | Return cities by attractions. |
| Review | string | none | true | Return user review of city visited. |
| Rating| int | none | true | Return user rating of city |

### Example Query
```
https://localhost:5000/api/cities/?name=Renton
```

### Sample JSON Response
```
{
  "Id": 1,
  "Name": "Renton",
  "Rating": 9,
  "Attraction": "Boeing",
  "Review": "Some hot tubs
}
```
..........................................................................................
### Packlist
Access information on a list of things to pack for a trip

```
GET /api/packlist
POST /api/packlist
GET /api/packlist/{id}
PUT /api/packlist/{id}
DELETE /api/packlist/{id}
```

#### Path Parameters
| Parameter | Type | Default | Required | Description |
| :---: | :---: | :---: | :---: | --- |
| Items | string | none | true | Return matches by items to pack.

### Example Query
```
https://localhost:5000/api/packlist/
```

### Sample JSON Response
```
{
  "Id": 1,
  "Items": "Toothbrush, sandles, hot tub shorts"
}
```

## **Known Bugs**
No known bugs at this time

## **Technology Used**
* C# 7.3
* .NET Core 2.2
* Entity
* Git
* MySQL
* CSS
* HMTL
* Bootstrap
* Razor
* dotnet script, REPL
* Identity
* Postman
* Swagger
* Swashbuckle

## **Authors and Contributors**

    Author
    GitHub Profile
    Contact Email

    David Sterry
    https://github.com/Dave-Sterry
<EMAIL_ADDRESS>

    Taylor Delph
    https://github.com/taylulz
<EMAIL_ADDRESS>

    Chelsea Becker
    https://github.com/cschweig2
<EMAIL_ADDRESS>

## **Contact**
If you have any issues during installation delete both the bin and obj folders and follow the set up instructions again. Please contact any of the contributors if you run into any problems.

## **License**

This project is licensed under **MIT 2.0**

Copyright © 2020 David Sterry, Taylor Delph, Chelsea Becker

repository: Dave-Sterry/TravelAPI

repo_name: Dave-Sterry/TravelAPI