text:
[//000000001]: # (grammar::me\_vm \- Grammar operations and usage)
[//000000002]: # (Generated from file 'me\_vm\.man' by tcllib/doctools with format 'markdown')
[//000000003]: # (Copyright © 2005 Andreas Kupries<EMAIL_ADDRESS>[//000000004]: # (grammar::me\_vm\(n\) 0\.1 tcllib "Grammar operations and usage")

 [ Main Table Of Contents | Table Of Contents | Keyword Index | Categories | Modules | Applications ]

# NAME

grammar::me\_vm \- Virtual machine for parsing token streams

# Table Of Contents

  - [Table Of Contents](#toc)

  - [Description](#section1)

  - [MACHINE STATE](#section2)

  - [MACHINE INSTRUCTIONS](#section3)

      - [TERMINAL MATCHING](#subsection1)

      - [NONTERMINAL MATCHING](#subsection2)

      - [UNCONDITIONAL MATCHING](#subsection3)

      - [CONTROL FLOW](#subsection4)

      - [INPUT LOCATION HANDLING](#subsection5)

      - [ERROR HANDLING](#subsection6)

      - [SEMANTIC VALUES](#subsection7)

      - [AST STACK HANDLING](#subsection8)

  - [Bugs, Ideas, Feedback](#section4)

  - [Keywords](#keywords)

  - [Category](#category)

  - [Copyright](#copyright)

# DESCRIPTION

Please go and read the document __[grammar::me\_intro](me\_intro\.md)__
first for an overview of the various documents and their relations\.

This document specifies a virtual machine for the controlled matching and
parsing of token streams, creating an *[abstract syntax
tree](\.\./\.\./\.\./\.\./index\.md\#abstract\_syntax\_tree)* \(short
*[AST](\.\./\.\./\.\./\.\./index\.md\#ast)*\) reflecting the structure of the input\.
Special machine features are the caching and reuse of partial results, caching
of the encountered input, and the ability to backtrack in both input and AST
creation\.

These features make the specified virtual machine especially useful to packrat
parsers based on parsing expression grammars\. It is however not restricted to
this type of parser\. Normal LL and LR parsers can be implemented with it as
well\.

The following sections will discuss first the abstract state kept by ME virtual
machines, and then their instruction set\.

# MACHINE STATE

A ME virtual machine manages the following state:

  - *Current token* CT

    The token from the input under consideration by the machine\.

    This information is used and modified by the instructions defined in the
    section [TERMINAL MATCHING](#subsection1)\.

  - *Current location* CL

    The location of the *current token* in the input stream, as offset
    relative to the beginning of the stream\. The first token is considered to be
    at offset __0__\.

    This information is implicitly used and modified by the instructions defined
    in the sections [TERMINAL MATCHING](#subsection1) and [NONTERMINAL
    MATCHING](#subsection2), and can be directly queried and modified by the
    instructions defined in section [INPUT LOCATION
    HANDLING](#subsection5)\.

  - *Location stack* LS

    In addition to the above a stack of locations, for backtracking\. Locations
    can put on the stack, removed from it, and removed with setting the current
    location\.

    This information is implicitly used and modified by the instructions defined
    in the sections [TERMINAL MATCHING](#subsection1) and [NONTERMINAL
    MATCHING](#subsection2), and can be directly queried and modified by the
    instructions defined in section [INPUT LOCATION
    HANDLING](#subsection5)\.

  - *Match status* OK

    A boolean value, the result of the last attempt at matching input\. It is set
    to __true__ if that attempt was successful, and __false__ otherwise\.

    This information is influenced by the instructions defined in the sections
    [TERMINAL MATCHING](#subsection1), [NONTERMINAL
    MATCHING](#subsection2), and [UNCONDITIONAL
    MATCHING](#subsection3)\. It is queried by the instructions defined in
    the section [CONTROL FLOW](#subsection4)\.

  - *Semantic value* SV

    The semantic value associated with \(generated by\) the last attempt at
    matching input\. Contains either the empty string or a node for the abstract
    syntax tree constructed from the input\.

    This information is influenced by the instructions defined in the sections
    [SEMANTIC VALUES](#subsection7), and [AST STACK
    HANDLING](#subsection8)\.

  - *AST stack* AS

    A stack of partial abstract syntax trees constructed by the machine during
    matching\.

    This information is influenced by the instructions defined in the sections
    [SEMANTIC VALUES](#subsection7), and [AST STACK
    HANDLING](#subsection8)\.

  - *AST Marker stack* MS

    In addition to the above a stack of stacks, for backtracking\. This is
    actually a stack of markers into the AST stack, thus implicitly snapshooting
    the state of the AST stack at some point in time\. Markers can be put on the
    stack, dropped from it, and used to roll back the AST stack to an earlier
    state\.

    This information is influenced by the instructions defined in the sections
    [SEMANTIC VALUES](#subsection7), and [AST STACK
    HANDLING](#subsection8)\.

  - *Error status* ER

    Error information associated with the last attempt at matching input\.
    Contains either the empty string or a list of 2 elements, a location in the
    input and a list of error messages associated with it, in this order\.

    *Note* that error information can be set even if the last attempt at
    matching input was successful\. For example the \*\-operator \(matching a
    sub\-expression zero or more times\) in a parsing expression grammar is always
    successful, even if it encounters a problem further in the input and has to
    backtrack\. Such problems must not be forgotten when continuing to match\.

    This information is queried and influenced by the instructions defined in
    the sections [TERMINAL MATCHING](#subsection1), [NONTERMINAL
    MATCHING](#subsection2), and [ERROR HANDLING](#subsection6)\.

  - *Error stack* ES

    In addition to the above a stack of error information, to allow the merging
    of current and older error information when performing backtracking in
    choices after an unsucessful match\.

    This information is queried and influenced by the instructions defined in
    the sections [TERMINAL MATCHING](#subsection1), [NONTERMINAL
    MATCHING](#subsection2), and [ERROR HANDLING](#subsection6)\.

  - *Return stack* RS

    A stack of program counter values, i\.e\. locations in the code controlling
    the virtual machine, for the management of subroutine calls, i\.e\. the
    matching of nonterminal symbols\.

    This information is queried and influenced by the instructions defined in
    the section [NONTERMINAL MATCHING](#subsection2)\.

  - *Nonterminal cache* NC

    A cache of machine states \(A 4\-tuple containing a location in the input,
    match status *OK*, semantic value *SV*, and error status *ER*\) keyed
    by name of nonterminal symbol and location in the input stream\.

    The key location is where machine started the attempt to match the named
    nonterminal symbol, and the location in the value is where machine ended up
    after the attempt completed, independent of the success of the attempt\.

    This status is queried and influenced by the instructions defined in the
    section [NONTERMINAL MATCHING](#subsection2)\.

# MACHINE INSTRUCTIONS

With the machine state specified it is now possible to explain the instruction
set of ME virtual machines\. They are grouped roughly by the machine state they
influence and/or query\.

## TERMINAL MATCHING

First the instructions to match tokens from the input stream, and by extension
all terminal symbols\.

These instructions are the only ones which may retrieve a new token from the
input stream\. This is a *may* and not a *will* because the instructions will
a retrieve new token if, and only if the current location *CL* is at the head
of the stream\. If the machine has backtracked \(see __icl\_rewind__\) the
instructions will retrieve the token to compare against from the internal cache\.

  - __ict\_advance__ *message*

    This instruction tries to advance to the next token in the input stream,
    i\.e\. the one after the current location *CL*\. The instruction will fail
    if, and only if the end of the input stream is reached, i\.e\. if there is no
    next token\.

    The sucess/failure of the instruction is remembered in the match status
    *OK*\. In the case of failure the error status *ER* is set to the current
    location and the message *message*\. In the case of success the error
    status *ER* is cleared, the new token is made the current token *CT*,
    and the new location is made the current location *CL*\.

    The argument *message* is a reference to the string to put into the error
    status *ER*, if such is needed\.

  - __ict\_match\_token__ *tok* *message*

    This instruction tests the current token *CT* for equality with the
    argument *tok* and records the result in the match status *OK*\. The
    instruction fails if the current token is not equal to *tok*\.

    In case of failure the error status *ER* is set to the current location
    *CL* and the message *message*, and the current location *CL* is moved
    one token backwards\. Otherwise, i\.e\. upon success, the error status *ER*
    is cleared and the current location *CL* is not touched\.

  - __ict\_match\_tokrange__ *tokbegin* *tokend* *message*

    This instruction tests the current token *CT* for being in the range of
    tokens from *tokbegin* to *tokend* \(inclusive\) and records the result in
    the match status *OK*\. The instruction fails if the current token is not
    inside the range\.

    In case of failure the error status *ER* is set to the current location
    *CL* and the message *message*, and the current location *CL* is moved
    one token backwards\. Otherwise, i\.e\. upon success, the error status *ER*
    is cleared and the current location *CL* is not touched\.

  - __ict\_match\_tokclass__ *code* *message*

    This instruction tests the current token *CT* for being a member of the
    token class *code* and records the result in the match status *OK*\. The
    instruction fails if the current token is not a member of the specified
    class\.

    In case of failure the error status *ER* is set to the current location
    *CL* and the message *message*, and the current location *CL* is moved
    one token backwards\. Otherwise, i\.e\. upon success, the error status *ER*
    is cleared and the current location *CL* is not touched\.

    Currently the following classes are legal:

      * alnum

        A token is accepted if it is a unicode alphabetical character, or a
        digit\.

      * alpha

        A token is accepted if it is a unicode alphabetical character\.

      * digit

        A token is accepted if it is a unicode digit character\.

      * xdigit

        A token is accepted if it is a hexadecimal digit character\.

      * punct

        A token is accepted if it is a unicode punctuation character\.

      * space

        A token is accepted if it is a unicode space character\.

## NONTERMINAL MATCHING

The instructions in this section handle the matching of nonterminal symbols\.
They query the nonterminal cache *NC* for saved information, and put such
information into the cache\.

The usage of the cache is a performance aid for backtracking parsers, allowing
them to avoid an expensive rematch of complex nonterminal symbols if they have
been encountered before\.

  - __inc\_restore__ *branchlabel* *nt*

    This instruction checks if the nonterminal cache *NC* contains information
    about the nonterminal symbol *nt*, at the current location *CL*\. If that
    is the case the instruction will update the machine state \(current location
    *CL*, match status *OK*, semantic value *SV*, and error status *ER*\)
    with the found information and continue execution at the instruction refered
    to by the *branchlabel*\. The new current location *CL* will be the last
    token matched by the nonterminal symbol, i\.e\. belonging to it\.

    If no information was found the instruction will continue execution at the
    next instruction\.

    Together with __icf\_ntcall__ it is possible to generate code for
    memoized and non\-memoized matching of nonterminal symbols, either as
    subroutine calls, or inlined in the caller\.

  - __inc\_save__ *nt*

    This instruction saves the current state of the machine \(current location
    *CL*, match status *OK*, semantic value *SV*, and error status
    *ER*\), to the nonterminal cache *NC*\. It will also pop an entry from the
    location stack *LS* and save it as the start location of the match\.

    It is expected to be called at the end of matching a nonterminal symbol,
    with *nt* the name of the nonterminal symbol the code was working on\. This
    allows the instruction __inc\_restore__ to check for and retrieve the
    data, should we have to match this nonterminal symbol at the same location
    again, during backtracking\.

  - __icf\_ntcall__ *branchlabel*

    This instruction invokes the code for matching the nonterminal symbol *nt*
    as a subroutine\. To this end it stores the current program counter *PC* on
    the return stack *RS*, the current location *CL* on the location stack
    *LS*, and then continues execution at the address *branchlabel*\.

    The next matching __icf\_ntreturn__ will cause the execution to continue
    at the instruction coming after the call\.

  - __icf\_ntreturn__

    This instruction will pop an entry from the return stack *RS*, assign it
    to the program counter *PC*, and then continue execution at the new
    address\.

## UNCONDITIONAL MATCHING

The instructions in this section are the remaining match operators\. They change
the match status *OK* directly and unconditionally\.

  - __iok\_ok__

    This instruction sets the match status *OK* to __true__, indicating a
    successful match\.

  - __iok\_fail__

    This instruction sets the match status *OK* to __false__, indicating a
    failed match\.

  - __iok\_negate__

    This instruction negates the match status *OK*, turning a failure into a
    success and vice versa\.

## CONTROL FLOW

The instructions in this section implement both conditional and unconditional
control flow\. The conditional jumps query the match status *OK*\.

  - __icf\_jalways__ *branchlabel*

    This instruction sets the program counter *PC* to the address specified by
    *branchlabel* and then continues execution from there\. This is an
    unconditional jump\.

  - __icf\_jok__ *branchlabel*

    This instruction sets the program counter *PC* to the address specified by
    *branchlabel*\. This happens if, and only if the match status *OK*
    indicates a success\. Otherwise it simply continues execution at the next
    instruction\. This is a conditional jump\.

  - __icf\_jfail__ *branchlabel*

    This instruction sets the program counter *PC* to the address specified by
    *branchlabel*\. This happens if, and only if the match status *OK*
    indicates a failure\. Otherwise it simply continues execution at the next
    instruction\. This is a conditional jump\.

  - __icf\_halt__

    This instruction halts the machine and blocks any further execution\.

## INPUT LOCATION HANDLING

The instructions in this section are for backtracking, they manipulate the
current location *CL* of the machine state\. They allow a user of the machine
to query and save locations in the input, and to rewind the current location
*CL* to saved locations, making them one of the components enabling the
implementation of backtracking parsers\.

  - __icl\_push__

    This instruction pushes a copy of the current location *CL* on the
    location stack *LS*\.

  - __icl\_rewind__

    This instruction pops an entry from the location stack *LS* and then moves
    the current location *CL* back to this point in the input\.

  - __icl\_pop__

    This instruction pops an entry from the location stack *LS* and discards
    it\.

## ERROR HANDLING

The instructions in this section provide read and write access to the error
status *ER* of the machine\.

  - __ier\_push__

    This instruction pushes a copy of the current error status *ER* on the
    error stack *ES*\.

  - __ier\_clear__

    This instruction clears the error status *ER*\.

  - __ier\_nonterminal__ *message*

    This instruction checks if the error status *ER* contains an error whose
    location is just past the location found in the top entry of the location
    stack *LS*\. Nothing happens if no such error is found\. Otherwise the found
    error is replaced by an error at the location found on the stack, having the
    message *message*\.

  - __ier\_merge__

    This instruction pops an entry from the error stack *ES*, merges it with
    the current error status *ER* and stores the result of the merge as the
    new error status *ER*\.

    The merge is performed as described below:

    If one of the two error states is empty the other is chosen\. If neither
    error state is empty, and refering to different locations, then the error
    state with the location further in the input is chosen\. If both error states
    refer to the same location their messages are merged \(with removing
    duplicates\)\.

## SEMANTIC VALUES

The instructions in this section manipulate the semantic value *SV*\.

  - __isv\_clear__

    This instruction clears the semantic value *SV*\.

  - __isv\_terminal__

    This instruction creates a terminal AST node for the current token *CT*,
    makes it the semantic value *SV*, and also pushes the node on the AST
    stack *AS*\.

  - __isv\_nonterminal\_leaf__ *nt*

    This instruction creates a nonterminal AST node without any children for the
    nonterminal *nt*, and makes it the semantic value *SV*\.

    This instruction should be executed if, and only if the match status *OK*
    indicates a success\. In the case of a failure __isv\_clear__ should be
    called\.

  - __isv\_nonterminal\_range__ *nt*

    This instruction creates a nonterminal AST node for the nonterminal *nt*,
    with a single terminal node as its child, and makes this AST the semantic
    value *SV*\. The terminal node refers to the input string from the location
    found on top of the location stack *LS* to the current location *CL*
    \(both inclusive\)\.

    This instruction should be executed if, and only if the match status *OK*
    indicates a success\. In the case of a failure __isv\_clear__ should be
    called\.

  - __isv\_nonterminal\_reduce__ *nt*

    This instruction creates a nonterminal AST node for the nonterminal *nt*
    and makes it the semantic value *SV*\.

    All entries on the AST stack *AS* above the marker found in the top entry
    of the AST Marker stack *MS* become children of the new node, with the
    entry at the stack top becoming the rightmost child\. If the AST Marker stack
    *MS* is empty the whole stack is used\. The AST marker stack *MS* is left
    unchanged\.

    This instruction should be executed if, and only if the match status *OK*
    indicates a success\. In the case of a failure __isv\_clear__ should be
    called\.

## AST STACK HANDLING

The instructions in this section manipulate the AST stack *AS*, and the AST
Marker stack *MS*\.

  - __ias\_push__

    This instruction pushes the semantic value *SV* on the AST stack *AS*\.

  - __ias\_mark__

    This instruction pushes a marker for the current state of the AST stack
    *AS* on the AST Marker stack *MS*\.

  - __ias\_mrewind__

    This instruction pops an entry from the AST Marker stack *MS* and then
    proceeds to pop entries from the AST stack *AS* until the state
    represented by the popped marker has been reached again\. Nothing is done if
    the AST stack *AS* is already smaller than indicated by the popped marker\.

  - __ias\_mpop__

    This instruction pops an entry from the AST Marker stack *MS* and discards
    it\.

# Bugs, Ideas, Feedback

This document, and the package it describes, will undoubtedly contain bugs and
other problems\. Please report such in the category *grammar\_me* of the
[Tcllib Trackers](http://core\.tcl\.tk/tcllib/reportlist)\. Please also report
any ideas for enhancements you may have for either package and/or documentation\.

When proposing code changes, please provide *unified diffs*, i\.e the output of
__diff \-u__\.

Note further that *attachments* are strongly preferred over inlined patches\.
Attachments can be made by going to the __Edit__ form of the ticket
immediately after its creation, and then using the left\-most button in the
secondary navigation bar\.

# KEYWORDS

[grammar](\.\./\.\./\.\./\.\./index\.md\#grammar),
[parsing](\.\./\.\./\.\./\.\./index\.md\#parsing), [virtual
machine](\.\./\.\./\.\./\.\./index\.md\#virtual\_machine)

# CATEGORY

Grammars and finite automata

# COPYRIGHT

Copyright © 2005 Andreas Kupries<EMAIL_ADDRESS>

repository: markemer/macports-base

gha_language: Tcl

repo_name: markemer/macports-base


text:
---
pill: cli_migrate
subtitle: 'Command-line: migrate'
---
# Command-line: migrate

Migrates the schema to the latest version. Flyway will create the schema history table automatically if it doesn't
    exist.

## Usage

> flyway [options] migrate

## Options

See [configuration](Configuration/parameters) for a full list of supported configuration parameters.

## Sample configuration

```properties
flyway.driver=org.hsqldb.jdbcDriver
flyway.url=jdbc:hsqldb:file:/db/flyway_sample
flyway.user=SA
flyway.password=mySecretPwd
flyway.connectRetries=10
flyway.initSql=SET ROLE 'myuser'
flyway.defaultSchema=schema1
flyway.defaultCatalogs=catalog1
flyway.schemas=schema1,schema2,schema3
flyway.createSchemas=true
flyway.table=schema_history
flyway.tablespace=my_tablespace
flyway.locations=classpath:com.mycomp.migration,database/migrations,filesystem:/sql-migrations,s3:migrationsBucket,gcs:migrationsBucket
flyway.sqlMigrationPrefix=Migration-
flyway.undoSqlMigrationPrefix=downgrade
flyway.repeatableSqlMigrationPrefix=RRR
flyway.sqlMigrationSeparator=__
flyway.sqlMigrationSuffixes=.sql,.pkg,.pkb
flyway.stream=true
flyway.batch=true
flyway.encoding=ISO-8859-1
flyway.placeholderReplacement=true
flyway.placeholders.aplaceholder=value
flyway.placeholders.otherplaceholder=value123
flyway.placeholderPrefix=#[
flyway.placeholderSuffix=]
flyway.resolvers=com.mycomp.project.CustomResolver,com.mycomp.project.AnotherResolver
flyway.skipDefaultCallResolvers=false
flyway.callbacks=com.mycomp.project.CustomCallback,com.mycomp.project.AnotherCallback
flyway.skipDefaultCallbacks=false
flyway.target=5.1
flyway.outOfOrder=false
flyway.outputQueryResults=false
flyway.validateOnMigrate=true
flyway.cleanOnValidationError=false
flyway.mixed=false
flyway.group=false
flyway.cleanDisabled=false
flyway.baselineOnMigrate=false
flyway.installedBy=my-user
flyway.errorOverrides=99999:17110:E,42001:42001:W
flyway.dryRunOutput=/my/sql/dryrun-outputfile.sql
flyway.lockRetryCount=10
flyway.oracle.sqlplus=true
flyway.oracle.sqlplusWarn=true
flyway.workingDirectory=C:/myProject
flyway.jdbcProperties.myProperty=value
```

## Sample output

> flyway migrate

Flyway {{ site.flywayVersion }} by Redgate

Database: jdbc:h2:file:flyway.db (H2 1.3)
Successfully validated 5 migrations (execution time 00:00.010s)
Creating Schema History table: "PUBLIC"."flyway_schema_history"
Current version of schema "PUBLIC": << Empty Schema >>
Migrating schema "PUBLIC" to version 1 - First
Migrating schema "PUBLIC" to version 1.1 - View
Successfully applied 2 migrations to schema "PUBLIC" (execution time 00:00.030s).

## Sample JSON output

> flyway migrate -outputType=json

{
  "initialSchemaVersion": null,
  "targetSchemaVersion": "1",
  "schemaName": "public",
  "migrations": [
    {
      "category": "Versioned",
      "version": "1",
      "description": "first",
      "type": "SQL",
      "filepath": "C:\\flyway\\sql\\V1__first.sql",
      "executionTime": 0
    },
    {
      "category": "Repeatable",
      "version": "",
      "description": "repeatable",
      "type": "SQL",
      "filepath": "C:\\flyway\\sql\\R__repeatable.sql",
      "executionTime": 0
    }
  ],
  "migrationsExecuted": 2,
  "flywayVersion": "{{ site.flywayVersion }}",
  "database": "testdb",
  "warnings": [],
  "operation": "migrate"
}

url: https://raw.githubusercontent.com/nycjay/flyway/16730ccdbbb3fbd079a0b21fd3f58d0ea8e5898d/documentation/Flyway CLI and API/Usage/Command-line/Command-line - migrate.md

repository: nycjay/flyway

branch_name: refs/heads/main

extension: md

filename: Command-line - migrate.md

gha_language: Java

license_type: permissive

repo_name: nycjay/flyway


text:
---
title: CircleCI
description: Examples and instructions for setting up deps in CircleCI
---

# CircleCI

## 1. Set your environment variables

For deps variables that should be kept secret (such as `DEPS_GITHUB_TOKEN`) you'll want to use a [context](https://circleci.com/docs/2.0/contexts/).
You can get your `DEPS_TOKEN` from [3.dependencies.io](https://3.dependencies.io).

[![CircleCI context for deps](/assets/img/screenshots/circleci-context.png)](/assets/img/screenshots/circleci-context.png)

## 2. Add a deps workflow triggered by cron

This example shows two different languages in use,
each running in their own container.

The `--type` option is used to run the specific language updates in their respective containers.

> Note: CircleCI is supported by [CI autoconfigure](/ci/#autoconfigure).

```yaml
version: 2
jobs:

  # in addition to your existing jobs

  deps-python:
    docker:
      - image: circleci/python:3.7
    steps:
      - checkout
      - run: curl https://deps.app/install.sh | bash -s -- -b $HOME/bin
      - run: pipenv sync --dev
      - run: $HOME/bin/deps ci --type python
  deps-node:
    docker:
      - image: circleci/node:12
    steps:
      - checkout
      - run: curl https://deps.app/install.sh | bash -s -- -b $HOME/bin
      - run: yarn install
      - run: $HOME/bin/deps ci --type js

workflows:
  version: 2
  # in addition to your existing workflows
  deps:
    jobs:
      - deps-python:
          context: deps
      - deps-node:
          context: deps
    triggers:
      - schedule:
          cron: "0 0 * * *"  # nightly
          filters:
            branches:
              only:
                - master
```

license: MIT

repository: watonist/deps

branch_name: refs/heads/master

repo_name: watonist/deps


text:
@# Date range input

The __DateRangeInput__ component is [__ControlGroup__](#core/components/control-group) composed
of two [__InputGroups__](#core/components/input-group). It shows a
[__DateRangePicker__](#datetime/daterangepicker) in a [__Popover__](#core/components/popover)
on focus.

Unlike [__DateInput__](#datetime/date-input), this component does _not_ yet have support for
a built-in [__TimezoneSelect__](#datetime/timezone-select).

<!-- It optionally shows a [TimezoneSelect](#datetime/timezone-select) as the third
element in the ControlGroup, allowing the user to change the timezone of the selected date range. -->

@reactExample DateRangeInputExample

@## Usage

__DateRangeInput__ supports both controlled and uncontrolled usage. You can control
the selected date by setting the `value` prop, or use the component in
uncontrolled mode and specify an initial date by setting `defaultValue`.
Use the `onChange` prop callback to listen for changes to the selected day and
the `onError` prop to react to invalid dates entered in the text inputs.

@## Date formatting

Customize the date format with the required `formatDate` and `parseDate` props.
See [DateInput's date formatting docs](#datetime/date-input.date-formatting) for more details.

@## Props interface

@interface DateRangeInputProps

@## Localization

See the [DatePicker localization docs](#datetime/datepicker.localization).

repository: palantir/blueprint

branch_name: refs/heads/develop

gha_language: TypeScript

repo_name: palantir/blueprint


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).

## [1.0.1]
### Changed
- Fix `PlayFromInitialScene` been shared between projects, now its individual
- Added icon for the Save All
- Fix Easy Selection to Ping target object as well.
- Fix making default Name and Description from the default extendable base item

## [1.0.0]
### Added
- First initial working version

### Unreleased

[1.0.1]: https://github.com/brunomikoski/Toolbar/releases/tag/v1.0.1
[1.0.0]: https://github.com/brunomikoski/Toolbar/releases/tag/v1.0.0

repository: brunomikoski/Toolbar

repo_name: brunomikoski/Toolbar


text:
## Bell Numbers

Use bottom-up DP to solve Bell numbers. This code uses Stirling numbers to calculate Bell numbers.
This is due to the following recurrence:

B(n) = sum_{k = 0}^{n} S(n,k)

The code also includes the calculation using the Bell triangle.

__Complexity__
* DP version: polinomial.

__References__

[[1]](https://en.wikipedia.org/wiki/Stirling_numbers_of_the_second_kind) Stirling numbers of the second kind, Wikipedia.

[[2]](https://en.wikipedia.org/wiki/Bell_number) Bell number, Wikipedia.

## Notes

Relation of Stirling numbers with Bell numbers.

![Alt text](/BellNumbers/stirling_bell.png?raw=true "Relationship between Bell number and Stirling numbers")


text:
# FixedPriceOrder

## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**id** | **str** | The Order's identifier, unique within the Order's Account. | [optional]
**create_time** | **str** | The time when the Order was created. | [optional]
**state** | **str** | The current state of the Order. | [optional]
**client_extensions** | [**ClientExtensions**](ClientExtensions.md) |  | [optional]
**type** | **str** | The type of the Order. Always set to \"FIXED_PRICE\" for Fixed Price Orders. | [optional]
**instrument** | **str** | The Fixed Price Order's Instrument. | [optional]
**units** | **str** | The quantity requested to be filled by the Fixed Price Order. A posititive number of units results in a long Order, and a negative number of units results in a short Order. | [optional]
**price** | **str** | The price specified for the Fixed Price Order. This price is the exact price that the Fixed Price Order will be filled at. | [optional]
**position_fill** | **str** | Specification of how Positions in the Account are modified when the Order is filled. | [optional]
**trade_state** | **str** | The state that the trade resulting from the Fixed Price Order should be set to. | [optional]
**take_profit_on_fill** | [**TakeProfitDetails**](TakeProfitDetails.md) |  | [optional]
**stop_loss_on_fill** | [**StopLossDetails**](StopLossDetails.md) |  | [optional]
**trailing_stop_loss_on_fill** | [**TrailingStopLossDetails**](TrailingStopLossDetails.md) |  | [optional]
**trade_client_extensions** | [**ClientExtensions**](ClientExtensions.md) |  | [optional]
**filling_transaction_id** | **str** | ID of the Transaction that filled this Order (only provided when the Order's state is FILLED) | [optional]
**filled_time** | **str** | Date/time when the Order was filled (only provided when the Order's state is FILLED) | [optional]
**trade_opened_id** | **str** | Trade ID of Trade opened when the Order was filled (only provided when the Order's state is FILLED and a Trade was opened as a result of the fill) | [optional]
**trade_reduced_id** | **str** | Trade ID of Trade reduced when the Order was filled (only provided when the Order's state is FILLED and a Trade was reduced as a result of the fill) | [optional]
**trade_closed_i_ds** | **list[str]** | Trade IDs of Trades closed when the Order was filled (only provided when the Order's state is FILLED and one or more Trades were closed as a result of the fill) | [optional]
**cancelling_transaction_id** | **str** | ID of the Transaction that cancelled the Order (only provided when the Order's state is CANCELLED) | [optional]
**cancelled_time** | **str** | Date/time when the Order was cancelled (only provided when the state of the Order is CANCELLED) | [optional]

[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)


text:
# nixie
## Nixie tube

Nixie tubes were used extensivaly in 60's and 70's in various instruments to display digits and other symbols. They are cold cathode tubes made of glass with one anode (a grid) and multiple cathodes, each of which is shaped like the displayed sign.

Cold cathode means that the tube is cool during operation (usually does not exceed 40°C). However, it runs on high voltage (around 200V), so do not attempt to build this project if you don't know exactly what you are doing.

## Clock

- features four tubes to display hours and minutes
- has an alarm
- is powered by 12V DC
- easily reprogrammable with a PICkit3
- can communicate via serial
- time is battery backed

## Electronics

- Microchip PIC16F722A/723A microcontroller
- Microchip MCP7940N real-time clock/calendar
- switching HV supply
- multiplexed display: one anode pulled to HV, BCD driver pulls selected cathode to ground

## I/O

### Inputs

- rotary encoder with a momentary switch
- push-button (optional)
- anode voltage trimmer

### Outputs

- 4 nixie tubes with digits 0-9
- two LEDs in the upper left-hand corner
- buzzer connector (12V)

### Serial port

There is an optional 3-pin header with GND, TX and RX available should there be a need for interfacing with other equipment.

repository: skurella/nixie

repo_name: skurella/nixie


text:
[![Build Status](https://travis-ci.org/asmcup/runtime.svg)](https://travis-ci.org/asmcup/runtime)
[![Join the chat](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/asmcup/Lobby)

# asmcup

`asmcup` is a game where players create small and limited programs
to power robots in a virtual environment to compete for prizes.

It is currently in active beta development.

## Screenshot

![](http://i.imgur.com/Snvjuon.gif)

## Getting Started

The quickest way to get started is to download
[asmcup.jar](https://github.com/asmcup/runtime/releases)
and run it. This will launch the Sandbox which allows you to write, compile,
and debug your robot. **You need to have Java 8 installed to run the Jar file.**

You can find sample bots to try out over [here](https://github.com/asmcup/bots),
and there's a [first steps](https://github.com/asmcup/runtime/wiki/Programming) guide.

asmcup.jar also has command line tools:

 * `asmcup.compiler.Main` compiles assembly source into binaries
 * `asmcup.decompiler.Main` decompiles binary files into source
 * `asmcup.runtime.Main` simulates a game world via the command line

If you want to improve the Sandbox or make changes to the game code itself
you can either import the project into Eclipse or build using `gradle jar`.

## Compete

Made a robot you think can hold its own on our servers?

*Note we aren't ready for uploading until come November*

 * [Upload your robot](https://asmcup.github.io)

## Specifications

If you want to code a robot, you should take a look at the
[SPEC.md](https://github.com/asmcup/runtime/blob/master/SPEC.md) file for details
on the available instructions and operations.

## Game Basics

The game world is randomly generated based on a seed value. This allows anyone
to easily generate a new world and test their robot within it. When running the
code on our servers, the seed value will be randomized and all bots will have to
discover the world they have been placed into and compete for resources.

The world consists of tiles of size 32x32. Aside from normal ground tiles,
there are tiles with items, hazards, obstacles and walls/rooms. Robots have
multiple ways of interacting with the world, ranging from controls for motor
and steering over a beam sensor, a laser, a compass and more to being able to
(*WIP*) communicating with each other.

It is planned that multiple robots will be able to compete in the same world,
including the ability to fight each other.

### Items

The main goal of each robot is to collect gold, which occurs as item in the world.
Players will receive prizes based on the amount of gold their robots collected.
Robots can also pick up battery items to recharge their internal battery, which is
consumed when executing instructions and taking damage.

### Hazards

There are currently 4 different hazards that penalize robots for standing in them:

* Mud pit (low damage)
* Water pit (medium damage)
* Fire pit (severe damage)
* Deep pit  (instant death)

### Obstacles

There are four types of obstacles, with the first two just being basic doodads
in the game world like stumps and bushes. The last two are rocks which can be
destroyed with a laser.

### Rooms

Some areas of the game world spawn "rooms", which are walled off areas, sometimes
with rocks blocking their entrances. Some rooms can have hazards as walls, these
have more loot in them.

repository: asmcup/runtime

gha_license_id: MIT

repo_name: asmcup/runtime


text:
---
layout: page
title: Site Walkthrough
tags: [walkthrough, meteor, galaxy, olelo]
date: 2018-04-18
comments: false
---

ʻŌlelo International is a networking app for University of Hawai'i at Manoa students taking language courses.

## Landing Page
When you first open up the application, you will see the landing page which invites users to join ʻŌlelo International. The user may sign in or sign up by clicking on the 'Login' icon at the top right corner of the page.

## Register
If the user doesn't yet have an account, they can register with their UH System username and password, along with some information about the language course they're taking, if they're a student or faculty memeber, etc.

## Sign In
Site will require users to sign up with a hawaii.edu email. If any other email is used, site will generate an error.

## User Home Page
When the user logs in, they will see a page similar to the landing page but has a link to the Langauge Forums in the NavBar.

## Language Forums Page
Originally we decided that we would create a dropdown for "Language Forums" where the user would be able to select the specific langauge forum that they are taking corresponding courses in. However, since UH Manoa offers many language courses, the dropdown would likely be very lengthy and look messy. So instead we decided to have a Lanuage Forums page that contains links to each of the language forums.

## Language Pages
Separate pages for each language (i.e. Japanese, Korean). Pages will be forum style. Posts are sorted from newest (left) to oldest (right).

Users can make a post (i.e. asking if someone wants to meet up). Other users can comment on that post.

The user will get a notification if their post was added successfully.


text:
---
templateKey: about-page
title: About She Daddy
---
She Daddy is a project started by Justice Marks in 2018 to support and organize direct action using grassroots tactics in new ways. She is currently based in Chicago, IL, USA and is making connections across the US to synthesize a community focused on compassionate and communal care. She works as  software developer and works to support harm reduction throughout the Midwest.

# About us

She Daddy is a platform for individuals to bring cutting edge grassroots tactics to their own communities. She Daddy's current initiative is to bring comprehensive standards for safety and overdose prevention to DIY Electronic scenes and serve as a reference for those just starting out in bringing direct action to their communities.

# Questions?

[Contact us through our form](https://shedaddy.com/contact) or send an email to the [site maintainer and founder](mailto:her@shedaddy.com).

repository: justrmarks/shedaddy-com

gha_language: JavaScript

repo_name: justrmarks/shedaddy-com


text:
# blinkmobile / server-cli

## CORS Configuration

[Cross-Origin Resource Sharing](https://www.w3.org/TR/cors/) protocol allows browsers to make cross-origin API calls.
CORS is required by web applications running inside a browser which are loaded from a different domain than the API server.

CORS can be configured in a `.blinkmrc.json` file that is in the root of your project directory e.g.

### Directory Structure

```
|-- project-root
|   |-- .blinkmrc.json
|   |-- helloworld
|   |   |-- index.js
```

### .blinkmrc.json

By setting `cors` to `false`, Cross-Origin resource sharing will not be allowed. **This is the default behaviour**

```json
{
  "server": {
    "cors": false
  }
}
```

Cross-Origin resource sharing can also be configured as below:
- origins: https://www.w3.org/TR/cors/#access-control-allow-origin-response-header
- headers: https://www.w3.org/TR/cors/#access-control-allow-headers-response-header
- exposedHeaders: https://www.w3.org/TR/cors/#access-control-expose-headers-response-header
- credentails: https://www.w3.org/TR/cors/#access-control-allow-credentials-response-header
- maxAge: https://www.w3.org/TR/cors/#access-control-max-age-response-header

### Example
**Note:** If any properties are omitted, they will default to:

```json
{
  "server": {
    "cors": {
      "origins": [
        "*"
      ],
      "headers": [
        "Accept",
        "Authorization",
        "Content-Type",
        "If-None-Match",
        "X-Amz-Date",
        "X-Amz-Security-Token",
        "X-Api-Key"
      ],
      "exposedHeaders": [
        "Server-Authorization",
        "WWW-Authenticate"
      ],
      "credentials": false,
      "maxAge": 86400 // in seconds = 1 day
    }
  }
}
```

Alternatively `cors` can be set to `true` to use the defaults above.

```json
{
  "server": {
    "cors": true
  }
}
```

repository: oneblink/server-cli

repo_name: oneblink/server-cli


text:
# Frontstart - Quickly make awesome projects with the help of html5-boilerplate and Bootstrap

Frontstart is a series of gulp tasks that help you quickly setup your frontend development, without too many complex packages or libraries, is like an artist blank canvas.

The tasks basically are the following:

- Copy html5-boilerplate dist folder from node_modules to our main newly created app folder
- Copy bootstrap core scss files to our core app/scss folder
- Create an empty main.scss file for you to start your journey from there. You should import bootstrap files and your custom scss here, is up to you how you want to proceed.
- After that you need to execute another task to watch your html and scss for changes and live reloading.

# Setup

After cloning or downloading this repo,
First, make sure you have node and gulp installed on your system,
On your terminal, navigate to the root frontstart folder and execute:

```
npm install
```

then:

```
gulp frontstart
```

and lastly:

```
gulp happyfrontending
```

Start making your magic on app/index.html or whatever .html file, and changing styles on scss/main.scss to livereload.
Watch your changes live, as you've made them on:

```
http://localhost:8080/
```

Voila!

# Dependencies

- gulp
- gulp-sass
- gulp-connect
- html5-boilerplate
- bootstrap

# TO-DO

- css uglify
- html uglify
- image optimization
- deploy a dist folder for production

repository: javierpreda/frontstart

repo_name: javierpreda/frontstart


text:
---
layout: post
title: Developing a tabs component in Angular
date: 2015-04-09T00:00:00.000Z
update_date: 2016-12-16T00:00:00.000Z
summary: >-
  This article details how to build a simple, but widely used type of component
  in Angular: tabs.
categories:
  - angular
tags:
  - angular2
topic: getting-started
author: pascal_precht
demos:
  - url: 'http://embed.plnkr.co/KU8eGM/'
    title: Tabs Component build with Angular 2 (RC4)
  - url: 'https://plnkr.co/edit/LEpgaP?p=preview'
    title: Tabs Component build with Angular 2 (RC5)
  - url: 'https://embed.plnkr.co/afhLA8wHw9LRnzwwTT3M/'
    title: Tabs Component using @ContentChildren
related_posts:
  - RxJS Master Class and courseware updates
  - Advanced caching with RxJS
  - Custom Overlays with Angular's CDK - Part 2
  - Custom Overlays with Angular's CDK
  - Easy Dialogs with Angular Material
  - A web animations deep dive with Angular
related_videos:
  - '175255006'
  - '193524896'
  - '189792758'
  - '189785428'
  - '175218351'
  - '189618526'

---
Just recently, we wrote about how to [build a zippy component](/angular/2015/03/27/building-a-zippy-component-in-angular-2.html) in Angular. We explored how to get started with the framework and learned about some concepts that it comes with to build a very simple component. If you haven't read the article, you might want to check it out.

As a follow up, we now want to build yet another component that is widely used in a lot of applications: Tabs. Building tabs has always been the de facto example when it comes to explaining directive controllers in Angular. Angular >= 2.x does not have the concept of directive controllers, because the component itself is the execution context. It also makes it much easier to access other directives and components through dependency injection. However, you **do** want to [use directive controllers](/angularjs/2015/01/02/exploring-angular-1.3-bindToController.html) in Angular 1.x in order to make the migration process to Angular >= 2.x easier.

{% include demos-and-videos-buttons.html post=page %}

Let's start right away and learn how easy it is to build a tabs component in Angular without the confusing relationship between directive link functions and controllers. We'll skip the installation part, since that was explored in the other article.

### TABLE OF CONTENTS
{:.no_toc}
* TOC
{:toc}

## What it should look like

Before we start implementing the actual component, let's first clarify what we want to achieve from a consumer point of view. Building tabs with web technologies usually ends up with having a HTML list, that represents the tabs, and container elements per each tab that display the content of a tab.

Of course, in Angular, those implementation details are hidden behind some nice readable and declarative elements that we all know as directives. Having a tool like Angular (and also Web Components) allows us to create custom elements, so that a consumer could use something like the following snippet to add tabs to an application:

{% highlight html %}
{% raw %}
<tabs>
  <tab tabTitle="Tab 1">
    Here's some content.
  </tab>
  <tab tabTitle="Tab 2">
    And here's more in another tab.
  </tab>
</tabs>
{% endraw %}
{% endhighlight %}

We have a `<tab>` element that simply represents a single tab which has a title, and we have a `<tabs>` element that takes care of making those `<tab>` elements actually "tabbable".

If you've been following the development and concepts of Angular, you probably learned that, since Angular 2.x, the **consumer** of a component is in charge of deciding how a value is passed to a component. Whereas in Angular 1.x, the directive defines how a value is bound to it's scope, so the consumer needs to know about the inner workings of a directive.

This means, talking about the `tabTitle` attribute that we have in the code above, consumers can either write to the component attribute (if it exists), or to the component property. The latter would allow the consumer to pass expressions to the component that first get evaluated. Here's what it could look like:

{% highlight html %}
{% raw %}
<tab tabTitle="This is just a String">
  ...
</tab>
<tab [tabTitle]="thisIsAnExpression">
  ...
</tab>
{% endraw %}
{% endhighlight %}

Alright, now that we know what we want to build, let's get our hands dirty with some Angular code.

## Building the components

We start off by implementing a rather static version of the `<tabs>` element. If you've read our article on [building a zippy component in Angular](/angular/2015/03/27/building-a-zippy-component-in-angular-2.html),
you know that we need the `@Component()` decorator to tell Angular what the selector and template for our component should be.

{% highlight js %}
{% raw %}
@Component({
  selector: 'tabs',
  template: `

Tab 1

Tab 2

  `
})
export class Tabs {

}
{% endraw %}
{% endhighlight %}

When using the `Component` decorator, we can specify the template using the `template` property. The back tick syntax comes with ES2015 and allows us to do multi-line string definition without using concatenation operators like `+`.

As you can see, the component template already comes with a static list of tabs. This list will be replaced with a dynamic directive later, for now we keep it like this so we get a better picture of the direction we're going. We also need a place where the tab contents will go. Let's add an insertion point to our template. This will project the outer light DOM into the Shadow DOM (Emulation).

{% highlight js %}
{% raw %}
@Component({
  selector: 'tabs',
  template: `

Tab 1

Tab 2

    <ng-content></ng-content>
  `
})
{% endraw %}
{% endhighlight %}

Cool, we can already start using our `<tabs>` component and write HTML into it like this:

{% highlight html %}
{% raw %}
<tabs>

Some random HTML with some random content

</tabs>
{% endraw %}
{% endhighlight %}

Of course, we do want to use `<tab>` elements inside our `<tabs>` component, so let's build that one. It turns out that the `<tab>` element is actually quite primitive. It's basically just a container element that has an insertion point to project light DOM. We shouldn't forget the configurable `tabTitle`. Here's how we do it.

{% highlight js %}
{% raw %}
@Component({
  selector: 'tab',
  template: `

      <ng-content></ng-content>

  `
})
export class Tab {
  @Input() tabTitle;
}
{% endraw %}
{% endhighlight %}

The element should be named `<tab>` so we set the `selector` property accordingly. We bind the `tabTitle` **input** to the component's `tabTitle` **property**. Last but not least we add a template that is just a div with an insertion point.

Wait, that's it? Well, sort of. There's a tiny bit more we need to do, but let's just use our new `<tab>` component in our `<tabs>` component.

{% highlight html %}
{% raw %}
<tabs>
  <tab tabTitle="Foo">
    Content of tab Foo
  </tab>
  <tab tabTitle="Bar">
    Content of tab Bar
  </tab>
</tabs>
{% endraw %}
{% endhighlight %}

Executing this in the browser, we notice that we still get a list with `Tab 1` and `Tab 2` and in addition, we see the projected contents of both tabs at the same time. That's not quite a tabs component, right?

## Making the components dynamic

We're getting there. Let's first make our `<tabs>` component to actually use the correct titles instead of a hard-coded list. In order to generate a dynamic list, we need a collection. We can use our component's constructor to initialize a collection that holds all tabs like this:

{% highlight js %}
{% raw %}
export class Tabs {

  // typescript needs to know what properties will exist on class instances
  tabs: Tab[] = [];
}
{% endraw %}
{% endhighlight %}

Okay cool, but how do we get our tab titles into that collection? This is where, in Angular 1, directive controllers come in. However, since Angular 2.x it's much easier. First we need an interface so that the outside world can actually add items to our internal collection. Let's add a method `addTab(tab: Tab)`, that takes a `Tab` object and does exactly what we need.

{% highlight js %}
{% raw %}
export class Tabs {
  ...
  addTab(tab:Tab) {
    this.tabs.push(tab);
  }
}
{% endraw %}
{% endhighlight %}

The method just simply pushes the given object into our collection and we're good. Next we update the template so that the list is generated dynamically based on our collection. In Angular 1 we have a `ngRepeat` directive that lets us iterate over a collection to repeat DOM. Since Angular 2.x there a a `ngFor` directive that pretty much solves the exact same problem. We use the directive to iterate over our tabs collection to generate a dynamic list of tab titles in the component's template.

{% highlight js %}
{% raw %}
@Component({
  ...
  template: `

{{ tab.tabTitle }}

  `
})
{% endraw %}
{% endhighlight %}

If the templating syntax doesn't make sense to you at all, you might want to check out [this design doc](https://docs.google.com/document/d/1HHy_zPLGqJj0bHMiWPzPCxn1pO5GlOYwmv-qGgl4f_s/edit).

Alright, we have a collection, we have an API to extend the collection and we have a list in our template that is generated dynamically based on that collection. Since the collection is empty by default, the generated list is empty and no tab title is shown. Somebody needs to call this `addTab()` method!

That's where the `<tab>` component comes into play (again). Inside the component we can simply ask for a **parent** `Tabs` dependency by using the new, much more powerful dependency injection system and get an instance of it. This allows us to simply use given APIs inside a child component. Let's take a look at what that looks like.

{% highlight js %}
{% raw %}
class Tab {
  constructor(tabs: Tabs) {
    tabs.addTab(this)
  }
}
{% endraw %}
{% endhighlight %}

Wait, what happens here? `tabs: Tabs` is just Typescript type annotation which Angular uses for Dependency Injection.
Please check out our article where we go deeper inside [Angular DI](/angular/2015/05/18/dependency-injection-in-angular-2)

**tl;dr**

> Angular Hierarchical Injector knows, that we want first `Tabs` instance that it can get,
when traversing upwards from current host. In our case the actual host is our  `<tab>` component.
> Injector ask on tab for Tabs, if there is none, Injector will ask Parent Injector for `Tabs`. In our case parent Injector is on `<tabs>` component
and it has indeed `Tabs` instance, so it will return the correct instance of `Tabs`.

For now it's just important to understand that this particular type annotation gives you access to a **parent** component dependency, which in our case is `<tabs>`.
Using that instance, we can simply call the `addTab()` method with a `Tab` object and we are good to go.

## Making it tabbable

Using the components as they are right now, we **do** get a tabs list generated by our tab titles, but we still see all the contents of each tab at the same time. What we want, is to make that component actually "tabbable", so that only one tab content is shown. How do we achieve that?

Well, first we need a property that activates or deactivates a tab and depending on that value, we either show or hide it. We can simply extend our `<tab>` template accordingly like this:

{% highlight js %}
{% raw %}
@Component({
  template: `

      <ng-content></ng-content>

  `
})
class Tab { ... }
{% endraw %}
{% endhighlight %}

If a tab is not active, we simply hide it. We haven't specified this property anywhere, which means it's `undefined` which evaluates to `false` in that condition. So every tab is deactivated by default. In order to have at least one tab active, we can extend the `addTab()` method accordingly. The following code for instance, activates the very first tab that is added to the collection.

{% highlight js %}
{% raw %}
export class Tabs {
  ...
  addTab(tab:Tab) {
    if (this.tabs.length === 0) {
      tab.active = true;
    }
    this.tabs.push(tab);
  }
}
{% endraw %}
{% endhighlight %}

Awesome! The only thing that is missing, is to activate other tabs when a user clicks on a tab. In order to make this possible, we just need a function that sets the `activate` property when a tab is clicked. Here's what such a function could look like.

{% highlight js %}
{% raw %}
export class Tabs {
  ...
  selectTab(tab:Tab) {
    this.tabs.forEach((tab) => {
      tab.active = false;
    });
    tab.active = true
  }
}
{% endraw %}
{% endhighlight %}

We simply iterate over all tabs we have, deactivate them, and activate the one that is passed to that function. Then we just add this function to the template, so it is executed whenever a user clicks a tab, like this.

{% highlight js %}
{% raw %}
@Component({
  ...
  template: `

        {{tab.tabTitle}}

  `
})
{% endraw %}
{% endhighlight %}

Again, if this template syntax is new to you, check out the mentioned design document. What happens here is, whenever a `click` event is fired `selectTab()` is executed with the iterator tab instance. Try it out!

Here's the complete source in case you ran into any problems.

{% highlight js %}
{% raw %}
@Component({
  selector: 'tabs',
  template: `

        {{tab.tabTitle}}

    <ng-content></ng-content>
  `,
})
export class Tabs {
  tabs: Tab[] = [];

  selectTab(tab: Tab) {
    this.tabs.forEach((tab) => {
      tab.active = false;
    });
    tab.active = true;
  }

  addTab(tab: Tab) {
    if (this.tabs.length === 0) {
      tab.active = true;
    }
    this.tabs.push(tab);
  }
}

@Component({
  selector: 'tab',
  template: `

      <ng-content></ng-content>

  `
})
export class Tab {

  @Input() tabTitle: string;

  constructor(tabs:Tabs) {
    tabs.addTab(this);
  }
}
{% endraw %}
{% endhighlight %}

And we shouldn't forget that these components need to be declared on our application module:

{% highlight js %}
{% raw %}
@NgModule({
  imports: [BrowserModule],
  declarations: [Tab, Tabs, AppComponent],
  bootstrap: [AppComponent]
})
export class AppModule {}
{% endraw %}
{% endhighlight %}

## Where to go from here

This is a very rudimentary implementation of a tabs component. We can use that as a starting point to make it better over time. For example, we haven't done anything in terms of accessibility. It would also be nice if the component emits some custom events when a tab is activated. We'll cover working with events in Angular in another article.

## Bonus

Angular is so awesome that there is not just one way how to do things!

We can take a totally different approach how to implement our simple tabs ( which isn't so easily possible in Angular 1.x ),
leveraging special Angular `@ContentChildren` property decorator with `QueryList` type and `AfterContentInit` life cycle hook.
Those are more advanced concepts, which are covered in more details by [Juri Strumpflohner](https://twitter.com/juristr) in [his follow-up article](http://juristr.com/blog/2016/02/learning-ng2-creating-tab-component).

If you're just curious what it looks like, check out the demos below!

repository: thoughtram/blog

gha_language: SCSS

repo_name: thoughtram/blog


text:
# How-To-Build-a-MEAN-Stack

Repository for tutorials on the following:

1. [Link to Website describing project](https://caesarbonicillo.github.io/MeanStack/views/html/index.html)
2. [How to build a MEAN stack tutorial](https://docs.google.com/document/d/1m541e1Nkd5TquYAkNdu9SUT-apfWXNpNEg8abqUSinc/edit?usp=sharing)
3. [How to build a 'Hello World' web app on a MEAN stack tutorial](https://docs.google.com/document/d/1Kiya3Be_Vr8RRRSzGjg1xbi66RmqvZFONCvs6g9iPdc/edit?usp=sharing)
4. [Link to Clone Repo](https://github.com/caesarbonicillo/MeanStack-Actual)

Team:

David Bonicillo - Co-Project/Repo Management and Research

Khanh Trinh Nguyen - Co-Project//Repo Management

Sebastian Quintana - Design and Development

Crosby Allison - Design and Development

Josh Bordallo - Development, Review, Edit

Joen Ho - Design, Write, Edit, Test

Jessica Sites - Outline, Write, Edit, Test

repository: caesarbonicillo/MeanStack

gha_language: HTML

repo_name: caesarbonicillo/MeanStack


text:
# gulp-snippet-prettify

Gulp plugin to rename code snippet function variables to make them look pretty.

NOTE: This plugin will only rename variables in the first function definition it finds.

If you are creating snippets or widgets for websites, and you have some code like this:

```
!function(u,g,l,y,w,t,f) {
```

You can use *gulp-snippet-prettify* to make it look something like this (a la google analytics)

```
!function(i,s,o,g,r,a,m) {
```

We use this at [Stackbin](https://stkbn.com) to make our snippets look pretty :)

## Installation

```
npm install gulp-snippet-prettify --save
```

## Usage

Example below of using uglify to mangle/compress some code, then rename the variables.

gulpfile.js:

```javascript
var gulp = require('gulp');
var uglify = require('gulp-uglify');
var snippetPrettify = require('gulp-snippet-prettify');

gulp.task('snippet', function () {
    gulp.src('snippet.js')
        .pipe(uglify())
        .pipe(snippetPrettify({
            replacements: ['i', 's', 'o', 'g', 'r', 'a', 'm']
        }))
        .pipe(gulp.dest('dist'));
});
```

## License

MIT - See LICENSE file

repository: stackbin/gulp-snippet-prettify

repo_name: stackbin/gulp-snippet-prettify


text:
## Pre-Submission Checklist

- You have only one commit (if not, squash them into one commit).
- All new and existing tests pass the command `yarn test` and `yarn lint`.

## Description

<!--Write a description of what you changed and how to test your PR -->

repository: mvfsillva/dialetus

repo_name: mvfsillva/dialetus


text:
# Westone W60
See [usage instructions](https://github.com/jaakkopasanen/AutoEq#usage) for more options and info.

### Parametric EQs
In case of using parametric equalizer, apply preamp of **-7.5dB** and build filters manually
with these parameters. The first 5 filters can be used independently.
When using independent subset of filters, apply preamp of **-7.5dB**.

| Type    | Fc       |    Q | Gain    |
|:--------|:---------|:-----|:--------|
| Peaking | 102 Hz   | 0.42 | -3.0 dB |
| Peaking | 243 Hz   | 0.65 | -4.3 dB |
| Peaking | 2574 Hz  | 1.82 | 5.8 dB  |
| Peaking | 5007 Hz  | 1.62 | 6.4 dB  |
| Peaking | 20632 Hz | 0.17 | -4.3 dB |
| Peaking | 941 Hz   | 3.08 | 1.9 dB  |
| Peaking | 1464 Hz  | 4.12 | -2.1 dB |
| Peaking | 6427 Hz  | 6.21 | 2.5 dB  |
| Peaking | 8279 Hz  | 5.38 | -4.7 dB |
| Peaking | 12330 Hz | 2.72 | 1.4 dB  |

### Fixed Band EQs
In case of using fixed band (also called graphic) equalizer, apply preamp of **-8.2dB**
(if available) and set gains manually with these parameters.

| Type    | Fc       |    Q | Gain    |
|:--------|:---------|:-----|:--------|
| Peaking | 31 Hz    | 1.41 | -1.3 dB |
| Peaking | 62 Hz    | 1.41 | -1.9 dB |
| Peaking | 125 Hz   | 1.41 | -4.6 dB |
| Peaking | 250 Hz   | 1.41 | -5.3 dB |
| Peaking | 500 Hz   | 1.41 | -2.2 dB |
| Peaking | 1000 Hz  | 1.41 | 0.2 dB  |
| Peaking | 2000 Hz  | 1.41 | 2.2 dB  |
| Peaking | 4000 Hz  | 1.41 | 7.5 dB  |
| Peaking | 8000 Hz  | 1.41 | -0.5 dB |
| Peaking | 16000 Hz | 1.41 | -3.8 dB |

### Graphs
![](https://raw.githubusercontent.com/jaakkopasanen/AutoEq/master/results/crinacle/usound/Westone%20W60/Westone%20W60.png)


text:
# github-actions-runner

## Description

Host your own fleet of GitHub Actions runners.

Please refer to https://docs.github.com/en/actions/hosting-your-own-runners
for more information about self-hosted runners.

## Usage

First get Runner Token for your repository from GitHub, please refer to
https://docs.github.com/en/actions/hosting-your-own-runners/adding-self-hosted-runners
for more information.

Then you can deploy the GitHub Actions Runner Charmed Operator:

    juju deploy --channel beta \
        --config repository=https://github.com/github/your-repository \
        --config runner-token=YOUR-RUNNER-TOKEN \
        github-actions-runner

To scale out your deployment:

    juju add-unit github-actions-runner

To update the runner token:

    juju config github-actions-runner token=YOUR-NEW-RUNNER-TOKEN

repository: fnordahl/github-actions-runner-operator

gha_language: Python

repo_name: fnordahl/github-actions-runner-operator


text:
---
layout: post
title: "HWNet v2: An Efficient Word Image Representation for Handwritten Documents"
date: 2019-03-19 09:07:02
categories: arXiv_CV
tags: arXiv_CV Image_Caption CNN Transfer_Learning Classification
author: Praveen Krishnan, C.V. Jawahar
mathjax: true
---

* content
{:toc}

##### Abstract
We present a framework for learning an efficient holistic representation for handwritten word images. The proposed method uses a deep convolutional neural network with traditional classification loss. The major strengths of our work lie in: (i) the efficient usage of synthetic data to pre-train a deep network, (ii) an adapted version of the ResNet-34 architecture with the region of interest pooling (referred to as HWNet v2) which learns discriminative features for variable sized word images, and (iii) a realistic augmentation of training data with multiple scales and distortions which mimics the natural process of handwriting. We further investigate the process of transfer learning to reduce the domain gap between synthetic and real domain, and also analyze the invariances learned at different layers of the network using visualization techniques proposed in the literature.
 Our representation leads to a state-of-the-art word spotting performance on standard handwritten datasets and historical manuscripts in different languages with minimal representation size. On the challenging IAM dataset, our method is first to report an mAP of around 0.90 for word spotting with a representation size of just 32 dimensions. Furthermore, we also present results on printed document datasets in English and Indic scripts which validates the generic nature of the proposed framework for learning word image representation.

##### Abstract (translated by Google)

##### URL
[http://arxiv.org/abs/1802.06194](http://arxiv.org/abs/1802.06194)

##### PDF
[http://arxiv.org/pdf/1802.06194](http://arxiv.org/pdf/1802.06194)


text:
# Oracle Java on Docker

Build a Docker image containing Oracle Java (Server JRE specifically).

The Oracle Java Server JRE provides the same features as Oracle Java JDK commonly required for Server-side Applications (i.e. Java EE application servers). For more information about Server JRE, visit this [release notes](http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#serverjre).

## Wiremock for Windows Nano Server

[Download Server JRE 8](http://www.oracle.com/technetwork/java/javase/downloads/server-jre8-downloads-2133154.html) `.tar.gz` file and drop it inside this (current) folder.

Update the `./wiremock-nano/Dockerfile` to use the downloaded JRE version.

Build image:

``` powershell
PS> docker build -t wiremock:nano -f wiremock-nano/Dockerfile .
```

repository: jlouros/Docker-Toolbox

repo_name: jlouros/Docker-Toolbox


text:
# chirpstack-api

ChirpStack gRPC API message and service wrappers for Java.

## ToDo

* publish java package to maven central: https://docs.github.com/en/actions/language-and-framework-guides/publishing-java-packages-with-maven

## Install

An artifact is not yet public on Maven Central, you have build your own jar with

```sh
make java-current-user
```

at the end the build process, the .jar artifact will be installed on your Local Maven Repository `$HOME/.m2`

## Usage

All messages, services, constants, etc. are auto-generated from the ChirpStack protobuf definitions. The result is that
this package structure matches that of the protobuf definitions.

The protobuf definitions can be found here: https://github.com/brocaar/chirpstack-api/tree/master/protobuf

### Example

Maven dependencies.

NOTE: for `chirpstack-api` you have to follow [Install](#Install) instructions

```xml
<dependency>
  <groupId>io.grpc</groupId>
  <artifactId>grpc-okhttp</artifactId>
  <version>${grpc.version}</version>
</dependency>

<dependency>
  <groupId>io.chirpstack</groupId>
  <artifactId>chirpstack-api</artifactId>
  <version>3.12.4</version>
</dependency>
```

#### #1 blocking stub login

```java
private static void login() {
    ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
            .build();

    InternalServiceGrpc.InternalServiceBlockingStub stub = InternalServiceGrpc.newBlockingStub(channel);

    Internal.LoginRequest loginRequest = Internal.LoginRequest.newBuilder()
            .setEmail("user")
            .setPassword("password")
            .build();

    Internal.LoginResponse loginResponse = stub.login(loginRequest);

    String token = loginResponse.getJwt();
    logger.info("token={}", token);

    channel.shutdown();
}
```

repository: brocaar/chirpstack-api

repo_name: brocaar/chirpstack-api


text:
TileMan
=======

TileMan+Tirex: new alternative for Tile Service

    State of the Map 2013, Birmingham
    Hiroshi Miura(@miurahr)
    OpenStreetMap Foundation Japan

    github.com/miurahr

Agenda
----

Motivation
==========

Motivation: At first
----------

- Realize simple tile CDN for Japan

- Utilize cloud server sponsord by GMO Internet

Motivation: chaged mind soon
-----------------

- Starting local tile service

  * Feature to help adoption in public sector

  * Map design to familiar local users

  * Flexible

Technologies behind
=============

OpenResty: App Server Extension for Nginx
-----

Web Application Server

- high-performance & 10K+ connections

- Lua programming language

- backends: MySQL, PostgreSQL, Memcached, and Redis

Nginx
-----

nginx.org: high performance http server

- World 2nd http server (12.3% of active site)

- Asynchronous architecture, event driven

- Low memory foot print, CPU usage

Lua
---

- "Lua" (pronounced LOO-ah) means "Moon" in Portuguese

Lua
---

lua.org

- Scripting language born in Brazil in 1992

  * Simple procedural syntax

  * powerful data description

  * Dynamic variable type

  * Register-based virtual machine

  * Automatic memory management

Tirex: at glance
---------

Tirex: pronounce "Ti-rex"

- the tile server suite

- designed for OpenStreetMap

- powered by Perl

- multiple backend: mapnik, mapserver, et. al.

- parallel rendering

TileMan
=====

  Distributed tile server frontend

```http://osmfj.github.io/tileman```

TileMan: tile manager
-----

Non-fledged Tile Serving Manager

- It makes Tirex to different

  + Distributed Tile Serving
  + render-ahead feature
  + non-blocking, high performance request handling

- Just started in March, 2013.
  and now v1.3 (released Today!)

TileMan: powerful
-----

- Powerful load control and direction

  + by requested tiles geometory.

  + by client address, city, country

  + by requested browser version

TileMan: by client country
----

Border dispute Island between Korea and Japan.

 From IP Address Korean,    From IP Address Japan

TileMan: configuration
----

Typical Servers configuration

TileMan: configuration (cont.)
---

Extensive servers configuration

TileMan: use case
----

- OSMF Japan serves Japan tiles: tile.openstreetmap.jp

  - Act as cache server for other tiles than Japan

  - Dynamic boarder display control

  - Serving live tiles around Japan

  - render-ahead feature enabled

TileMan: utilities
-----------

- Help create/import/update postgis DB from planet data

- Expire old tile using powerful Tirex-batch

- Vagrant script for automate configution .

Easy install
-----------

You can get it on Uubntu PPA at launchpad.net/~osmjapan

Future Challenge
----

- mod_tile/renderd protocol support

- Lightweight Vector tile service
  + GeoJSON
  + PostgreSQL/PostGIS integration

Thanks
------

  Ideas, suggestion and participation are welcome!

  - tile-serving ML or ```github.com/osmfj/tileman```

  You can reach this presentation at ```https://miurahr.github.io/```

  - Tile Server supported by GMO Internet group.
  - TileMan Photo: flickr.com/photos/brieanddylan/4602743878


text:
\[\[wiki|Back To Overview\]\]

{{>toc}}

Software Requirement Specification
==================================

for "powerplant"/ pp\_ / ...
Version <0.8>

Introduction
============

powerplant is a software that allows anyone planning a garden to utilize companion planting and other permaculture practices. It provides intelligent suggestions to help the gardener by advising the best planting schedules and combinations of crops to maximize the garden's yield.

Users
=====

-   Gardeners, including anyone who wants to plan a garden and is happy to use open source software.

More detail below.

Goal
====

The goal of powerplant is to help users effectively plan their garden by providing planning and maintenance suggestions which utilize permaculture principles with a focus on companion planting.

Product Scope
-------------

> Provide a short description of the software being specified and its purpose, including relevant benefits, objectives and goals.

### Software description

-   Offer fast and easy solution for knowing which crops (bene)fit together
-   Provide an easy to follow schedule for planting, transplanting, and harvesting
-   Provide information about the crops themselves
-   Push and pull crop information to/from several open data platforms
-   User can submit changes to improve data
-   Open-source/open-data

> TODO: write more and better text

### Objectives

-   Improve planning process for anyone who wants to use permaculture principles in their gardening.
-   Save time during the planning process for anyone who wants to use permaculture principles in their gardening.
-   Education of users
-   Improve and collect data in open databases
-   Increase harvest yield
-   Connect with other open source projects for mutual benefit

Overall Description
===================

                                +-----------------------+
                                |  OpenFarm.cc API      |
                                +-----------+-----------+
                                            ^
                                            |
                                            |
                                            |
                                            v
    +-------------+                    +----+-----------------+             +----------------+
    | Front End   +<------------------>+    Back End          +<----------->+ powerplant DB  |
    +-------------+                    +----+-----------------+             +----------------+
                                            ^
                                            |
                                            |
                                            |
                                            |
                                            v
                                +--------------+--------+
                                |  FarmOS API           |
                                +-----------------------+

Product Perspective
-------------------

Our vision is that people are able to plan their own gardens using companion planting and other permacultures practices using our app as a central resource for information. The resources we can provide to the user will grow as the app is used more.

Context
-------

The information that we provide is all out there, we want to provide a central source for all of it. Aid those gardening without experience and help make quick and precise descision for the more experienced gardener.

Origin
------

Permaculture guidelines, gardening best practices.

The permaculture ideals are:

-   Care for the earth
-   Care for the people
-   Fair share

Open Source/ Open Data.

### Outcome

A year of use of this software will result in:

-   Users adding to data from all over the world (different climates, soil types)
-   Maybe make some money for affiliate links (seeds, supplies) or donations
-   Users plan garden and fields with our software
-   Users are better educated about gardening and permaculture
-   Enhance other open source projects with valuable information
-   More development on powerplant resulting in better software
    -   especially including more OS/OD enthusiasts
    -   building up networks with different OS/OD projects

Product Functionality
---------------------

> 1 TODO: Summarize the major functions that the product must perform or must let the user perform.
> 2 TODO: Still sorting this

### Must Have

-   Select different guides
-   Offline and online user experience
-   Suggestions for existing beds
-   Mark a bed as full or not
-   Notifications from schedule
-   Tasks and actions
-   Schedule

<!-- -->

-   user can signup/ login or decide to use with local storage only
-   user can create an account from garden data they've already entered
-   user can create beds
-   user can create gardens

<!-- -->

-   Need a list of available plants (internal)
-   Need to be able to see compatible/incompatible plants (internal)
-   Need to be able to filter by compatibility with multiple plants (internal)
-   Find optimal planting schedule for a target bed (with at least one user picked crop)
-   -   Read more information on the plant we display
-   Print Requirements for selected crops (openfarm guides)
    -   Planting requirements - displayed when refining crop selection for a bed
-   List Plants that match some specific attributes (internal)

<!-- -->

-   Create and edit garden/s
-   Create and edit bed/s within a garden
-   Create a list of preferred plants
-   Generate 5 plant combination suggestions for a given bed
-   Generate compatibility chart while picking plants for a bed
-   Modify a plant combination suggestion
    -   Provide advice to user to aid in their decision
        -   Advice on compatibility, plant requirements
        -   Suggest alternate plants to modify combination
-   Provide schedule for a bed including potting, transplanting, harvesting
-   Change the grow-state a plant is in (seed, pot, greenhouse, outside...)
-   Change timeframe of schedule (min:week, max:month)
-   Provide suggestions for filling blank spaces in schedule
-   Add plants to future schedule of bed using the plant-selection process as before
-   Report weekly what needs to be done with each plant
-   Store and load bed or garden from url and display schedule for current date
-   profile to store multiple gardens
-   erase bed history/garden history
-   take user feedback - simple form: user can choose category and write a message
-   View schedule for entire garden
-   Reporting new data or modifying existing data
    -   Crop Information, Crop Relationship, and Guide
-   get climate zone from location

### Should Have

-   When offline:
    -   Get suggestions for where to plant crops
        -   TODO: Figure out if this is possible offline.
        -   Only for plants currently in local memory (eg that are already in beds). More plants is then just disabled.
-   If we get the data, notify the user of maintenance tasks include watering, weeding, pruning, etc.
-   Suggest plants based on distance between plants
-   List suggestions for following plants for harvested beds
-   Sharing/collaboration between users about a specific garden using shareable link
-   Add a crop entry
    -   fill out form
    -   should be validated
-   validation of other users data for a specific climate (proofread, rate, comment, improve)
    -   flag trolls/...
-   Keep track of nitrogen fixers/consumers in each bed over time
-   Save edit history for OpenFarm data
-   permaculture zones:
    -   a garden can have zones
    -   suggestions based on zones
        -   which plant where dependent on how much attention they need/how often you harvest
            -   TODO: think about this, how to figure that out

### Cool to Have

-   Include types of beds required for a crop
-   Get revenue from links for more information.
-   Plant pictures
-   Print Shopping List
-   modify the same garden by multiple users at the same time
-   Have some visualization of garden beds with plants
-   Draw in current crops
-   Gamification
    -   Levels/badges for users
        -   Contributor
        -   Expert farmer
        -   etc.

> TODO: Figure out where these attributes belong: Soil conditions, grow time, climate, sun direction relative to each bed, labor required for each plant, sun+water required, best season/time to plant, care frequency, nitrogen/ consumption

### Detailed function description.

#### Select different Guides

User should choose between different guides (from openfarm.cc) for a crop that fits their needs

-   When adding a crop to a bed, users have the option of selecting a guide available from openfarm
-   Users can view the guide for a crop at any time from the crop details page
-   Guides can be removed, added or changed to a crop in crop view (only one guide per crop)

#### Offline and Online user experience

NEARLY the same UX (user experience) both offline and online! This is really important because people will need to use on mobile in their garden

-   Things a user will most likely want to do while offline. Use command pattern for the actions and queue them up. They sync when the phone/browser has network connection again. This also allows undo's.
    -   Add a new bed
    -   Add existing crops to that bed
    -   Change the status of a crop
    -   Change status of a task
    -   Switch to any other bed in their garden
    -   View a guide/information for a crop

#### Suggestions

-   Provide suggestions for adding specific crops to existing beds
    -   User can ask for crop suggestions when adding crops to a garden or bed
-   Provide suggestions for adding specific crops to a specific bed
    -   User can also ask for suggestions for crops to add to a specific bed
-   Must have at least one user-selected crop to provide suggestions

#### Notifications

Notify users of tasks that should be done for each garden/bed/crop on a given day

-   Email notifications
    -   should be opt out by default
    -   include weekly summary of upcoming tasks

<!-- -->

-   Push notifications
    -   Need to be enabled in browser (would only work on desktop)
    -   include events happening on the current day

#### Tasks and Actions

-   Right now, this would include planting, transplanting, and harvesting - only the major events
-   Users can add custom tasks from a predefined set of actions (or "other")
    -   Tasks are associated with a location, bed, or crop
    -   Repeatable tasks
-   Mark tasks as complete, or postpone or ignore them

#### Schedule

Find optimal planting schedule for a target bed (with at least one user picked crop)

-   When adding a crop, users can get suggestions for when to plant it based on the duration of growth
-   Goal is to maximize the overall yield and allow for consistent harvest throughout the year

Information accessible on timeline of different stages and locations of growth (i.e. when to grow in greenhouse and transplant them outside)

-   Users can view the schedule for a location or bed as a chart
-   Growth periods are shaded in bars, single events are represented as lines
-   Should allow the user to see, at a quick glance, what is growing and when things can be harvested
    -   Also be able to identify gaps in the schedule which could be filled
-   Should also show information about compatibility interactions
    -   Needs to be intuitive and simple to understand, obvious from one look at the schedule

#### User Contributions

Users can contribute in the form of editing existing cropinformation, croprelationship, and guides.

Creating Guides should link into OpenFarm directly - Create Guide.

-   pro: less work for developer
-   contra: might be confusing for the user
    Editing Guides should be put into powerplant "centralized improved guide" (except it is your own guide?). This avoids parallel versions of the same guide edited by different users, and instead puts all the edits in one place.
    Editing Cropinformation should be edited in OpenFarm directly.
    Croprelation should be changed in the app and put into OpenFarm.

### Terminology

Location: Group of gardens
Garden: combination of beds
Bed: Section in a garden (can be a greenhouse, a pot or a patch of soil)
Crop: Specific instance of a crop that will be planted in a bed
Transplant: action moving plants to a different bed.

### 2. Provide a Data Flow Diagram of the system to show how these functions relate to each other.

Data flow diagram for cropinformation/croprelationship data (from openfarm)

                ```````````                           `...`
              `.           .`                       `.`   `.`
             ``             ``                    ```       `.`
             .               .                  ```-Openfarm-..`
        -````.
     Power plant   .
        .>/- `Database` .:<`````Send ```````-  Backend    `  .
           .` ---:::--` .                   `.   .------:    .
            .`        `.                     .`             .
              `````````                       `.`         .`
                                                ``````````

Users and Characteristics
-------------------------

### Identify the various users that you anticipate will use this product.

-   Hobbyist - small home garden. 20 m2
-   Countryside garden - 250 - 1000 m2
-   Organic farmer - 1000 m2 +
-   Consultant - all of the above
-   Anyone who wants to plan a garden by using companion planting.
-   People who want to use open source/ open data software.

### Describe the relevant and important characteristics of each user.

-   All users: consistent harvest throughout the year
-   Hobbyist - Not too much labor is better; organic/natural garden
-   Countryside garden - Same as Hobbyist, also wants to be self-sufficient
-   Organic farmer - Same as Hobbyist, also prioritizing lower labor. Intermixed plants means more labor. Technologically literate, want to use software to improve their yields
-   Consultant - Provide advice to other hobbyists/gardeners/farmers

Operating Environment
---------------------

> Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist. In this part, make sure to include a simple diagram that shows the major components of the overall system, subsystem interconnections, and external interface

-   Lower range laptop
-   Windows 10, Chrome, use in office or garden
-   Android x.x.x, Chrome, use in office or garden, but mainly garden
-   With temporary internet connection

Design and Implementation Constraints
-------------------------------------

> Describe any items or issues that will limit the options available to the developers. These might include:
> \* hardware limitations (timing requirements, memory requirements)
> \* interfaces to other applications
> \* specific technologies
> \* tools
> \* databases to be used
> \* language requirements
> \* User Documentation

-   React for front end with JSX to generate HTML
-   SASS for css
-   Need to eventually be compatible with FarmOS.
-   Need to eventually be compatible with Openfarm.cc.
-   Want to be similar to Openfarm crop database structure.
-   Want tasks to be similar to FarmOS Log data structure
-   Text + photo editors.
-   NodeJS as backend engine running ES6
    -   MongoDB for database with Mongoose as ODM
    -   Express for route handling
    -   Passport for user authentication
    -   Mocha + Chai + supertest for unit testing and integration testing
-   Mobile-first, offline-first design (ok, maybe mobile-first, offline-second. they can't both be first)

User Documentation
------------------

> TO DO: Describe what kind of manuals and what kind of help is needed for the software you will be developing.
List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software.//

Need to have user documentation. Usability will be severly limited without. Need to have in depth descriptions of how to input data, what screens should look like, how to interpret output. Need to document things before creating them.

-   User manual
-   FAQ
-   First time user prompts
-   Community talking points
-   Chat rooms (like FarmOS)
-   Tutorials for most exemplary tasks (Videos, ...)

Specific Requirements
=====================

External Interface Requirements
-------------------------------

> TO DO: Describe user interfaces, different screen images, any GUI standards, standard buttons and functions (e.g., Cancel) that will be available to the user. Define error message display standards.

### GUI standards

https://material.io/guidelines/
https://medium.com/@marcintreder/the-minimum-viable-design-system-75ca1806848a

-   Lots of rounded rectangles to contain components
-   Font size standards based on Marvel prototype (maybe change to be based on screen size in the future)
    -   Main page title: 26pt
    -   Subtitle: 18pt
    -   Body text: 14pt
-   Sidebar menu accessible from any screen which shows the current location and allows jumping to any screen above it in the hierarchy (All Gardens -> Garden Dashboard -> Bed Dashboard -> Crop)
-   Gardens and Beds contain 3 subscreens (fragments?)
    -   Dashboard, Beds/Crops, Schedule
    -   Dashboard shows relevant tasks
    -   Beds/Crops shows all Beds/Crops contained within the Garden/Bed
    -   Schedule shows history of all past, present, and future crops for the Garden/Bed
-   Any time there is a title/heading of an element containing a Garden, Bed, or Crop, it will have a small drop down menu next to it
    -   Menu items: Edit, delete
    -   This is the main mechanism by which user can change settings/status of a specific Garden, Bed, or Crop

### View Description

[View the prototype! (INCOMPLETE)](https://marvelapp.com/94c4bh4)

> TODO: add many many more more more more views

### Hardware Interfaces

> Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include, the supported device types, the nature of the data and control interactions between the software and the hardware.

\* 800x400 display
\* 100kB/s
\* 200mb memory on mobile
\* 512mb memory on non-mobile
\* 5mb local storage

### Software Interfaces

> TO DO: Describe: the connections between the product and other specific software components (name and version), databases, operating systems (Windows? Linux? Etc…), tools, libraries and integrated commercial components.

-   FarmOS
    -   FarmOS users can provide the url of their server and save/load all of their data BESIDES crop guides and crop information from there
    -   There will have to be a moderate amount of translation between powerplant data format and FarmOS data format
    -   Rather than building a seperate FarmOS module, we will make our web app compatible with FarmOS
    -   A FarmOS module could be possible, but requires much more time and expertise than it is worth at the moment
-   Openfarm.cc
    -   Openfarm stores CropRelationships, Crop Guides, and Crop Information
    -   Powerplant users can choose to register their accounts with Openfarm as well
    -   Users who do this will be able to save/modify this data
    -   All users (registered or not), while load this data from Openfarm

> TO DO: Identify data items or messages coming into the system and going out and describe the purpose of each.

-   FarmOS specs go here
-   openfarm.cc specs go here

> TO DO: Describe the services needed.

> TO DO: Identify data that will be shared across software components.

-   need to look at what FarmOS stores and what we store
    figure out what we can store in FarmOS

### Communications Interfaces

TO DO:

1. Describe the requirements associated with any communication functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms.
2. Define any pertinent message formatting.

communication standards that will be used, such as FTP or HTTP.
---------------------------------------------------------------

REST

[Auto-generated API specs](https://github.com/Ecohackerfarm/powerplant/blob/master/docs/spec.md)

API error messages have the following format:

<pre>
{
status: Number,
message: (optional) String,
errors: (optional) {
fieldName1: String,
...
}
}

</pre>
`status`: HTTP status code
`errors`: Object containing error messages pertinent to specific UI elements, e.g. a login request with an incorrect password would result in `{password: "Incorrect password"}`
`message`: A general description of the error, which can be displayed to the user

#### communication security or encryption issues, data transfer rates, and synchronization mechanisms.

\* Profile could have sensitive info
\* Even in case of (locally) illegal crops being grown, info cannot be accessible by anyone
\* Yield is sensitive
\* Complete transparency within network of gardeners, zero transparency outside
\* low bandwidth because garden usually has bad reception (GPRS traffic)
\* Sync profile data between local and server

Behavior Requirements
---------------------

### Use Case View

> TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors.

[Workflow Diagram](https://github.com/Ecohackerfarm/powerplant/blob/master/docs/Powerplant%20Workflow.svg)

> TODO: Create use case diagrams involving each of the possible types of users

List of Use case
----------------

Diagram
> TODO: Next time
--------------------

TODO:
Convince openfarm to enhance companionship model

repository: petteripitkanen/powerplant

gha_license_id: NOASSERTION

repo_name: petteripitkanen/powerplant


text:
---
layout: post
title: "Hosting Octopress automatically with AWS S3"
date: 2014-08-09 02:13:15 -0400
comments: true
categories: AWS
---

###Initial Setup

You’ll need to install [GPG tools](https://gpgtools.org/gpgsuite.html) suite for this. Get that and then come back.

Make sure you also have [homebrew](http://brew.sh/) cause you’ll need it soon.

###Now for AWS

Log into your AWS account, or make one if you don’t already. Log in and go to the IAM section and then create an access key for a user. **_Make sure you download the secret key file_**. You’ll need it to install s3cmd, as it will need your AWS Secret Key.

You’ll also want to create a bucket in S3. Make sure it is the same name as your domain name you’re going to use (i.e. my bucket was named neal.codes as this domain is neal.codes).

``` bash Install s3cmd and configure prompt
brew install s3cmd
s3cmd --configure

Enter new values or accept defaults in brackets with Enter.
Refer to user manual for detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3
Access Key: accesskey
Secret Key: secretkey

Encryption password is used to protect your files from reading
by unauthorized persons while in transfer to S3
Encryption password: makeyourownpassword
Path to GPG program [/usr/local/bin/gpg]:

When using secure HTTPS protocol all communication with Amazon S3
servers is protected from 3rd party eavesdropping. This method is
slower than plain HTTP and can't be used if you're behind a proxy
Use HTTPS protocol [No]: yes

New settings:
  Access Key: accesskey
  Secret Key: secretkey
  Encryption password: makeyourownpassword
  Path to GPG program: /usr/local/bin/gpg
  Use HTTPS protocol: True
  HTTP Proxy server name:
  HTTP Proxy server port: 0

Test access with supplied credentials? [Y/n] y
Please wait, attempting to list all buckets...
Success. Your access key and secret key worked fine :-)

Now verifying that encryption works...
Success. Encryption and decryption worked fine :-)

Save settings? [y/N] y
Configuration saved to '/Users/neal/.s3cfg'
```

Now add all of the below to your Rakefile in your Octopress root. You’ll be able to auto-sync your local Octopress blog with the S3 bucket using the `rake s3` command thereafter.

``` ruby Rakefile
# change deploy_default - add s3_bucket
deploy_default = "s3"
s3_bucket      = "neal.codes/blog" # My bucket name and domain name // notice folder name for subdirectory
```

``` ruby Rakefile
# Add this somewhere, probably in the deploy section
desc "Deploy website to s3"
task :s3 do
  exclude = ""
  if File.exists?('./s3-exclude')
    exclude = "--exclude-from '#{File.expand_path('./s3-exclude')}'"
  end
  puts "## Deploying website via s3cmd"
  ok_failed system("s3cmd sync --guess-mime-type --acl-public #{exclude} #{"--delete-removed" } #{public_dir}/ s3://#{s3_bucket}/")
end
```

###Getting your domain to point to AWS

You’ll have to mess with whereever you bought the domain from. Edit the DNS records for your domain, and then add an CNAME record with a value of **yourbucket.name.s3-website-us-east-1.amazonaws.com** or something similar. Mine is **neal.codes.s3-website-us-east-1.amazonaws.com**.

That’s all folks.

extension: markdown


text:
## Seaborn Basics with Python 3

This is my revision of the tutorials at

- The Ultimate Python Seaborn Tutorial: https://elitedatascience.com/python-seaborn-tutorial
- Styling plots with Seaborn: http://jose-coto.com/styling-with-seaborn

## Setup

Clone the repo, go to the repo folder, setup the virtual environment, and install the required packages:

```
$ cd path_to_this folder
$ virtualenv -p python3 venv
$ source venv/bin/activate
$ pip3 install -r requirements.txt
```

Run `$ jupyter notebook` to go over the tutorial step-by-step.

repository: DisenWang/data-analysis-tutorials

repo_name: DisenWang/data-analysis-tutorials


text:
# godot-profanity-check

! DISCLAIMER !
This repository is not production ready at all!

This repository tests out a possible way to implement a profanity filter in Godot using pure GDScript.
The algorithm used is an optimized version of the [Wagner-Fischer algorithm](https://en.wikipedia.org/wiki/Wagner%E2%80%93Fischer_algorithm).

Godot itself implements the [Sørensen–Dice coefficient](https://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient) natively using the `similarity()`, but this algorithm doesn't seem that capable of performing any profanity checks.

There's some big problems remaining with the algorithm that might (or might not) be fixed at some point.