rrm workspace: TRM/HRM/SRM code, Maze dataset, dynamical-analysis pipelineHEADmain

Curated export for clone-and-run Maze training (2x A6000) + diagnostics.
trm/hrm pretrain.py carry trajectory-augmentation code (backward-compatible).
Heavy artifacts (checkpoints/wandb/npz) gitignored; see PROVENANCE.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

13 files changed, 2128 insertions, 0 deletions

diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/api.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/api.md
new file mode 100644
index 0000000..29a54c4
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/api.md
@@ -0,0 +1,88 @@
+# [**12.** API Reference](@id API-Reference)
+
+This section describes the function interface, or "API mode",
+for interacting with Pkg.jl. The function API is recommended
+for non-interactive usage, for example in scripts.
+
+## General API Reference
+
+Certain options are generally useful and can be specified in any API call.
+You can specify these options by setting keyword arguments.
+
+### Redirecting output
+
+Use the `io::IOBuffer` keyword argument to redirect Pkg output.
+For example, `Pkg.add("Example"; io=devnull)` will discard any output produced by the `add` call.
+
+## Package API Reference
+
+In the REPL mode, packages (with associated version, UUID, URL etc) are parsed from strings,
+for example `"Package#master"`,`"Package@v0.1"`, `"www.mypkg.com/MyPkg#my/feature"`.
+
+In the API mode, it is possible to use strings as arguments for simple commands (like `Pkg.add(["PackageA", "PackageB"])`,
+but more complicated commands, which e.g. specify URLs or version range, require the use of a more structured format over strings.
+This is done by creating an instance of [`PackageSpec`](@ref) which is passed in to functions.
+
+```@docs
+PackageSpec
+PackageMode
+UpgradeLevel
+Pkg.add
+Pkg.develop
+Pkg.activate
+Pkg.rm
+Pkg.update
+Pkg.test
+Pkg.build
+Pkg.pin
+Pkg.free
+Pkg.instantiate
+Pkg.resolve
+Pkg.gc
+Pkg.status
+Pkg.precompile
+Pkg.offline
+Pkg.setprotocol!
+Pkg.dependencies
+Pkg.project
+Pkg.undo
+Pkg.redo
+```
+
+
+## Registry API Reference
+
+!!! compat "Julia 1.1"
+    Pkg's registry handling requires at least Julia 1.1.
+
+The function API for registries uses [`RegistrySpec`](@ref)s, similar to
+[`PackageSpec`](@ref).
+
+```@docs
+RegistrySpec
+Pkg.Registry.add
+Pkg.Registry.rm
+Pkg.Registry.update
+Pkg.Registry.status
+```
+
+## [Artifacts API Reference](@id Artifacts-Reference)
+
+!!! compat "Julia 1.3"
+    Pkg's artifacts API requires at least Julia 1.3.
+
+```@docs
+Pkg.Artifacts.create_artifact
+Pkg.Artifacts.remove_artifact
+Pkg.Artifacts.verify_artifact
+Pkg.Artifacts.artifact_meta
+Pkg.Artifacts.artifact_hash
+Pkg.Artifacts.bind_artifact!
+Pkg.Artifacts.unbind_artifact!
+Pkg.Artifacts.download_artifact
+Pkg.Artifacts.find_artifacts_toml
+Pkg.Artifacts.ensure_artifact_installed
+Pkg.Artifacts.ensure_all_artifacts_installed
+Pkg.Artifacts.@artifact_str
+Pkg.Artifacts.archive_artifact
+```
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/artifacts.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/artifacts.md
new file mode 100644
index 0000000..7b1ade6
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/artifacts.md
@@ -0,0 +1,229 @@
+# [**8.** Artifacts](@id Artifacts)
+
+!!! compat "Julia 1.3"
+    Pkg's artifacts functionality requires at least Julia 1.3.
+
+`Pkg` can install and manage containers of data that are not Julia packages.  These containers can contain platform-specific binaries, datasets, text, or any other kind of data that would be convenient to place within an immutable, life-cycled datastore.
+These containers, (called "Artifacts") can be created locally, hosted anywhere, and automatically downloaded and unpacked upon installation of your Julia package.
+This mechanism is also used to provide the binary dependencies for packages built with [`BinaryBuilder.jl`](https://github.com/JuliaPackaging/BinaryBuilder.jl).
+
+## Basic Usage
+
+`Pkg` artifacts are declared in an `Artifacts.toml` file, which can be placed in your current directory or in the root of your package.
+Currently, `Pkg` supports downloading of tarfiles (which can be compressed) from a URL.
+Following is a minimal `Artifacts.toml` file which will permit the downloading of a `socrates.tar.gz` file from `github.com`.
+In this example, a single artifact, given the name `socrates`, is defined.
+
+```TOML
+# a simple Artifacts.toml file
+[socrates]
+git-tree-sha1 = "43563e7631a7eafae1f9f8d9d332e3de44ad7239"
+
+    [[socrates.download]]
+    url = "https://github.com/staticfloat/small_bin/raw/master/socrates.tar.gz"
+    sha256 = "e65d2f13f2085f2c279830e863292312a72930fee5ba3c792b14c33ce5c5cc58"
+```
+
+If this `Artifacts.toml` file is placed in your current directory, then `socrates.tar.gz` can be downloaded, unpacked and used with `artifact"socrates"`.
+Since this tarball contains a folder `bin`, and a text file named `socrates` within that folder, we could access the content of that file as follows.
+
+```julia
+using Pkg.Artifacts
+
+rootpath = artifact"socrates"
+open(joinpath(rootpath, "bin", "socrates")) do file
+    println(read(file, String))
+end
+```
+
+If you have an existing tarball that is accessible via a `url`, it could also be be accessed in this manner.
+To create the `Artifacts.toml` you must compute two hashes: the `sha256` hash of the download file, and the `git-tree-sha1` of the unpacked content.
+These can be computed as follows.
+
+```julia
+using Tar, Inflate, SHA
+
+filename = "socrates.tar.gz"
+println("sha256: ", bytes2hex(open(sha256, filename)))
+println("git-tree-sha1: ", Tar.tree_hash(IOBuffer(inflate_gzip(filename))))
+```
+
+To access this artifact from within a package you create, place the `Artifacts.toml` at the root of your package, adjacent to `Project.toml`. Then, make sure to add `Pkg` in your `deps` and set `julia = "1.3"` or higher in your `compat` section.
+
+## `Artifacts.toml` files
+
+`Pkg` provides an API for working with artifacts, as well as a TOML file format for recording artifact usage in your packages, and to automate downloading of artifacts at package install time.
+Artifacts can always be referred to by content hash, but are typically accessed by a name that is bound to a content hash in an `Artifacts.toml` file that lives in a project's source tree.
+
+!!! note
+    It is possible to use the alternate name `JuliaArtifacts.toml`, similar
+    to how it is possible to use `JuliaProject.toml` and `JuliaManifest.toml`
+    instead of `Project.toml` and `Manifest.toml`, respectively.
+
+An example `Artifacts.toml` file is shown here:
+
+```TOML
+# Example Artifacts.toml file
+[socrates]
+git-tree-sha1 = "43563e7631a7eafae1f9f8d9d332e3de44ad7239"
+lazy = true
+
+    [[socrates.download]]
+    url = "https://github.com/staticfloat/small_bin/raw/master/socrates.tar.gz"
+    sha256 = "e65d2f13f2085f2c279830e863292312a72930fee5ba3c792b14c33ce5c5cc58"
+
+    [[socrates.download]]
+    url = "https://github.com/staticfloat/small_bin/raw/master/socrates.tar.bz2"
+    sha256 = "13fc17b97be41763b02cbb80e9d048302cec3bd3d446c2ed6e8210bddcd3ac76"
+
+[[c_simple]]
+arch = "x86_64"
+git-tree-sha1 = "4bdf4556050cb55b67b211d4e78009aaec378cbc"
+libc = "musl"
+os = "linux"
+
+    [[c_simple.download]]
+    sha256 = "411d6befd49942826ea1e59041bddf7dbb72fb871bb03165bf4e164b13ab5130"
+    url = "https://github.com/JuliaBinaryWrappers/c_simple_jll.jl/releases/download/c_simple+v1.2.3+0/c_simple.v1.2.3.x86_64-linux-musl.tar.gz"
+
+[[c_simple]]
+arch = "x86_64"
+git-tree-sha1 = "51264dbc770cd38aeb15f93536c29dc38c727e4c"
+os = "macos"
+
+    [[c_simple.download]]
+    sha256 = "6c17d9e1dc95ba86ec7462637824afe7a25b8509cc51453f0eb86eda03ed4dc3"
+    url = "https://github.com/JuliaBinaryWrappers/c_simple_jll.jl/releases/download/c_simple+v1.2.3+0/c_simple.v1.2.3.x86_64-apple-darwin14.tar.gz"
+
+[processed_output]
+git-tree-sha1 = "1c223e66f1a8e0fae1f9fcb9d3f2e3ce48a82200"
+```
+
+This `Artifacts.toml` binds three artifacts; one named `socrates`, one named `c_simple` and one named `processed_output`.
+The single required piece of information for an artifact is its `git-tree-sha1`.
+Because artifacts are addressed only by their content hash, the purpose of an `Artifacts.toml` file is to provide metadata about these artifacts, such as binding a human-readable name to a content hash, providing information about where an artifact may be downloaded from, or even binding a single name to multiple hashes, keyed by platform-specific constraints such as operating system or libgfortran version.
+
+## Artifact types and properties
+
+In the above example, the `socrates` artifact showcases a platform-independent artifact with multiple download locations.
+When downloading and installing the `socrates` artifact, URLs will be attempted in-order until one succeeds.
+The `socrates` artifact is marked as `lazy`, which means that it will not be automatically downloaded when the containing package is installed, but rather will be downloaded on-demand when the package first attempts to use it.
+
+The `c_simple` artifact showcases a platform-dependent artifact, where each entry in the `c_simple` array contains keys that help the calling package choose the appropriate download based on the particulars of the host machine.
+Note that each artifact contains both a `git-tree-sha1` and a `sha256` for each download entry.  This is to ensure that the downloaded tarball is secure before attempting to unpack it, as well as enforcing that all tarballs must expand to the same overall tree hash.
+
+The `processed_output` artifact contains no `download` stanza, and so cannot be installed.
+An artifact such as this would be the result of code that was previously run, generating a new artifact and binding the resultant hash to a name within this project.
+
+## Using Artifacts
+
+Artifacts can be manipulated using convenient APIs exposed from the `Pkg.Artifacts` namespace.
+As a motivating example, let us imagine that we are writing a package that needs to load the [Iris machine learning dataset](https://archive.ics.uci.edu/ml/datasets/iris).
+While we could just download the dataset during a build step into the package directory, and many packages currently do precisely this, that has some significant drawbacks:
+
+* First, it modifies the package directory, making package installation stateful, which we want to avoid.
+  In the future, we would like to reach the point where packages can be installed completely read-only, instead of being able to modify themselves after installation.
+
+* Second, the downloaded data is not shared across different versions of our package.
+  If we have three different versions of the package installed for use by various projects, then we need three different copies of the data, even if it hasn't changed between those versions.
+  Moreover, each time we upgrade or downgrade the package, unless we do something clever (and probably brittle), we have to download the data again.
+
+With artifacts, we will instead check to see if our `iris` artifact already exists on-disk and only if it doesn't will we download and install it, after which we can bind the result into our `Artifacts.toml` file:
+
+```julia
+using Pkg.Artifacts
+
+# This is the path to the Artifacts.toml we will manipulate
+artifact_toml = joinpath(@__DIR__, "Artifacts.toml")
+
+# Query the `Artifacts.toml` file for the hash bound to the name "iris"
+# (returns `nothing` if no such binding exists)
+iris_hash = artifact_hash("iris", artifact_toml)
+
+# If the name was not bound, or the hash it was bound to does not exist, create it!
+if iris_hash == nothing || !artifact_exists(iris_hash)
+    # create_artifact() returns the content-hash of the artifact directory once we're finished creating it
+    iris_hash = create_artifact() do artifact_dir
+        # We create the artifact by simply downloading a few files into the new artifact directory
+        iris_url_base = "https://archive.ics.uci.edu/ml/machine-learning-databases/iris"
+        download("$(iris_url_base)/iris.data", joinpath(artifact_dir, "iris.csv"))
+        download("$(iris_url_base)/bezdekIris.data", joinpath(artifact_dir, "bezdekIris.csv"))
+        download("$(iris_url_base)/iris.names", joinpath(artifact_dir, "iris.names"))
+    end
+
+    # Now bind that hash within our `Artifacts.toml`.  `force = true` means that if it already exists,
+    # just overwrite with the new content-hash.  Unless the source files change, we do not expect
+    # the content hash to change, so this should not cause unnecessary version control churn.
+    bind_artifact!(artifact_toml, "iris", iris_hash)
+end
+
+# Get the path of the iris dataset, either newly created or previously generated.
+# this should be something like `~/.julia/artifacts/dbd04e28be047a54fbe9bf67e934be5b5e0d357a`
+iris_dataset_path = artifact_path(iris_hash)
+```
+
+For the specific use case of using artifacts that were previously bound, we have the shorthand notation `artifact"name"` which will automatically search for the `Artifacts.toml` file contained within the current package, look up the given artifact by name, install it if it is not yet installed, then return the path to that given artifact.
+An example of this shorthand notation is given below:
+
+```julia
+using Pkg.Artifacts
+
+# For this to work, an `Artifacts.toml` file must be in the current working directory
+# (or in the root of the current package) and must define a mapping for the "iris"
+# artifact.  If it does not exist on-disk, it will be downloaded.
+iris_dataset_path = artifact"iris"
+```
+
+## The `Pkg.Artifacts` API
+
+The `Artifacts` API is broken up into three levels: hash-aware functions, name-aware functions and utility functions.
+
+* **Hash-aware** functions deal with content-hashes and essentially nothing else. These methods allow you to query whether an artifact exists, what its path is, to verify that an artifact satisfies its content hash on-disk, etc.  Hash-aware functions include: `artifact_exists()`, `artifact_path()`, `remove_artifact()`, `verify_artifact()` and `archive_artifact()`.  Note that in general you should not use `remove_artifact()` and should instead use `Pkg.gc()` to cleanup artifact installations.
+
+* **Name-aware** functions deal with bound names within an `Artifacts.toml` file, and as such, typically require both a path to an `Artifacts.toml` file as well as the artifact name.  Name-aware functions include: `artifact_meta()`, `artifact_hash()`, `bind_artifact!()`, `unbind_artifact!()`, `download_artifact()` and `ensure_artifact_installed()`.
+
+* **Utility** functions deal with miscellaneous aspects of artifact life, such as `create_artifact()`, `ensure_all_artifacts_installed()`, and even the `@artifact_str` string macro.
+
+For a full listing of docstrings and methods, see the [Artifacts Reference](@ref) section.
+
+## Overriding artifact locations
+
+It is occasionally necessary to be able to override the location and content of an artifact.
+A common use case is a computing environment where certain versions of a binary dependency must be used, regardless of what version of this dependency a package was published with.
+While a typical Julia configuration would download, unpack and link against a generic library, a system administrator may wish to disable this and instead use a library already installed on the local machine.
+To enable this, `Pkg` supports a per-depot `Overrides.toml` file placed within the `artifacts` depot directory (e.g. `~/.julia/artifacts/Overrides.toml` for the default user depot) that can override the location of an artifact either by content-hash or by package UUID and bound artifact name.
+Additionally, the destination location can be either an absolute path, or a replacement artifact content hash.
+This allows sysadmins to create their own artifacts which they can then use by overriding other packages to use the new artifact.
+
+```TOML
+# Override single hash to absolute path
+78f35e74ff113f02274ce60dab6e92b4546ef806 = "/path/to/replacement"
+
+# Override single hash to new artifact content-hash
+683942669b4639019be7631caa28c38f3e1924fe = "d826e316b6c0d29d9ad0875af6ca63bf67ed38c3"
+
+# Override package bindings by specifying the package UUID and bound artifact name
+# For demonstration purposes we assume this package is called `Foo`
+[d57dbccd-ca19-4d82-b9b8-9d660942965b]
+libfoo = "/path/to/libfoo"
+libbar = "683942669b4639019be7631caa28c38f3e1924fe"
+```
+
+Due to the layered nature of `Pkg` depots, multiple `Overrides.toml` files may be in effect at once.
+This allows the "inner" `Overrides.toml` files to override the overrides placed within the "outer" `Overrides.toml` files.
+To remove an override and re-enable default location logic for an artifact, insert an entry mapping to the empty string:
+
+```TOML
+78f35e74ff113f02274ce60dab6e92b4546ef806 = "/path/to/new/replacement"
+683942669b4639019be7631caa28c38f3e1924fe = ""
+
+[d57dbccd-ca19-4d82-b9b8-9d660942965b]
+libfoo = ""
+```
+
+If the two `Overrides.toml` snippets as given above are layered on top of eachother, the end result will be mapping the content-hash `78f35e74ff113f02274ce60dab6e92b4546ef806` to `"/path/to/new/replacement"`, and mapping `Foo.libbar` to the artifact identified by the content-hash `683942669b4639019be7631caa28c38f3e1924fe`.
+Note that while that hash was previously overridden, it is no longer, and therefore `Foo.libbar` will look directly at locations such as `~/.julia/artifacts/683942669b4639019be7631caa28c38f3e1924fe`.
+
+Most methods that are affected by overrides have the ability to ignore overrides by setting `honor_overrides=false` as a keyword argument within them.
+For UUID/name based overrides to work, `Artifacts.toml` files must be loaded with the knowledge of the UUID of the loading package.
+This is deduced automatically by the `artifacts""` string macro, however if you are for some reason manually using the `Pkg.Artifacts` API within your package and you wish to honor overrides, you must provide the package UUID to API calls like `artifact_meta()` and `ensure_artifact_installed()` via the `pkg_uuid` keyword argument.
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/basedocs.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/basedocs.md
new file mode 100644
index 0000000..21a12c5
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/basedocs.md
@@ -0,0 +1,25 @@
+```@meta
+EditURL = "https://github.com/JuliaLang/Pkg.jl/blob/master/docs/src/basedocs.md"
+```
+
+# Pkg
+
+Pkg is Julia's builtin package manager, and handles operations
+such as installing, updating and removing packages.
+
+!!! note
+    What follows is a very brief introduction to Pkg. For more
+    information on `Project.toml` files, `Manifest.toml` files, package
+    version compatibility (`[compat]`), environments, registries, etc.,
+    it is highly recommended to read the full manual, which is available here:
+    [https://julialang.github.io/Pkg.jl/v1/](https://julialang.github.io/Pkg.jl/v1/).
+
+```@eval
+import Markdown
+file = joinpath(Sys.STDLIB, "Pkg", "docs", "src", "getting-started.md")
+str = read(file, String)
+str = replace(str, r"^#.*$"m => "")
+str = replace(str, "[API Reference](@ref)" =>
+          "[API Reference](https://julialang.github.io/Pkg.jl/v1/api/)")
+Markdown.parse(str)
+```
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/compatibility.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/compatibility.md
new file mode 100644
index 0000000..94f160e
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/compatibility.md
@@ -0,0 +1,201 @@
+# [**6.** Compatibility](@id Compatibility)
+
+Compatibility refers to the ability to restrict the versions of the dependencies that your project is compatible with.
+If the compatibility for a dependency is not given, the project is assumed to be compatible with all versions of that dependency.
+
+Compatibility for a dependency is entered in the `Project.toml` file as for example:
+
+```toml
+[compat]
+julia = "1.0"
+Example = "0.4.3"
+```
+
+After a compatibility entry is put into the project file, `up` can be used to apply it.
+
+The format of the version specifier is described in detail below.
+
+!!! info
+    There is currently no way to give compatibility from the Pkg REPL mode so for now, one has to manually edit the project file.
+
+## Version specifier format
+
+Similar to other package managers, the Julia package manager respects [semantic versioning](https://semver.org/) (semver).
+As an example, a version specifier given as e.g. `1.2.3` is therefore assumed to be compatible with the versions `[1.2.3 - 2.0.0)` where `)` is a non-inclusive upper bound.
+More specifically, a version specifier is either given as a **caret specifier**, e.g. `^1.2.3`  or as a **tilde specifier**, e.g. `~1.2.3`.
+Caret specifiers are the default and hence `1.2.3 == ^1.2.3`. The difference between a caret and tilde is described in the next section.
+The union of multiple version specifiers can be formed by comma separating individual version specifiers, e.g.
+```toml
+[compat]
+Example = "1.2, 2"
+```
+will result in `[1.2.0, 3.0.0)`.  Note leading zeros are treated differently, e.g. `Example = "0.2, 1"` would only result in `[0.2.0-0.3.0, 1.0.0-2.0.0]`. See the next section for more information on versions with leading zeros.
+
+### [Behavior of versions with leading zeros (0.0.x and 0.x.y)](@id compat-pre-1.0)
+
+While the semver specification says that all versions with a major version of 0 (versions before 1.0.0) are incompatible
+with each other, we have decided to only apply that for when both the major and minor versions are zero. In other words,
+0.0.1 and 0.0.2 are considered incompatible. A pre-1.0 version with non-zero minor version (`0.a.b` with `a != 0`) is
+considered compatible with versions with the same minor version and smaller or equal patch versions (`0.a.c` with `c <= b`);
+i.e., the versions 0.2.2 and 0.2.3 are compatible with 0.2.1 and 0.2.0. Versions with a major version of 0 and different
+minor versions are not considered compatible, so the version 0.3.0 might have breaking changes from 0.2.0. To that end, the
+`[compat]` entry:
+
+```toml
+[compat]
+Example = "0.0.1"
+```
+
+results in a versionbound on `Example` as `[0.0.1, 0.0.2)` (which is equivalent to only the version 0.0.1), while the
+`[compat]` entry:
+
+```toml
+[compat]
+Example = "0.2.1"
+```
+
+results in a versionbound on Example as `[0.2.1, 0.3.0)`.
+
+In particular, a package may set `version = "0.2.4"` when it has feature additions compared to 0.2.3 as long as it
+remains backward compatible with 0.2.0.  See also [The `version` field](@ref).
+
+### Caret specifiers
+
+A caret specifier allows upgrade that would be compatible according to semver.
+An updated dependency is considered compatible if the new version does not modify the left-most non zero digit in the version specifier.
+
+Some examples are shown below.
+
+```toml
+[compat]
+PkgA = "^1.2.3" # [1.2.3, 2.0.0)
+PkgB = "^1.2"   # [1.2.0, 2.0.0)
+PkgC = "^1"     # [1.0.0, 2.0.0)
+PkgD = "^0.2.3" # [0.2.3, 0.3.0)
+PkgE = "^0.0.3" # [0.0.3, 0.0.4)
+PkgF = "^0.0"   # [0.0.0, 0.1.0)
+PkgG = "^0"     # [0.0.0, 1.0.0)
+```
+
+### Tilde specifiers
+
+A tilde specifier provides more limited upgrade possibilities. When specifying major, minor
+and patch versions, or when specifying major and minor versions, only the patch version is
+allowed to change. If you only specify a major version, then both minor and patch versions
+are allowed to be upgraded (`~1` is thus equivalent to `^1`).
+For example:
+
+```toml
+[compat]
+PkgA = "~1.2.3" # [1.2.3, 1.3.0)
+PkgB = "~1.2"   # [1.2.0, 1.3.0)
+PkgC = "~1"     # [1.0.0, 2.0.0)
+PkgD = "~0.2.3" # [0.2.3, 0.3.0)
+PkgE = "~0.0.3" # [0.0.3, 0.0.4)
+PkgF = "~0.0"   # [0.0.0, 0.1.0)
+PkgG = "~0"     # [0.0.0, 1.0.0)
+```
+
+For all versions with a major version of 0 the tilde and caret specifiers are equivalent.
+
+### Equality specifier
+
+Equality can be used to specify an exact version:
+
+```toml
+[compat]
+PkgA = "= 1.2.3"  # [1.2.3, 1.2.3]
+```
+
+### Inequality specifiers
+
+Inequalities can also be used to specify version ranges:
+
+```toml
+[compat]
+PkgB = ">= 1.2.3" # [1.2.3,  ∞)
+PkgC = "≥ 1.2.3"  # [1.2.3,  ∞)
+PkgD = "< 1.2.3"  # [0.0.0, 1.2.3) = [0.0.0, 1.2.2]
+```
+
+### Hyphen specifiers
+
+Hyphen syntax can also be used to specify version ranges. Make sure that you have a space on both sides of the hyphen.
+
+```toml
+[compat]
+PkgA = "1.2.3 - 4.5.6" # [1.2.3, 4.5.6]
+PkgA = "0.2.3 - 4.5.6" # [0.2.3, 4.5.6]
+```
+
+Any unspecified trailing numbers in the first end-point are considered to be zero:
+
+```toml
+[compat]
+PkgA = "1.2 - 4.5.6"   # [1.2.0, 4.5.6]
+PkgA = "1 - 4.5.6"     # [1.0.0, 4.5.6]
+PkgA = "0.2 - 4.5.6"   # [0.2.0, 4.5.6]
+PkgA = "0.2 - 0.5.6"   # [0.2.0, 0.5.6]
+```
+
+Any unspecified trailing numbers in the second end-point will be considered to be wildcards:
+
+```toml
+[compat]
+PkgA = "1.2.3 - 4.5"   # 1.2.3 - 4.5.* = [1.2.3, 4.6.0)
+PkgA = "1.2.3 - 4"     # 1.2.3 - 4.*.* = [1.2.3, 5.0.0)
+PkgA = "1.2 - 4.5"     # 1.2.0 - 4.5.* = [1.2.0, 4.6.0)
+PkgA = "1.2 - 4"       # 1.2.0 - 4.*.* = [1.2.0, 5.0.0)
+PkgA = "1 - 4.5"       # 1.0.0 - 4.5.* = [1.0.0, 4.6.0)
+PkgA = "1 - 4"         # 1.0.0 - 4.*.* = [1.0.0, 5.0.0)
+PkgA = "0.2.3 - 4.5"   # 0.2.3 - 4.5.* = [0.2.3, 4.6.0)
+PkgA = "0.2.3 - 4"     # 0.2.3 - 4.*.* = [0.2.3, 5.0.0)
+PkgA = "0.2 - 4.5"     # 0.2.0 - 4.5.* = [0.2.0, 4.6.0)
+PkgA = "0.2 - 4"       # 0.2.0 - 4.*.* = [0.2.0, 5.0.0)
+PkgA = "0.2 - 0.5"     # 0.2.0 - 0.5.* = [0.2.0, 0.6.0)
+PkgA = "0.2 - 0"       # 0.2.0 - 0.*.* = [0.2.0, 1.0.0)
+```
+
+!!! compat "Julia 1.4"
+    Hyphen specifiers requires at least Julia 1.4, so it is strongly recomended to also add
+    ```toml
+    [compat]
+    julia = "1.4"
+    ```
+    to the project file when using them.
+
+## Fixing conflicts
+
+Version conflicts were introduced previously with an [example](@ref conflicts)
+of a conflict arising in a package `D` used by two other packages, `B` and `C`.
+Our analysis of the error message revealed that `B` is using an outdated
+version of `D`.
+To fix it, the first thing to try is to `pkg> dev B` so that
+you can modify `B` and its compatibility requirements.
+If you open its `Project.toml` file in an editor, you would probably notice something like
+
+```toml
+[compat]
+D = "0.1"
+```
+
+Usually the first step is to modify this to something like
+```toml
+[compat]
+D = "0.1, 0.2"
+```
+
+This indicates that `B` is compatible with both versions 0.1 and version 0.2; if you `pkg> up`
+this would fix the package error.
+However, there is one major concern you need to address first: perhaps there was an incompatible change
+in `v0.2` of `D` that breaks `B`.
+Before proceeding further, you should update all packages and then run `B`'s tests, scanning the
+output of `pkg> test B` to be sure that `v0.2` of `D` is in fact being used.
+(It is possible that an additional dependency of `D` pins it to `v0.1`, and you wouldn't want to be misled into thinking that you had tested `B` on the newer version.)
+If the new version was used and the tests still pass,
+you can assume that `B` didn't need any further updating to accomodate `v0.2` of `D`;
+you can safely submit this change as a pull request to `B` so that a new release is made.
+If instead an error is thrown, it indicates that `B` requires more extensive updates to be
+compatible with the latest version of `D`; those updates will need to be completed before
+it becomes possible to use both `A` and `B` simultaneously.
+You can, though, continue to use the independently of one another.
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/creating-packages.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/creating-packages.md
new file mode 100644
index 0000000..a21887c
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/creating-packages.md
@@ -0,0 +1,290 @@
+# **5.** Creating Packages
+
+A package is a project with a `name`, `uuid` and `version` entry in the `Project.toml` file, and a `src/PackageName.jl` file that defines the module `PackageName`.
+This file is executed when the package is loaded.
+
+### Generating files for a package
+
+!!! note
+    The [PkgTemplates](https://github.com/invenia/PkgTemplates.jl) package offers a very easy, repeatable, and 
+    customizable way to generate the files for a new package. We recommend that you use PkgTemplates for creating
+    new packages instead of using the minimal `pkg> generate` functionality described below.
+
+To generate files for a new package, use `pkg> generate`.
+
+```julia-repl
+(v1.0) pkg> generate HelloWorld
+```
+
+This creates a new project `HelloWorld` with the following files (visualized with the external [`tree` command](https://linux.die.net/man/1/tree)):
+
+```julia-repl
+julia> cd("HelloWorld")
+
+shell> tree .
+.
+├── Project.toml
+└── src
+    └── HelloWorld.jl
+
+1 directory, 2 files
+```
+
+The `Project.toml` file contains the name of the package, its unique UUID, its version, the authors and potential dependencies:
+
+```toml
+name = "HelloWorld"
+uuid = "b4cd1eb8-1e24-11e8-3319-93036a3eb9f3"
+version = "0.1.0"
+authors = ["Some One <someone@email.com>"]
+
+[deps]
+```
+
+The content of `src/HelloWorld.jl` is:
+
+```julia
+module HelloWorld
+
+greet() = print("Hello World!")
+
+end # module
+```
+
+We can now activate the project and load the package:
+
+```julia-repl
+pkg> activate .
+
+julia> import HelloWorld
+
+julia> HelloWorld.greet()
+Hello World!
+```
+
+### Adding dependencies to the project
+
+Let’s say we want to use the standard library package `Random` and the registered package `JSON` in our project.
+We simply `add` these packages (note how the prompt now shows the name of the newly generated project,
+since we `activate`d it):
+
+```julia-repl
+(HelloWorld) pkg> add Random JSON
+ Resolving package versions...
+  Updating "~/Documents/HelloWorld/Project.toml"
+ [682c06a0] + JSON v0.17.1
+ [9a3f8284] + Random
+  Updating "~/Documents/HelloWorld/Manifest.toml"
+ [34da2185] + Compat v0.57.0
+ [682c06a0] + JSON v0.17.1
+ [4d1e1d77] + Nullables v0.0.4
+ ...
+```
+
+Both `Random` and `JSON` got added to the project’s `Project.toml` file, and the resulting dependencies got added to the `Manifest.toml` file.
+The resolver has installed each package with the highest possible version, while still respecting the compatibility that each package enforces on its dependencies.
+
+We can now use both `Random` and `JSON` in our project. Changing `src/HelloWorld.jl` to
+
+```julia
+module HelloWorld
+
+import Random
+import JSON
+
+greet() = print("Hello World!")
+greet_alien() = print("Hello ", Random.randstring(8))
+
+end # module
+```
+
+and reloading the package, the new `greet_alien` function that uses `Random` can be called:
+
+```julia-repl
+julia> HelloWorld.greet_alien()
+Hello aT157rHV
+```
+
+### Adding a build step to the package
+
+The build step is executed the first time a package is installed or when explicitly invoked with `build`.
+A package is built by executing the file `deps/build.jl`.
+
+```julia-repl
+julia> print(read("deps/build.jl", String))
+println("I am being built...")
+
+(HelloWorld) pkg> build
+  Building HelloWorld → `deps/build.log`
+ Resolving package versions...
+
+julia> print(read("deps/build.log", String))
+I am being built...
+```
+
+If the build step fails, the output of the build step is printed to the console
+
+```julia-repl
+julia> print(read("deps/build.jl", String))
+error("Ooops")
+
+(HelloWorld) pkg> build
+  Building HelloWorld → `deps/build.log`
+ Resolving package versions...
+┌ Error: Error building `HelloWorld`:
+│ ERROR: LoadError: Ooops
+│ Stacktrace:
+│  [1] error(::String) at ./error.jl:33
+│  [2] top-level scope at none:0
+│  [3] include at ./boot.jl:317 [inlined]
+│  [4] include_relative(::Module, ::String) at ./loading.jl:1071
+│  [5] include(::Module, ::String) at ./sysimg.jl:29
+│  [6] include(::String) at ./client.jl:393
+│  [7] top-level scope at none:0
+│ in expression starting at /Users/kristoffer/.julia/dev/Pkg/HelloWorld/deps/build.jl:1
+└ @ Pkg.Operations Operations.jl:938
+```
+
+### Adding tests to the package
+
+When a package is tested the file `test/runtests.jl` is executed:
+
+```julia-repl
+julia> print(read("test/runtests.jl", String))
+println("Testing...")
+
+(HelloWorld) pkg> test
+   Testing HelloWorld
+ Resolving package versions...
+Testing...
+   Testing HelloWorld tests passed
+```
+
+Tests are run in a new Julia process, where the package itself, and any
+test-specific dependencies, are available, see below.
+
+#### Test-specific dependencies in Julia 1.2 and above
+
+!!! compat "Julia 1.2"
+    This section only applies to Julia 1.2 and above. For specifying test dependencies
+    on previous Julia versions, see [Test-specific dependencies in Julia 1.0 and 1.1](@ref).
+
+!!! note
+    The exact interaction between `Project.toml`, `test/Project.toml` and their corresponding
+    `Manifest.toml`s are not fully worked out, and may be subject to change in future versions.
+    The old method of adding test-specific dependencies, described in the next section, will
+    therefore be supported throughout all Julia 1.X releases.
+
+In Julia 1.2 and later the test environment is given by `test/Project.toml`. Thus, when running
+tests, this will be the active project, and only dependencies to the `test/Project.toml` project
+can be used. Note that Pkg will add the tested package itself implictly.
+
+!!! note
+    If no `test/Project.toml` exists Pkg will use the old style test-setup, as
+    described in [Test-specific dependencies in Julia 1.0 and 1.1](@ref).
+
+To add a test-specific dependency, i.e. a dependency that is available only when testing,
+it is thus enough to add this dependency to the `test/Project.toml` project. This can be
+done from the Pkg REPL by activating this environment, and then use `add` as one normally
+does. Lets add the `Test` standard library as a test dependency:
+
+```julia-repl
+(HelloWorld) pkg> activate ./test
+[ Info: activating environment at `~/HelloWorld/test/Project.toml`.
+
+(test) pkg> add Test
+ Resolving package versions...
+  Updating `~/HelloWorld/test/Project.toml`
+  [8dfed614] + Test
+  Updating `~/HelloWorld/test/Manifest.toml`
+  [...]
+```
+
+We can now use `Test` in the test script and we can see that it gets installed when testing:
+
+```julia-repl
+julia> print(read("test/runtests.jl", String))
+using Test
+@test 1 == 1
+
+(HelloWorld) pkg> test
+   Testing HelloWorld
+ Resolving package versions...
+  Updating `/var/folders/64/76tk_g152sg6c6t0b4nkn1vw0000gn/T/tmpPzUPPw/Project.toml`
+  [d8327f2a] + HelloWorld v0.1.0 [`~/.julia/dev/Pkg/HelloWorld`]
+  [8dfed614] + Test
+  Updating `/var/folders/64/76tk_g152sg6c6t0b4nkn1vw0000gn/T/tmpPzUPPw/Manifest.toml`
+  [d8327f2a] + HelloWorld v0.1.0 [`~/.julia/dev/Pkg/HelloWorld`]
+   Testing HelloWorld tests passed```
+```
+
+#### Test-specific dependencies in Julia 1.0 and 1.1
+
+!!! note
+    The method of adding test-specific dependencies described in this section will
+    be replaced by the method from the previous section in future Julia versions.
+    The method in this section will, however, be supported throughout all Julia 1.X
+    releases.
+
+In Julia 1.0 and Julia 1.1 test-specific dependencies are added to the main
+`Project.toml`. To add `Markdown` and `Test` as test-dependencies, add the following:
+
+```toml
+[extras]
+Markdown = "d6f4376e-aef5-505a-96c1-9c027394607a"
+Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
+
+[targets]
+test = ["Markdown", "Test"]
+```
+
+### Package naming guidelines
+
+Package names should be sensible to most Julia users, *even to those who are not domain experts*.
+The following guidelines applies to the `General` registry, but may be useful for other package
+registries as well.
+
+Since the `General` registry belongs to the entire community, people may have opinions about
+your package name when you publish it, especially if it's ambiguous or can be confused with
+something other than what it is. Usually you will then get suggestions for a new name that
+may fit your package better.
+
+1. Avoid jargon. In particular, avoid acronyms unless there is minimal possibility of confusion.
+
+     * It's ok to say `USA` if you're talking about the USA.
+     * It's not ok to say `PMA`, even if you're talking about positive mental attitude.
+2. Avoid using `Julia` in your package name or prefixing it with `Ju`.
+
+     * It is usually clear from context and to your users that the package is a Julia package.
+     * Package names already have a `.jl` extension, which communicates to users that `Package.jl` is a Julia package.
+     * Having Julia in the name can imply that the package is connected to, or endorsed by, contributors
+       to the Julia language itself.
+3. Packages that provide most of their functionality in association with a new type should have pluralized
+   names.
+
+     * `DataFrames` provides the `DataFrame` type.
+     * `BloomFilters` provides the `BloomFilter` type.
+     * In contrast, `JuliaParser` provides no new type, but instead new functionality in the `JuliaParser.parse()`
+       function.
+4. Err on the side of clarity, even if clarity seems long-winded to you.
+
+     * `RandomMatrices` is a less ambiguous name than `RndMat` or `RMT`, even though the latter are shorter.
+5. A less systematic name may suit a package that implements one of several possible approaches to
+   its domain.
+
+     * Julia does not have a single comprehensive plotting package. Instead, `Gadfly`, `PyPlot`, `Winston`
+       and other packages each implement a unique approach based on a particular design philosophy.
+     * In contrast, `SortingAlgorithms` provides a consistent interface to use many well-established
+       sorting algorithms.
+6. Packages that wrap external libraries or programs should be named after those libraries or programs.
+
+     * `CPLEX.jl` wraps the `CPLEX` library, which can be identified easily in a web search.
+     * `MATLAB.jl` provides an interface to call the MATLAB engine from within Julia.
+7. Avoid naming a package closely to an existing package
+     * `Websocket` is too close to `WebSockets` and can be confusing to users. Rather use a new name such as `SimpleWebsockets`.
+
+### Registering packages
+
+Once a package is ready it can be registered with the [General Registry](https://github.com/JuliaRegistries/General).
+Currently packages are submitted via [`Registrator`](https://juliaregistrator.github.io/).
+In addition to `Registrator`, [`TagBot`](https://github.com/apps/julia-tagbot) helps manage the process of tagging releases.
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/environments.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/environments.md
new file mode 100644
index 0000000..9d5bd46
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/environments.md
@@ -0,0 +1,108 @@
+# **4.** Working with Environments
+
+The following discusses Pkg's interaction with environments. For more on the role environments play in code loading, including the "stack" of environments from which code can be loaded, see [this section in the Julia manual](https://docs.julialang.org/en/v1/manual/code-loading/#Environments-1).
+
+## Creating your own projects
+
+So far we have added packages to the default project at `~/.julia/environments/v1.0`. It is however easy to create other, independent, projects.
+It should be pointed out that when two projects use the same package at the same version, the content of this package is not duplicated.
+In order to create a new project, create a directory for it and then activate that directory to make it the "active project", which package operations manipulate:
+
+```julia-repl
+julia> mkdir("MyProject")
+
+julia> cd("MyProject")
+/Users/kristoffer/MyProject
+
+(v1.0) pkg> activate .
+
+(MyProject) pkg> st
+    Status `Project.toml`
+```
+
+Note that the REPL prompt changed when the new project is activated. Since this is a newly created project, the status command shows that it contains no packages, and in fact, it has no project or manifest file until we add a package to it:
+
+```julia-repl
+julia> readdir()
+0-element Array{String,1}
+
+(MyProject) pkg> add Example
+  Updating registry at `~/.julia/registries/General`
+  Updating git-repo `https://github.com/JuliaRegistries/General.git`
+ Resolving package versions...
+  Updating `Project.toml`
+  [7876af07] + Example v0.5.1
+  Updating `Manifest.toml`
+  [7876af07] + Example v0.5.1
+  [8dfed614] + Test
+Precompiling project...
+  1 dependency successfully precompiled in 2 seconds
+
+julia> readdir()
+2-element Array{String,1}:
+ "Manifest.toml"
+ "Project.toml"
+
+julia> print(read("Project.toml", String))
+[deps]
+Example = "7876af07-990d-54b4-ab0e-23690620f79a"
+
+julia> print(read("Manifest.toml", String))
+[[Example]]
+deps = ["Test"]
+git-tree-sha1 = "8eb7b4d4ca487caade9ba3e85932e28ce6d6e1f8"
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+version = "0.5.1"
+
+[[Test]]
+uuid = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
+```
+
+This new environment is completely separate from the one we used earlier.
+
+
+## Project Precompilation
+
+By default any package that is added to a project or updated in a Pkg action will be automatically precompiled, along
+with its dependencies. The exception is the `develop` command, which neither builds nor precompiles the package, when
+that happens is left up to the user to decide.
+
+If a package that has been updated is already loaded in the session, the precompilation process will go ahead and precompile
+the new version, and any packages that depend on it, but will note that the package cannot be used until session restart.
+
+To disable this auto-precompilation, set `ENV["JULIA_PKG_PRECOMPILE_AUTO"]=0`, after which precompilation can be triggered
+manually either serially via code loading
+
+```julia-repl
+julia> using Example
+[ Info: Precompiling Example [7876af07-990d-54b4-ab0e-23690620f79a]
+```
+
+ or the parallel precompilation, which can be significantly faster when many dependencies are involved, via
+
+```julia-repl
+pkg> precompile
+Precompiling project...
+  23 dependencies successfully precompiled in 36 seconds
+```
+
+## Using someone else's project
+
+Simply clone their project using e.g. `git clone`, `cd` to the project directory and call
+
+```julia-repl
+(v1.0) pkg> activate .
+
+(SomeProject) pkg> instantiate
+```
+
+If the project contains a manifest, this will install the packages in the same state that is given by that manifest.
+Otherwise, it will resolve the latest versions of the dependencies compatible with the project.
+
+!!! note "Specifying project on startup"
+    Instead of using `activate` from within Julia you can specify the project on startup using
+    the `--project=<path>` flag. For example, to run a script from the command line using the
+    environment in the current directory you can run
+    ```bash
+    $ julia --project=. myscript.jl
+    ```
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/faq.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/faq.md
new file mode 100644
index 0000000..3809353
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/faq.md
@@ -0,0 +1,3 @@
+# **8.** FAQ
+
+### Should `Manifest.toml` be checked in to the package?
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/getting-started.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/getting-started.md
new file mode 100644
index 0000000..acfb0c5
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/getting-started.md
@@ -0,0 +1,216 @@
+# **2.** Getting Started
+
+What follows is a quick overview of Pkg, Julia's package manager.
+It should help new users become familiar with basic Pkg features.
+
+## Basic Usage
+
+Pkg comes with a REPL.
+Enter the Pkg REPL by pressing `]` from the Julia REPL.
+To get back to the Julia REPL, press backspace or ^C.
+
+!!! note
+    This guide relies on the Pkg REPL to execute Pkg commands.
+    For non-interactive use, we recommend the Pkg API.
+    The Pkg API is fully documented in the [API Reference](@ref) section of the Pkg documentation.
+
+Upon entering the Pkg REPL, you should see a similar prompt:
+
+```julia-repl
+(v1.1) pkg>
+```
+
+To add a package, use `add`:
+
+```julia-repl
+(v1.1) pkg> add Example
+```
+
+!!! note
+    Some Pkg output has been omitted in order to keep this guide focused.
+    This will help maintain a good pace and not get bogged down in details.
+    If you require more details, refer to subsequent sections of the Pkg manual.
+
+We can also specify multiple packages at once:
+
+```julia-repl
+(v1.1) pkg> add JSON StaticArrays
+```
+
+To remove packages, use `rm`:
+
+```julia-repl
+(v1.1) pkg> rm JSON StaticArrays
+```
+
+So far, we have referred only to registered packages.
+Pkg also supports working with unregistered packages.
+To add an unregistered package, specify a URL:
+
+```julia-repl
+(v1.1) pkg> add https://github.com/JuliaLang/Example.jl
+```
+
+Use `rm` to remove this package by name:
+
+```julia-repl
+(v1.1) pkg> rm Example
+```
+
+Use `update` to update an installed package:
+
+```julia-repl
+(v1.1) pkg> update Example
+```
+
+To update all installed packages, use `update` without any arguments:
+
+```julia-repl
+(v1.1) pkg> update
+```
+
+## Getting Started with Environments
+
+Up to this point, we have covered basic package management: adding, updating and removing packages.
+This will be familiar if you have used other package managers.
+Pkg offers significant advantages over traditional package managers
+by organizing dependencies into **environments**.
+
+You may have noticed the `(v1.1)` in the REPL prompt.
+This lets us know `v1.1` is the **active environment**.
+The active environment is the environment that will be modified by Pkg commands such as `add`, `rm` and `update`.
+
+Let's set up a new environment so we may experiment.
+To set the active environment, use `activate`:
+
+```julia-repl
+(v1.1) pkg> activate tutorial
+[ Info: activating new environment at `/tmp/tutorial/Project.toml`.
+```
+
+Pkg lets us know we are creating a new environment and that this environment
+will be stored in the `/tmp/tutorial` directory.
+
+Pkg has also updated the REPL prompt in order to reflect the new
+active environment:
+
+```julia-repl
+(tutorial) pkg>
+```
+
+We can ask for information about the active environment by using `status`:
+
+```julia-repl
+(tutorial) pkg> status
+    Status `/tmp/tutorial/Project.toml`
+   (empty environment)
+```
+
+`/tmp/tutorial/Project.toml` is the location of the active environment's **project file**.
+A project file is where Pkg stores metadata for an environment.
+Notice this new environment is empty.
+Let us add a package and observe:
+
+```julia-repl
+(tutorial) pkg> add Example
+...
+
+(tutorial) pkg> status
+    Status `/tmp/tutorial/Project.toml`
+  [7876af07] Example v0.5.1
+```
+
+We can see `tutorial` now contains `Example` as a dependency.
+
+## Modifying A Dependency
+
+Say we are working on `Example` and feel it needs new functionality.
+How can we modify the source code?
+We can use `develop` to set up a git clone of the `Example` package.
+
+```julia-repl
+(tutorial) pkg> develop --local Example
+...
+
+(tutorial) pkg> status
+    Status `/tmp/tutorial/Project.toml`
+  [7876af07] Example v0.5.1+ [`dev/Example`]
+```
+
+Notice the feedback has changed.
+`dev/Example` refers to the location of the newly created clone.
+If we look inside the `/tmp/tutorial` directory, we will notice the following files:
+
+```
+tutorial
+├── dev
+│   └── Example
+├── Manifest.toml
+└── Project.toml
+```
+
+Instead of loading a registered version of `Example`,
+Julia will load the source code contained in `tutorial/dev/Example`.
+
+Let's try it out.
+First we modify the file at `tutorial/dev/Example/src/Example.jl` and add a simple function:
+
+```julia
+plusone(x::Int) = x + 1
+```
+
+Now we can go back to the Julia REPL and load the package:
+
+```julia-repl
+julia> import Example
+```
+
+!!! warn
+    A package can only be loaded once per Julia session.
+    If you have run `import Example` in the current Julia session, you will
+    have to restart Julia and rerun `activate tutorial` in the Pkg REPL.
+    [Revise.jl](https://github.com/timholy/Revise.jl/) can make this process
+    significantly more pleasant, but setting it up is beyond the scope of this guide.
+
+Julia should load our new code. Let's test it:
+
+```julia-repl
+julia> Example.plusone(1)
+2
+```
+
+Say we have a change of heart and decide the world is not ready for such elegant code.
+We can tell Pkg to stop using the local clone and use a registered version instead.
+We do this with `free`:
+
+```julia-repl
+(tutorial) pkg> free Example
+```
+
+When you are done experimenting with `tutorial`, you can return to the **default
+environment** by running `activate` with no arguments:
+
+```julia-repl
+(tutorial) pkg> activate
+
+(v1.1) pkg>
+```
+
+## Asking for Help
+
+If you are ever stuck, you can ask `Pkg` for help:
+
+```julia-repl
+(v1.1) pkg> ?
+```
+
+You should see a list of available commands along with short descriptions.
+You can ask for more detailed help by specifying a command:
+
+```julia-repl
+(v1.1) pkg> ?develop
+```
+
+This guide should help you get started with `Pkg`.
+`Pkg` has much more to offer in terms of powerful package management,
+read the full manual to learn more!
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/glossary.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/glossary.md
new file mode 100644
index 0000000..f632140
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/glossary.md
@@ -0,0 +1,124 @@
+# [**9.** Glossary](@id Glossary)
+
+**Project:** a source tree with a standard layout, including a `src` directory
+for the main body of Julia code, a `test` directory for testing the project,
+a `docs` directory for documentation files, and optionally a `deps` directory for a build
+script and its outputs. A project will typically also have a project file and
+may optionally have a manifest file:
+
+- **Project file:** a file in the root directory of a project, named
+  `Project.toml` (or `JuliaProject.toml`), describing metadata about the project,
+  including its name, UUID (for packages), authors, license, and the names and
+  UUIDs of packages and libraries that it depends on.
+
+- **Manifest file:** a file in the root directory of a project, named
+  `Manifest.toml` (or `JuliaManifest.toml`), describing a complete dependency graph
+  and exact versions of each package and library used by a project.
+
+**Package:** a project which provides reusable functionality that can be used by
+other Julia projects via `import X` or `using X`. A package should have a
+project file with a `uuid` entry giving its package UUID. This UUID is used to
+identify the package in projects that depend on it.
+
+!!! note
+    For legacy reasons it is possible to load a package without a project file or
+    UUID from the REPL or the top-level of a script. It is not possible, however,
+    to load a package without a project file or UUID from a project with them. Once
+    you've loaded from a project file, everything needs a project file and UUID.
+
+**Application:** a project which provides standalone functionality not intended
+to be reused by other Julia projects. For example a web application or a
+commmand-line utility, or simulation/analytics code accompanying a scientific paper.
+An application may have a UUID but does not need one.
+An application may also provide global configuration options for packages it
+depends on. Packages, on the other hand, may not provide global configuration
+since that could conflict with the configuration of the main application.
+
+!!! note
+    **Projects _vs._ Packages _vs._ Applications:**
+
+    1. **Project** is an umbrella term: packages and applications are kinds of projects.
+    2. **Packages** should have UUIDs, applications can have a UUIDs but don't need them.
+    3. **Applications** can provide global configuration, whereas packages cannot.
+
+**Library (future work):** a compiled binary dependency (not written in Julia)
+packaged to be used by a Julia project. These are currently typically built in-
+place by a `deps/build.jl` script in a project’s source tree, but in the future
+we plan to make libraries first-class entities directly installed and upgraded
+by the package manager.
+
+**Environment:** the combination of the top-level name map provided by a project
+file combined with the dependency graph and map from packages to their entry points
+provided by a manifest file. For more detail see the manual section on code loading.
+
+- **Explicit environment:** an environment in the form of an explicit project
+  file and an optional corresponding manifest file together in a directory. If the
+  manifest file is absent then the implied dependency graph and location maps are
+  empty.
+
+- **Implicit environment:** an environment provided as a directory (without a
+  project file or manifest file) containing packages with entry points of the form
+  `X.jl`, `X.jl/src/X.jl` or `X/src/X.jl`. The top-level name map is implied by
+  these entry points. The dependency graph is implied by the existence of project
+  files inside of these package directories, e.g. `X.jl/Project.toml` or
+  `X/Project.toml`. The dependencies of the `X` package are the dependencies in
+  the corresponding project file if there is one. The location map is implied by
+  the entry points themselves.
+
+**Registry:** a source tree with a standard layout recording metadata about a
+registered set of packages, the tagged versions of them which are available, and
+which versions of packages are compatible or incompatible with each other. A
+registry is indexed by package name and UUID, and has a directory for each
+registered package providing the following metadata about it:
+
+- name – e.g. `DataFrames`
+- UUID – e.g. `a93c6f00-e57d-5684-b7b6-d8193f3e46c0`
+- authors – e.g. `Jane Q. Developer <jane@example.com>`
+- license – e.g. MIT, BSD3, or GPLv2
+- repository – e.g. `https://github.com/JuliaData/DataFrames.jl.git`
+- description – a block of text summarizing the functionality of a package
+- keywords – e.g. `data`, `tabular`, `analysis`, `statistics`
+- versions – a list of all registered version tags
+
+For each registered version of a package, the following information is provided:
+
+- its semantic version number – e.g. `v1.2.3`
+- its git tree SHA-1 hash – e.g. `7ffb18ea3245ef98e368b02b81e8a86543a11103`
+- a map from names to UUIDs of dependencies
+- which versions of other packages it is compatible/incompatible with
+
+Dependencies and compatibility are stored in a compressed but human-readable
+format using ranges of package versions.
+
+**Depot:** a directory on a system where various package-related resources live,
+including:
+
+- `environments`: shared named environments (e.g. `v1.0`, `devtools`)
+- `clones`: bare clones of package repositories
+- `compiled`: cached compiled package images (`.ji` files)
+- `config`: global configuration files (e.g. `startup.jl`)
+- `dev`: default directory for package development
+- `logs`: log files (e.g. `manifest_usage.toml`, `repl_history.jl`)
+- `packages`: installed package versions
+- `registries`: clones of registries (e.g. `General`)
+
+**Load path:** a stack of environments where package identities, their
+dependencies, and entry-points are searched for. The load path is controlled in
+Julia by the `LOAD_PATH` global variable which is populated at startup based on
+the value of the `JULIA_LOAD_PATH` environment variable. The first entry is your
+primary environment, often the current project, while later entries provide
+additional packages one may want to use from the REPL or top-level scripts.
+
+**Depot path:** a stack of depot locations where the package manager, as well as
+Julia's code loading mechanisms, look for registries, installed packages, named
+environments, repo clones, cached compiled package images, and configuration
+files. The depot path is controlled by the Julia `DEPOT_PATH` global variable
+which is populated at startup based on the value of the `JULIA_DEPOT_PATH`
+environment variable. The first entry is the “user depot” and should be writable
+by and owned by the current user. The user depot is where: registries are
+cloned, new package versions are installed, named environments are created and
+updated, package repos are cloned, newly compiled package image files are saved,
+log files are written, development packages are checked out by default, and
+global configuration data is saved. Later entries in the depot path are treated
+as read-only and are appropriate for registries, packages, etc. installed and
+managed by system administrators.
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/index.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/index.md
new file mode 100644
index 0000000..8cbab92
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/index.md
@@ -0,0 +1,65 @@
+# **1.** Introduction
+
+Welcome to the documentation for Pkg, Julia's package manager.
+The documentation covers many things, for example managing package
+installations, developing packages, working with package registries and more.
+
+Throughout the manual the REPL interface to Pkg is used in the examples.
+There is also a functional API interface, which is preferred when not working
+interactively. This API is documented in the [API Reference](@ref) section.
+
+## Background and Design
+
+Pkg is a complete rewrite of Julia's old package manager[^1] and was released
+together with Julia v1.0. Unlike traditional
+package managers, which install and manage a single global set of packages, Pkg
+is designed around “environments”: independent sets of packages that can be
+local to an individual project or shared and selected by name. The exact set of
+packages and versions in an environment is captured in a _manifest file_ which
+can be checked into a project repository and tracked in version control,
+significantly improving reproducibility of projects. If you’ve ever tried to run
+code you haven’t used in a while only to find that you can’t get anything to
+work because you’ve updated or uninstalled some of the packages your project was
+using, you’ll understand the motivation for this approach. In Pkg, since each
+project maintains its own independent set of package versions, you’ll never have
+this problem again. Moreover, if you check out a project on a new system, you
+can simply materialize the environment described by its manifest file and
+immediately be up and running with a known-good set of dependencies.
+
+Since environments are managed and updated independently from each other,
+“dependency hell” is significantly alleviated in Pkg. If you want to use the
+latest and greatest version of some package in a new project but you’re stuck on
+an older version in a different project, that’s no problem – since they have
+separate environments they can just use different versions, which are both
+installed at the same time in different locations on your system. The location
+of each package version is canonical, so when environments use the same versions
+of packages, they can share installations, avoiding unnecessary duplication of
+the package. Old package versions that are no longer used by any environments
+are periodically “garbage collected” by the package manager.
+
+Pkg’s approach to local environments may be familiar to people who have used
+Python’s `virtualenv` or Ruby’s `bundler`. In Julia, instead of hacking the
+language’s code loading mechanisms to support environments, we have the benefit
+that Julia natively understands them. In addition, Julia environments are
+“stackable”: you can overlay one environment with another and thereby have
+access to additional packages outside of the primary environment. This makes it
+easy to work on a project, which provides the primary environment, while still
+having access from the REPL to all your usual dev tools like profilers,
+debuggers, and so on, just by having an environment including these dev tools
+later in the load path.
+
+Last but not least, Pkg is designed to support federated package registries.
+This means that it allows multiple registries managed by different parties to
+interact seamlessly. In particular, this includes private registries which can
+live behind corporate firewalls. You can install and update your own packages
+from a private registry with exactly the same tools and workflows that you use
+to install and manage official Julia packages. If you urgently need to apply a
+hotfix for a public package that’s critical to your company’s product, you can
+tag a private version of it in your company’s internal registry and get a fix to
+your developers and ops teams quickly and easily without having to wait for an
+upstream patch to be accepted and published. Once an official fix is published,
+however, you can just upgrade your dependencies and you'll be back on an
+official release again.
+
+[^1]: Often denoted `Pkg2`, now archived as `OldPkg` at
+      [`github.com/JuliaAttic/OldPkg.jl`](https://github.com/JuliaAttic/OldPkg.jl).
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/managing-packages.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/managing-packages.md
new file mode 100644
index 0000000..45df972
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/managing-packages.md
@@ -0,0 +1,428 @@
+# **3.** Managing Packages
+
+## Adding packages
+
+There are two ways of adding packages, either using the `add` command or the `dev` command.
+The most frequently used is `add` and its usage is described first.
+
+### Adding registered packages
+
+In the Pkg REPL, packages can be added with the `add` command followed by the name of the package, for example:
+
+```julia-repl
+(v1.0) pkg> add Example
+   Cloning default registries into /Users/kristoffer/.julia/registries
+   Cloning registry General from "https://github.com/JuliaRegistries/General.git"
+  Updating registry at `~/.julia/registries/General`
+  Updating git-repo `https://github.com/JuliaRegistries/General.git`
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] + Example v0.5.1
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] + Example v0.5.1
+  [8dfed614] + Test
+```
+
+Here we added the package Example to the current project. In this example, we are using a fresh Julia installation,
+and this is our first time adding a package using Pkg. By default, Pkg clones Julia's General registry,
+and uses this registry to look up packages requested for inclusion in the current environment.
+The status update shows a short form of the package UUID to the left, then the package name, and the version.
+Since standard libraries (e.g. `Test`) are shipped with Julia, they do not have a version. The project status contains the packages
+you have added yourself, in this case, `Example`:
+
+```julia-repl
+(v1.0) pkg> st
+    Status `Project.toml`
+  [7876af07] Example v0.5.1
+```
+
+The manifest status shows all the packages in the environment, including recursive dependencies:
+
+```julia-repl
+(v1.0) pkg> st --manifest
+    Status `Manifest.toml`
+  [7876af07] Example v0.5.1
+  [8dfed614] Test
+```
+
+It is possible to add multiple packages in one command as `pkg> add A B C`.
+
+After a package is added to the project, it can be loaded in Julia:
+
+```julia-repl
+julia> using Example
+
+julia> Example.hello("User")
+"Hello, User"
+```
+
+A specific version can be installed by appending a version after a `@` symbol, e.g. `@v0.4`, to the package name:
+
+```julia-repl
+(v1.0) pkg> add Example@0.4
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] + Example v0.4.1
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] + Example v0.4.1
+```
+
+If a branch (or a certain commit) of `Example` has a hotfix that is not yet included in a registered version,
+we can explicitly track that branch (or commit) by appending `#branchname` (or `#commitSHA1`) to the package name:
+
+```julia-repl
+(v1.0) pkg> add Example#master
+  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1+ #master (https://github.com/JuliaLang/Example.jl.git)
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1+ #master (https://github.com/JuliaLang/Example.jl.git)
+```
+
+The status output now shows that we are tracking the `master` branch of `Example`.
+When updating packages, we will pull updates from that branch.
+
+To go back to tracking the registry version of `Example`, the command `free` is used:
+
+```julia-repl
+(v1.0) pkg> free Example
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] ~ Example v0.5.1+ #master (https://github.com/JuliaLang/Example.jl.git) ⇒ v0.5.1
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] ~ Example v0.5.1+ #master )https://github.com/JuliaLang/Example.jl.git) ⇒ v0.5.1
+```
+
+
+### Adding unregistered packages
+
+If a package is not in a registry, it can be added by specifying a URL to the repository:
+
+```julia-repl
+(v1.0) pkg> add https://github.com/fredrikekre/ImportMacros.jl
+  Updating git-repo `https://github.com/fredrikekre/ImportMacros.jl`
+ Resolving package versions...
+Downloaded MacroTools ─ v0.4.1
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [e6797606] + ImportMacros v0.0.0 # (https://github.com/fredrikekre/ImportMacros.jl)
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [e6797606] + ImportMacros v0.0.0 # (https://github.com/fredrikekre/ImportMacros.jl)
+  [1914dd2f] + MacroTools v0.4.1
+```
+
+The dependencies of the unregistered package (here `MacroTools`) got installed.
+For unregistered packages we could have given a branch name (or commit SHA1) to track using `#`, just like for registered packages.
+
+If you want to add a package using the SSH-based `git` protocol, you have to use quotes because the URL contains a `@`. For example,
+```julia-repl
+(v1.0) pkg> add "git@github.com:fredrikekre/ImportMacros.jl.git"
+    Cloning git-repo `git@github.com:fredrikekre/ImportMacros.jl.git`
+   Updating git-repo `git@github.com:fredrikekre/ImportMacros.jl.git`
+   Updating registry at `~/.julia/registries/General`
+  Resolving package versions...
+Updating `~/.julia/environments/v1/Project.toml`
+  [92a963f6] + ImportMacros v1.0.0 `git@github.com:fredrikekre/ImportMacros.jl.git#master`
+Updating `~/.julia/environments/v1/Manifest.toml`
+  [92a963f6] + ImportMacros v1.0.0 `git@github.com:fredrikekre/ImportMacros.jl.git#master`
+```
+
+### Adding a local package
+
+Instead of giving a URL of a git repo to `add` we could instead have given a local path to a git repo.
+This works similar to adding a URL. The local repository will be tracked (at some branch) and updates
+from that local repo are pulled when packages are updated.
+Note tracking a package through `add` is distinct from `develop`:
+changes to files in the local package repository will not immediately be reflected when loading that package.
+The changes would have to be committed and the packages updated in order to pull in the changes.
+
+In addition, it is possible to add packages relatively to the `Manifest.toml` file, see [Developing packages](@ref developing) for an example.
+
+### [Developing packages](@id developing)
+
+By only using `add` your Manifest will always have a "reproducible state", in other words, as long as the repositories and registries used are still accessible
+it is possible to retrieve the exact state of all the dependencies in the project. This has the advantage that you can send your project (`Project.toml`
+and `Manifest.toml`) to someone else and they can "instantiate" that project in the same state as you had it locally.
+However, when you are developing a package, it is more convenient to load packages at their current state at some path. For this reason, the `dev` command exists.
+
+Let's try to `dev` a registered package:
+
+```julia-repl
+(v1.0) pkg> dev Example
+  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] + Example v0.5.1+ [`~/.julia/dev/Example`]
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] + Example v0.5.1+ [`~/.julia/dev/Example`]
+```
+
+The `dev` command fetches a full clone of the package to `~/.julia/dev/` (the path can be changed by setting the environment variable `JULIA_PKG_DEVDIR`).
+When importing `Example` julia will now import it from `~/.julia/dev/Example` and whatever local changes have been made to the files in that path are consequently
+reflected in the code loaded. When we used `add` we said that we tracked the package repository, we here say that we track the path itself.
+Note the package manager will never touch any of the files at a tracked path. It is therefore up to you to pull updates, change branches etc.
+If we try to `dev` a package at some branch that already exists at `~/.julia/dev/` the package manager we will simply use the existing path.
+For example:
+
+```julia-repl
+(v1.0) pkg> dev Example
+  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
+[ Info: Path `/Users/kristoffer/.julia/dev/Example` exists and looks like the correct package, using existing path instead of cloning
+```
+
+Note the info message saying that it is using the existing path.
+When tracking a path, the package manager will never modify the files at that path.
+
+If `dev` is used on a local path, that path to that package is recorded and used when loading that package.
+The path will be recorded relative to the project file, unless it is given as an absolute path.
+
+To stop tracking a path and use the registered version again, use `free`:
+
+```julia-repl
+(v1.0) pkg> free Example
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] ↓ Example v0.5.1+ [`~/.julia/dev/Example`] ⇒ v0.5.1
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] ↓ Example v0.5.1+ [`~/.julia/dev/Example`] ⇒ v0.5.1
+```
+
+It should be pointed out that by using `dev` your project is now inherently stateful.
+Its state depends on the current content of the files at the path and the manifest cannot be "instantiated" by someone else without
+knowing the exact content of all the packages that are tracking a path.
+
+Note that if you add a dependency to a package that tracks a local path, the Manifest (which contains the whole dependency graph) will become
+out of sync with the actual dependency graph. This means that the package will not be able to load that dependency since it is not recorded
+in the Manifest. To synchronize the Manifest, use the REPL command `resolve`.
+
+In addition to absolute paths, `add` and `dev` can accept relative paths to packages.
+In this case, the relative path from the active project to the package is stored.
+This approach is useful when the relative location of tracked dependencies is more important than their absolute location.
+For example, the tracked dependencies can be stored inside of the active project directory.
+The whole directory can be moved and `Pkg` will still be able to find the dependencies
+because their path relative to the active project is preserved even though their absolute path has changed.
+
+## Removing packages
+
+Packages can be removed from the current project by using `pkg> rm Package`.
+This will only remove packages that exist in the project; to remove a package that only
+exists as a dependency use `pkg> rm --manifest DepPackage`.
+Note that this will remove all packages that depend on `DepPackage`.
+
+## [Updating packages](@id updating)
+
+When new versions of packages that the project is using are released, it is a good idea to update. Simply calling `up` will try to update *all* the dependencies of the project
+to the latest compatible version. Sometimes this is not what you want. You can specify a subset of the dependencies to upgrade by giving them as arguments to `up`, e.g:
+
+```julia-repl
+(v1.0) pkg> up Example
+```
+
+If `Example` has a dependency which is also a dependency for another explicitly added package, that dependency will not be updated. If you only want to update the minor version of packages, to reduce the risk that your project breaks, you can give the `--minor` flag, e.g:
+
+```julia-repl
+(v1.0) pkg> up --minor Example
+```
+
+Packages that track a local repository are not updated when a minor upgrade is done.
+Packages that track a path are never touched by the package manager.
+
+## Pinning a package
+
+A pinned package will never be updated. A package can be pinned using `pin`, for example:
+
+```julia-repl
+(v1.0) pkg> pin Example
+ Resolving package versions...
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1 ⚲
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1 ⚲
+```
+
+Note the pin symbol `⚲` showing that the package is pinned. Removing the pin is done using `free`
+
+```julia-repl
+(v1.0) pkg> free Example
+  Updating `~/.julia/environments/v1.0/Project.toml`
+  [7876af07] ~ Example v0.5.1 ⚲ ⇒ v0.5.1
+  Updating `~/.julia/environments/v1.0/Manifest.toml`
+  [7876af07] ~ Example v0.5.1 ⚲ ⇒ v0.5.1
+```
+
+## Testing packages
+
+The tests for a package can be run using `test`command:
+
+```julia-repl
+(v1.0) pkg> test Example
+   Testing Example
+   Testing Example tests passed
+```
+
+## Building packages
+
+The build step of a package is automatically run when a package is first installed.
+The output of the build process is directed to a file.
+To explicitly run the build step for a package, the `build` command is used:
+
+```julia-repl
+(v1.0) pkg> build MbedTLS
+  Building MbedTLS → `~/.julia/packages/MbedTLS/h1Vu/deps/build.log`
+
+julia> print(read("~/.julia/packages/MbedTLS/h1Vu/deps/build.log", String))
+┌ Warning: `wait(t::Task)` is deprecated, use `fetch(t)` instead.
+│   caller = macro expansion at OutputCollector.jl:63 [inlined]
+└ @ Core OutputCollector.jl:63
+...
+[ Info: using prebuilt binaries
+```
+
+## [Interpreting and resolving version conflicts](@id conflicts)
+
+An environment consists of a set of mutually-compatible packages.
+Sometimes, you can find yourself in a situation in which two packages you'd like to use simultaneously
+have incompatible requirements.
+In such cases you'll get an "Unsatisfiable requirements" error:
+
+```@setup conflict
+using Pkg
+include(joinpath(pkgdir(Pkg), "test", "resolve_utils.jl"))
+using .ResolveUtils
+deps_data = Any[["A", v"1.0.0", "C", v"0.2"],
+                ["B", v"1.0.0", "D", v"0.1"],
+                ["C", v"0.1.0", "D", v"0.1"],
+                ["C", v"0.1.1", "D", v"0.1"],
+                ["C", v"0.2.0", "D", v"0.2"],
+                ["D", v"0.1.0"],
+                ["D", v"0.2.0"],
+                ["D", v"0.2.1"]]
+reqs_data = Any[["A", "*"],
+                ["B", "*"]]
+```
+
+```@example conflict
+print("pkg> add A\n", try resolve_tst(deps_data, reqs_data) catch e sprint(showerror, e) end)   # hide
+```
+
+This message means that a package named `D` has a version conflict.
+Even if you have never `add`ed `D` directly, this kind of error can arise
+if `D` is required by other packages that you are trying to use.
+
+The error message has a lot of crucial information.
+It may be easiest to interpret piecewise:
+
+```
+Unsatisfiable requirements detected for package D [756980fe]:
+ D [756980fe] log:
+ ├─possible versions are: [0.1.0, 0.2.0-0.2.1] or uninstalled
+```
+means that `D` has three released versions, `v0.1.0`, `v0.2.0`, and `v0.2.1`.
+You also have the option of not having it installed at all.
+Each of these options might have different implications for the set of other packages that can be installed.
+
+Crucially, notice the stroke characters (vertical and horizontal lines) and their indentation.
+Together, these connect *messages* to specific *packages*.
+For instance the right stroke of `├─` indicates that the message to its right (`possible versions...`)
+is connected to the package pointed to by its vertical stroke (`D`).
+This same principle applies to the next line:
+
+```
+ ├─restricted by compatibility requirements with B [f4259836] to versions: 0.1.0
+```
+The vertical stroke here is also aligned under `D`, and thus this message
+is in reference to `D`.
+Specifically, there's some other package `B` that depends on version `v0.1.0` of `D`.
+Notice that this is not the newest version of `D`.
+
+Next comes some information about `B`:
+
+```
+ │ └─B [f4259836] log:
+ │   ├─possible versions are: 1.0.0 or uninstalled
+ │   └─restricted to versions * by an explicit requirement, leaving only versions 1.0.0
+```
+The two lines below the first have a vertical stroke that aligns with `B`,
+and thus they provide information about `B`.
+They tell you that `B` has just one release, `v1.0.0`.
+You've not specified a particular version of `B` (`restricted to versions *` means that any version will do),
+but the `explicit requirement` means that you've asked for `B` to be part of your environment,
+for example by `pkg> add B`.
+You might have asked for `B` previously, and the requirement is still active.
+
+The conflict becomes clear with the line
+```
+└─restricted by compatibility requirements with C [c99a7cb2] to versions: 0.2.0 — no versions left
+```
+
+Here again the vertical stroke aligns with `D`: this means that `D` is *also* required by another package, `C`.
+`C` requires `v0.2.0` of `D`, and this conflicts with `B`'s need for `v0.1.0` of `D`.
+This explains the conflict.
+
+But wait, you might ask, what is `C` and why do I need it at all?
+The next few lines introduce the problem:
+
+```
+   └─C [c99a7cb2] log:
+     ├─possible versions are: [0.1.0-0.1.1, 0.2.0] or uninstalled
+     └─restricted by compatibility requirements with A [29c70717] to versions: 0.2.0
+```
+These provide more information about `C`, revealing that it has 3 released versions: `v0.1.0`, `v0.1.1`, and `v0.2.0`.
+Moreover, `C` is required by another package `A`.
+Indeed, `A`'s requirements are such that we need `v0.2.0` of `C`.
+`A`'s origin is revealed on the next lines:
+
+```
+       └─A [29c70717] log:
+         ├─possible versions are: 1.0.0 or uninstalled
+         └─restricted to versions * by an explicit requirement, leaving only versions 1.0.0
+```
+
+So we can see that `A` was `explicitly required`, and in this case it's because we were trying to
+`add` it to our environment.
+
+In summary, we explicitly asked to use `A` and `B`, but this gave a conflict for `D`.
+The reason was that `B` and `C` require conflicting versions of `D`.
+Even though `C` isn't something we asked for explicitly, it was needed by `A`.
+
+To fix such errors, you have a number of options:
+
+- try [updating your packages](@ref updating). It's possible the developers of these packages have recently released new versions that are mutually compatible.
+- remove either `A` or `B` from your environment. Perhaps `B` is left over from something you were previously working on, and you don't need it anymore. If you don't need `A` and `B` at the same time, this is the easiest way to fix the problem.
+- try reporting your conflict. In this case, we were able to deduce that `B` requires an outdated version of `D`. You could thus report an issue in the development repository of `B.jl` asking for an updated version.
+- try fixing the problem yourself.
+  This becomes easier once you understand `Project.toml` files and how they declare their compatiblity requirements. We'll return to this example in [Fixing conflicts](@ref).
+
+## Garbage collecting old, unused packages
+
+As packages are updated and projects are deleted, installed package versions and artifacts that were
+once used will inevitably become old and not used from any existing project.
+`Pkg` keeps a log of all projects used so it can go through the log and see exactly which projects still exist
+and what packages/artifacts those projects used.
+If a package or artifact is not marked as used by any project, it is added to a list of orphaned packages.
+Packages and artifacts that are in the orphan list for 30 days without being used again are deleted from the system on the next garbage collection.
+This timing is configurable via the `collect_delay` keyword argument to `Pkg.gc()`.
+A value of `0` will cause anything currently not in use immediately, skipping the orphans list entirely;
+If you are short on disk space and want to clean out as many unused packages and artifacts as possible, you may want to try this, but if you need these versions again, you will have to download them again.
+To run a typical garbage collection with default arguments, simply use the `gc` command at the `pkg>` REPL:
+
+```julia-repl
+(v1.0) pkg> gc
+    Active manifests at:
+        `~/BinaryProvider/Manifest.toml`
+        ...
+        `~/Compat.jl/Manifest.toml`
+    Active artifacts:
+        `~/src/MyProject/Artifacts.toml`
+
+    Deleted ~/.julia/packages/BenchmarkTools/1cAj: 146.302 KiB
+    Deleted ~/.julia/packages/Cassette/BXVB: 795.557 KiB
+   ...
+   Deleted `~/.julia/artifacts/e44cdf2579a92ad5cbacd1cddb7414c8b9d2e24e` (152.253 KiB)
+   Deleted `~/.julia/artifacts/f2df5266567842bbb8a06acca56bcabf813cd73f` (21.536 MiB)
+
+   Deleted 36 package installations (113.205 MiB)
+   Deleted 15 artifact installations (20.759 GiB)
+```
+
+Note that only packages in `~/.julia/packages` are deleted.
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/registries.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/registries.md
new file mode 100644
index 0000000..be6f8e2
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/registries.md
@@ -0,0 +1,81 @@
+# **7.** Registries
+
+Registries contain information about packages, such as
+available releases and dependencies, and where they can be downloaded.
+The `General` registry (https://github.com/JuliaRegistries/General)
+is the default one, and is installed automatically.
+
+## Managing registries
+
+!!! compat "Julia 1.1"
+    Pkg's registry handling requires at least Julia 1.1.
+
+Registries can be added, removed and updated from either the Pkg REPL
+or by using the function based API. In this section we will describe the
+REPL interface. The registry API is documented in
+the [Registry API Reference](@ref) section.
+
+### Adding registries
+
+A custom registry can be added with the `registry add` command
+from the Pkg REPL. Usually this will be done with a URL to the
+registry. Here we add the `General` registry:
+
+```julia-repl
+pkg> registry add https://github.com/JuliaRegistries/General
+   Cloning registry from "https://github.com/JuliaRegistries/General"
+     Added registry `General` to `~/.julia/registries/General`
+```
+
+and now all the packages registered in `General` are available for e.g. adding.
+To see which registries are currently installed you can use the `registry status`
+(or `registry st`) command
+
+```julia-repl
+pkg> registry st
+Registry Status
+ [23338594] General (https://github.com/JuliaRegistries/General.git)
+```
+
+Registries are always added to the user depot, which is the first entry in `DEPOT_PATH` (cf. the [Glossary](@ref) section).
+
+### Removing registries
+
+Registries can be removed with the `registry remove` (or `registry rm`) command.
+Here we remove the `General` registry
+
+```julia-repl
+pkg> registry rm General
+  Removing registry `General` from ~/.julia/registries/General
+
+pkg> registry st
+Registry Status
+  (no registries found)
+```
+
+In case there are multiple registries named `General` installed you have to
+disambiguate with the `uuid`, just as when manipulating packages, e.g.
+
+```julia-repl
+pkg> registry rm General=23338594-aafe-5451-b93e-139f81909106
+  Removing registry `General` from ~/.julia/registries/General
+```
+
+### Updating registries
+
+The `registry update` (or `registry up`) command is available to update registries.
+Here we update the `General` registry:
+
+```julia-repl
+pkg> registry up General
+  Updating registry at `~/.julia/registries/General`
+  Updating git-repo `https://github.com/JuliaRegistries/General`
+```
+
+and to update all installed registries just do:
+
+```julia-repl
+pkg> registry up
+  Updating registry at `~/.julia/registries/General`
+  Updating git-repo `https://github.com/JuliaRegistries/General`
+```
diff --git a/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/toml-files.md b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/toml-files.md
new file mode 100644
index 0000000..d79f9ef
--- /dev/null
+++ b/research/flossing/external/julia-1.6.7/share/julia/stdlib/v1.6/Pkg/docs/src/toml-files.md
@@ -0,0 +1,270 @@
+# [**10.** `Project.toml` and `Manifest.toml`](@id Project-and-Manifest)
+
+Two files that are central to Pkg are `Project.toml` and `Manifest.toml`. `Project.toml`
+and `Manifest.toml` are written in [TOML](https://github.com/toml-lang/toml) (hence the
+`.toml` extension) and include information about dependencies, versions, package names,
+UUIDs etc.
+
+!!! note
+    The `Project.toml` and `Manifest.toml` files are not only used by the package manager;
+    they are also used by Julia's code loading, and determine e.g. what `using Example`
+    should do. For more details see the section about
+    [Code Loading](https://docs.julialang.org/en/v1/manual/code-loading/)
+    in the Julia manual.
+
+
+## `Project.toml`
+
+The project file describes the project on a high level, for example the package/project
+dependencies and compatibility constraints are listed in the project file. The file entries
+are described below.
+
+
+### The `authors` field
+
+For a package, the optional `authors` field is a list of strings describing the
+package authors, in the form `NAME <EMAIL>`. For example:
+```toml
+authors = ["Some One <someone@email.com>",
+           "Foo Bar <foo@bar.com>"]
+```
+
+
+### The `name` field
+
+The name of the package/project is determined by the `name` field, for example:
+```toml
+name = "Example"
+```
+The name can contain word characters `[a-zA-Z0-9_]`, but can not start with a number. For
+packages it is recommended to follow the
+[package naming guidelines](@ref Package-naming-guidelines). The `name` field is mandatory
+for packages.
+
+
+### The `uuid` field
+
+`uuid` is a string with a [universally unique identifier]
+(https://en.wikipedia.org/wiki/Universally_unique_identifier) for the package/project, for example:
+```toml
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+```
+The `uuid` field is mandatory for packages.
+
+!!! note
+    It is recommended that `UUIDs.uuid4()` is used to generate random UUIDs.
+
+
+### The `version` field
+
+`version` is a string with the version number for the package/project. It should consist of
+three numbers, major version, minor version and patch number, separated with a `.`, for example:
+```toml
+version = "1.2.5"
+```
+Julia uses [Semantic Versioning](https://semver.org/) (SemVer) and the `version` field
+should follow SemVer. The basic rules are:
+* Before 1.0.0, anything goes, but when you make breaking changes the minor version should
+  be incremented.
+* After 1.0.0 only make breaking changes when incrementing the major version.
+* After 1.0.0 no new public API should be added without incrementing the minor version.
+  This includes, in particular, new types, functions, methods and method overloads, from
+  `Base` or other packages.
+See also the section on [Compatibility](@ref).
+
+Note that Pkg.jl deviates from the SemVer specification when it comes to versions pre-1.0.0. See
+the section on [pre-1.0 behavior](@ref compat-pre-1.0) for more details.
+
+
+### The `[deps]` section
+
+All dependencies of the package/project are listed in the `[deps]` section. Each dependency
+is listed as a name-uuid pair, for example:
+
+```toml
+[deps]
+Example = "7876af07-990d-54b4-ab0e-23690620f79a"
+Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
+```
+
+Typically it is not needed to manually add entries to the `[deps]` section; this is instead
+handled by Pkg operations such as `add`.
+
+
+### The `[compat]` section
+
+Compatibility constraints for the dependencies listed under `[deps]` can be listed in the
+`[compat]` section.
+Example:
+
+```toml
+[deps]
+Example = "7876af07-990d-54b4-ab0e-23690620f79a"
+
+[compat]
+Example = "1.2"
+```
+
+The [Compatibility](@ref) section describes the different possible compatibility
+constraints in detail. It is also possible to list constraints on `julia` itself, although
+`julia` is not listed as a dependency in the `[deps]` section:
+
+```toml
+[compat]
+julia = "1.1"
+```
+
+
+## `Manifest.toml`
+
+The manifest file is an absolute record of the state of the packages in the environment.
+It includes exact information about (direct and indirect) dependencies of the project.
+Given a `Project.toml` + `Manifest.toml` pair, it is possible to instantiate the exact same
+package environment, which is very useful for reproducibility.
+For the details, see [`Pkg.instantiate`](@ref).
+
+!!! note
+    The `Manifest.toml` file is generated and maintained by Pkg and, in general, this file
+    should *never* be modified manually.
+
+
+### `Manifest.toml` entries
+
+Each dependency has its own section in the manifest file, and its content varies depending
+on how the dependency was added to the environment. Every
+dependency section includes a combination of the following entries:
+
+* `uuid`: the [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier)
+  for the dependency, for example `uuid = "7876af07-990d-54b4-ab0e-23690620f79a"`.
+* `deps`: a vector listing the dependencies of the dependency, for example
+  `deps = ["Example", "JSON"]`.
+* `version`: a version number, for example `version = "1.2.6"`.
+* `path`: a file path to the source code, for example `path = /home/user/Example`.
+* `repo-url`: a URL to the repository where the source code was found,
+  for example `repo-url = "https://github.com/JuliaLang/Example.jl.git"`.
+* `repo-rev`: a git revision, for example a branch `repo-rev = "master"`
+  or a commit `repo-rev = "66607a62a83cb07ab18c0b35c038fcd62987c9b1"`.
+* `git-tree-sha1`: a content hash of the source tree, for example
+  `git-tree-sha1 = "ca3820cc4e66f473467d912c4b2b3ae5dc968444"`.
+
+
+#### Added package
+
+When a package is added from a package registry, for example by invoking `pkg> add Example`
+or with a specific version `pkg> add Example@1.2`, the resulting `Manifest.toml` entry looks
+like:
+
+```toml
+[[Example]]
+deps = ["DependencyA", "DependencyB"]
+git-tree-sha1 = "8eb7b4d4ca487caade9ba3e85932e28ce6d6e1f8"
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+version = "1.2.3"
+```
+
+Note, in particular, that no `repo-url` is present, since that information is included in
+the registry where this package were found.
+
+#### Added package by branch
+
+The resulting dependency section when adding a package specified by a branch, e.g.
+`pkg> add Example#master` or `pkg> add https://github.com/JuliaLang/Example.jl.git`,
+looks like:
+
+```toml
+[[Example]]
+deps = ["DependencyA", "DependencyB"]
+git-tree-sha1 = "54c7a512469a38312a058ec9f429e1db1f074474"
+repo-rev = "master"
+repo-url = "https://github.com/JuliaLang/Example.jl.git"
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+version = "1.2.4"
+```
+
+Note that both the branch we are tracking (`master`) and the remote repository url
+(`"https://github.com/JuliaLang/Example.jl.git"`) are stored in the manifest.
+
+#### Added package by commit
+
+The resulting dependency section when adding a package specified by a commit, e.g.
+`pkg> add Example#cf6ba6cc0be0bb5f56840188563579d67048be34`, looks like:
+
+```toml
+[[Example]]
+deps = ["DependencyA", "DependencyB"]
+git-tree-sha1 = "54c7a512469a38312a058ec9f429e1db1f074474"
+repo-rev = "cf6ba6cc0be0bb5f56840188563579d67048be34"
+repo-url = "https://github.com/JuliaLang/Example.jl.git"
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+version = "1.2.4"
+```
+
+The only difference from tracking a branch is the content of `repo-rev`.
+
+#### Developed package
+
+The resulting dependency section when adding a package with `develop`,
+e.g. `pkg> develop Example` or `pkg> develop /path/to/local/folder/Example`,
+looks like:
+
+```toml
+[[Example]]
+deps = ["DependencyA", "DependencyB"]
+path = "/home/user/.julia/dev/Example/"
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+version = "1.2.4"
+```
+
+Note that the path to the source code is included, and changes made to that
+source tree is directly reflected.
+
+#### Pinned package
+
+Pinned packages are also recorded in the manifest file; the resulting
+dependency section for e.g. `pkg> add Example; pin Example` looks like:
+
+```toml
+[[Example]]
+deps = ["DependencyA", "DependencyB"]
+git-tree-sha1 = "54c7a512469a38312a058ec9f429e1db1f074474"
+pinned = true
+uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
+version = "1.2.4"
+```
+
+The only difference is the addition of the `pinned = true` entry.
+
+#### Multiple package with the same name
+
+Julia differentiates packages based on UUID, which means that the name alone is not enough
+to identify a package. It is possible to have multiple packages in the same environment
+with the same name, but with different UUID. In such a situation the `Manifest.toml` file
+looks a bit different. Consider for example the situation where you have added `A` and `B`
+to your environment, and the `Project.toml` file looks as follows:
+
+```toml
+[deps]
+A = "ead4f63c-334e-11e9-00e6-e7f0a5f21b60"
+B = "edca9bc6-334e-11e9-3554-9595dbb4349c"
+```
+
+If `A` now depends on `B = "f41f7b98-334e-11e9-1257-49272045fb24"`, i.e. *another* package
+named `B` there will be two different `B` packages in the `Manifest.toml` file. In this
+case the full `Manifest.toml` file, with `git-tree-sha1` and `version` fields removed for
+clarity, looks like:
+
+```toml
+[[A]]
+uuid = "ead4f63c-334e-11e9-00e6-e7f0a5f21b60"
+
+    [A.deps]
+    B = "f41f7b98-334e-11e9-1257-49272045fb24"
+
+[[B]]
+uuid = "f41f7b98-334e-11e9-1257-49272045fb24"
+[[B]]
+uuid = "edca9bc6-334e-11e9-3554-9595dbb4349c"
+```
+
+There is now an array of the two `B` packages, and the `[deps]` section for `A` has been
+expanded in order to be explicit about which `B` package `A` depends on.