text:
PEP: 600 Title: Future \'manylinux\' Platform Tags for Portable Linux
Built Distributions Version: \$Revision\$ Last-Modified: \$Date\$
Author: Nathaniel J. Smith<EMAIL_ADDRESS>Thomas Kluyver
<EMAIL_ADDRESS>Sponsor: Paul Moore<EMAIL_ADDRESS>BDFL-Delegate: Paul Moore<EMAIL_ADDRESS>Discussions-To:
Discourse
<https://discuss.python.org/t/the-next-manylinux-specification/1043>
Status: Accepted Type: Informational Content-Type: text/x-rst Created:
3-May-2019 Post-History: 3-May-2019 Resolution:
<https://discuss.python.org/t/pep-600-future-manylinux-platform-tags-for-portable-linux-built-distributions/2414/27>

Abstract
========

This PEP proposes a scheme for new \'manylinux\' wheel tags to be
defined without requiring a PEP for every specific tag, similar to how
Windows and macOS tags already work. This will allow package maintainers
to take advantage of new tags more quickly, while making better use of
limited volunteer time.

Non-goals include: handling non-glibc-based platforms; integrating with
external package managers or handling external dependencies such as
CUDA; making manylinux tags more sophisticated than their Windows/macOS
equivalents; doing anything besides taking our existing tried-and-tested
approach and streamlining it. These are important issues and other PEPs
may address them in the future, but for this PEP they\'re out of scope.

Rationale
=========

Python users appreciate it when PyPI has pre-compiled packages for their
platform, because it makes installation fast and simple. But
distributing pre-compiled binaries on Linux is challenging because of
the diversity of Linux-based platforms. For example, Debian, Android,
and Alpine all use the Linux kernel, but with radically different
userspace libraries, which makes it difficult or impossible to create a
single wheel that works on all three. This complexity has caused many
previous discussions of Linux wheels to stall out.

The \"manylinux\" project succeeded by adopting a strategy of ruthless
pragmatism. We chose a large but tractable set of Linux platforms --
specifically, mainstream glibc-based distributions like Debian,
OpenSuSE, Ubuntu, RHEL, etc. -- and then we did whatever it takes to
make wheels that work across all these platforms.

This approach requires many compromises. Manylinux wheels can only rely
on a external libraries that maintain a consistent ABI and are
universally available across all these distributions, which in practice
restricts them to a small set of core libraries like glibc and a few
others. Wheels have to be built on carefully-chosen platforms of the
oldest possible vintage, using a Python that is itself built in a
carefully-chosen configuration. Other shared library dependencies have
to be bundled into the wheel, which requires a complex process to avoid
collisions between unrelated wheels. And finally, the details of these
requirements change over time, as new distro versions are released, and
old ones fall out of use.

It turns out that these requirements are not too onerous: they\'re
essentially equivalent to what you have to do to ship Windows or macOS
wheels, and the manylinux approach has achieved substantial uptake among
both package maintainers and end-users. But any manylinux PEP needs some
way to address these complexities.

In previous manylinux PEPs (`513`{.interpreted-text role="pep"},
`571`{.interpreted-text role="pep"}), we\'ve done this by attempting to
write down in the PEP the exact set of libraries, symbol versions,
Python configuration, etc. that we believed would lead to wheels that
work on all mainstream glibc-based Linux systems. But this created
several problems:

First, PEPs are generally supposed to be normative references: if
software doesn\'t match the PEP, then we fix the software. But in this
case, the PEPs are attempting to describe Linux distributions, which are
a moving target, and do not consider our PEPs to constrain their
behavior. This means that we\'ve been taking on an unbounded commitment
to keep updating every manylinux PEP whenever the Linux distro landscape
changes. This is a substantial commitment for unfunded volunteers to
take on, and it\'s not clear that this work produces value for our
users.

And second, every time we move manylinux forward to a newer range of
supported platforms, or add support for a new architecture, we have to
go through a fairly elaborate process: writing a new PEP, updating the
PyPI and pip codebases to recognize the new tag, waiting for the new pip
to percolate to users, etc. None of this happens on Windows/macOS; it\'s
only a tax on Linux maintainers. This slows deployment of new manylinux
versions, and consumes part of our community\'s limited PEP review
bandwidth, thus slowing progress of the Python packaging ecosystem as a
whole. This is especially problematic for less-popular architectures,
who have less volunteer resources to overcome these barriers.

How can we fix it?

A manylinux PEP has to address three main audiences:

-   **Package installers**, like pip, need to be able to determine which
    wheel tags are compatible with the system they find themselves
    running on. This requires some automated process to introspect the
    system and match it up with wheel tags.
-   **Package indexes**, like PyPI, need to be able to validate which
    wheel tags are valid. Generally, this just requires something like a
    list of valid tags, or regex they match, with no need to know
    anything about the actual semantics for individual tags. (But see
    the discussion of upload verification below.)
-   **Package maintainers** need to be able to build wheels that meet
    the requirements for a given wheel tag.

Here\'s the key insight behind this new PEP: it\'s crucial that
different **package installers** and **package indexes** all agree on
which manylinux tags are valid and which systems they install on, so we
need a PEP to specify these -- but, these are straightforward, and
don\'t really change between manylinux versions. The complicated part
that keeps changing is the process of actually **building the wheels**
-- but, if there are multiple competing build environments, it *doesn\'t
matter* whether they use exactly the same rules as each other, as long
as they all produce wheels that work on end-user systems. Therefore, we
don\'t need an interoperability standard for building wheels, so we
don\'t need to write the details into a PEP.

To further convince ourselves that this approach will work, let\'s look
again at how we handle wheels on Windows and macOS: the PEPs describe
which tags are valid, and which systems they\'re supposed to work on,
but not how to actually build wheels for those platforms. And in
practice, if you want to distribute Windows or macOS wheels, you might
have to jump through some complicated and poorly documented hoops in
order to bundle dependencies, target the right range of OS versions,
etc. But the system works, and the way to improve it is to write better
docs and build better tooling; no-one thinks that the way to make
Windows wheels work better is to publish a PEP describing which symbols
we think Microsoft should be including in their libraries and how their
linker ought to work. This PEP extends that philosophy to manylinux as
well.

Specification
=============

Core definition
---------------

Tags using the new scheme will look like:

    manylinux_2_17_x86_64

Or more generally:

    manylinux_${GLIBCMAJOR}_${GLIBCMINOR}_${ARCH}

This tag is a promise: the wheel\'s creator promises that the wheel will
work on any mainstream Linux distro that uses glibc version
`${GLIBCMAJOR}.${GLIBCMINOR}` or later, and where the `${ARCH}` matches
the return value from `distutils.util.get_platform()`. (For more detail
about architecture tags, see `425`{.interpreted-text role="pep"}.)

If a user installs this wheel into an environment that matches these
requirements and it doesn\'t work, then that wheel does not comply with
this specification. This should be considered a bug in the wheel, and
it\'s the wheel creator\'s responsibility to look for a fix (possibly
with the help of the broader community).

The word \"mainstream\" is intentionally somewhat vague, and should be
interpreted expansively. The goal is to rule out weird homebrew Linux
systems; generally any distro you\'ve actually heard of should be
considered \"mainstream\". We also provide a way for maintainers of
\"weird\" distros to manually override this check, though based on
experience with previous manylinux PEPs, we don\'t expect this feature
to see much use.

And finally, compliant wheels are required to \"play well with others\",
i.e., installing a manylinux wheel must not cause other unrelated
packages to break.

Any method of producing wheels which meets these criteria is acceptable.
However, in practice we expect that the auditwheel project will maintain
an up-to-date set of tools and build images for producing manylinux
wheels, as well as documentation about how they work and how to use
them, and that most maintainers will want to use those. For the latest
information on building manylinux wheels, including recommendations
about which build images to use, see <https://packaging.python.org>.

Since these requirements are fairly high-level, here are some examples
of how they play out in specific situations:

Example: if a wheel is tagged as `manylinux_2_17_x86_64`, but it uses
symbols that were only added in glibc 2.18, then that wheel won\'t work
on systems with glibc 2.17. Therefore, we can conclude that this wheel
is in violation of this specification.

Example: Until \~2017, all major Linux distros included
`libncursesw.so.5` as part of their default install. Until that date, a
wheel that linked to `libncursesw.so.5` was compliant with this
specification. Then, distros started switching to ncurses 6, which has a
different name and incompatible ABI, and stopped installing
`libncursesw.so.5` by default. So after that date, a wheel that links to
`libncursesw.so.5` was no longer compliant with this specification.

Example: The Linux ELF linker places all shared library SONAMEs into a
single process-global namespace. If independent wheels used the same
SONAME for their bundled libraries, they might end up colliding and
using the wrong library version, which would violate the \"play well
with others\" rule. Therefore, this specification requires that wheels
use globally-unique names for all bundled libraries. (Auditwheel
currently accomplishes this by renaming all bundled libraries to include
a globally-unique hash.)

Example: we\'ve observed certain wheels using C++ in ways that
[interfere with other
packages](https://github.com/apache/arrow/pull/2210) via an unclear
mechanism. This is also a violation of the \"play well with others\"
rule, so those wheels aren\'t compliant with this specification.

Example: The imaginary architecture LEG v7 has both big-endian and
little-endian variants. Big-endian binaries require a big-endian system,
and little-endian binaries require a little-endian system. But
unfortunately, it\'s discovered that due to a bug in
`425`{.interpreted-text role="pep"}, both variants use the same
architecture tag, `legv7`. This makes it impossible to create a
compliant `manylinux_2_17_legv7` wheel: no matter what we do, it will
crash on some user\'s systems. So, we write a new PEP defining
architecture tags `legv7le` and `legv7be`; now we can ship manylinux LEG
v7 wheels.

Example: There\'s also a LEG v8. It also has big-endian and
little-endian variants. But fortunately, it turns out that
`425`{.interpreted-text role="pep"} already does the right thing LEG v8,
so LEG v8 enthusiasts can start shipping `manylinux_2_17_legv8le` and
`manylinux_2_17_legv8be` wheels immediately once this PEP is
implemented, even though the authors of this PEP don\'t know anything at
all about LEG v8.

Legacy manylinux tags
---------------------

The existing manylinux tags are redefined as aliases for new-style tags:

-   `manylinux1_x86_64` is now an alias for `manylinux_2_5_x86_64`
-   `manylinux1_i686` is now an alias for `manylinux_2_5_i686`
-   `manylinux2010_x86_64` is now an alias for `manylinux_2_12_x86_64`
-   `manylinux2010_i686` is now an alias for `manylinux_2_12_i686`

This redefinition is largely a no-op, but does affect a few things:

-   Previously, we had an open-ended and growing commitment to keep
    updating every manylinux PEP whenever a new Linux distro was
    released, for the rest of time. By making this PEP normative for the
    older tags, that obligation goes away. When this PEP is accepted,
    the previous manylinux PEPs will receive a final update noting that
    they are no longer maintained and referring to this PEP.
-   The \"play well with others\" rule was always intended, but previous
    PEPs didn\'t state it explicitly; now it\'s explicit.
-   Previous PEPs assumed that glibc 3.x might be incompatible with
    glibc 2.x, so we checked for compatibility between a system and a
    tag using logic like:

        sys_major == tag_major and sys_minor >= tag_minor

    Recently the glibc maintainers [advised
    us](https://sourceware.org/bugzilla/show_bug.cgi?id=24636) that we
    should assume that glibc will maintain backwards-compatibility
    indefinitely, even if they bump the major version number. So the new
    check for compatibility is:

        (sys_major, sys_minor) >= (tag_major, tag_minor)

Package installers
------------------

Generally, package installers should install manylinux wheels on systems
that have an appropriate glibc and architecture, and not otherwise. If
there are multiple compatible manylinux wheels available, then the wheel
with the highest glibc version should be preferred, in order to take
advantage of newer compilers and glibc features.

In addition, we follow previous specifications, and allow for Python
distributors to manually override this check by adding a `_manylinux`
module to their standard library. If this package is importable, and if
it defines a function called `manylinux_compatible`, then package
installers should call this function, passing in the major version,
minor version, and architecture from the manylinux tag, and it will
either return a boolean saying whether wheels with the given tag should
be considered compatible with the current system, or else `None` to
indicate that the default logic should be used.

For compatibility with previous specifications, if the tag is
`manylinux1` or `manylinux_2_5` exactly, then we also check the module
for a boolean attribute `manylinux1_compatible`, and if the tag version
is `manylinux2010` or `manylinux_2_12` exactly, then we also check the
module for a boolean attribute `manylinux2010_compatible`. If both the
new and old attributes are defined, then `manylinux_compatible` takes
precedence.

Here\'s some example code. You don\'t have to actually use this code,
but you can use it for reference if you have questions about the exact
semantics:

    LEGACY_ALIASES = {
        "manylinux1_x86_64": "manylinux_2_5_x86_64",
        "manylinux1_i686": "manylinux_2_5_i686",
        "manylinux2010_x86_64": "manylinux_2_12_x86_64",
        "manylinux2010_i686": "manylinux_2_12_i686",
    }

    def manylinux_tag_is_compatible_with_this_system(tag):
        # Normalize and parse the tag
        tag = LEGACY_ALIASES.get(tag, tag)
        m = re.match("manylinux_([0-9]+)_([0-9]+)_(.*)", tag)
        if not m:
            return False
        tag_major_str, tag_minor_str, tag_arch = m.groups()
        tag_major = int(tag_major_str)
        tag_minor = int(tag_minor_str)

        if not system_uses_glibc():
            return False
        sys_major, sys_minor = get_system_glibc_version()
        if (sys_major, sys_minor) < (tag_major, tag_minor):
            return False
        sys_arch = get_system_arch()
        if sys_arch != tag_arch:
            return False

        # Check for manual override
        try:
            import _manylinux
        except ImportError:
            pass
        else:
            if hasattr(_manylinux, "manylinux_compatible"):
                result = _manylinux.manylinux_compatible(
                    tag_major, tag_minor, tag_arch,
                )
                if result is not None:
                    return bool(result)
            else:
                if (tag_major, tag_minor) == (2, 5):
                    if hasattr(_manylinux, "manylinux1_compatible"):
                        return bool(_manylinux.manylinux1_compatible)
                if (tag_major, tag_minor) == (2, 12):
                    if hasattr(_manylinux, "manylinux2010_compatible"):
                        return bool(_manylinux.manylinux2010_compatible)

        return True

Package indexes
---------------

The exact set of wheel tags accepted by PyPI, or any package index, is a
policy question, and up to the maintainers of that index. But, we
recommend that package indexes accept any wheels whose platform tag
matches the following regexes:

-   `manylinux1_(x86_64|i686)`
-   `manylinux2010_(x86_64|i686)`
-   `manylinux_[0-9]+_[0-9]+_(.*)`

Package indexes may impose additional requirements; for example, they
might audit uploaded wheels and reject those that contain known
problems, such as a `manylinux_2_17` wheel that references symbols from
later glibc versions, or dependencies on external libraries that are
known not to exist on all systems. Or a package index might decide to be
conservative and reject wheels tagged `manylinux_2_999`, on the grounds
that no-one knows what the Linux distro landscape will look like when
glibc 2.999 is released. We leave the details of any such checks to the
discretion of the package index maintainers.

Rejected alternatives
=====================

**Continuing the manylinux20XX series**: As discussed above, this leads
to much more effort-intensive, slower, and more complex rollouts of new
versions. And while there are two places where it seems at first to have
some compensating benefits, if you look more closely this turns out not
to be the case.

First, this forces us to produce human-readable descriptions of how
Linux distros work, in the text of the PEP. But this is less valuable
than it might seem at first, and can actually be handled better by the
new \"perennial\" approach anyway.

If you\'re trying to build wheels, the main thing you need is a tutorial
on how to use the build images and tooling around them. If you\'re
trying to add support for a new build profile or create a competitor to
auditwheel, then your best resources will be the auditwheel source code
and issue tracker, which are always going to be more detailed, precise,
and reliable than a summary spec written in English and without tests.
Documentation like the old manylinux20XX PEPs does add value! But in
both cases, it\'s primarily as a secondary reference to provide overview
and context.

And furthermore, the PEP process is poorly suited to maintaining this
kind of reference documentation -- there\'s a reason we don\'t keep the
pip user manual in the PEPs repository! The auditwheel maintainers are
the best situated to understand what kinds of documentation are useful
to their users, and to maintain that documentation over time. For
example, there\'s substantial overlap between the different manylinux
versions, and the PEP process currently forces us to handle this by
copy-pasting everything between a growing list of documents; instead,
the auditwheel maintainers might choose to factor out the common parts
into a single piece of shared documentation.

A related concern was that with the perennial approach, it may become
harder for package maintainers to decide which build profile to target:
instead of having to pick between `manylinux1`, `manylinux2010`,
`manylinux2014`, \..., they now have a wider array of options like
`manylinux_2_5`, `manylinux_2_6`, \..., `manylinux_2_20`, \... But
again, we don\'t believe this will be a problem in practice. In either
system, most package maintainers won\'t be starting by reading PEPs and
trying to implement them from scratch. If you\'re a particularly expert
and ambitious package maintainer who needs to target a new version or
new architecture, the perennial approach gives you additional
flexibility. But for regular everyday maintainers, we expect they\'ll
start from a tutorial like packaging.python.org, and by choosing from
existing build images. A tutorial can just as easily recommend
`manylinux_2_17` as it can recommend `manylinux2014`, and we expect the
actual set of pre-provided build images to be identical in both cases.
And again, by maintaining this documentation in the right place, instead
of trying to do it PEPs repository, we expect that we\'ll end up with
documentation that\'s higher-quality and more fitted to purpose.

Finally, some participants have pointed out that it\'s very nice to be
able to look at a wheel and tell definitively whether it meets the
requirements of the spec. With the new \"perennial\" approach, we can
never say with 100% certainty that a wheel does meet the spec, because
that depends on the Linux distros. As engineers we have a well-justified
dislike for that kind of uncertainty.

However: as demonstrated by the examples above, we can still tell
definitively when a wheel *doesn\'t* meet the spec, which turns out to
be what\'s important in practice. And, in practice, with the
manylinux20XX approach, whenever distros change, we actually change the
spec; it takes a bit longer. So even if a wheel was compliant today, it
might be become non-compliant tomorrow. This is frustrating, but
unfortunately this uncertainty is unavoidable if what you care about is
distributing working wheels to users.

So even on these points where the old approach initially seems to have
advantages, we expect the new approach to actually do as well or better.

**Switching to perennial tags, but continuing to write a PEP for each
version**: This was proposed as a kind of hybrid, to try to get some of
the advantages of the perennial tagging system -- like easier rollouts
of new versions -- while keeping the advantages of the manylinux20XX
scheme, like forcing us to write documentation about Linux distros,
simplifying options for package maintainers, and being able to
definitively tell when a wheel meets the spec. But as discussed above,
on a closer look, it turns out that these advantages are largely
illusory. And this also inherits significant *dis*advantages from the
manylinux20XX scheme, like creating indefinite obligations to update a
growing list of copy-pasted PEPs.

**Making auditwheel normative**: Another possibility that was considered
was to make auditwheel the normative reference on the definition of
manylinux, i.e., a wheel would be compliant if and only if
`auditwheel check` completed without errors. This was rejected because
the point of packaging PEPs is to define interoperability between tools,
not to bless specific tools.

**Adding extra words to the tag string**: Another proposal we considered
was to add extra words to the wheel tag, e.g. `manylinux_glibc_2_17`
instead of `manylinux_2_17`. The motivation would be to leave the door
open to other kinds of versioning heuristics in the future -- for
example, we could have `manylinux_glibc_$VERSION` and
`manylinux_alpine_$VERSION`.

But \"manylinux\" has always been a synonym for \"broad compatibility
with mainstream glibc-based distros\"; reusing it for unrelated build
profiles like alpine is more confusing than helpful. Also, some early
reviewers who aren\'t steeped in the details of packaging found the word
`glibc` actively misleading, jumping to the conclusion that it meant
they needed a system with *exactly* that glibc version. And tags like
`manylinux_$VERSION` and `alpine_$VERSION` also have the advantages of
parsimony and directness. So we\'ll go with that.

repository: erdal-pb/opep

repo_name: erdal-pb/opep


text:
# Personal Health Records FHIR Implementation Guide
{:.no_toc}

{% include publish-box.html %}

* Do not remove this line (it will not be displayed)
{:toc}

This implementation guide is an Australian realm implementation guide of the HL7TM FHIR® specification to PLACEHOLDER-TEXT

This [implementation guide](http://hl7.org/fhir/STU3/implementationguide.html) is based on [FHIR® version 3.0.1](http://hl7.org/fhir/STU3/index.html).

## Scope

### Use Cases
The following is the expected scenario:
* An individual or their authorised representative authors content to be stored in the My Health Record system

### Profiles
The FHIR® profiles that form part of this implementation guide are shown below. The profiles defined in this implementation guide do not include profile-specific mappings to another format. The base FHIR® STU3 mapping content for each of the resources referenced in this implementation guide can be found on the applicable resource documentation in the [FHIR Release 3 (STU)](http://hl7.org/fhir/STU3/index.html).

A profile that defines a representation of common header constraints for consumer entered aka Personal Health documents:
 * [Consumer Entered Information Document Header](StructureDefinition-composition-docheader-cei-1.html)

And supported documents:
* [Personal Health Notes](StructureDefinition-composition-phn-1.html)
* [Personal Health Summary](StructureDefinition-composition-phs-1.html)

license: MIT

branch_name: refs/heads/master

extension: md

gha_language: HTML

license_type: permissive


text:
[![Travis](https://img.shields.io/travis/Pinjasaur/meed.svg)](https://travis-ci.org/Pinjasaur/meed)

Modern JS library for getting Medium RSS feeds (user, publcation, topic, or tag)
as JSON. Targets modern browsers / Node.js with an API that utilizes
[`fetch`][fetch] along with [`async` / `await`][async].

Check out the [Meed docs][docs] for details.

## What

Get Medium RSS feeds as JSON. Check out [Ghosts/medium-feed][mf] because it may
suit your needs better.

## Why

Because [@Ghosts](https://github.com/Ghosts) was writing [medium-feed][mf]. ¯\\\_(ツ)_/¯

## How

Medium provides basic docs regarding the RSS feeds: https://help.medium.com/hc/en-us/articles/214874118-RSS-feeds
You can get feeds for a user, publication, topic, or tag. Topics can be found at
https://medium.com/topics or via `Meed#topics()`. In general, feeds seem to be
limited to 10 items.

Check out the [Meed docs][docs] for more.

### Install

Via npm or unpkg:
- `npm install meed` / `yarn add meed`
- https://unpkg.com/meed

### Use

In a browser that supports [`fetch`][ciu-fetch] & [`async`/`await`][ciu-async]:

```js
const feed = new Meed()

;(async () => {
  const user = await feed.user("Medium")
  console.log(user)
})()
```

or in Node.js (bring your own `fetch`):

```js
const Meed  = require("meed")
const fetch = require("node-fetch")

const feed = new Meed({ fetch })

;(async () => {
  const user = await feed.user("Medium")
  console.log(user)
})()
```

### Proxy

For local(host) testing in a browser, you'll probably need a CORS proxy. Here's
a list: https://gist.github.com/jimmywarting/ac1be6ea0297c16c477e17f8fbe51347

You can use one like so:

```js
new Meed({ proxy: "PROXY_URL" })
```

I've had good luck with ~~https://cors-anywhere.herokuapp.com/~~ https://cors.bridged.cc/.

Check out the [Meed docs][docs] for more details.

## Who

[Paul Esch-Laurent](https://github.com/Pinjasaur).

## License

[MIT](https://pinjasaur.mit-license.org/2018).

[mf]: https://github.com/Ghosts/medium-feed
[docs]: https://meed.js.org/

[fetch]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
[async]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
[ciu-fetch]: https://caniuse.com/#feat=fetch
[ciu-async]: https://caniuse.com/#feat=async-functions

repository: Pinjasaur/meed

repo_name: Pinjasaur/meed


text:
PackageReference management
---------------------------

## Usage

KoreBuild includes tools to help you automatically update your `dependencies.props` files.

#### Generating a dependencies.props file

On an existing project, you can execute the following command:
```
run.ps1 generate deps
```

This will update csproj files and overwrite your build/dependencies.props file with variables.

#### Updating dependencies.props

KoreBuild can help you automatically update the `build/dependencies.props` file in your repo by using a lineup package.

On command line, you can then execute
```
run.ps1 upgrade deps
```

This command requires you set a few properties so the command can download a remote package and use that as the source
of version information. Most aspnetcore repos will set this in `build/repo.props`

```xml
<PropertyGroup>
  <LineupPackageId>Internal.AspNetCore.Universe.Lineup</LineupPackageId>
  <!-- Optional, and can float -->
  <LineupPackageVersion>2.1.0-*</LineupPackageVersion>
  <LineupPackageRestoreSource>https://dotnet.myget.org/F/aspnetcore-dev/api/v3/index.json</LineupPackageRestoreSource>
</PropertyGroup>
```

The lineup package itself contains a file that lists all version, and is itself also packaged under `build/dependencies.props`. The `upgrade deps` command will update any matching variables from the lineup package in the local copy of build/dependencies.props.

## Restrictions on PackageReference usage

To manage the complexity of keeping PackageReference versions consistent within a repo and between multiple repos, KoreBuild will enforce the following patterns for using PackageReference.

#### 1. build/dependencies.props

Each repository should have this file, and it should look like this.

```xml
<Project>
  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>
  <PropertyGroup Label="Package Versions: Auto">
    <NewtonsoftJsonPackageVersion>10.0.1</NewtonsoftJsonPackageVersion>
    <MicrosoftNETTestSdkPackageVersion>15.3.0</MicrosoftNETTestSdkPackageVersion>
    <MoqPackageVersion>4.7.49</MoqPackageVersion>
    <XunitPackageVersion>2.3.0</XunitPackageVersion>
  </PropertyGroup>
  <Import Project="$(DotNetPackageVersionPropsPath)" Condition=" '$(DotNetPackageVersionPropsPath)' != '' " />
  <PropertyGroup Label="Package Versions: Pinned">
    <StablePackageVersion>10.0.1</StablePackageVersion>
  </PropertyGroup>
</Project>
```

The `<PropertyGroup Label="Package Versions: Auto">` section is for variables which should be automatically updated.

The `<PropertyGroup Label="Package Versions: Pinned">` section is for variables which upgrade automation should not touch.

### 2. PackageReference's should use variables to set versions

All .csproj files should set the version of a package reference like this:

```xml
<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="$(NewtonsoftJsonPackageVersion)" />
</ItemGroup>
```

#### Opt-out of restrictions

To opt-out of these restrictions, projects should add this to the `build/repo.props` file in their repository.
```xml
<PropertyGroup>
  <DisablePackageReferenceRestrictions>true</DisablePackageReferenceRestrictions>
</PropertyGroup>
```


text:
---
hrs_structure:
  division: '1'
  volume: '3'
  title: '12'
  chapter: 183D
  section: 183D-11
type: hrs_section
tags:
  - Government
menu:
  hrs:
    identifier: HRS_0183D-0011
    parent: HRS0183D
    name: 183D-11 Informer's fee
weight: 87065
title: Informer's fee
full_title: 183D-11 Informer's fee
---
**§183D-11 Informer's fee.** One-half of the fine imposed and collected in all cases where the defendant has been convicted for a violation of any of the provisions of this chapter or chapter 195D shall be paid to the person giving the information leading to the arrest of the person so convicted; provided that this section shall not apply, if the informer is a regular salaried sheriff, deputy sheriff, police officer, warden or constable, or officer or agent of the department. [L 1985, c 174, pt of §4; am L 1987, c 283, §17; am L 1989, c 211, §10; am L 1990, c 281, §11]

repository: SamMade/BlueAndKrabby

repo_name: SamMade/BlueAndKrabby


text:
# Management Summary {.unnumbered}

## Introduction {.unnumbered}

Creating a custom styled OSM map is one of the most common use cases among cartographers yet
it is very difficult to do so. With the new emerging technology of vector tiles it is possible
to allow anyone to create their custom OSM maps without downloading the entire database
and managing complex infrastructure. The task of this project is to make this as easy
as possible.

## Approach / Technologies {.unnumbered}

Our project is focused on creating a free and Open Source vector tiles of Open Street Map
that can easily used by developers, cartographers and designers to create their
custom maps.

Through the use of Docker we can provide workflows that don't need a complicate setup
and are deployable across operating systems.

## Result {.unnumbered}

- Docker Container to create vector tiles (MBTiles with PBF) from OSM
- Docker Container to serve vector tiles together with custom styles as raster data


text:
---
layout: contribute
title: Windows Scoop maintenance
---

# Maintaining Bazel Scoop package on Windows

**NOTE:** The Scoop package is experimental; please provide feedback (`@excitoon` in issue tracker).

## Prerequisites

You need:

*    [Scoop package manager](https://scoop.sh/) installed
*    (to publish) GitHub account in order to create pull requests to [scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main)
     * [@excitoon](https://github.com/excitoon) currently maintains this
       unofficial package. Feel free to ask questions by<EMAIL_ADDRESS>or [Telegram](http://telegram.me/excitoon).

## Release process

Scoop packages are very easy to maintain. Once you've got an URL of released Bazel, you will need to make appropriate changes in [this file](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json):
- update version;
- update dependencies if needed;
- update URL;
- update hash (`sha256` by default).

In your filesystem `bazel.json` is located in the directory `%UserProfile%/scoop/buckets/main/bucket` by default. This directory belongs to your clone of a Git repository [scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main).

Test the result:

```
scoop uninstall bazel
scoop install bazel
bazel version
bazel something_else
```

(first time) Make a fork of [scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main) and specify it as your own remote for `%UserProfile%/scoop/buckets/main`:

```
git remote add mine FORK_URL
```

Push your changes to your fork and create a pull request.

repository: bazelbuild/bazel-website

repo_name: bazelbuild/bazel-website


text:
# Online Scheduled Hard Example Selection for Visual Storytelling

|  |  |
| :--- | :--- |
| title | Online Scheduled Hard Example Selection for Visual Storytelling |
| author | Zhengyuan Zhu |
| year | 2019 |
| paper | None |
| github |  https://github.com/824zzy/worldmodel_VD |
| paperweekly | None |
| page | 10 |
| member | [@824zzy](https://github.com/824zzy) |


text:
# Developing browser-ready real-time computer vision apps with Streamlit

# Set up
* Kill heavy processes, or reboot the machine
* Set display resolution lower or zoom up the browser and the editor
* Open demo pages in private window
* Open editor
  * Comment out all the code
* Launch demos on local as fallbacks
* Run all the demos once
* Shutdown notifications

# Contents
* Intro
  * Streamlit: https://streamlit.io/
  * streamlit-webrtc: https://github.com/whitphx/streamlit-webrtc
* Demo: https://share.streamlit.io/whitphx/streamlit-webrtc-example/main/app.py
  * Web-based
  * Consuming real-time video stream from local webcam
  * Applying object detection frame by frame
  * Displaying result frames with bounding boxes
  * Hosted on a public cloud
    * Easy to share
  * Interactive
* Live coding
  * Basics of Streamlit
  * Basic usage of streamlit-webrtc
  * streamlit-webrtc with OpenCV filter
* (Optional) drawbacks of `cv2.VideoCapture` and `cv2.imshow`
* Other examples
  * Speech-to-Text: https://share.streamlit.io/whitphx/streamlit-stt-app/main/app_deepspeech.py
    * STT model: https://github.com/mozilla/DeepSpeech
  * Style Transfer: https://share.streamlit.io/whitphx/style-transfer-web-app/main/app.py
    * Forked from https://github.com/malraharsh/style-transfer-web-app
  * Pictogram: https://share.streamlit.io/whitphx/tokyo2020-pictogram-using-mediapipe/streamlit-app
    * Using MediaPipe
    * Original implementation: https://twitter.com/KzhtTkhs/status/1420390042564927489

branch_name: refs/heads/main


text:
[<<< Index](../README.md)

# Installation

When Podium is already in your `vendor` folder, simply add this to your
[application configuration](https://www.yiiframework.com/doc/guide/2.0/en/concept-configurations#application-configurations)
file:

```php
[
    'components' => [
        'podium' => \Podium\Api\Podium::class,
    ],
]
```

In this case the _component ID_ is `podium`. All application's components must use unique IDs, so if yours is already using
`podium`, or you would like to choose another word, you can do so, but notice that this documentation is always assuming
the default ID.

# Usage

To use any of Podium components simply call it with ID chosen above like:

```php
\Yii::$app->podium->componentName->componentMethod();
```

Most of component's methods are returning [PodiumResponse](https://github.com/yii-podium/yii2-api/blob/master/src/PodiumResponse.php)
object.

---

[<<< Index](../README.md) | [Next >>> Account](account.md)

gha_language: PHP


text:
# Coffeekraken s-typography-style

![npm](https://img.shields.io/npm/l/@coffeekraken/s-typography-style?style=flat-square)
![npm](https://img.shields.io/npm/v/@coffeekraken/s-typography-style?style=flat-square)
![npm](https://img.shields.io/npm/dw/@coffeekraken/s-typography-style?style=flat-square)

Full stack typography styling for your website including titles, paragraphs, lists, inline styles, blockquotes, etc...

## Table of content

1. [Features](#readme-features)
2. [Install](#readme-install)
3. [Get Started](#readme-get-started)
4. [SASS API](doc/sass)
5. [The `tf` and `vr` classes](#readme-tf-vr-classes)

## Features

1. Title styling `h1 h2 h3 h4 h5 h6`
2. Paragraphs styling `p p.lead`
3. Lists styling `ul ol li dl dt dd`
4. Inline text styling `mark del s ins u small strong em`
5. Caption and figcaption styling `caption figcaption`
6. Quote styling `quote blockquote cite`

## Install

```
npm install @coffeekraken/typography-style --save
```

## Get Started

First, [import and init sugar](https://github.com/Coffeekraken/coffeekraken/tree/master/util/sugar) into your project.

Then, import the component into your scss file like so:

```scss
@use "node_modules/@coffeekraken/typography-style/index" as typography-style;
```

Then simply generate the classes using the component mixin like so:

```scss
@include typography-style.classes($color: primary);
```

And finally use the classes inside your html

```html
<!-- directly with tags in scoped tf (text format) class -->
<!-- applying vertical rhythm using the vr class -->
<div class="tf vr">
  <h1>Hello world</h1>
  <p>
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.  Vestibulum vehicula,
  lorem accumsan semper tincidunt, metus diam porta tellus.
</p>
<ul class="ul">
  <li class="li">List item #1</li>
  <li class="li">List item #2</li>
  <li class="li">List item #3</li>
</ul>
```

## The `tf` and `vr` classes

The `tf` class is for "text format". It allows you to apply typography styling on the tags that are scoped inside it like so:

```html
<div class="tf">
  <h1>I will be styled like an h1</h1>
</div>
<h1>I will not bein styled like an h1</h1>
<h1 class="h1">I will be styled like an h1</h1>
```

The `vr` class is for "vertical rhythm". It allows you to apply margins between typography styled elements on the tags that are scoped inside it like so:

```html
<div class="tf vr">
  <h1>I will be styled like an h1 and have a margin bottom if needed</h1>
  <p>I will be styled like a paragraph and have a margin bottom if needed</p>
</div>
```

# Coffeekraken

We are a young collective of front-end creative developers with one goal in mind. Build tools to make every team working day life better. This is our first and only concern. All our tools are build around that purpose.
All what we provide are some cool tools that you can use the way you want. These tools features cover a large scope of the front-end workflow (styleguide generation, colors/fonts management, etc...). You can use only the parts that you need and let the rest aside...

[![Coffeekraken](.resources/coffeekraken-logo.jpg)](https://coffeekraken.io)

repository: jd-buzz/coffeekraken

repo_name: jd-buzz/coffeekraken


text:
# Haplotrichum aureum (Pers.) Hol.-Jech., 1976 SPECIES

#### Status
SYNONYM

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

#### Published in
Ceská Mykol. 30(1): 3 (1976)

#### Original name
null

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Basidiomycota/Agaricomycetes/Cantharellales/Botryobasidiaceae/Botryobasidium/Botryobasidium aureum/ Syn. Haplotrichum aureum/README.md

repo_name: mdoering/backbone


text:
## Description

The _depends_ pattern makes it possible to make visibility of content conditional on form data.

## Documentation

The _depends_ pattern makes it possible to make visibility of content
conditional on form data. A common use case is to only show parts of a
form when relevant. Here is an example from a hypothetical pizza order
form:

    <form>
      <input type="checkbox" name="custom"/> Add extra toppings

      <fieldset class="pat-depends" data-pat-depends="custom">
        <legend>Extra toppings</legend>
        <input type="checkbox" name="pineapple"/> Pineapple
        <input type="checkbox" name="gorgonzola"/> Gorgonzola
        <input type="checkbox" name="peanuts"/> Peanuts
        <input type="checkbox" name="redonion"/> Red onions
      </fieldset>
    </form>

In this example the fieldset with options for extra toppings is only
shown when the user indicates he wants to add extra toppings.

Another common use case is filtering a list based on some options:

    <input type="checkbox" name="paid"/> Show paid invoices
    <input type="checkbox" name="draft"/> Show draft invoices
    <input type="checkbox" name="overdue" checked="checked"/> Show overdue invoices

A paid invoice

Another paid invoice

An overdue invoice

A draft invoice

      …

### Dependency expressions

Dependencies are specified via _dependency expression_. These are
expressions that specify when an item should be visible or not.

The simplest form of a dependency expression is `<input name>` which
indicates that an input element with the given name (or id) must have a
value (if it is a checkbox must be checked). You can also test for a
specific value:

-   `<input name> = <value>`: indicates that an input element must have a
    specific value. This is most useful when used to check which radio
    button is checked.
-   `<input name> != <value>`: indicates that an input element must not
    have a specific value. This is most useful when used to check if a
    specific radio button is not checked.
-   `<input name> <= <value>`: indicates that an input element must have
    a value less than or equal than the given value. This is most useful
    for number and range inputs.
-   `<input name> < <value>`: indicates that an input element must have
    a value less than the given value. This is most useful for number
    and range inputs. inputs.
-   `<input name> > <value>`: indicates that an input element must have
    a value greater than the given value. This is most useful for number
    and range inputs. inputs.
-   `<input name> >= <value>`: indicates that an input element must have
    a value greater than or equal than the given value. This is most
    useful for number and range inputs.
-   `<input name> ~= <value>`: check if the value is a substring of the
    current value of the input.

You can also revert a test by putting the `not` keyword in front of it.
Here are some examples:

    <input type="checkbox" name="hidden"/>

        Hidden items will be included.

        Not showing hidden items.

    <input type="range" name="price" value="50"/>

    <p class="pat-depends" data-pat-depends="price<100">
        Showing cheap options.

You can also combine multiple tests using `and` and `or`, optionally
using parenthesis to specify the desired grouping. Here is a more
complex example which demonstrates the use of `and`:

    <fieldset>
      <legend>Select your flavour</legend>
      <input type="radio" name="flavour" value="hawaii"/> Hawaii
      <input type="radio" name="flavour" value="meat"/> Meat fest
      <input type="radio" name="flavour" value="veg"/> Vegeration
      <input type="checkbox" name="custom"/> Add extra ingredients
    </fieldset>

    <fieldset class="pat-depends" data-pat-depends="custom">
      <legend>Select custom ingredients</legend>
      <input type="checkbox" name="cheese"/> Extra cheese
      <input type="checkbox" name="bacon"/> Bacon
    </fieldset>

      Adding bacon means your pizza is no longer vegetarian!

This pizza menu will show a warning if the user selects a vegetarian
pizza but then also adds extra bacon to it.

### Actions

Two types of actions can be taken by the pattern: changing visibility
and disabling elements. The action can be specified using the `action`
property.

    <button data-pat-depends="title enable">Submit</button>

This example shows a submit button which is disabled if the title input
has no value.

The available actions are:

-   `show`: make an item's visibility conditional, based on the
    dependencies. If the dependencies are not met the item will
    be made invisible. In addition a CSS class of `hidden` or
    `visible` will be set.
-   `enable`: disables items and adds a `disabled` class if the
    dependencies are not met. Input elements are disabled by setting
    their disabled property. Links are disabled by registered a
    temporary event handler that blocks their default behaviour.
-   `both`: both the `enable` and `show` actions will be applied. Conversely, an
    element will be both hidden and disabled when the condition is not met.

### Transitions

When hiding or showing items you can specify a transition effect to be
used. The default behaviour is to not use any transition and immediately
hide or show the element by toggling its `display` style. If you prefer
to control the effect completely with CSS you can use the `css`
transition.

    <fieldset class="pat-depends" data-pat-depends="condition:custom; transition: css">
      <legend>Select custom ingredients</legend>
      <input type="checkbox" name="cheese"/> Extra cheese
      <input type="checkbox" name="bacon"/> Bacon
    </fieldset>

This allow full control in CSS, including the use of animation for
browsers supporting CSS animation. Two non-CSS based animation options
are also included: `fade` will fade the element in and out, and `slide`
uses a vertical sliding effect. During a transition an `in-progress`
class will be set on the element.

### Option reference

The depends can be configured through a `data-pat-depends` attribute.
The available options are:

| Field             | Default | Description                                                                                |
| ----------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `condition`       |         | The dependency condition.                                                                                |
| `action`          | `show`  | Action to perform. One of `show`, `enable` or `both`.                                                                                |
| `transition`      | `show`  | Transition effect to use if the action is `show`. Must be one of `none`, `css`, `fade` or `slide`.                                                         |
| `effect-duration` | `fast`  | Duration of transition. This is ignored if the transition is `none` or `css`.                                                                              |
| `effect-easing`   | `swing` | Easing to use for the transition. This must be a known jQuery easing method. jQuery includes `swing` and `linear`, but more can be included via jQuery UI. |

repository: plone/mockup

gha_language: JavaScript

repo_name: plone/mockup


text:
# http://docs.ansible.com/ansible/latest/docker_login_module.html

* Requirements (on host that executes module)
  * python >= 2.6
  * docker-py >= 1.7.0
  * Docker API >= 1.20
  * Only to be able to logout (state=absent): the docker command line utility

```yaml
- name: Log into DockerHub
  docker_login:
    username: docker
    password: rekcod
    email<EMAIL_ADDRESS>
- name: Log into private registry and force re-authorization
  docker_login:
    registry: your.private.registry.io
    username: yourself
    password: secrets3
    reauthorize: yes

- name: Log into DockerHub using a custom config file
  docker_login:
    username: docker
    password: rekcod
    email<EMAIL_ADDRESS>    config_path: /tmp/.mydockercfg

- name: Log out of DockerHub
  docker_login:
    state: absent
    email<EMAIL_ADDRESS>```

repository: reymont/ReadAndLearn

gha_language: Jupyter Notebook

repo_name: reymont/ReadAndLearn


text:
---
hrs_structure:
  division: '1'
  volume: '6'
  title: '19'
  chapter: '330'
  section: 330-2
type: hrs_section
tags:
  - Government
menu:
  hrs:
    identifier: HRS_0330-0002
    parent: HRS0330
    name: 330-2 Rules concerning poisons
weight: 48010
title: Rules concerning poisons
full_title: 330-2 Rules concerning poisons
---
**§330-2 Rules concerning poisons.** The department of health may adopt rules concerning poisons and poison containers. [PC 1869, c 88, §1; am L 1872, c 16, §1; RL 1925, §1004; am L 1931, c 224, pt of §1; RL 1935, §1430; RL 1945, §2952; am L 1945, c 139, §1(b); RL 1955, §53-2; am L Sp 1959 2d, c 1, §19; [HRS §330-2](/title-19/chapter-330/section-330-2/); am L 2001, c 2, §2]

Cross References

Rulemaking, see chapter 91.


text:
---
layout: post
title: 'Word of the Day: Variadic Functions'
published: true
---

Variadic Functions have come to JavaScript thanks to ES2015. A **Variadic Function** is a function that can accept any number of arguments. For example: `funcName("one");` or `funcName("one", "two");` or `funcName("one", "two", "three");`.

It can accept any number of argguments because the total number of parameters are unknown and can be adjusted at the time the method is called.

#### References:
- [MDN: Spread operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator)
- [ES6 ECMAScript 6 — New Features: Overview & Comparison](http://es6-features.org/#RestParameter)


text:
## Test environments

* Ubuntu 12.04 (on travis-ci: old, current, devel; https://travis-ci.org/petermeissner/robotstxt)
* LinuxMint 17.3 (local, current)
* win-builder (devel and release)

## R CMD check results

0 errors | 0 warnings | 1 note

* This is a new release.

## Note

* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Peter Meissner<EMAIL_ADDRESS>New submission

License components with restrictions and base license permitting such:
  MIT + file LICENSE
File 'LICENSE':
  YEAR: 2016
  COPYRIGHT HOLDER: Peter Meissner
Found the following (possibly) invalid URLs:
  URL: http://cran.r-project.org/package=robotstxt
    From: README.md
    Status: 404
    Message: Not Found

--> Te license is MIT, one of the valid ones for CRAN
--> The link is in canonical form and should be valid when the package is published on CRAN

## Reverse dependencies

This is a new release, so there are no reverse dependencies.

repository: seozoidberg/robotstxt

repo_name: seozoidberg/robotstxt


text:
# GraphQL Performance

## Simple Code Search

In this section, GraphQL for selecting Observation resources with a certain code is used.

### Download of Resources

All measurements are done after Blaze is in a steady state with all resources to download in it's resource cache in order to cancel out resource load times from disk or file system cache.

Download is done using the following `curl` command:

```sh
curl -s -H "Content-Type: application/graphql" -d "{ ObservationList { subject { reference } } }" "http://localhost:8080/\$graphql" > /dev/null"
```

| CPU        | Heap Mem | Block Cache | # Res. ¹ | # Obs. ² | Code    | # Hits | Time (s) | T / 1M ³ |
|------------|---------:|------------:|---------:|---------:|---------|-------:|---------:|---------:|
| EPYC 7543P |     8 GB |        1 GB |     29 M |     28 M | 17861-6 |  171 k |    1.045 |     6.11 |
| EPYC 7543P |     8 GB |        1 GB |     29 M |     28 M | 39156-5 |  967 k |    5.740 |     5.94 |
| EPYC 7543P |     8 GB |        1 GB |     29 M |     28 M | 29463-7 |  1.3 M |    8.057 |     6.20 |
| EPYC 7543P |    30 GB |       10 GB |    292 M |    278 M | 17861-6 |  1.7 M |   10.744 |     6.32 |
| EPYC 7543P |    30 GB |       10 GB |    292 M |    278 M | 39156-5 |  9.7 M |   70.122 |     7.23 |
| EPYC 7543P |    30 GB |       10 GB |    292 M |    278 M | 29463-7 |   13 M |   96.735 |     7.44 |

¹ Number of Resources, ² Number of Observations, ³ Time in seconds per 1 million resources, The amount of system memory was 128 GB in all cases.

According to the measurements, the time needed by Blaze to deliver Observations containing only the subject reference is about **twice as fast** as returning the same information via [Subsetted FHIR Search](fhir-search.md#download-of-resources-with-subsetting) and **4 times as fast** as downloading the whole Observation Resources using [FHIR Search](fhir-search.md#download-of-resources).

## Used Dataset

The dataset was the same as in [FHIR Search](fhir-search.md) performance tests.

repository: samply/blaze

gha_language: Clojure

repo_name: samply/blaze


text:
# SequenceToSequence
My implementation of Sequence To Sequence model (Seq2Seq) using Tensorflow. This encoder / decode allow learning semantic representations of variables sequences (like words or sentenses) using Gated Recurrents Units (GRU cells).

## Random letter sequences example
File: random_sequences.py
The implemented exemple in the main.py file is a word embedding model that take letters as features sequences (26 features as one hot vector for 15 step random sequences).

### Grid search hyperparameter optimization
A grid search hyperparameter optimization was done on this example.
Optimized hyperparameters are:
- Learning Rate (optimal value: 1e-2)
- Number of hidden lstm units (optimal value: 250)
- Training batch size (optimal value: 50)

### Results
Reached 100% accuracy in 4k training steps

## Sentence sentences exemple
File: sentences.py
The goal of this exemple is to compare distances between sentences's embeddings.

### Grid search hyperparameter optimization
A grid search hyperparameter optimization was done on this example.
Optimized hyperparameters are:
- Learning Rate (optimal value: 2e-2)
- Number of hidden lstm units (optimal value: 10)

### Results
Reached 100% accuracy in 50 to 100 training steps.
The sentence "This cat is cute" is closer to "This cat is eating" (distance: 0.3331) than "My name is Florian" (distance: 1.2888).

## Other applications
- [Deep Spelling Corrections](https://machinelearnings.co/deep-spelling-9ffef96a24f6)

## Useful links
[Sequence to Sequence Learning with Neural Networks](https://arxiv.org/pdf/1409.3215.pdf)

repository: Florian-BACHO/SequenceToSequence

repo_name: Florian-BACHO/SequenceToSequence


text:
March 2, 2020
Attending: timmywil, mgol

Location: https://gitter.im/jquery/meeting

## Deleting issues is now enabled for admins
* Delete any spam issues, especially ones similar to the recent spam

## Travis restarts
* Resolved an issue with mgol not being able to restart builds

## Issues and PRs needing review
* https://github.com/jquery/jquery/pull/4634
	- yes, but looking into size reduction
* https://github.com/jquery/jquery/issues/4616 Summit
	- https://github.com/openjs-foundation/summit/issues/254

## Docs
* https://github.com/jquery/api.jquery.com/milestone/2
* Need to get 3.0 deprecations in the docs
- https://github.com/jquery/api.jquery.com/issues/970

## Swarm check
* http://swarm.jquery.org/job/9430
	- Event failures in iOS, Opera, and Safari

gha_license_id: NOASSERTION


text:
Thank you for your contribution! 🎉

Here are a few checks to help us make this the _best PR ever_ depending on the nature of your changes.

🥦 Please __replace these lines above with your PR message__, and remove the section below that doesn't apply:

###  Features and Bug Fixes

- [ ] Issue being fixed is referenced.
- [ ] Test coverage added/updated.
- [ ] Typings added/updated.
- [ ] README updated (API changes, instructions, etc.).
- [ ] Changes to dependencies explained.
- [ ] Changeset added (run `yarn changeset` locally to add one, follow prompts).

👉 If any of these don't apply, please ~cross them out~.

### Tooling

- [ ] Issue being fixed is referenced.
- [ ] Changes to dependencies explained.
- [ ] README instructions updated.
- [ ] A Changeset is __not__ added.

👉 If any of these don't apply, please ~cross them out~.

repository: liunate/focus-trap

gha_license_id: MIT

repo_name: liunate/focus-trap


text:
# [VCL](https://vcl.github.io/) size-modulation

Scale the size of text and whole widgets.

## Features

Can scale the size of simple text and whole widgets comprised of
multiple components as far as they use relative units
that depend on the font-size in the context, like `em` for.
As this is true for VCL components, they can be applied to any of them.

## Usage

Scale the size of simple text and whole widgets.

[text example](/demo/example-text.html)

The size modulation can be applied to whole widgets like this
pagination at 130%.

[widget example](/demo/example-widget.html)

## Classes

- `vclScale75p`
- `vclScale85p`
- `vclScale110p`
- `vclScale115p`
- `vclScale120p`
- `vclScale130p`
- `vclScale155p`
- `vclScale180p`
- `vclScale250p`
- `vclScale300p`

## Modifiers

## Variables

## Demo

[example.html](/demo/example.html) on GH-pages.


text:
# About
ANEAmazonAds is an Adobe AIR native extension (ANE) for Kindle tablets (and others Android devices) to show Amazon Ads.

Supported functionality:

- show ad;

- hide ad;

- cache interstitial;

- show interstitial;

- listen tap, close, etc. event.

# Docs
Please, read docs and try ANE before asking any questions.

https://developer.amazon.com/appsandservices/apis/earn/mobile-ads

http://help.adobe.com/en_US/air/extensions/index.html

# Installation
Extension ID: com.pozirk.ads.AmazonAds

Add "AmazonAds.ane" and "air\AdMob\bin\AmazonAds.swc" to your AIR project.

Add the following lines to your AIR Aplication-app.xml file inside <manifestAdditions> section:

<uses-permission android:name="android.permission.INTERNET"/>

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

<application>

	<activity android:name="com.amazon.device.ads.AdActivity" android:configChanges="keyboardHidden|orientation|screenSize"/>

</application>

Internet permission is mandatory, others are optional.

# Example
```actionscript
import com.pozirk.ads.amazon.AmazonAds;
import com.pozirk.ads.amazon.AdParams;
import com.pozirk.ads.amazon.AdEvent;

...

protected var _amazonAds:AmazonAds = null;

...

//> initialization of AmazonAds
_amazonAds = new AmazonAds();
_amazonAds.addEventListener(AdEvent.AD_LOADED, onEvent);
_amazonAds.addEventListener(AdEvent.AD_FAILED_TO_LOAD, onEvent);
_amazonAds.addEventListener(AdEvent.AD_EXPANDED, onEvent);
_amazonAds.addEventListener(AdEvent.AD_COLLAPSED, onEvent);
_amazonAds.init("YOUR_APP_ID");
_amazonAds.enableLogging(true); //for debug only!
_amazonAds.enableTesting(true); //for debug only!
//<

...

protected function onEvent(ae:AdEvent):void
{
	trace(ae.type+" "+ae._data);
}
//<

//showing 600x90 ad at the bottom center side of the screen
_amazonAds.show(AdParams.SIZE_600x90, AdParams.HALIGN_CENTER, AdParams.VALIGN_BOTTOM);
_amazonAds.setTimeout(30000); //set timeout (in milliseconds) to load new ad, not sure if it works properly...

//caching interstitial
_amazonAds.cacheInterstitial();

//showing interstitial
_amazonAds.showInterstitial();
```

# Game with Amazon Mobile Ads
www.amazon.com/Pozirk-Games-All-in-One-Mahjong-FREE/dp/B00JQHVJSU/

*If Amazon Ads don't work (no fill), game will fall back to AdMob.*

In order to see the interstitial ad, you need to win/lose any game.

# Misc
ANE is build with AIR14.0, in order to rebuild for another version (prior 14.0) do the following:

- edit "air\extension.xml" and change 14.0 in very first line to any SDK you need;

- edit "build.bat" and in the very last line change path from AIR14.0 SDK to any AIR SDK you need;

- execute "build.bat" to repack the ANE.

repository: pozirk/ANEAmazonAds

repo_name: pozirk/ANEAmazonAds


text:
# Get trending shows

In this example we get the first two pages of trending shows.

Since we do not need authentication or authorization for this example, only the Client-ID is required.

[!code-csharp[](../../../codesnippets/examples/ClientSetup.cs)]

The following lines show how to get the first page of trending shows.

If no [`TraktPagedParameters`](xref:TraktNet.Parameters.TraktPagedParameters) are given, the default page is the first page and the default limit per page is 10 items.

[!code-csharp[](../../../codesnippets/examples/modules/shows/TrendingShows.cs#L7-L12)]

For getting the second page, we use the [`TraktPagedParameters`](xref:TraktNet.Parameters.TraktPagedParameters) for setting the page we want to get.

[!code-csharp[](../../../codesnippets/examples/modules/shows/TrendingShowsPaged.cs#L3-L3)]

[!code-csharp[](../../../codesnippets/examples/modules/shows/TrendingShowsPaged.cs#L5-L13)]

Here are the complete codes.

Trending Shows with default first page:
[!code-csharp[](../../../codesnippets/examples/modules/shows/TrendingShows.cs)]

Trending Shows with second page:
[!code-csharp[](../../../codesnippets/examples/modules/shows/TrendingShowsPaged.cs)]

branch_name: refs/heads/develop

gha_language: C#


text:
# budget-tracker
An application for budget tracking whilst on a trip or in areas where you may not have access to WiFi.

## Contents
Section | Description
------------ | -------------
[Screenshot](#screenshot) | Screenshots of the Budget Tracker and a link to the repo.
[Functionality](#functionality) | Information on the functionality of the Budget Tracker.
[Licence](#licence) | Licence for the source code

## Screenshot
![Screenshot of working Budget Tracker](assets/budget-tracker.PNG)

You can access the Budget Tracker [here](https://kvtemadden-budget-tracker.herokuapp.com/)

You can access the GitHub Repo via [this link](https://github.com/kvtemadden/budget-tracker)

## Functionality
When visiting the landing page, a user will see a blank graph on their initial visit, a total and a form fill area.

This form allows users to input either an increase or decrease in their current budget.

The changes in budget will then be added to the graph, which allows someone to see any peaks or troughs in their current budget spend.

As the budget tracker may be used by a certain demographic, e.g. travellers, the user will be able to use the tracker whilst it's offline but notice no difference.

Their spend will then be added back onto the database meaning it'll be recalled for when they return to the app.

## Licence
> This site was created under the standard MIT licence.

![GitHub](https://img.shields.io/github/license/kvtemadden/portfolio?color=%23203333&label=LICENCED%20AS&style=for-the-badge)

repository: kvtemadden/budget-tracker

repo_name: kvtemadden/budget-tracker


text:
# [SONATA](http://www.sonata-nfv.eu)'s Gatekeeper Rate Limit micro-service
[![Build Status](http://jenkins.sonata-nfv.eu/buildStatus/icon?job=son-gkeeper)](http://jenkins.sonata-nfv.eu/job/son-gkeeper)

This is the folder of the Rate Limiter micro-service.

The rate limiter is based on the [leaky bucket
algorithm](https://en.wikipedia.org/wiki/Leaky_bucket). Each client/limit has
an empty bucket assigned with a given capacity (according to a limit
definition). Each request goes into the bucket, that is leaking requests at a
given rate (again according to a limit definition). A client is allowed to
perform the request if there are remaining capacity in the bucket.

Example: Suppose that we have a limit that allows at maximum 6 requests per
minute. Then our bucket can hold at maximum 6 requests. However we’ll start
draining our bucket after 60 seconds at a rate of 6reqs/60sec, that is
removing one request from the bucket every 10 seconds.

# Rate Limit API
The rate limiter micro-service exposes a RESTful HTTP API that can perform basic
CRUD operations on rate limit definitions, and an endpoint to check resource
usage allowance.

## Create or update a rate limit definition
```
PUT /limits/{resource-limit-id}
```

A rate limit establishes how many requests in a time interval a client is
allowed to perform. For example, a client is allowed to perform at maximum 10
requests per hour.

This operation accepts the following parameters:

- **period** - Time sliding window (in seconds) for which the control of maximum
  number of requests is verified. (*required*)
- **limit** - Maximum number of requests that a client is allowed to perform in
  the specified period. (*required*)
- **description** - A human readable limit description. (*optional*)

### Sample request / response
The following request creates a limit, identified by
"check_account_balance_limit" where a client is allowed to perform a maximum of
10 requests per hour.

```json
PUT /limits/check_account_balance_limit
Content-Type: application/json
{
  "period": 3600,
  "limit": 10,
  "description": "Can check account balance 10 times / hour"
}

-- response
204 No Content
```

This operation can return the following HTTP status codes:
 - 204 No Content - The limit has been created or updated
 - 400 Bad Request - If the request is malformed, i.e., invalid values or missing parameters

## Delete resource limit
```
DELETE /limits/{resource-limit-id}
```

This operation can return the following HTTP status codes:
 - 204 No Content - The limit was deleted
 - 404 Not Found -  The specified resource limit does not exist.

## Retrieve existing resource limit definitions
```
GET /limits
```
### Sample request / response
```json
GET /limits
-- response
200 OK
Content-Type: application/json
[
  { "id": "other_account_operations", "period": 60, "limit": 100 },
  { "id": "create_account", "period": 3600, "limit": 10, "description": "Can create 10 accounts / hour" },
  { "id": "default", "period": 1, "limit": 10, "description": "Global request rate policy is 10req/s"}
]
```

## Check limit
```
POST /check
```

This operation checks if a client is either allowed or not allowed to perform
the request according to the specified limit. Each call to this endpoint will
consume one request associated to the given client.

This operation accepts the following parameters:
 * **limit_id** - The limit identifier that should be applied. (*required*)
 * **client_id** - Any string that identifies the client. Cannot contain spaces. (*required*)

### Sample request / response
```json
POST /check
{
  "limit_id": "create_account",
  "client_id": "user_a"
}

-- response

200 Ok
{
  "allowed": true,
  "remaining": 10
}
```
Where the response body attributes:
 * allowed - If the client is allowed to perform the request. This can be either
   *true* or *false*.
 * remaining - Total number of available requests at the current time.

This operation can return the following HTTP status codes:
 - 200 Ok - Request was successfully processed. Client should inspect response
   body in order to check if client is allowed to perform the request.
 - 400 Bad Request - If the specified "limit_id" does not exist or the request
   is malformed

# Quick start
NOTE: In order to try this example you must have access to a redis instance. Set the
  `REDIS_URL` if necessary (defaults to "redis://<IP_ADDRESS>:6379") and `REDIS_PASSWORD` (not required)
  with the appropriate values.

Here's a quick start how to use the rate limiter. First start by creating a limit
definition. In our example we're creating a limit that will allow one request
each five seconds.

```sh
curl -XPUT http://localhost:5000/limits/meaningfull_limit_id -d '{
  "period": 5,
  "limit": 1,
  "description": "Can check account balance 10 times / hour"
}'
```
Now that we have out limit definition, we can start sending requests. If you
send a second request without waiting a few seconds, it will not be allowed.
```sh
curl -XPOST http://localhost:5000/check -d '{"limit_id": "meaningfull_limit_id", "client_id": "client1"}'
{"allowed":true,"remaining":0}

curl -XPOST http://localhost:5000/check -d '{"limit_id": "meaningfull_limit_id", "client_id": "client1"}'
{"allowed":false,"remaining":0}
```

Wait a few seconds and try again...

## License
The license of the SONATA Gatekeeper is Apache 2.0 (please see the
[license](https://github.com/sonata-nfv/son-editorgkeeper/blob/master/LICENSE)
file).

#### Feedback-Chanels

Please use the [GitHub issues](https://github.com/sonata-nfv/son-gkeeper/issues)
and the SONATA development mailing list<EMAIL_ADDRESS>for
feedback.

repository: felipevicens/son-gkeeper

gha_language: Ruby

repo_name: felipevicens/son-gkeeper


text:
---
layout: post
title: "CRL4,OsGNOM1"
description: ""
category: genes
tags: [anther, crown root, lemma, auxin, growth, shoot, root, adventitious root, lateral root, crown]
---

* **Information**
    + Symbol: CRL4,OsGNOM1
    + MSU: [LOC_Os03g46330](http://rice.uga.edu/cgi-bin/ORF_infopage.cgi?orf=LOC_Os03g46330)
    + RAPdb: [Os03g0666100](https://rapdb.dna.affrc.go.jp/locus/?name=Os03g0666100)

* **Publication**
    + [CRL4 regulates crown root formation through auxin transport in rice](http://www.ncbi.nlm.nih.gov/pubmed?term=CRL4 regulates crown root formation through auxin transport in rice%5BTitle%5D), 2008, Plant Root.
    + [Adventitious root formation in rice requires OsGNOM1 and is mediated by the OsPINs family](http://www.ncbi.nlm.nih.gov/pubmed?term=Adventitious root formation in rice requires OsGNOM1 and is mediated by the OsPINs family%5BTitle%5D), 2009, Cell Res.

* **Genbank accession number**

* **Key message**
    + RT-PCR and analysis of promoter::GUS transgenic plants showed that OsGNOM1 is expressed in AR primordia, vascular tissues, LRs, root tips, leaves, anthers and lemma veins, with a distribution pattern similar to that of auxin
    + ) mutant crown rootless4 (crl4) that was found to have defective crown root formation
    + Besides reduced crown root number, the crl4 mutant showed auxin-related abnormal phenotypical character-istics such as reduced lateral root number and impaired root gravitropism
    + These results indicate that maintaining an appropriate auxin accumulation and gradient through CRL4 in the basal portion of shoots is essential for crown root formation in rice
    + CRL4 regulates crown root formation through auxin transport in rice
    + CRL4 encodes a protein highly homologous with Arabidopsis GNOM, which mediates auxin-dependent plant growth by coordinating the polar localization of auxin efflux carrier PIN1
    + In the crl4 mutant, auxin transport was impaired in shoots and roots
    + Adventitious root formation in rice requires OsGNOM1 and is mediated by the OsPINs family

* **Connection**

[//]: # * **Key figures**


text:
# Service Worker Exploration
Please read [Getting Started](#getting-started) to start.

![service worker cover](https://philna.sh/images/service-worker.png)

## Overview

A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don't need a web page or user interaction. Today, they already include features like push notifications and background sync. In the future, service workers will support other things like periodic sync or geofencing. The core feature discussed in this tutorial is the ability to intercept and handle network requests, including programmatically managing a cache of responses.

The reason this is such an exciting API is that it allows you to support offline experiences, giving developers complete control over the experience.

Before service worker, there was one other API that gave users an offline experience on the web called AppCache. There are a number of issues with the AppCache API that service workers were designed to avoid.

ref : https://developers.google.com/web/fundamentals/primers/service-workers/

## Index
* [1.0 Cache static files](1.0.cache-static-files)

  The Service Worker API comes with a Cache interface, that lets you create stores of responses keyed by request. While this interface was intended for service workers it is actually exposed on the window, and can be accessed from anywhere in your scripts. The entry point is caches.

* [2.0 Offline first](2.0.offline-first)

  Do not let your visitor go because there is not internet connection. Offline first lets you to display web content even though no internet network is available.

* [3.0 Background Sync](3.0.background-sync)

  Background sync is a new web API that lets you defer actions until the user has stable connectivity. This is useful for ensuring that whatever the user wants to send, is actually sent

* [4.0 Push notification](4.0.push-notifications)

  Push notification provides a simple and effective way to re-engage with your users.

* [WIP] Geofencing

## Prerequisites
Service worker only support `localhost` and `HTTPS`, you need some webserver to run in local. Here are some that we recomend :
* [https-server (npm)](https://www.npmjs.com/package/http-server)
* [Web Server from Chrome (Google Chrome Extention)](https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb?hl=en)

## Getting Started
We split the module into several directory, to get started please read `README.md` we provide in each directory.

## Service Worker Compatilbility (last update: 19-08-2019)
Ref : https://caniuse.com/#feat=serviceworkers
![Service Worker Compatibily](https://res.cloudinary.com/dhjkktmal/image/upload/v1566198365/github/Screenshot_from_2019-08-19_14-05-29.png)

## Contributtors
* [Yusuf Akhsan H.](https://twitter.com/xyussanx)

repository: SebangsaHQ/exploration-service-worker

repo_name: SebangsaHQ/exploration-service-worker


text:
---
layout: post
title: The challenges of writing safe Lua abstractions in Rust
tags: coding
---

For the past few months, as an exercise of writing low-level Rust/C interop code, I've been trying to write a safe high-level interface for the [Lua virtual machine][1] in Rust.
I may or may not publish my code as a crate eventually, but regardless, here are a few challenges I've faced.

### Ensuring stack space

Most Lua APIs interact with the stack, and the [Lua documentation][2] emphasizes that you (the caller) must ensure there is enough stack space before calling a function that modifies the stack.
The stack is a LIFO collection, and the API offers many functions to push, pop and inspect the elements inside it.
The API does not perform bounds checking however, so if you don't ensure enough space for an operation, it will trigger **undefined behavior**.

Writing safe Rust code means it can never trigger UB.
Under no circumstances should safe code ever be able to trigger UB, which means our safe abstraction must be able to prevent every edge case that may trigger UB.
If safe code somehow manages to trigger UB, we can only ever hope for a nice segfault.

This is a deceptively hard problem to solve. One naive solution is to simply call [`lua_checkstack`][3] before all calls that push to the stack.

```c
assert(lua_checkstack(L, 1)); // ensure stack space for the number
lua_pushnumber(L, 1.2);
```

We can then create a safe abstraction for pushing to a stack, so that the caller won't have to worry about stack spaces.

```rust
struct Stack(*mut lua_State);

impl Stack {
    fn push_number(&self, n: f64) {
        unsafe {
            assert!(lua_checkstack(self.0, 1) != 0);
            lua_pushnumber(self.0, n);
        }
    }
}
```

However, calling `lua_checkstack` before every stack operation seems rather inefficient.
Although Rust incurs essentially no performance penalty for calling C functions, and the function itself should be a quick pointer comparison most of the time, it's more efficient to perform one stack check and reallocation for a large set of operations if possible.
Also, as I'll discuss later, this combining of stack checks actually becomes necessary to support proper error handling without significant overhead.
For example, the following two snippets are equivalent, but the latter is clearly more efficient:

```c
// lua equivalent: { foo = "bar" }
assert(lua_checkstack(L, 1)); // ensure stack space for the table
lua_newtable(L);
assert(lua_checkstack(L, 1)); // ensure stack space for the value
lua_pushstring(L, "bar");
lua_setfield(L, -2, "foo"); // set the field

// optimized equivalent:
assert(lua_checkstack(L, 2)); // ensure stack space for both the table and value
lua_newtable(L);
lua_pushstring(L, "bar");
lua_setfield(L, -2, "foo"); // set the field
```

How could we group these related operations together and predict the total required stack space in advance?
One elegant solution is to represent each stack operation as an _expression_.
The creation of a table is an expression, and the pushing of a string is also an expression.
The setting of a field is a _composite expression_ taking three child expressions — the table, key and value — forming an expression tree.
We can then take advantage of Rust's expressive type system and static analysis to accurately predict the required stack space at **compile time**.

For simplicity and illustrative purposes, let's assume that evaluating an expression pushes exactly one value onto the stack.
This would be more complex if we were to support [multi-valued expressions][4].
We can create an abstraction for expressions using _traits_, and implement the trait for every type that can be evaluated on the stack.

```rust
trait Expression {
    /// The number of stack slots required for this expression.
    const STACK_SIZE: c_int;

    /// Evaluates this expression on the stack.
    ///
    /// # Safety
    ///
    /// Caller must ensure there is enough stack space.
    unsafe fn eval(&self, stack: *mut lua_State);
}

struct NewTable;
struct PushString(String);
struct SetField<T: Expression, K: Expression, V: Expression>(T, K, V);
```

Implementing `Expression` for `NewTable` and `PushString` is straightforward; both require only one stack space for the push operation.

```rust
impl Expression for NewTable {
    const STACK_SIZE: c_int = 1;

    unsafe fn eval(&self, stack: *mut lua_State) {
        lua_newtable(stack);
    }
}

impl Expression for PushString {
    const STACK_SIZE: c_int = 1;

    unsafe fn eval(&self, stack: *mut lua_State) {
        lua_pushlstring(stack, self.0.as_ptr() as *const c_char, self.0.len());
    }
}
```

Implementing `Expression` for `SetField` is less straightforward, but it is intuitive.
Each operand of the expression can be arbitrarily complex themselves, but we know that evaluating them will push exactly one value onto the stack each as a result.
Thus the required stack space for a `SetField` is the maximum of its operands' required stack space plus whatever is already on the stack from evaluating the previous operands.

```rust
impl<T: Expression, K: Expression, V: Expression> Expression for SetField<T, K, V> {
    const STACK_SIZE: c_int = max(
        T::STACK_SIZE,
        1 + K::STACK_SIZE, // +1 to account for the table on the stack
        2 + V::STACK_SIZE, // +2 to account for the table and key
    );

    unsafe fn eval(&self, stack: *mut lua_State) {
        self.0.eval(stack); // push table
        self.1.eval(stack); // push key
        self.2.eval(stack); // push value
        lua_settable(stack, -3); // pop key and value into field
        // the table is left on the stack
    }
}
```

Then it is simply a matter of composing the expressions and inspecting the stack size constant in order to evaluate them safely.
We can create arbitrarily complex expressions and the compiler will always be able to predict the exact amount of required stack space (well, as far as [`recursion_limit`][11] allows).

```rust
impl Stack {
    fn eval<E: Expression>(expr: &E) {
        unsafe {
            // ensure stack space for the entire expression
            assert!(lua_checkstack(self.0, E::STACK_SIZE) != 0);
            expr.eval(self.0);
            lua_pop(self.0);
        }
    }
}

// compose and evaluate complex expression
let stack: Stack = ...;
let table = NewTable;
let key = PushString("foo".into());
let value = PushString("bar".into());
stack.eval(SetField(table, key, value)); // { foo = "bar" }
```

Finally, a safe high-level Lua abstraction with little overhead... Right?

### Error handling

Unfortunately, it turns out that the code above is completely unsafe due to the lack of error handling.
Many Lua APIs can throw _exceptions_, for example if the allocation for the new table or string fails.
Reading and writing table fields can also throw exceptions because the table may have _metamethods_.
However, whereas a C++ runtime would be able to throw _real_ exceptions, Lua is written in C which doesn't have real exceptions; instead it emulates them using [`longjmp`][5].

A `longjmp` is essentially a `goto` that is not restricted to a function scope.
It can jump up _anywhere_ there is a `setjmp`.
Lua uses these functions to create a _protected context_.
Before calling some fallible code, it creates a recovery point with a `setjmp` and then calls the fallible code.
If the fallible code wants to throw an exception, it pushes the exception onto the stack and then performs a `longjmp` back to the recovery point.
This achieves an effect similar to a C++ `try`/`catch` block.

At this point, it's probably necessary to clarify some terminologies.
There is the _Lua stack_ which is a heap-allocated structure that contains Lua values.
_Lua code_ uses this stack for passing function arguments and return values, holding local variables, etc.
A _Lua stack_ are tied to a _Lua thread_, and in practice these are the same thing.
Lua threads are also called _coroutines_ or _green threads_; there seems to be no consensus on how to call this thing.

There is also the _call stack_ which is a block of raw memory where _native code_ stores things like local variables, return addresses, etc.
Both _C code_ and _Rust code_ share the same call stack.
A _call stack_ is tied to a real _OS thread_.

With that in mind, let's imagine what might happen when the Lua runtime encounters some Lua code that wants to throw an exception.
It pushes the exception value onto the Lua stack, then performs a `longjmp` back to the recovery point.
This is like traversing _up_ the call stack with a `goto` until the recovery point, _jumping over_ all stack frames between the `longjmp` and `setjmp` points.
The recovery point then detects that a `longjmp` had occurred and pops the exception value from the Lua stack.

This is perfectly fine in the context of plain old C code.
However, where it becomes problematic is when _Rust_ code is intermingled with C code.
The issue with `longjmp` is that its behavior is platform-dependent and [it does not play nicely with Rust's destructors][6].
`longjmp` could be implemented by simply changing the stack pointer which results in Rust's stack frames being "forgotten".
Although safe Rust doesn't actually guarantee that destructors are ever called, it would be in our best interests to avoid leaking memory by forgetting destructors.
`longjmp` could also be implemented by unwinding the stack, and it may or may not call destructors while unwinding.
If it does call destructors, that would trigger undefined behavior unless the Rust stack frame is marked with [`C-unwind` which is still experimental][13].

It seems like there is no way to write safe Rust code that can be jumped over by `longjmp` without relying on platform implementation details.
We also want to be able to catch exceptions without letting them propagate through Rust code.
That means we need to wrap every fallible code in a protected context so that the exception is caught before it touches Rust stack frames.
Fortunately, Lua provides `lua_pcall` to do exactly this.

### Lua 5.1 and LuaJIT complications

To fix the earlier examples, we could try wrapping the code for allocating the table and string using `lua_pushcfunction`.
This creates a Lua function, that calls back into Rust code, that calls back into Lua to create a new table, and we can call _that_ wrapper function in a protected context using `lua_pcall`.

```rust
impl Expression for NewTable {
    const STACK_SIZE: c_int = 1; // one for the callback function

    unsafe fn eval(&self, stack: *mut lua_State) {
        unsafe extern "C" fn cb_newtable(L: *mut lua_State) -> c_int {
            // lua guarantees 20 stack space; no checkstack necessary
            lua_newtable(L);
            1 // return the new table
        }

        lua_pushcfunction(stack, cb_newtable);
        assert!(lua_pcall(stack, 0, 1, 0) == 0, "out of memory");
        // the table is now on the stack
    }
}
```

This code should be perfectly safe. Problem solved?
Unfortunately in Lua 5.1 and LuaJIT implementations, [`lua_pushcfunction` can also throw a memory error][7] if allocation for the Lua wrapper for the C function fails.

We could use `lua_cpcall` instead, which only exists in Lua 5.1 and LuaJIT.
It guarantees that it will never throw, but there is a catch:
The callback called by `lua_cpcall` cannot return any values.
Why does this limitation exist? I'm not sure.
One way to circumvent this is to create a separate temporary thread to perform the fallible operation on, and then move the result to the main stack.

```rust
impl Expression for NewTable {
    const STACK_SIZE: c_int = 2; // two for the thread and table

    unsafe fn eval(&self, stack: *mut lua_State) {
        // create a temporary thread for fallible operation
        // this also pushes the thread onto the main stack
        let temp = lua_newthread(stack);

        unsafe extern "C" fn cb_newtable(L: *mut lua_State) -> c_int {
            // pointer to the main stack given as the first argument
            let stack = lua_topointer(L, 1) as *mut lua_State;
            // lua guarantees 20 stack space; no checkstack necessary
            lua_newtable(L);
            // move the new table to the main stack
            lua_xmove(L, stack, 1);

            0
        }

        // create the table on the temporary thread
        assert!(lua_cpcall(temp, cb_newtable, stack as *mut c_void) == 0, "out of memory");

        // the table is now on the stack; remove temporary thread
        lua_replace(stack, -2);

        // the table is left on the stack
    }
}
```

Okay, now this code should be perfectly safe. Problem solved?
Unfortunately, `lua_newthread` can also throw a memory error if allocation fails.
To create a temporary thread to catch exceptions, we need to create another temporary thread to safely create the temporary thread, like a chicken and egg problem.
One way to circumvent this is to create the temporary thread on runtime initialization, cache it to the registry and retrieve it when necessary, since reading a field from a table will never throw (without metamethods, at least).

As you can see, even the deceptively simple act of creating a new empty table can get quite convoluted when creating a safe abstraction that can handle every edge case.
It seems impossible to create a safe "zero-cost" abstraction for Lua when the API does not provide any way of handling errors in a zero-cost manner.

There is another edge case we need to handle when interacting with Lua 5.1 and LuaJIT: `lua_checkstack` can throw a memory error.
That's right, the very function responsible for checking if the stack can be resized, will also throw if resizing the stack fails, so it must also be wrapped in a protected context...

```rust
impl Stack {
    fn eval<E: Expression>(expr: &E) {
        unsafe {
            unsafe extern "C" fn cb_checkstack<E: Expression>(L: *mut lua_State) -> c_int {
                // this can throw since we are protected
                luaL_checkstack(L, E::STACK_SIZE, b"out of memory".as_ptr() as *const c_char);
                0
            }

            assert!(lua_cpcall(self.0, cb_checkstack::<E>, ptr::null_mut()) == 0, "out of memory");
            expr.eval(self.0);
            lua_pop(self.0);
        }
    }
}
```

This circles back to the previously discussed point about combining stack checks for a large set of operations.
A simple `lua_checkstack` may be cheap and unsafe, but wrapping that in `lua_cpcall` for safety probably adds a non-negligible overhead.
Combining the stack checks is a nice compromise that achieves both safety and performance.

### Zero-cost error handling using C++ exceptions

Everything I've discussed so far relied on `lua_pcall` to create a protected context.
This is reasonable because a Rust library that interacts with a Lua host cannot assume anything about how the exception mechanism is actually implemented under the hood, and on most systems that would be `setjmp`/`longjmp`.
However when Rust code is the host of Lua code, we have the option of compiling Lua to use _real_ C++ exceptions as its exception mechanism.

This may allow us to ditch `lua_pcall` and all the dance around temporary threads, but Rust code still cannot catch C++ exceptions directly, or so it seems.
Rust panics are _probably_ implemented using the same unwinding mechanism (libunwind) as Lua (if compiled in C++ with Clang?) which could allow us to catch exceptions directly in Rust using `catch_unwind`, but the documentation explicitly declares this as [undefined behavior][8].
We could also try using the [`try` compiler intrinsic][9] directly, but this nightly-only API will never be stabilized and there seems to be very little documentation around its usage.

As far as I can tell, the only safe and stable way of catching C++ exceptions in Rust that doesn't rely on black magic is manually writing C++ wrapper functions for every Lua function that may throw and linking them into Rust.
It would be a massive PITA, but there shouldn't be any overhead from calling C++ wrapper functions if [link-time optimizations][10] are enabled.

I've yet to explore this area further, but the possibility of safe zero-cost abstractions makes exploring it seem worthwhile in the future.

[1]: https://www.lua.org
[2]: http://www.lua.org/manual/5.1/manual.html#3.2
[3]: http://www.lua.org/manual/5.1/manual.html#lua_checkstack
[4]: https://www.lua.org/pil/5.1.html
[5]: https://en.wikipedia.org/wiki/Setjmp.h
[6]: https://github.com/rust-lang/unsafe-code-guidelines/issues/210
[7]: http://lua-users.org/lists/lua-l/2021-11/msg00077.html
[8]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html#notes
[9]: https://doc.rust-lang.org/std/intrinsics/fn.try.html
[10]: https://doc.rust-lang.org/cargo/reference/profiles.html#lto
[11]: https://doc.rust-lang.org/reference/attributes/limits.html#the-recursion_limit-attribute
[12]: https://blog.rust-lang.org/inside-rust/2021/01/26/ffi-unwind-longjmp.html
[13]: https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html


text:
---
title: Translating the Gatsby Documentation
---

import LangList from "@components/lang-list"

There is an ongoing effort to translate the content in the Gatsby docs into multiple languages. For members of the community around the world building Gatsby sites and learning about web development, having docs and learning materials in your own language provides a lot of value. There's also a great opportunity for folks like you to contribute to the translations of the Gatsby docs.

If you're a fluent speaker of a language other than English and you're interested in helping translate [gatsbyjs.com](https://gatsbyjs.com), here is some information for you to know:

## The general process

Each translation has its own repository in the [gatsbyjs](https://github.com/gatsbyjs/) organization on GitHub, with designated codeowners to review and approve changes. Each repo will include all pages needing translations (with some prioritized over others), and a bot to notify of changes in the main repo to keep everything up-to-date.

## Ongoing translations

Currently, the following languages are being translated:

<LangList />

> Note: Once a new translation repository is created, feel free to add it here in a PR!

## Creating a new translation

If you don't see your language in the above list, please see [Starting a new language](/contributing/translation/new-translations/) for how to start up a new translation repository.

## Contributing translations

If you do see your language on the list, please see the [translation contributor guide](/contributing/translation/translators/) for information on how to contribute translations in your language.

## Maintainers

Each translation repo will have at least two maintainers and codeowners that are responsible for the upkeep of the repo. Please see the [Translation Maintainer Guide](/contributing/translation/maintainers/) for information on the responsibilities of translation maintainers.

## Language-specific channels

Each translation group may want to have a space for maintainers and community members to ask questions and coordinate the project. **[Discord](https://gatsby.dev/discord) is the official channel** and maintainers can have their own private groups if desired. Some groups may elect to use a different platform such as Wechat or Whatsapp, but that will be at your own discretion.

To set up a Discord channel for a translation group (if it doesn't already exist), [ping the Gatsbyjs team](/contributing/how-to-contribute/#not-sure-how-to-start-contributing).


text:
<!--
 * @Author: Vincent Young
 * @Date: 2022-10-05 05:19:33
 * @LastEditors: Vincent Young
 * @LastEditTime: 2022-10-05 07:11:25
 * @FilePath: /Telegraph-Image-Hosting/README.md
 * @Telegram: https://t.me/missuo
 *
 * Copyright © 2022 by Vincent, All Rights Reserved.
-->
# Telegraph-Image-Hosting
Build a free image hosting with [Telegraph](https://telegra.ph)

**[中文](https://github.com/missuo/Telegraph-Image-Hosting/blob/main/README-OLD.md) document is no longer maintained**

## Features
- Free
- Unlimited bandwidth (It will consume the traffic of your VPS)
- No censorship (NSFW image can be uploaded)
- You can upload any file, not just image files

## Disadvantages
- Single file cannot exceed 5MB
- Access speed may not be ideal in China Mainland

## Current Strategy (Recommended)
**Full enable HTTPS**
```
Client -> Cloudflare Server (Optional) -> Your VPS (Example: Oracle Cloud) -> Telegraph Servers (NL)
```
## Demo Site
[missuo.ru](https://missuo.ru)

![0e8a64f1538a6727edfda](https://telegraph.eowo.us/file/0e8a64f1538a6727edfda.png)

## Deployment
### Preparation
- a Domain (Make sure it's not blocked by GFW)
- an overseas VPS (Make sure you can access [Telegraph](https://telegra.ph))
- Install Nginx

### Configure Nginx
**I don't talk too much about simple steps such as domain name resolution and SSL certificate application.**
```
location /upload {
            add_header Access-Control-Allow-Origin *;
            add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
            add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
            if ($request_method = 'OPTIONS') {
                return 204;}
            proxy_pass https://telegra.ph/upload;
}
location /file {
            proxy_pass https://telegra.ph/file;
}

client_max_body_size 5m;
```
**Note: Remove all other useless `location` related configuration and just keep the two above.**

## With uPic for macOS/iOS
**Thanks to my best friend [Svend](https://github.com/gee1k) (author of [uPic](https://github.com/gee1k/uPic)) for guiding the configuration scheme**

1. You can change the `API URL` and `Domain` to your own.

![7e28f947345cba3709835](https://telegraph.eowo.us/file/7e28f947345cba3709835.png)

2. Don't forget to click on the `Other fields` to add the header information.

![7516a06df832d1897922a](https://telegraph.eowo.us/file/7516a06df832d1897922a.png)

## Deploy the Web Site (Optional)
**Please excuse the fact that I can't write a front-end, so the front-end is very minimal. If you have written a nice front-end, please submit a `Pull Request` and I will appreciate it.**

1. Connect your server by SSH, then enter your web directory.
```shell
cd /www/wwwroot/xxx.com
```
2. Download the source code on GitHub with `Git`.
```shell
git clone https://github.com/missuo/Telegraph-Image-Hosting.git ./
```

3. Move all the files in `web` directory to web root directory.
```shell
mv web/* ./
```

4. Modify the line 34 to your domain in `api.php`

5. Have fun.

## Finally
There is no guarantee that it will work all the time, after all, Telegraph is on the GFW list. Use it and cherish it!

## LICENSE
[MIT License](https://raw.githubusercontent.com/missuo/Telegraph-Image-Hosting/main/LICENSE)

repository: OwenDrost/Telegraph-Image-Hosting

repo_name: OwenDrost/Telegraph-Image-Hosting


text:
# Food Catalogue

> Food catalogue helps you find different recipe that suits your preferences.

![screenshot](./src/Img/foodcatalogue.png)

## Built With

- Javascript
- React
- CSS
- Bootstrap
- Redux
- API

## Live Demo

[Live Demo](https://maj-kitchen.netlify.app/)

## Getting Started

To get a local copy up and running follow these simple example steps.

# Instructions (Set Up)

Clone this repository in your computer

```
$ git clone git@github.com:Kingobaino1/food-catalogue-react.js.git
```

To install dependencies, run the code below in terminal

```
$ npm install
```

To see it locally run

```
$ npm start
```

To run test

```
$ npm test
```

Then open localhost:3000 in your web browser.

## Author

👤 **Kingsley Ibeh**

- GitHub: [@githubhandle](https://github.com/Kingobaino1)
- Twitter: [@twitterhandle](https://twitter.com/ibehkingso)
- Linkedin: [@linkedinhandle](https://www.linkedin.com/in/kingsley-ibeh/)

## 🤝 Contributing

Contributions, issues and feature requests are welcome!
Feel free to check the issues page.

## Show your support

Give a ⭐ if you like this project!

## Acknowledgments

- [Microverse](https://www.microverse.org/).
- [ Nelson Sakwa on Behance](https://www.behance.net/gallery/31579789/Ballhead-App-(Free-PSDs)).
- [The Meal Db](https://www.themealdb.com/api.php)

## 📝 License

This project is [MIT licensed](/LICENSE).

branch_name: refs/heads/development