text:
# Packages

A package is a library of Haskell modules known to the compiler. GHC
comes with several packages: see the accompanying [library
documentation](../libraries/index.html). More packages to install can be
obtained from
[HackageDB](http://hackage.haskell.org/packages/hackage.html).

Using a package couldn\'t be simpler: if you\'re using `--make` or GHCi,
then most of the installed packages will be automatically available to
your program without any further options. The exceptions to this rule
are covered below in `using-packages`{.interpreted-text role="ref"}.

Building your own packages is also quite straightforward: we provide the
[Cabal](http://www.haskell.org/cabal/) infrastructure which automates
the process of configuring, building, installing and distributing a
package. All you need to do is write a simple configuration file, put a
few files in the right places, and you have a package. See the [Cabal
documentation](http://www.haskell.org/cabal/users-guide/) for details,
and also the Cabal libraries (`Distribution.Simple.`{.interpreted-text
role="cabal-ref"}, for example).

Using Packages
--------------

::: {.index}
single: packages; using
:::

GHC only knows about packages that are *installed*. Installed packages
live in package databases. For details on package databases and how to
control which package databases or specific set of packages are visible
to GHC, see `package-databases`{.interpreted-text role="ref"}.

To see which packages are currently available, use the `ghc-pkg list`
command:

``` {.sourceCode .none}
$ ghc-pkg list
/usr/lib/ghc-6.12.1/package.conf.d:
    Cabal-1.7.4
    array-<IP_ADDRESS>
    base-<IP_ADDRESS>
    base-<IP_ADDRESS>
    bin-package-db-<IP_ADDRESS>
    binary-<IP_ADDRESS>
    bytestring-<IP_ADDRESS>
    containers-<IP_ADDRESS>
    directory-<IP_ADDRESS>
    (dph-base-0.4.0)
    (dph-par-0.4.0)
    (dph-prim-interface-0.4.0)
    (dph-prim-par-0.4.0)
    (dph-prim-seq-0.4.0)
    (dph-seq-0.4.0)
    extensible-exceptions-<IP_ADDRESS>
    ffi-1.0
    filepath-<IP_ADDRESS>
    (ghc-6.12.1)
    ghc-prim-<IP_ADDRESS>
    haskeline-0.6.2
    haskell98-<IP_ADDRESS>
    hpc-<IP_ADDRESS>
    integer-gmp-<IP_ADDRESS>
    mtl-<IP_ADDRESS>
    old-locale-<IP_ADDRESS>
    old-time-<IP_ADDRESS>
    pretty-<IP_ADDRESS>
    process-<IP_ADDRESS>
    random-<IP_ADDRESS>
    rts-1.0
    syb-<IP_ADDRESS>
    template-haskell-<IP_ADDRESS>
    terminfo-0.3.1
    time-1.1.4
    unix-<IP_ADDRESS>
    utf8-string-0.3.4
```

An installed package is either *exposed* or *hidden* by default.
Packages hidden by default are listed in parentheses (e.g.
`(lang-1.0)`), or possibly in blue if your terminal supports colour, in
the output of `ghc-pkg list`. Command-line flags, described below, allow
you to expose a hidden package or hide an exposed one. Only modules from
exposed packages may be imported by your Haskell code; if you try to
import a module from a hidden package, GHC will emit an error message.
It should be noted that a hidden package might still get linked with
your program as a dependency of an exposed package, it is only
restricted from direct imports.

If there are multiple exposed versions of a package, GHC will prefer the
latest one. Additionally, some packages may be broken: that is, they are
missing from the package database, or one of their dependencies are
broken; in this case; these packages are excluded from the default set
of packages.

::: {.note}
::: {.admonition-title}
Note
:::

If you\'re using Cabal, then the exposed or hidden status of a package
is irrelevant: the available packages are instead determined by the
dependencies listed in your `.cabal` specification. The exposed/hidden
status of packages is only relevant when using `ghc` or `ghci` directly.
:::

Similar to a package\'s hidden status is a package\'s trusted status. A
package can be either trusted or not trusted (distrusted). By default
packages are distrusted. This property of a package only plays a role
when compiling code using GHC\'s Safe Haskell feature (see
`safe-haskell`{.interpreted-text role="ref"}) with the `-fpackage-trust`
flag enabled.

To see which modules are provided by a package use the `ghc-pkg` command
(see `package-management`{.interpreted-text role="ref"}):

``` {.sourceCode .none}
$ ghc-pkg field network exposed-modules
exposed-modules: Network.BSD,
                 Network.CGI,
                 Network.Socket,
                 Network.URI,
                 Network
```

The GHC command line options that control packages are:

::: {.ghc-flag shortdesc="Expose package ⟨pkg⟩" type="dynamic" category=""}
-package ⟨pkg⟩

This option causes the installed package ⟨pkg⟩ to be exposed. The
package ⟨pkg⟩ can be specified in full with its version number (e.g.
`network-1.0`) or the version number can be omitted in which case GHC
will automatically expose the latest non-broken version from the
installed versions of the package.

By default (when `-hide-all-packages`{.interpreted-text role="ghc-flag"}
is not specified), GHC exposes only one version of a package, all other
versions become hidden. If [-package]{.title-ref} option is specified
multiple times for the same package the last one overrides the previous
ones. On the other hand, if `-hide-all-packages`{.interpreted-text
role="ghc-flag"} is used, GHC allows you to expose multiple versions of
a package by using the [-package]{.title-ref} option multiple times with
different versions of the same package.

[-package]{.title-ref} supports thinning and renaming described in
`package-thinning-and-renaming`{.interpreted-text role="ref"}.

The `-package ⟨pkg⟩` option also causes package ⟨pkg⟩ to be linked into
the resulting executable or shared object. Whether a packages\' library
is linked statically or dynamically is controlled by the flag pair
`-static`{.interpreted-text role="ghc-flag"}/
`-dynamic`{.interpreted-text role="ghc-flag"}.

In `--make`{.interpreted-text role="ghc-flag"} mode and
`--interactive`{.interpreted-text role="ghc-flag"} mode (see
`modes`{.interpreted-text role="ref"}), the compiler normally determines
which packages are required by the current Haskell modules, and links
only those. In batch mode however, the dependency information isn\'t
available, and explicit `-package` options must be given when linking.
The one other time you might need to use `-package` to force linking a
package is when the package does not contain any Haskell modules (it
might contain a C library only, for example). In that case, GHC will
never discover a dependency on it, so it has to be mentioned explicitly.

For example, to link a program consisting of objects `Foo.o` and
`Main.o`, where we made use of the `network` package, we need to give
GHC the `-package` flag thus:

``` {.sourceCode .sh}
$ ghc -o myprog Foo.o Main.o -package network
```

The same flag is necessary even if we compiled the modules from source,
because GHC still reckons it\'s in batch mode:

``` {.sourceCode .sh}
$ ghc -o myprog Foo.hs Main.hs -package network
```
:::

::: {.ghc-flag shortdesc="Expose package by id ⟨unit-id⟩" type="dynamic" category=""}
-package-id ⟨unit-id⟩

Exposes a package like `-package ⟨pkg⟩`{.interpreted-text
role="ghc-flag"}, but the package is named by its unit ID (i.e. the
value of `id` in its entry in the installed package database, also
previously known as an installed package ID) rather than by name. This
is a more robust way to name packages, and can be used to select
packages that would otherwise be shadowed. Cabal passes `-package-id`
flags to GHC. `-package-id` supports thinning and renaming described in
`package-thinning-and-renaming`{.interpreted-text role="ref"}.
:::

::: {.ghc-flag shortdesc="Hide all packages by default" type="dynamic" category=""}
-hide-all-packages

Ignore the exposed flag on installed packages, and hide them all by
default. If you use this flag, then any packages you require (including
`base`) need to be explicitly exposed using
`-package ⟨pkg⟩`{.interpreted-text role="ghc-flag"} options.

This is a good way to insulate your program from differences in the
globally exposed packages, and being explicit about package dependencies
is a Good Thing. Cabal always passes the `-hide-all-packages` flag to
GHC, for exactly this reason.
:::

::: {.ghc-flag shortdesc="Hide package ⟨pkg⟩" type="dynamic" category=""}
-hide-package ⟨pkg⟩

This option does the opposite of `-package ⟨pkg⟩`{.interpreted-text
role="ghc-flag"}: it causes the specified package to be hidden, which
means that none of its modules will be available for import by Haskell
`import` directives.

Note that the package might still end up being linked into the final
program, if it is a dependency (direct or indirect) of another exposed
package.
:::

::: {.ghc-flag shortdesc="Ignore package ⟨pkg⟩" type="dynamic" category=""}
-ignore-package ⟨pkg⟩

Causes the compiler to behave as if package ⟨pkg⟩, and any packages that
depend on ⟨pkg⟩, are not installed at all.

Saying `-ignore-package ⟨pkg⟩` is the same as giving
`-hide-package ⟨pkg⟩`{.interpreted-text role="ghc-flag"} flags for ⟨pkg⟩
and all the packages that depend on ⟨pkg⟩. Sometimes we don\'t know
ahead of time which packages will be installed that depend on ⟨pkg⟩,
which is when the `-ignore-package ⟨pkg⟩`{.interpreted-text
role="ghc-flag"} flag can be useful.
:::

::: {.ghc-flag shortdesc="Don't automatically link in the base and rts packages." type="dynamic" category=""}
-no-auto-link-packages

By default, GHC will automatically link in the `base` and `rts`
packages. This flag disables that behaviour.
:::

::: {.ghc-flag shortdesc="Compile to be part of unit (i.e. package)
⟨unit-id⟩" type="dynamic" category=""}
-this-unit-id ⟨unit-id⟩

Tells GHC that the module being compiled forms part of unit ID
⟨unit-id⟩; internally, these keys are used to determine type equality
and linker symbols. As of GHC 8.0, unit IDs must consist solely of
alphanumeric characters, dashes, underscores and periods. GHC reserves
the right to interpret other characters in a special way in later
releases.
:::

::: {.ghc-flag shortdesc="Expose package ⟨pkg⟩ and set it to be trusted" type="dynamic" category="" noindex=""}
-trust ⟨pkg⟩

This option causes the install package ⟨pkg⟩ to be both exposed and
trusted by GHC. This command functions in a very similar way to the
`-package ⟨pkg⟩`{.interpreted-text role="ghc-flag"} command but in
addition sets the selected packages to be trusted by GHC, regardless of
the contents of the package database. (see
`safe-haskell`{.interpreted-text role="ref"}).
:::

::: {.ghc-flag shortdesc="Expose package ⟨pkg⟩ and set it to be distrusted" type="dynamic" category="" noindex=""}
-distrust ⟨pkg⟩

This option causes the install package ⟨pkg⟩ to be both exposed and
distrusted by GHC. This command functions in a very similar way to the
`-package ⟨pkg⟩`{.interpreted-text role="ghc-flag"} command but in
addition sets the selected packages to be distrusted by GHC, regardless
of the contents of the package database. (see
`safe-haskell`{.interpreted-text role="ref"}).
:::

::: {.ghc-flag shortdesc="Distrust all packages by default" type="dynamic" category="" noindex=""}
-distrust-all-packages

Ignore the trusted flag on installed packages, and distrust them by
default. If you use this flag and Safe Haskell then any packages you
require to be trusted (including `base`) need to be explicitly trusted
using `-trust ⟨pkg⟩`{.interpreted-text role="ghc-flag"} options. This
option does not change the exposed/hidden status of a package, so it
isn\'t equivalent to applying `-distrust ⟨pkg⟩`{.interpreted-text
role="ghc-flag"} to all packages on the system. (see
`safe-haskell`{.interpreted-text role="ref"}).
:::

The `main` package {#package-main}
------------------

Every complete Haskell program must define `main` in module `Main` in
package `main`. Omitting the `-this-unit-id ⟨unit-id⟩`{.interpreted-text
role="ghc-flag"} flag compiles code for package `main`. Failure to do so
leads to a somewhat obscure link-time error of the form:

``` {.sourceCode .none}
/usr/bin/ld: Undefined symbols:
_ZCMain_main_closure
```

Consequences of packages for the Haskell language {#package-overlaps}
-------------------------------------------------

It is possible that by using packages you might end up with a program
that contains two modules with the same name: perhaps you used a package
`P` that has a *hidden* module `M`, and there is also a module `M` in
your program. Or perhaps the dependencies of packages that you used
contain some overlapping modules. Perhaps the program even contains
multiple versions of a certain package, due to dependencies from other
packages.

None of these scenarios gives rise to an error on its own[^1], but they
may have some interesting consequences. For instance, if you have a type
`M.T` from version 1 of package `P`, then this is *not* the same as the
type `M.T` from version 2 of package `P`, and GHC will report an error
if you try to use one where the other is expected.

Formally speaking, in Haskell 98, an entity (function, type or class) in
a program is uniquely identified by the pair of the module name in which
it is defined and its name. In GHC, an entity is uniquely defined by a
triple: package, module, and name.

Thinning and renaming modules {#package-thinning-and-renaming}
-----------------------------

When incorporating packages from multiple sources, you may end up in a
situation where multiple packages publish modules with the same name.
Previously, the only way to distinguish between these modules was to use
`package-qualified-imports`{.interpreted-text role="ref"}. However,
since GHC 7.10, the `-package ⟨pkg⟩`{.interpreted-text role="ghc-flag"}
flags (and their variants) have been extended to allow a user to
explicitly control what modules a package brings into scope, by analogy
to the import lists that users can attach to module imports.

The basic syntax is that instead of specifying a package name P to the
package flag `-package`, instead we specify both a package name and a
parenthesized, comma-separated list of module names to import. For
example, `-package "base (Data.List, Data.Bool)"` makes only `Data.List`
and `Data.Bool` visible from package `base`. We also support renaming of
modules, in case you need to refer to both modules simultaneously; this
is supporting by writing `OldModName as NewModName`, e.g.
`-package "base (Data.Bool as Bool)`. You can also write
`-package "base with (Data.Bool as Bool)` to include all of the original
bindings (e.g. the renaming is strictly additive). It\'s important to
specify quotes so that your shell passes the package name and
thinning/renaming list as a single argument to GHC.

Package imports with thinning/renaming do not hide other versions of the
package: e.g. if containers-0.9 is already exposed,
`-package "containers-0.8 (Data.List as ListV8)"` will only add an
additional binding to the environment. Similarly,
`-package "base (Data.Bool as Bool)" -package "base (Data.List as List)"`
is equivalent to
`-package "base (Data.Bool as Bool, Data.List as List)"`. Literal names
must refer to modules defined by the original package, so for example
`-package "base (Data.Bool as Bool, Bool as Baz)"` is invalid unless
there was a `Bool` module defined in the original package. Hiding a
package also clears all of its renamings.

You can use renaming to provide an alternate prelude, e.g.
`-hide-all-packages -package "basic-prelude (BasicPrelude as Prelude)"`,
in lieu of the `rebindable-syntax`{.interpreted-text role="ref"}
extension.

Package Databases
-----------------

A package database is where the details about installed packages are
stored. It is a directory, usually called `package.conf.d`, that
contains a file for each package, together with a binary cache of the
package data in the file `package.cache`{.interpreted-text role="file"}.
Normally you won\'t need to look at or modify the contents of a package
database directly; all management of package databases can be done
through the `ghc-pkg`{.interpreted-text role="command"} tool (see
`package-management`{.interpreted-text role="ref"}).

GHC knows about two package databases in particular:

-   The *global package database*, which comes with your GHC
    installation, e.g. `/usr/lib/ghc-6.12.1/package.conf.d`.
-   The *user package database* private to each user. On Unix systems
    this will be `$HOME/.ghc/arch-os-version/package.conf.d`, and on
    Windows it will be something like
    `C:\Documents And Settings\user\ghc\package.conf.d`. The `ghc-pkg`
    tool knows where this file should be located, and will create it if
    it doesn\'t exist (see `package-management`{.interpreted-text
    role="ref"}).

*Package database stack:* Package databases are arranged in a stack
structure. When GHC starts up it adds the global and the user package
databases to the stack, in that order, unless
`GHC_PACKAGE_PATH`{.interpreted-text role="envvar"} is specified. When
[GHC\_PACKAGE\_PATH]{.title-ref} is specified then it will determine the
initial database stack. Several command line options described below can
further manipulate this initial stack. You can see GHC\'s effective
package database stack by running GHC with the `-v`{.interpreted-text
role="ghc-flag"} flag.

This stack structure means that the order of
`-package-db ⟨file⟩`{.interpreted-text role="ghc-flag"} flags or
`GHC_PACKAGE_PATH`{.interpreted-text role="envvar"} is important. Each
substack of the stack must be well formed (packages in databases on top
of the stack can refer to packages below, but not vice versa).

*Package shadowing:* When multiple package databases are in use it is
possible, though rarely, that the same installed package id is present
in more than one database. In that case, packages closer to the top of
the stack will override (*shadow*) those below them. If the conflicting
packages are found to be equivalent (by ABI hash comparison) then one of
them replaces all references to the other, otherwise the overridden
package and all those depending on it will be removed.

*Package version selection:* When selecting a package, GHC will search
for packages in all available databases. If multiple versions of the
same package are available the latest non-broken version will be chosen.

*Version conflict resolution:* If multiple instances of a package
version chosen by GHC are available then GHC will choose an unspecified
instance.

You can control GHC\'s package database stack using the following
options:

::: {.ghc-flag shortdesc="Add ⟨file⟩ to the package db stack." type="dynamic" category=""}
-package-db ⟨file⟩

Add the package database ⟨file⟩ on top of the current stack.
:::

::: {.ghc-flag shortdesc="Remove the global package db from the stack." type="dynamic" category=""}
-no-global-package-db

Remove the global package database from the package database stack.
:::

::: {.ghc-flag shortdesc="Remove the user's package db from the stack." type="dynamic" category=""}
-no-user-package-db

Prevent loading of the user\'s local package database in the initial
stack.
:::

::: {.ghc-flag shortdesc="Clear the package db stack." type="dynamic" category=""}
-clear-package-db

Reset the current package database stack. This option removes every
previously specified package database (including those read from the
`GHC_PACKAGE_PATH`{.interpreted-text role="envvar"} environment
variable) from the package database stack.
:::

::: {.ghc-flag shortdesc="Add the global package db to the stack." type="dynamic" category=""}
-global-package-db

Add the global package database on top of the current stack. This option
can be used after `-no-global-package-db`{.interpreted-text
role="ghc-flag"} to specify the position in the stack where the global
package database should be loaded.
:::

::: {.ghc-flag shortdesc="Add the user's package db to the stack." type="dynamic" category=""}
-user-package-db

Add the user\'s package database on top of the current stack. This
option can be used after `-no-user-package-db`{.interpreted-text
role="ghc-flag"} to specify the position in the stack where the user\'s
package database should be loaded.
:::

### The `GHC_PACKAGE_PATH` environment variable {#ghc-package-path}

::: {.envvar}
GHC\_PACKAGE\_PATH

The [GHC\_PACKAGE\_PATH]{.title-ref} environment variable may be set to
a `:`-separated (`;`-separated on Windows) list of files containing
package databases. This list of package databases, used by GHC and
ghc-pkg, specifies a stack of package databases from top to bottom. This
order was chosen to match the behaviour of the `PATH`{.interpreted-text
role="envvar"} environment variable where entries earlier in the PATH
override ones that come later. See `package-databases`{.interpreted-text
role="ref"} for details on how the package database stack is used.

Normally [GHC\_PACKAGE\_PATH]{.title-ref} replaces the default package
stack. For example, all of the following commands are equivalent,
creating a stack with db1 at the top followed by db2 (use `;` instead of
`:` on Windows):

``` {.sourceCode .none}
$ ghc -clear-package-db -package-db db2.conf -package-db db1.conf
$ env GHC_PACKAGE_PATH=db1.conf:db2.conf ghc
$ env GHC_PACKAGE_PATH=db2.conf ghc -package-db db1.conf
```

However, if [GHC\_PACKAGE\_PATH]{.title-ref} ends in a separator, the
default databases (i.e. the user and global package databases, in that
order) are appended to the path. For example, to augment the usual set
of packages with a database of your own, you could say (on Unix):

``` {.sourceCode .none}
$ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf:
```

To check whether your [GHC\_PACKAGE\_PATH]{.title-ref} setting is doing
the right thing, `ghc-pkg list` will list all the databases in use, in
the reverse order they are searched.
:::

### Package environments

::: {.index}
single: package environments single: environment file
:::

A *package environment file* is a file that tells `ghc` precisely which
packages should be visible. It can be used to create environments for
`ghc` or `ghci` that are local to a shell session or to some file system
location. They are intended to be managed by build/package tools, to
enable `ghc` and `ghci` to automatically use an environment created by
the tool.

The file contains package IDs and optionally package databases, one
directive per line:

``` {.sourceCode .none}
clear-package-db
global-package-db
user-package-db
package-db db.d/
package-id id_1
package-id id_2
...
package-id id_n
```

If such a package environment is found, it is equivalent to passing
these command line arguments to `ghc`:

``` {.sourceCode .none}
-hide-all-packages
-clear-package-db
-global-package-db
-user-package-db
-package-db db.d/
-package-id id_1
-package-id id_2
...
-package-id id_n
```

Note the implicit `-hide-all-packages`{.interpreted-text
role="ghc-flag"} and the fact that it is
`-package-id ⟨unit-id⟩`{.interpreted-text role="ghc-flag"}, not
`-package ⟨pkg⟩`{.interpreted-text role="ghc-flag"}. This is because the
environment specifies precisely which packages should be visible.

Note that for the `package-db` directive, if a relative path is given it
must be relative to the location of the package environment file.

::: {.ghc-flag shortdesc="Use the specified package environment." type="dynamic" category=""}
-package-env ⟨file⟩\|⟨name⟩

Use the package environment in ⟨file⟩, or in
`$HOME/.ghc/arch-os-version/environments/⟨name⟩` If set to `-` no
package environment is read.
:::

::: {.envvar}
GHC\_ENVIRONMENT

Specifies the path to the package environment file to be used by GHC.
Overridden by the `-package-env ⟨file⟩|⟨name⟩`{.interpreted-text
role="ghc-flag"} flag if set.
:::

In order, `ghc` will look for the package environment in the following
locations:

-   File ⟨file⟩ if you pass the option
    `-package-env ⟨file⟩|⟨name⟩`{.interpreted-text role="ghc-flag"}.
-   File `$HOME/.ghc/arch-os-version/environments/name` if you pass the
    option `-package-env ⟨name⟩`.
-   File ⟨file⟩ if the environment variable
    `GHC_ENVIRONMENT`{.interpreted-text role="envvar"} is set to ⟨file⟩.
-   File `$HOME/.ghc/arch-os-version/environments/name` if the
    environment variable `GHC_ENVIRONMENT`{.interpreted-text
    role="envvar"} is set to ⟨name⟩.

Additionally, unless `-hide-all-packages` is specified `ghc` will also
look for the package environment in the following locations:

-   File `.ghc.environment.arch-os-version` if it exists in the current
    directory or any parent directory (but not the user\'s home
    directory).
-   File `$HOME/.ghc/arch-os-version/environments/default` if it exists.

Package environments can be modified by further command line arguments;
for example, if you specify `-package foo` on the command line, then
package ⟨foo⟩ will be visible even if it\'s not listed in the currently
active package environment.

Installed package IDs, dependencies, and broken packages {#package-ids}
--------------------------------------------------------

Each installed package has a unique identifier (the \"installed package
ID\"), which distinguishes it from all other installed packages on the
system. To see the installed package IDs associated with each installed
package, use `ghc-pkg list -v`:

``` {.sourceCode .none}
$ ghc-pkg list -v
using cache: /usr/lib/ghc-6.12.1/package.conf.d/package.cache
/usr/lib/ghc-6.12.1/package.conf.d
   Cabal-1.7.4 (Cabal-1.7.4-48f5247e06853af93593883240e11238)
   array-<IP_ADDRESS> (array-<IP_ADDRESS>-9cbf76a576b6ee9c1f880cf171a0928d)
   base-<IP_ADDRESS> (base-<IP_ADDRESS>-6cbb157b9ae852096266e113b8fac4a2)
   base-<IP_ADDRESS> (base-<IP_ADDRESS>-247bb20cde37c3ef4093ee124e04bc1c)
   ...
```

The string in parentheses after the package name is the installed
package ID: it normally begins with the package name and version, and
ends in a hash string derived from the compiled package. Dependencies
between packages are expressed in terms of installed package IDs, rather
than just packages and versions. For example, take a look at the
dependencies of the `haskell98` package:

``` {.sourceCode .none}
$ ghc-pkg field haskell98 depends
depends: array-<IP_ADDRESS>-9cbf76a576b6ee9c1f880cf171a0928d
         base-<IP_ADDRESS>-247bb20cde37c3ef4093ee124e04bc1c
         directory-<IP_ADDRESS>-f51711bc872c35ce4a453aa19c799008
         old-locale-<IP_ADDRESS>-d17c9777c8ee53a0d459734e27f2b8e9
         old-time-<IP_ADDRESS>-1c0d8ea38056e5087ef1e75cb0d139d1
         process-<IP_ADDRESS>-d8fc6d3baf44678a29b9d59ca0ad5780
         random-<IP_ADDRESS>-423d08c90f004795fd10e60384ce6561
```

The purpose of the installed package ID is to detect problems caused by
re-installing a package without also recompiling the packages that
depend on it. Recompiling dependencies is necessary, because the newly
compiled package may have a different ABI (Application Binary Interface)
than the previous version, even if both packages were built from the
same source code using the same compiler. With installed package IDs, a
recompiled package will have a different installed package ID from the
previous version, so packages that depended on the previous version are
now orphaned - one of their dependencies is not satisfied. Packages that
are broken in this way are shown in the `ghc-pkg list` output either in
red (if possible) or otherwise surrounded by braces. In the following
example, we have recompiled and reinstalled the `filepath` package, and
this has caused various dependencies including `Cabal` to break:

``` {.sourceCode .none}
$ ghc-pkg list
WARNING: there are broken packages.  Run 'ghc-pkg check' for more details.
/usr/lib/ghc-6.12.1/package.conf.d:
    {Cabal-1.7.4}
    array-<IP_ADDRESS>
    base-<IP_ADDRESS>
    ... etc ...
```

Additionally, `ghc-pkg list` reminds you that there are broken packages
and suggests `ghc-pkg check`, which displays more information about the
nature of the failure:

``` {.sourceCode .none}
$ ghc-pkg check
There are problems in package ghc-6.12.1:
  dependency "filepath-<IP_ADDRESS>-87511764eb0af2bce4db05e702750e63" doesn't exist
There are problems in package haskeline-0.6.2:
  dependency "filepath-<IP_ADDRESS>-87511764eb0af2bce4db05e702750e63" doesn't exist
There are problems in package Cabal-1.7.4:
  dependency "filepath-<IP_ADDRESS>-87511764eb0af2bce4db05e702750e63" doesn't exist
There are problems in package process-<IP_ADDRESS>:
  dependency "filepath-<IP_ADDRESS>-87511764eb0af2bce4db05e702750e63" doesn't exist
There are problems in package directory-<IP_ADDRESS>:
  dependency "filepath-<IP_ADDRESS>-87511764eb0af2bce4db05e702750e63" doesn't exist

The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
ghc-6.12.1
haskeline-0.6.2
Cabal-1.7.4
process-<IP_ADDRESS>
directory-<IP_ADDRESS>
bin-package-db-<IP_ADDRESS>
hpc-<IP_ADDRESS>
haskell98-<IP_ADDRESS>
```

To fix the problem, you need to recompile the broken packages against
the new dependencies. The easiest way to do this is to use
`cabal-install`, or download the packages from
[HackageDB](http://hackage.haskell.org/packages/hackage.html) and build
and install them as normal.

Be careful not to recompile any packages that GHC itself depends on, as
this may render the `ghc` package itself broken, and `ghc` cannot be
simply recompiled. The only way to recover from this would be to
re-install GHC.

Package management (the `ghc-pkg` command) {#package-management}
------------------------------------------

::: {.index}
single: packages; management
:::

The `ghc-pkg`{.interpreted-text role="command"} tool is for querying and
modifying package databases. To see what package databases are in use,
use `ghc-pkg list`. The stack of databases that
`ghc-pkg`{.interpreted-text role="command"} knows about can be modified
using the `GHC_PACKAGE_PATH`{.interpreted-text role="envvar"}
environment variable (see `ghc-package-path`{.interpreted-text
role="ref"}, and using `-package-db ⟨file⟩`{.interpreted-text
role="ghc-flag"} options on the `ghc-pkg`{.interpreted-text
role="command"} command line.

When asked to modify a database, `ghc-pkg` modifies the global database
by default. Specifying `--user` causes it to act on the user database,
or `--package-db` can be used to act on another database entirely. When
multiple of these options are given, the rightmost one is used as the
database to act upon.

Commands that query the package database (list, latest, describe, field,
dot) operate on the list of databases specified by the flags `--user`,
`--global`, and `--package-db`. If none of these flags are given, the
default is `--global --user`.

If the environment variable `GHC_PACKAGE_PATH`{.interpreted-text
role="envvar"} is set, and its value does not end in a separator (`:` on
Unix, `;` on Windows), then the last database is considered to be the
global database, and will be modified by default by `ghc-pkg`. The
intention here is that `GHC_PACKAGE_PATH` can be used to create a
virtual package environment into which Cabal packages can be installed
without setting anything other than `GHC_PACKAGE_PATH`.

The `ghc-pkg` program may be run in the ways listed below. Where a
package name is required, the package can be named in full including the
version number (e.g. `network-1.0`), or without the version number.
Naming a package without the version number matches all versions of the
package; the specified action will be applied to all the matching
packages. A package specifier that matches all version of the package
can also be written `⟨pkg⟩ -*`, to make it clearer that multiple
packages are being matched. To match against the installed package ID
instead of just package name and version, pass the `--ipid` flag.

`ghc-pkg init path`

:   Creates a new, empty, package database at ⟨path⟩, which must not
    already exist.

`ghc-pkg register ⟨file⟩`

:   Reads a package specification from ⟨file⟩ (which may be \"`-`\" to
    indicate standard input), and adds it to the database of installed
    packages. The syntax of ⟨file⟩ is given in
    `installed-pkg-info`{.interpreted-text role="ref"}.

    The package specification must be a package that isn\'t already
    installed.

`ghc-pkg update ⟨file⟩`

:   The same as `register`, except that if a package of the same name is
    already installed, it is replaced by the new one.

`ghc-pkg unregister ⟨P⟩`

:   Remove the specified package from the database.

`ghc-pkg check`

:   Check consistency of dependencies in the package database, and
    report packages that have missing dependencies.

`ghc-pkg expose ⟨P⟩`

:   Sets the `exposed` flag for package ⟨P⟩ to `True`.

`ghc-pkg hide ⟨P⟩`

:   Sets the `exposed` flag for package ⟨P⟩ to `False`.

`ghc-pkg trust ⟨P⟩`

:   Sets the `trusted` flag for package ⟨P⟩ to `True`.

`ghc-pkg distrust ⟨P⟩`

:   Sets the `trusted` flag for package ⟨P⟩ to `False`.

`ghc-pkg list [⟨P⟩] [--simple-output]`

:   This option displays the currently installed packages, for each of
    the databases known to `ghc-pkg`. That includes the global database,
    the user\'s local database, and any further files specified using
    the `-f` option on the command line.

    Hidden packages (those for which the `exposed` flag is `False`) are
    shown in parentheses in the list of packages.

    If an optional package identifier ⟨P⟩ is given, then only packages
    matching that identifier are shown.

    If the option `--simple-output` is given, then the packages are
    listed on a single line separated by spaces, and the database names
    are not included. This is intended to make it easier to parse the
    output of `ghc-pkg list` using a script.

`ghc-pkg find-module ⟨M⟩ [--simple-output]`

:   This option lists registered packages exposing module ⟨M⟩. Examples:

        $ ghc-pkg find-module Var
        c:/fptools/validate/ghc/driver/package.conf.inplace:
            (ghc-6.9.20080428)

        $ ghc-pkg find-module Data.Sequence
        c:/fptools/validate/ghc/driver/package.conf.inplace:
            containers-0.1

    Otherwise, it behaves like `ghc-pkg list`, including options.

`ghc-pkg latest ⟨P⟩`

:   Prints the latest available version of package ⟨P⟩.

`ghc-pkg describe ⟨P⟩`

:   Emit the full description of the specified package. The description
    is in the form of an `InstalledPackageInfo`, the same as the input
    file format for `ghc-pkg register`. See
    `installed-pkg-info`{.interpreted-text role="ref"} for details.

    If the pattern matches multiple packages, the description for each
    package is emitted, separated by the string `---` on a line by
    itself.

`ghc-pkg field ⟨P⟩ ⟨field⟩[,⟨field⟩]*`

:   Show just a single field of the installed package description for
    `P`. Multiple fields can be selected by separating them with commas

`ghc-pkg dot`

:   Generate a graph of the package dependencies in a form suitable for
    input for the [graphviz](http://www.graphviz.org/) tools. For
    example, to generate a PDF of the dependency graph:

        ghc-pkg dot | tred | dot -Tpdf >pkgs.pdf

`ghc-pkg dump`

:   Emit the full description of every package, in the form of an
    `InstalledPackageInfo`. Multiple package descriptions are separated
    by the string `---` on a line by itself.

    This is almost the same as `ghc-pkg describe '*'`, except that
    `ghc-pkg dump` is intended for use by tools that parse the results,
    so for example where `ghc-pkg describe '*'` will emit an error if it
    can\'t find any packages that match the pattern, `ghc-pkg dump` will
    simply emit nothing.

`ghc-pkg recache`

:   Re-creates the binary cache file `package.cache` for the selected
    database. This may be necessary if the cache has somehow become
    out-of-sync with the contents of the database (`ghc-pkg` will warn
    you if this might be the case).

    The other time when `ghc-pkg recache` is useful is for registering
    packages manually: it is possible to register a package by simply
    putting the appropriate file in the package database directory and
    invoking `ghc-pkg recache` to update the cache. This method of
    registering packages may be more convenient for automated packaging
    systems.

Substring matching is supported for ⟨M⟩ in `find-module` and for ⟨P⟩ in
`list`, `describe`, and `field`, where a `'*'` indicates open substring
ends (`prefix*`, `*suffix`, `*infix*`). Examples (output omitted):

``` {.sourceCode .none}
-- list all regex-related packages
ghc-pkg list '*regex*' --ignore-case
-- list all string-related packages
ghc-pkg list '*string*' --ignore-case
-- list OpenGL-related packages
ghc-pkg list '*gl*' --ignore-case
-- list packages exporting modules in the Data hierarchy
ghc-pkg find-module 'Data.*'
-- list packages exporting Monad modules
ghc-pkg find-module '*Monad*'
-- list names and maintainers for all packages
ghc-pkg field '*' name,maintainer
-- list location of haddock htmls for all packages
ghc-pkg field '*' haddock-html
-- dump the whole database
ghc-pkg describe '*'
```

Additionally, the following flags are accepted by `ghc-pkg`:

`-f ⟨file⟩`, `-package-db ⟨file⟩`

:   ::: {.index}
    single: -f; ghc-pkg option single: -package-db; ghc-pkg option
    :::

    Adds ⟨file⟩ to the stack of package databases. Additionally, ⟨file⟩
    will also be the database modified by a `register`, `unregister`,
    `expose` or `hide` command, unless it is overridden by a later
    `--package-db`, `--user` or `--global` option.

`--force`

:   ::: {.index}
    single: \--force; ghc-pkg option
    :::

    Causes `ghc-pkg` to ignore missing dependencies, directories and
    libraries when registering a package, and just go ahead and add it
    anyway. This might be useful if your package installation system
    needs to add the package to GHC before building and installing the
    files.

`--global`

:   ::: {.index}
    single: \--global; ghc-pkg option
    :::

    Operate on the global package database (this is the default). This
    flag affects the `register`, `update`, `unregister`, `expose`, and
    `hide` commands.

`--help`, `-?`

:   ::: {.index}
    single: \--help; ghc-pkg option single: -?; ghc-pkg option
    :::

    Outputs the command-line syntax.

`--user`

:   ::: {.index}
    single: \--user; ghc-pkg option
    :::

    Operate on the current user\'s local package database. This flag
    affects the `register`, `update`, `unregister`, `expose`, and `hide`
    commands.

`-v [⟨n⟩]`, `--verbose [=⟨n⟩]`

:   ::: {.index}
    single: -v; ghc-pkg option single: \--verbose; ghc-pkg option
    :::

    Control verbosity. Verbosity levels range from 0-2, where the
    default is 1, and `-v` alone selects level 2.

`-V`; `--version`

:   ::: {.index}
    single: -V; ghc-pkg option single: \--version; ghc-pkg option
    :::

    Output the `ghc-pkg` version number.

`--ipid`, `--unit-id`

:   ::: {.index}
    single: \--ipid; ghc-pkg option single: \--unit-id; ghc-pkg option
    :::

    Causes `ghc-pkg` to interpret arguments as installed unit IDs (e.g.,
    an identifier like `unix-<IP_ADDRESS>-de7803f1a8cd88d2161b29b083c94240`).
    This is useful if providing just the package name and version are
    ambiguous (in old versions of GHC, this was guaranteed to be unique,
    but this invariant no longer necessarily holds).

Building a package from Haskell source {#building-packages}
--------------------------------------

::: {.index}
single: packages; building
:::

We don\'t recommend building packages the hard way. Instead, use the
[Cabal](http://www.haskell.org/cabal/users-guide/) infrastructure if
possible. If your package is particularly complicated or requires a lot
of configuration, then you might have to fall back to the low-level
mechanisms, so a few hints for those brave souls follow.

You need to build an \"installed package info\" file for passing to
`ghc-pkg` when installing your package. The contents of this file are
described in `installed-pkg-info`{.interpreted-text role="ref"}.

The Haskell code in a package may be built into one or more archive
libraries (e.g. `libHSfoo.a`), or a single shared object (e.g.
`libHSfoo.dll/.so/.dylib`). The restriction to a single shared object is
because the package system is used to tell the compiler when it should
make an inter-shared-object call rather than an intra-shared-object-call
call (inter-shared-object calls require an extra indirection).

-   Building a static library is done by using the
    `ar`{.interpreted-text role="command"} tool, like so:

    ``` {.sourceCode .sh}
    ar cqs libHSfoo-1.0.a A.o B.o C.o ...
    ```

    where `A.o`, `B.o` and so on are the compiled Haskell modules, and
    `libHSfoo.a` is the library you wish to create. The syntax may
    differ slightly on your system, so check the documentation if you
    run into difficulties.

-   To load a package `foo`, GHCi can load its `libHSfoo.a` library
    directly, but it can also load a package in the form of a single
    `HSfoo.o` file that has been pre-linked. Loading the `.o` file is
    slightly quicker, but at the expense of having another copy of the
    compiled package. The rule of thumb is that if the modules of the
    package were compiled with `-split-sections`{.interpreted-text
    role="ghc-flag"} then building the `HSfoo.o` is worthwhile because
    it saves time when loading the package into GHCi. Without
    `-split-sections`{.interpreted-text role="ghc-flag"}, there is not
    much difference in load time between the `.o` and `.a` libraries, so
    it is better to save the disk space and only keep the `.a` around.
    In a GHC distribution we provide `.o` files for most packages except
    the GHC package itself.

    The `HSfoo.o` file is built by Cabal automatically; use
    `--disable-library-for-ghci` to disable it. To build one manually,
    the following GNU `ld` command can be used:

    ``` {.sourceCode .sh}
    ld -r --whole-archive -o HSfoo.o libHSfoo.a
    ```

    (replace `--whole-archive` with `-all_load` on MacOS X)

-   When building the package as shared library, GHC can be used to
    perform the link step. This hides some of the details out the
    underlying linker and provides a common interface to all shared
    object variants that are supported by GHC (DLLs, ELF DSOs, and Mac
    OS dylibs). The shared object must be named in specific way for two
    reasons: (1) the name must contain the GHC compiler version, so that
    two library variants don\'t collide that are compiled by different
    versions of GHC and that therefore are most likely incompatible with
    respect to calling conventions, (2) it must be different from the
    static name otherwise we would not be able to control the linker as
    precisely as necessary to make the `-static`{.interpreted-text
    role="ghc-flag"}/`-dynamic`{.interpreted-text role="ghc-flag"} flags
    work, see `options-linker`{.interpreted-text role="ref"}.

    ``` {.sourceCode .sh}
    ghc -shared -dynamic -o libHSfoo-1.0-ghcGHCVersion.so A.o B.o C.o
    ```

    Using GHC\'s version number in the shared object name allows
    different library versions compiled by different GHC versions to be
    installed in standard system locations, e.g. under \*nix `/usr/lib`.
    To obtain the version number of GHC invoke `ghc --numeric-version`
    and use its output in place of ⟨GHCVersion⟩. See also
    `options-codegen`{.interpreted-text role="ref"} on how object files
    must be prepared for shared object linking.

-   When building a shared library, care must be taken to ensure that
    the resulting object is named appropriately. In particular, GHC
    expects the name of a shared object to have the form
    `libHS<unit id>-ghc<ghc version>.<ext>` where *unit id* is the unit
    ID given during compilation via the
    `-this-unit-id ⟨unit-id⟩`{.interpreted-text role="ghc-flag"} flag,
    *ghc version* is the version of GHC that produced/consumes the
    object and *ext* is the host system\'s usual file extension for
    shared objects.

To compile a module which is to be part of a new package, use the
`-package-name` (to identify the name of the package) and
`-library-name` (to identify the version and the version hashes of its
identities.) options (`using-packages`{.interpreted-text role="ref"}).
Failure to use these options when compiling a package will probably
result in disaster, but you will only discover later when you attempt to
import modules from the package. At this point GHC will complain that
the package name it was expecting the module to come from is not the
same as the package name stored in the `.hi` file.

It is worth noting with shared objects, when each package is built as a
single shared object file, since a reference to a shared object costs an
extra indirection, intra-package references are cheaper than
inter-package references. Of course, this applies to the `main` package
as well.

`InstalledPackageInfo`: a package specification {#installed-pkg-info}
-----------------------------------------------

A package specification is a Haskell record; in particular, it is the
record
`Distribution.InstalledPackageInfo.InstalledPackageInfo`{.interpreted-text
role="cabal-ref"} in the module Distribution.InstalledPackageInfo, which
is part of the Cabal package distributed with GHC.

An `InstalledPackageInfo` has a human readable/writable syntax. The
functions `parseInstalledPackageInfo` and `showInstalledPackageInfo`
read and write this syntax respectively. Here\'s an example of the
`InstalledPackageInfo` for the `unix` package:

``` {.sourceCode .none}
$ ghc-pkg describe unix
name: unix
version: <IP_ADDRESS>
id: unix-<IP_ADDRESS>-de7803f1a8cd88d2161b29b083c94240
license: BSD3
copyright:
maintainer<EMAIL_ADDRESS>stability:
homepage:
package-url:
description: This package gives you access to the set of operating system
             services standardised by POSIX 1003.1b (or the IEEE Portable
             Operating System Interface for Computing Environments -
             IEEE Std. 1003.1).
             .
             The package is not supported under Windows (except under Cygwin).
category: System
author:
exposed: True
exposed-modules: System.Posix System.Posix.DynamicLinker.Module
                 System.Posix.DynamicLinker.Prim System.Posix.Directory
                 System.Posix.DynamicLinker System.Posix.Env System.Posix.Error
                 System.Posix.Files System.Posix.IO System.Posix.Process
                 System.Posix.Process.Internals System.Posix.Resource
                 System.Posix.Temp System.Posix.Terminal System.Posix.Time
                 System.Posix.Unistd System.Posix.User System.Posix.Signals
                 System.Posix.Signals.Exts System.Posix.Semaphore
                 System.Posix.SharedMem
hidden-modules:
trusted: False
import-dirs: /usr/lib/ghc-6.12.1/unix-<IP_ADDRESS>
library-dirs: /usr/lib/ghc-6.12.1/unix-<IP_ADDRESS>
hs-libraries: HSunix-<IP_ADDRESS>
extra-libraries: rt util dl
extra-ghci-libraries:
include-dirs: /usr/lib/ghc-6.12.1/unix-<IP_ADDRESS>/include
includes: HsUnix.h execvpe.h
depends: base-<IP_ADDRESS>-247bb20cde37c3ef4093ee124e04bc1c
hugs-options:
cc-options:
ld-options:
framework-dirs:
frameworks:
haddock-interfaces: /usr/share/doc/ghc/html/libraries/unix/unix.haddock
haddock-html: /usr/share/doc/ghc/html/libraries/unix
```

Here is a brief description of the syntax of this file:

A package description consists of a number of field/value pairs. A field
starts with the field name in the left-hand column followed by a
\"`:`\", and the value continues until the next line that begins in the
left-hand column, or the end of file.

The syntax of the value depends on the field. The various field types
are:

freeform

:   Any arbitrary string, no interpretation or parsing is done.

string

:   A sequence of non-space characters, or a sequence of arbitrary
    characters surrounded by quotes `"...."`.

string list

:   A sequence of strings, separated by commas. The sequence may be
    empty.

In addition, there are some fields with special syntax (e.g. package
names, version, dependencies).

The allowed fields, with their types, are:

`name`

:   ::: {.index}
    single: name; package specification
    :::

    (string) The package\'s name (without the version).

`id`

:   ::: {.index}
    single: id; package specification
    :::

    (string) The installed package ID. It is up to you to choose a
    suitable one.

`version`

:   ::: {.index}
    single: version; package specification
    :::

    (string) The package\'s version, usually in the form `A.B` (any
    number of components are allowed).

`license`

:   ::: {.index}
    single: auto; package specification
    :::

    (string) The type of license under which this package is
    distributed. This field is a value of the
    `Distribution.License.License`{.interpreted-text role="cabal-ref"}
    type.

`license-file`

:   ::: {.index}
    single: license-file; package specification
    :::

    (optional string) The name of a file giving detailed license
    information for this package.

`copyright`

:   ::: {.index}
    single: copyright; package specification
    :::

    (optional freeform) The copyright string.

`maintainer`

:   ::: {.index}
    single: maintainer; package specification
    :::

    (optional freeform) The email address of the package\'s maintainer.

`stability`

:   ::: {.index}
    single: stability; package specification
    :::

    (optional freeform) A string describing the stability of the package
    (e.g. stable, provisional or experimental).

`homepage`

:   ::: {.index}
    single: homepage; package specification
    :::

    (optional freeform) URL of the package\'s home page.

`package-url`

:   ::: {.index}
    single: package-url; package specification
    :::

    (optional freeform) URL of a downloadable distribution for this
    package. The distribution should be a Cabal package.

`description`

:   ::: {.index}
    single: description; package specification
    :::

    (optional freeform) Description of the package.

`category`

:   ::: {.index}
    single: category; package specification
    :::

    (optional freeform) Which category the package belongs to. This
    field is for use in conjunction with a future centralised package
    distribution framework, tentatively titled Hackage.

`author`

:   ::: {.index}
    single: author; package specification
    :::

    (optional freeform) Author of the package.

`exposed`

:   ::: {.index}
    single: exposed; package specification
    :::

    (bool) Whether the package is exposed or not.

`exposed-modules`

:   ::: {.index}
    single: exposed-modules; package specification
    :::

    (string list) modules exposed by this package.

`hidden-modules`

:   ::: {.index}
    single: hidden-modules; package specification
    :::

    (string list) modules provided by this package, but not exposed to
    the programmer. These modules cannot be imported, but they are still
    subject to the overlapping constraint: no other package in the same
    program may provide a module of the same name.

`reexported-modules`

:   ::: {.index}
    single: reexported-modules; reexport specification
    :::

    Modules reexported by this package. This list takes the form of
    `pkg:OldName as NewName (A@orig-pkg-0.1-HASH)`: the first portion of
    the string is the user-written reexport specification (possibly
    omitting the package qualifier and the renaming), while the
    parenthetical is the original package which exposed the module under
    are particular name. Reexported modules have a relaxed overlap
    constraint: it\'s permissible for two packages to reexport the same
    module as the same name if the reexported moduleis identical.

`trusted`

:   ::: {.index}
    single: trusted; package specification
    :::

    (bool) Whether the package is trusted or not.

`import-dirs`

:   ::: {.index}
    single: import-dirs; package specification
    :::

    (string list) A list of directories containing interface files
    (`.hi` files) for this package.

    If the package contains profiling libraries, then the interface
    files for those library modules should have the suffix `.p_hi`. So
    the package can contain both normal and profiling versions of the
    same library without conflict (see also `library_dirs` below).

`library-dirs`

:   ::: {.index}
    single: library-dirs; package specification
    :::

    (string list) A list of directories containing libraries for this
    package.

`hs-libraries`

:   ::: {.index}
    single: hs-libraries; package specification
    :::

    (string list) A list of libraries containing Haskell code for this
    package, with the `.a` or `.dll` suffix omitted. When packages are
    built as libraries, the `lib` prefix is also omitted.

    For use with GHCi, each library should have an object file too. The
    name of the object file does *not* have a `lib` prefix, and has the
    normal object suffix for your platform.

    For example, if we specify a Haskell library as `HSfoo` in the
    package spec, then the various flavours of library that GHC actually
    uses will be called:

    `libHSfoo.a`

    :   The name of the library on Unix and Windows (mingw) systems.

    `HSfoo.dll`

    :   The name of the dynamic library on Windows systems (optional).

    `HSfoo.o`; `HSfoo.obj`

    :   The object version of the library used by GHCi.

`extra-libraries`

:   ::: {.index}
    single: extra-libraries; package specification
    :::

    (string list) A list of extra libraries for this package. The
    difference between `hs-libraries` and `extra-libraries` is that
    `hs-libraries` normally have several versions, to support profiling,
    parallel and other build options. The various versions are given
    different suffixes to distinguish them, for example the profiling
    version of the standard prelude library is named `libHSbase_p.a`,
    with the `_p` indicating that this is a profiling version. The
    suffix is added automatically by GHC for `hs-libraries` only, no
    suffix is added for libraries in `extra-libraries`.

    The libraries listed in `extra-libraries` may be any libraries
    supported by your system\'s linker, including dynamic libraries
    (`.so` on Unix, `.DLL` on Windows).

    Also, `extra-libraries` are placed on the linker command line after
    the `hs-libraries` for the same package. If your package has
    dependencies in the other direction (i.e. `extra-libraries` depends
    on `hs-libraries`), and the libraries are static, you might need to
    make two separate packages.

`include-dirs`

:   ::: {.index}
    single: include-dirs; package specification
    :::

    (string list) A list of directories containing C includes for this
    package.

`includes`

:   ::: {.index}
    single: includes; package specification
    :::

    (string list) A list of files to include for via-C compilations
    using this package. Typically the include file(s) will contain
    function prototypes for any C functions used in the package, in case
    they end up being called as a result of Haskell functions from the
    package being inlined.

`depends`

:   ::: {.index}
    single: depends; package specification
    :::

    (package id list) Packages on which this package depends.

`hugs-options`

:   ::: {.index}
    single: hugs-options; package specification
    :::

    (string list) Options to pass to Hugs for this package.

`cc-options`

:   ::: {.index}
    single: cc-options; package specification
    :::

    (string list) Extra arguments to be added to the gcc command line
    when this package is being used (only for via-C compilations).

`ld-options`

:   ::: {.index}
    single: ld-options; package specification
    :::

    (string list) Extra arguments to be added to the `gcc` command line
    (for linking) when this package is being used.

`framework-dirs`

:   ::: {.index}
    single: framework-dirs; package specification
    :::

    (string list) On Darwin/MacOS X, a list of directories containing
    frameworks for this package. This corresponds to the
    `-framework-path` option. It is ignored on all other platforms.

`frameworks`

:   ::: {.index}
    single: frameworks; package specification
    :::

    (string list) On Darwin/MacOS X, a list of frameworks to link to.
    This corresponds to the `-framework` option. Take a look at Apple\'s
    developer documentation to find out what frameworks actually are.
    This entry is ignored on all other platforms.

`haddock-interfaces`

:   ::: {.index}
    single: haddock-interfaces; package specification
    :::

    (string list) A list of filenames containing
    [Haddock](http://www.haskell.org/haddock/) interface files
    (`.haddock` files) for this package.

`haddock-html`

:   ::: {.index}
    single: haddock-html; package specification
    :::

    (optional string) The directory containing the Haddock-generated
    HTML for this package.

[^1]: it used to in GHC 6.4, but not since 6.6


text:
---
title: Nameservice - Query
---

# Query

## Tutorial.Nameservice.Query

~~~ haskell
module Tutorial.Nameservice.Query where

import Data.Proxy
import Nameservice.Modules.Nameservice.Keeper (storeKey)
import Nameservice.Modules.Nameservice.Types (Whois, Name)
import Polysemy (Members)
import Polysemy.Error (Error)
import Tendermint.SDK.BaseApp (RawStore, AppError, RouteQ, QueryApi, storeQueryHandlers)
~~~

The way to query application state is via the `query` message which uses a `url` like format. The SDK tries to abstract as much of this away as possible. For example, if you want to only serve state that you have registered with the store via the `IsKey` class, then things are very easy. If you need to make joins to serve requests, we support this as well and it's not hard, but we will skip this for now.

In the case we just want to serve data we have registered with the `IsKey` class, we simply need to declare some types

```haskell
type NameserviceContents = '[(Name, Whois)]

type Api = QueryApi NameserviceContents
```

- `NameserviceContents` is simply a type level list of the key value pairs you wish to serve. In this case there is only `Name -> Whois`
- `Api` is the list of leaves of valid url's for this module. When the type family `QueryApi` is applied, it will construct the leaves from the key value pairs based on the `IsKey` class. In this case you end up with only `"/whois"` endpoint, which accepts the `Name` in the `data` field of the `query` message encoded via the `HasCodec` class.

To serve all the data registered with the `IsKey` class, we can use the `storeQueryHandlers` function, supplying a proxy for the store contents, the `storeKey` and a proxy for the effects used in serving requests. In this case because we are serving only types registered with the store, we will need to assume the `RawStore` and `Error AppError` effects.

~~~ haskell
server
  :: Members [RawStore, Error AppError] r
  => RouteQ Api r
server =
  storeQueryHandlers (Proxy @NameserviceContents) storeKey (Proxy :: Proxy r)
~~~

Here `RouteT` is a type family that can build a server from the `Api` type to handle incoming requests. It is similar to how `servant` works, and is largely vendored from that codebase.

Note that more advanced queries are possible other than just serving what is in storage. For example you might want to use joins to fulfill requests or use query parameters in the url. These are all possible, but we won't go into details here as they are not used in the app.

repository: kejace/hs-abci

branch_name: refs/heads/master

extension: md

gha_language: Haskell

license_type: permissive

repo_name: kejace/hs-abci


text:
---
title: Hierarchy Repeat & Children
description: Details on how to work with the hierarchy repeat
keywords:
author: einari
aliases:
    - /interaction/aurelia/aurelia-components/templating/hierarchy_repeat
    - /interaction/aurelia/javascript.components.aurelia/templating/hierarchy_repeat
---
Some components require more than repeating over a flat list and data binding
to a recursive hierarchical structure is not supported out of the box in
Aurelia in a way that makes it easy to define and reuse a view template.
This is where the `hierarchy-repeat` construct will help in dealing with the
complexity of recursive repeating the same template on all levels.

The repeater itself is represented as an Aurelia custom attribute and can be
utilized on anything. It is not linked to any particular component or specific
constraint.

If you're used to the [`repeat.for`](https://aurelia.io/docs/templating/basics#repeaters)
attribute from Aurelia, you'll find yourself right at home.

```html
<ul hierarchy-repeat.for="item of nestedItems"
     hierarchy-children-property="children">
      <li>
        <span>${name}</span>
        <ul hierarchy-repeat-children></ul>
      </li>
</ul>
```

Within the template you'll need to define for which element all child elements
will be rendered to.

The `hierarchy-repeat.for` is expecting an expression that points to where
the items are within the binding context. The above example points to a property
called `nestedItems`.

The `hierarchy-children-property` is referring to what property of the data items
given holds the children items.

{{% notice tip %}}
Keep in mind that everything is recursive, so what you put inside the element
with the `hierarchy-repeat.for` attribute, will be repeated subsequently throughout
the hierarchy. Remember also that the `hierarchy-children-property` is referring to
a property that is expected to be on every level of the hierarchy in your data.
{{% /notice %}}

Given a view-model as follows:

```javascript
export class viewModel {
  constructor() {
    this.nestedItems = [
      {
        name: 'First Root Item', children: [
          {name:'First Root First Child item'},
          {name:'First Root Second Child item'}
        ]
      },
      {
        name: 'Second Root Item', children: [
          {name:'Second Root First Child item'},
          {name:'Second Root Second Child item'}
        ]
      }
    ]
  }
}
```

We should now be getting the following result

```text
* First Root Item
  * First Root First Child item
  * First Root Second Child item
* Second Root Item
  * Second Root First Child item
  * Second Root Second Child item
```

## HierarchyRepeatItem

Within a template when building reusable components, you typically want to encapsulate
the item in an autonomous component. If the component extends the `HierarchyRepeatItem`,
the repeater mechanism will recognize the template as being this and provide additional
value.

Your item would then have its view-model starting off as follows:

```javascript
import { HierarchyRepeatItem } from<EMAIL_ADDRESS>
export class myItem extends HierarchyRepeatItem {
  constructor() {
    super();
  }
}
```

### Hierarchy Navigation

The `HierarchyRepeatItem` gives two properties that enables each item to keep track of
its position in the hierarchy; `parent` and `children`. These will contain instances of
the view-model for your item template that implements `HierarchyRepeatItem`.

In addition there is also an integer called `hierarchyLevel` that is zero based.
The top level nodes will be given `0` as the value, while increased by one for each level
within the hierarchy.

To know if the item is a root level item or not, there is a property called `isRootLevel`.
There is also a convenience property for checking wether or not there are children; `hasChildren`.

license: MIT


text:
## generateGreyValueCooccurrenceMatrixBox

Takes an image and an intensity range to determine a grey value co-occurrence matrix.

For determining which pixel intensities are neighbors, the box neighborhood is taken into account.
Pixels with intensity below minimum of the given range are considered having the minimum intensity.
Pixels with intensity above the maximimum of the given range are treated analogously.
The resulting co-occurrence matrix contains probability values between 0 and 1.

Category: [Measurements](https://clij.github.io/clij2-docs/reference__measurement)

Availability: Available in Fiji by activating the update sites clij and clij2.
This function is part of clijx_-<IP_ADDRESS>.jar.

### Usage in ImageJ macro
```
Ext.CLIJx_generateGreyValueCooccurrenceMatrixBox(Image integer_image, Image grey_value_cooccurrence_matrix_destination, Number min_grey_value, Number max_grey_value);
```

### Usage in object oriented programming languages

Java

// init CLIJ and GPU
import net.haesleinhuepf.clijx.CLIJx;
import net.haesleinhuepf.clij.clearcl.ClearCLBuffer;
CLIJx clijx = CLIJx.getInstance();

// get input parameters
ClearCLBuffer integer_image = clijx.push(integer_imageImagePlus);
grey_value_cooccurrence_matrix_destination = clijx.create(integer_image);
float min_grey_value = 1.0;
float max_grey_value = 2.0;

// Execute operation on GPU
clijx.generateGreyValueCooccurrenceMatrixBox(integer_image, grey_value_cooccurrence_matrix_destination, min_grey_value, max_grey_value);

// show result
grey_value_cooccurrence_matrix_destinationImagePlus = clijx.pull(grey_value_cooccurrence_matrix_destination);
grey_value_cooccurrence_matrix_destinationImagePlus.show();

// cleanup memory on GPU
clijx.release(integer_image);
clijx.release(grey_value_cooccurrence_matrix_destination);

Matlab

% init CLIJ and GPU
clijx = init_clatlabx();

% get input parameters
integer_image = clijx.pushMat(integer_image_matrix);
grey_value_cooccurrence_matrix_destination = clijx.create(integer_image);
min_grey_value = 1.0;
max_grey_value = 2.0;

% Execute operation on GPU
clijx.generateGreyValueCooccurrenceMatrixBox(integer_image, grey_value_cooccurrence_matrix_destination, min_grey_value, max_grey_value);

% show result
grey_value_cooccurrence_matrix_destination = clijx.pullMat(grey_value_cooccurrence_matrix_destination)

% cleanup memory on GPU
clijx.release(integer_image);
clijx.release(grey_value_cooccurrence_matrix_destination);

[Back to CLIJ2 reference](https://clij.github.io/clij2-docs/reference)
[Back to CLIJ2 documentation](https://clij.github.io/clij2-docs)

[Imprint](https://clij.github.io/imprint)

gha_language: ImageJ Macro

gha_license_id: NOASSERTION


text:
# Server pipeline

This is app for sharing your .gitlab-ci.yml, for multi projects.

## Usage

```html
url/{branch}/filename.yml

```

Where url is the domain name of the app. And  master or development is the branch name.

Inside of your gitlab-ci-yml, you have that used ``` include ``` , for more information check the official documentation of gitlab https://docs.gitlab.com/ee/ci/yaml/includes.html

# Contributing
Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

Please make sure to update tests as appropriate.

# License
[MIT](https://choosealicense.com/licenses/mit/)

repository: violenti/server-pipeline

gha_language: Go

repo_name: violenti/server-pipeline


text:
---
layout: post
title: "Geometric Wavelet Scattering Networks on Compact Riemannian Manifolds"
date: 2019-05-24 21:19:04
categories: arXiv_CV
tags: arXiv_CV CNN Deep_Learning
author: Michael Perlmutter, Feng Gao, Guy Wolf, Matthew Hirn
mathjax: true
---

* content
{:toc}

##### Abstract
The Euclidean scattering transform was introduced nearly a decade ago to improve the mathematical understanding of convolutional neural networks. Inspired by recent interest in geometric deep learning, which aims to generalize convolutional neural networks to manifold and graph-structured domains, we define a geometric scattering transform on manifolds. Similar to the Euclidean scattering transform, the geometric scattering transform is based on a cascade of wavelet filters and pointwise nonlinearities. It is invariant to local isometries and stable to certain types of diffeomorphisms. Empirical results demonstrate its utility on several geometric learning tasks. Our results generalize the deformation stability and local translation invariance of Euclidean scattering, and demonstrate the importance of linking the used filter structures to the underlying geometry of the data.

##### Abstract (translated by Google)

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

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


text:
[![View SimpleBlobAlgorithm on File Exchange](https://www.mathworks.com/matlabcentral/images/matlab-file-exchange.svg)](https://de.mathworks.com/matlabcentral/fileexchange/98094-simpleblobalgorithm)

# SimpleBlobAlgorithm
This is a simple Blob Algorithm for Matlab Video Labeler

# Example
![ezgif com-gif-maker](https://user-images.githubusercontent.com/32844273/130474954-cef5aee4-3ba7-43a8-8a39-ee796571e101.gif)

# Installation
Copy the complete folder ```+vision/+labeler/``` on a directory on the matlab path

# Usage
- Launch the MATLAB video labeler app
  - from menu: "APPS > IMAGE PROCESSING AND COMPUTER VISION > Video Labeler"
  - from console: ```>> videoLabeler```
- Load your Video Sequence
- Make shure that:
  - the sequence is in correct order
  - all object are good visual
  - the background has low saturation
  - the object count doesn't change in the sequence
- Create ROIs for all objects you want to be automated and select them with ```ctrl + click```
- Refresh the Algorithm list and choose "Simple Blob Algorithm"
- Start the Algorithm with the "Play" button.
- If the Algorithm fails: try again with different Dilation Size in the Settings
- If you have changing Objects in the scene, automate the frames in segments.

And remember: This is a bare simple algorithm and is far from stable 😏

repository: MaKaNu/SimpleBlobAlgorithm

branch_name: refs/heads/main

repo_name: MaKaNu/SimpleBlobAlgorithm


text:
# ⚙ Development machine - ElementaryOS Vagrant Box

[![GitHub license](https://img.shields.io/github/license/mashape/apistatus.svg)](https://github.com/fbertola/dev-box/blob/master/LICENSE)

**Current ElementaryOS Version Used**: 0.4

## Requirements

The following software must be installed on your local machine before you can use Packer to build the Vagrant box file:

  - [Packer](http://www.packer.io/)
  - [Vagrant](http://vagrantup.com/)
  - [VirtualBox](https://www.virtualbox.org/)
  - [Ansible](http://docs.ansible.com/intro_installation.html)

## Usage

Make sure all the required software (listed above) is installed, then `cd` to the root directory and run:

```bash
packer build elementaryos-0.4-amd64.json
```

After a few minutes, Packer should tell you the box was generated successfully.

## Provisioning with Vagrant

There's an included Vagrantfile that allows to provision the built Vagrant box. Ansible is used for provisioning, using roles from [Ansible-Galaxy](https://galaxy.ansible.com). From the same directory of the Vagrantfile, run the following command for downloading the necessary roles:

```bash
ansible-galaxy install -r requirements.yml
```

Then, run these commands for provisioning the machine (you may want to edit the file `provisioning/vars/main.yml`):

```bash
vagrant box add ./build/elementaryos-0.4-amd64.box fbertola/elementaryos-0.4-amd64 -f
vagrant up virtualbox --provider=virtualbox
```

repository: fbertola/dev-box

repo_name: fbertola/dev-box


text:
# AI-Project-1-Drug-Molecular-Toxicity-Prediction
Project 1 for CS410 Artificial Intelligence 2020 Fall

<!-- TABLE OF CONTENTS -->
## Table of Contents

* [About the Project](#about-the-project)
* [Usage](#usage)

<!-- ABOUT THE PROJECT -->
## About The Project
This project is the individual project of CS410 Artificial Intelligence 2020 Fall in Shanghai Jiao Tong University
named Drug Molecular Toxicity Prediction. Given a dataset of drug molecules
and labels of their toxicity, develop a Deep Neural Network which can
learn from the data provided and predict the toxicity of other molecules.

<!-- USAGE -->
## Usage
This project provides an useful example of application of Deep Neural Network.
Any student can use it as a reference but no plagiarism is allowed.

<!-- LICENSE -->
## License
Distributed under the MIT License. See `LICENSE` for more information.


text:
# Treasure Hunt

### Description

Treasure Hunt is an exercise that teaches about permissions and other security loopholes in
Linux. In this virtual machine there are 16 imaginary users. Somewhere in his/her home
directory, each of these imaginary users has a “secret” file named username-secret.<ext>
(where <ext> is a file extension) whose contents are intended to be private (readable only by
the user and no one else). However, each of their secret files can actually be read by other
users who are both determined and clever.

Your goal is to collect the contents of as many of the
sixteen secret files as you can.

 ---

### Background
There are often multiple users on the same system or network. Given this case, how does a
system determine who is able to access specific files?

Linux system of file access permissions are used to control who is able to read, write and execute certain files. This is used both to keep
user files private as well as to protect critical system files. In order to obtain many of the secrets
in this exercise, you will need to understand the read, write, and execute permissions as well as
how permissions are applied to the owner, group owner, and every user.

If you are unfamiliar with linux permissions, see the section on Linux File Permissions in the Student Tutorials
section below.

This exercise also utilizes password cracking for a few users. That password cracking method
that you will work with utilizes linux password hashes. This exercise is not intended to teach
about hashes and password security techniques. If you are unfamiliar with the general idea of
them, a quick web search should catch you up with the basics.

The files that contain the password hashes are not publicly available on linux systems, but we have made them so for this
exercise and will show where to find them. Hopefully, this will give you an idea if the passwords
you use are secure or not!

You will also run into the .htaccess file in this exercise. This is a configuration file for Apache
Web Server. It is used for many things but here it is only used from user authorization. You
should be able to figure it out when you come across it. If not, a simple web search will help you
out again.

 ---
### Learning Objectives
Know the difference between read, write, and execute permissions and how this affects
directories and files U

Understand linux groups

Understand what Set User ID and Set Group ID do

Know how to find a file’s permissions and interpret this and similar lines ‘-rwsr-xr-x‘

Be able to create a symbolic link and know what it does

Recognize what sorts of passwords are easily cracked from known password hashes

Have a moderate understanding of some basic linux tools and how to use them

### Instructions
Connect to the scenario via your instructor’s directions, or as displayed on the EDURange page.

Once logged in, it is your goal to find the secrets of the following 16 fake users:

* Alice Wan (awan)
* Bob Duomo (bduomo)
* Cathy Dry (cdry)
* Debbie Shi (dshi)
* Ellen Quintus (equintus)
* Fred Sexon (fsexon)
* George Hepta (ghepta)
*  Helen Ochoa (hochoa)
* Inna Nunez (inunez)
* Jack Dekka (jdekka)
* Karen Elva (kelva)
* Loretta Douzette (Idouzette)
* Patricia Kaideka (pkaideka)
* Pyotr Theodore Radessime (pradessime)
* Quinn Sanera (qsanera)
* Tudor Daforth (tdaforth)

---
#### Important Disclaimer:
Accessing some secret files will require that you make changes to certain files/directories in the
accounts of the fake users. Once you determine the secret, be sure to undo any changes that
you make so that you leave the system exactly in the same state that you found it.

Otherwise, you could (1) make it very easy for others to access the information you worked so hard to get
or (2) make it impossible for others to access the information you found (this is unacceptable in
this exercise, though not in the real world).

Since some of your changes may be hard for you to undo, you can use the `resetFakeUsers`
command to resets all fake user accounts to their initial states and also resets other parts of the
system (e.g. deletes all files in the /tmp directory).

Executing this command should solve all reseting issues; if it does not, please let us know. By calling resetFakeUsers frequently, you
could cause a denial of service attack against your classmates; please do not do this!
 ---
### User Secrets
Each secret is contained somewhere in that user's home directory. All fake users belong to a
group named student, a fact that is important for some of the attacks. There are other significant
groups as well that some of these users are in.

There is no strict sequential order for finding the secrets, though some you will only be able to
get after gaining access to another user's account. Password cracking is a great place to start.
We will walk you through that below.

---
### Password Cracking:

For password cracking download [John the Ripper](http:/Awww.openwall.com/john/) onto a
local computer. John the Ripper is not on the Treasure Hunt container, and you won't be able to install
it there.

If you only have access to a Windows computer for your local machine, John the Ripper
suggests HashSuite; though we won't provide you with instructions on how to use that program.

On the Treasure Hunt mcontainer, gain access to the file /etc/shadow. (See hints below if stuck).
You will need a copy of /etc/shadow and /etc/passwd on your machine running John the Ripper.

Next, use John’s unshadow command to combine /etc/passwd and /etc/shadow into a single
password file (e.g. ‘'unshadow passwd shadow > mypasswd’).
Manually edit 'mypasswd' to exclude all accounts other than the 16 fake users for this problem —
otherwise you’re wasting processing time in your password cracker.

When you find the secret of a fake user, removing that user from the unshadowed file will help speed up future attempts.
You do not want to waste processing time trying to crack passwords you don’t need!

Run John on 'mypasswd' (e.g. ‘john passwords’). The basic john command uses the default
wordlist run/password.Ist, which should be able to fairly quickly crack two user passwords.
There is one more password that can be cracked, but you will need to feed john a custom word
list. Maybe if you Knew more about fake users...

### User Web Pages:
Each user has at least one web page in a public html directory. Some of these pages contain
information relevant to finding their secret. Although many of the user web pages are publicly
readable by any user on the THVM, some can only be read via a web browser.

Since you are logged in via ssh, you might be wondering how you can view these web pages.
Lynx is a textbased web browser that we have provided for your use. Typing `lynx localhost/~awan/` will let
you view awan's homepage. The same format can be used to view the other 15 user's pages.

Though you can see the public html pages in each user's directory, due to the permissions of
any private files, you will need to use Lynx to uncover some of the secrets. See Lynx's man
page for specific instructions.

`wget` and `curl` are also good alternative tools, since Lynx may not show you everything...

### Other Hints:
- It may be helpful to export certain files from the THVM to your local computer (or vice versa).
  You can use scp or ftp from your local computer to do this.

- Having trouble gaining access to /etc/shadow? Look in /bin/ and see if you can find something
  to help you.

- Access to web directories can be controlled by a .htaccess file. See
  http://www.javascriptkit.com/howto/htaccess.shtml for documentation on .htaccess files.

- The web server runs as user/group www-data. Including www-data in a group gives the web
  server whatever permissions are given to the group. There is a group named apache whose
  only member is www-data.

- In an HTML file, text between <!-- and > is a comment that is not displayed by the web
  browser.

- The utility `pdftotext` is installed for reading pdf files in the console. Alternatively, you may want to export relevant
  .pdf files from the THVM to your local computer and view them there.)

- It is possible to convert .pdf files to other file formats, and there are programs in the THVM for
  doing this. But saying exactly what those programs are would make one secret too easy too
  find. So you might want to research how to convert .pdf files to other formats in Linux.

- .docx format is a zipped (compressed) directory of XML files; it can be uncompressed with the
  unzip command. There are many ways to obtain that secret though.

- If you want to add a directory dir to the front of your PATH variable, a good way to do this is
  with the following command - export PATH= dir :$PATH (e.g. ‘export PATH=/tmp/:$PATH’)

- The strings command could be helpful for some secrets. As well as a hex viewer.

repository: apollo-heidal/edurange-flask

gha_license_id: MIT

repo_name: apollo-heidal/edurange-flask


text:
# warpalloc
[![GitHub](https://img.shields.io/github/license/pepsipu/warpalloc.svg?style=for-the-badge)](https://github.com/pepsipu/warpalloc/blob/master/LICENSE.md)

Warpalloc was written in Assembly in order to bid farewell to "C clutter". Warpalloc does not use stack variables or setup the stack to optimize the code. Warpalloc also does not classify different chunks (ie fastbins, smallbins, etc) for the sake of saving clock cycles. This makes it wonderful for small programs that use a small amount of concurrent allocations, but makes it slow for large programs that rapidly free and request more memory. In short, don't use warpalloc to make games. Warpalloc uses a new method of attaining memory called "preallocating". Preallocating requests memory from the operating system at the start of the program to save time during the program's functional execution. **YOU MUST PREALLOCATE SOMETHING.  Warpalloc currently works with Assembly, C, and C++.

Warpalloc does not replace ptmalloc. Warpalloc only outclasses ptmalloc in smaller programs because ptmalloc has many complicated and intricate systems, that in the long run, are faster. In contrast to smaller programs, warpalloc performs better because it has one bin and no complicated heuristics.

Warpalloc is similar to ptmalloc, which you may know as "malloc", but much faster for smaller programs. In fact, warpalloc performs about *300 times* faster than ptalloc when given 25 allocations.

![graph](https://i.imgur.com/p4gdW4D.png)

It's likely ptmalloc will perform better for programs that do thousands of allocations and frees, but for small programs, warpalloc kicks ass.
You can test it yourself by running "benchmark.py".

### Sounds cool? How do I use it?
Using Warpalloc is amazingly simple. Simply link the object file with your source file. For example, you can do this with gcc like so.

`gcc -m32 walloc.o main.c -no-pie`

Walloc.o can get obtained in the build directory of the project, or by compiling the library with NASM.

If you'd like your IDE to recognize you are using external functions from a static library, you can either include warpalloc header file (walloc.h) or write the following at the top of your code.

```c
extern void* walloc(int size);
extern void prewalloc(int size);
extern void wfree(void *ptr);
```

Know that you *MUST* preallocating something, even if the preallocation is 0. It doesn't matter what you preallocate, since once the preallocated area ends, it will simply request more from the operating system, which can cost you time. You must preallocate before allocating or freeing.

repository: pepsipu/warpalloc

repo_name: pepsipu/warpalloc


text:
# ShowAndTell

If you've ever had Rails forms with front-end logic that shows or hides form values conditionally on what's entered on the form, and then back-end validation that mirrors that logic, then boy do we have a gem for you!

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'show_and_tell'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install show_and_tell

## Usage

### Class Setup
Say you have a class named `FineCheese`. You want to set it up so that if the field `cheese` is given the value "brie", you want to show the `age` field. When `cheese` matches "cheddar", you want to validate the presence of the `origin` field. When `cheese` matches "nacho" you want to both show, and validate the presence of the `origin` field.

When the `age` field is anything above 40 years, you want to validate the presence of the `moldiness` field.

Here's how you set that up:

```ruby
class FineCheese
  include ActiveModel::Model
  include ShowAndTell

  attr_accessor :age, :cheese, :moldiness, :origin

  validates_presence_of :cheese

  form_option :cheese do |f|
    f.show_when_matches 'brie', :age

    f.tell_when_matches 'cheddar',
      origin: 'Kindly indicate the cheddar country'

    f.show_and_tell_when_matches 'nacho',
      origin: 'Country plz on yer nacho chz'
  end

  form_option :age do |f|
    f.tell_when_matches '[4-9]\d+', moldiness: 'oooh, how moldy is it?'
  end
end
```

### Javascript Front-End

To use the Javascript front-end, you'll need to add the following to your `app/assets/javascripts/application.js` file:

```javascript
//= require show_and_tell
```

Then, in your HTML, probably in the header just before the body:

```html
<script>
  const show_and_tell = new ShowAndTell
</script>
```

And at the bottom of every form that you wish to monitor, you can insert the magic incantation to inject monitoring:

```html
<%= show_and_tell_register FineCheese %>
```

... where `FineCheese` is the class name of the form being monitored (for example, `ParentCommentForm` or `CourseForm`, etc.).

For each field you monitor, you'll want to enclose everything you wish to show/hide in a `sat-field` node of some sort. For example:

```html
<div sat-field="cheese">
  Cheese:
  <label>
    <input type="radio" name="cheese" value="brie" />
    Brie
  </label>
  <label>
    <input type="radio" name="cheese" value="nacho" />
    Nacho
  </label>
</div>
<div sat-field="age">
  <label>
    Age:
    <input type="text" />
  </label>
</div>
<!-- etc. -->
```

## Development

After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/exploration/show_and_tell. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.

## License

The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

## Code of Conduct

Everyone interacting in the ShowAndTell project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/[USERNAME]/show_and_tell/blob/master/CODE_OF_CONDUCT.md).

repository: exploration/show-and-tell

repo_name: exploration/show-and-tell


text:
---
layout: default
---

# 1997-05-22 - spam is a good thing (was Re: Spam IS Free Speech)

## Header Data

From: Adam Back<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: b7274cd5883e9b2613881775b7e2494740e2a32326cc770dc9d02a884b964c3a

Message ID<EMAIL_ADDRESS>Reply To: \<<IP_ADDRESS>.19970521144153.00ac47e0@labg30\>

UTC Datetime: 1997-05-22 13:49:54 UTC

Raw Date: Thu, 22 May 1997 21:49:54 +0800

## Raw message

```
{% raw  %}From: Adam Back<EMAIL_ADDRESS>Date: Thu, 22 May 1997 21:49:54 +0800
To<EMAIL_ADDRESS>Subject: spam is a good thing (was Re: Spam IS Free Speech)
In-Reply-To: <<IP_ADDRESS>.19970521144153.00ac47e0@labg30>
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

John Deters<EMAIL_ADDRESS>writes:
> No, spam DOES cost the victim.  I'm not saying that the victim is the spam
> recipient.  Think of the ISPs that are the victims of Spamford's
> CyberPromotions.  Yes, victims.  [...]
>
> This situation is the exact situation that has entangled my ISP for the
> last couple of months.
>
> Are you telling me that being subjected to a jack-boot investigation for
> running pyramid schemes *and* having your customers leave because they
> can't get mail services is a reasonable expense to bear because of
> Spamford's "right to free speech"?  Spamford's speech (or that of his
> "customers") isn't even directed at the sendmail operator or his customers.
>  The sendmail operator above is merely being used by Spamford as a
> megaphone to broadcast the message of spam to other people (who really
> don't want it, either, but that's beside the point.)
>
> It's no longer the same as shouting down the marketing researcher.
>
> [your unmetered rented mega phone analogy]

The problem is that you and most of the rest of the internet world are
renting your mega phones/accounts out without charging for usage
volume.  You are also allowing completely free use of your account as
a recipient, and completely free use of your sendmail as a mail hub
service.

If this causes you grief, you need to start metering, and charging
postage to receive mail, and metering mail hub usage.

If I offered to supply a completely unmetered water supply, and there
were no clause in the legal agreement prohibiting it, I could use the
water supply to drive a mini-turbine and draw free electricity from
it, just pouring the water back down the drain.

If you have a cell-phone where it costs you to receive calls, and
people call you lots with junk marketing calls, I'd argue that it was
your problem.  You'd need to switch to a cell phone provider which
puts all the call metering charges on the caller.  (Cell phone
tarriffs are structured this way in the UK, I understand some/most
cell phones in the US, the receiver pays part or all of the call, this
seems a dumb arrangement).  If it's still economical for junk callers
to call you put a tariff on your line for non-designated callers.

It's a mean world, not every one plays nicely, if you offer free
services where the user gets some value, it _will_ get abused.  The
quicker crypto technology is used to fix this on the internet the
better, otherwise we get dumb government laws governing email usage
instead.

See:
	http://www.dcs.ex.ac.uk/~aba/hashcash/

for some thoughts on a short term solution to metering.  Long term
solution use ecash.

> In this particular case, of course, there was a technical solution:
> install a sendmail to prevent routing of incoming mail.  ISPs and
> corporations around the globe will need this new hardened sendmail to keep
> the spammers away.  Restricting the speech they carry.  Turning off the
> megaphones.

Long term solution charge for your IP packets per packet.  If you get
lots of "business" use the proceeds to buy more bandwidth, or put up
your prices.

Try if you can to think of it this way: spam is a good thing because
it draws our attention to underlying vulnerabilities in internet mail
transport protocols.  It's better that we are incentivized to fix
these problems (and Spamford/cyberpromo is doing us a service by
providing this incentive), than it is to leave it to governments to
"fix" the problems by dragging laws into it, which will likely result
in "Internet drivers licenses" and other undesirable effects.

Cypherpunks, I think should be involved in providing crypto solutions
to allow metering for services, using anonymous ecash.  If we don't do
it, someone else will, and it won't be anonymous.

Adam
--
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

{% endraw %}
```

## Thread

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

+ Return to "[Adam Back <aba@dcs.ex.ac.uk>](/authors/adam_back_aba_at_dcs_ex_ac_uk_)"
+ Return to "[John Deters <jad@dsddhc.com>](/authors/john_deters_jad_at_dsddhc_com_)"
+ Return to "[Kent Crispin <kent@songbird.com>](/authors/kent_crispin_kent_at_songbird_com_)"
+ Return to "[Paul Bradley <paul@fatmans.demon.co.uk>](/authors/paul_bradley_paul_at_fatmans_demon_co_uk_)"
+ Return to "[Robert Hettinga <rah@shipwright.com>](/authors/robert_hettinga_rah_at_shipwright_com_)"
+ Return to "["Ross Wright" <rwright@adnetsol.com>](/authors/ross_wright_rwright_at_adnetsol_com_)"
+ Return to<EMAIL_ADDRESS>(Roy M. Silvernail)](/authors/roy_at_sendai_scytale_com_roy_m_silvernail_)"
+ Return to "["Willaim H. Geiger III" <whgiii@amaranth.com>](/authors/willaim_h_geiger_iii_whgiii_at_amaranth_com_)"
+ Return to "["William H. Geiger III" <whgiii@amaranth.com>](/authors/william_h_geiger_iii_whgiii_at_amaranth_com_)"

+ 1997-05-15 (Thu, 15 May 1997 14:47:45 +0800) - [Re: Spam IS Free Speech](/archive/1997/05/c1ee3f777f1c5609b553b81044da5713c52565312d202fb5ab36ac057ad4e7c2) - _"Ross Wright"<EMAIL_ADDRESS>  + 1997-05-16 (Sat, 17 May 1997 02:14:56 +0800) - [Re: Spam IS Free Speech](/archive/1997/05/552219bc010c730025e9527dc8d4003a252a3a0b96629c3efe3806507f01de55) - _Paul Bradley<EMAIL_ADDRESS>  + 1997-05-21 (Thu, 22 May 1997 03:58:58 +0800) - [Re: Spam IS Free Speech](/archive/1997/05/4bf9801551de11e38944813a8ee0cf5df61bf2fc68a4e3e27eb1fefad4049fd6) - _John Deters<EMAIL_ADDRESS>    + 1997-05-22 (Thu, 22 May 1997 21:49:54 +0800) - spam is a good thing (was Re: Spam IS Free Speech) - _Adam Back<EMAIL_ADDRESS>      + 1997-05-22 (Thu, 22 May 1997 22:29:41 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/302b0c9a2c9475669de879467655035b89f4a5d2a65079687d450f2b2db72c90) - _"Willaim H. Geiger III"<EMAIL_ADDRESS>        + 1997-05-22 (Fri, 23 May 1997 01:25:52 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/9522d64f3399e2a7d8290febcd72fd950a1fdda97b5f24b1d9614a19950e327f) - _Adam Back<EMAIL_ADDRESS>          + 1997-05-22 (Fri, 23 May 1997 05:03:52 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/5d70afffc85905ba320f66818102012a1a325b483f822e6ef85bca168b57fbb0) - _"Willaim H. Geiger III"<EMAIL_ADDRESS>          + 1997-05-22 (Fri, 23 May 1997 06:03:47 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/56db7c302adb035786782a2acb5f6e590a1814cee579f89b7c60690983f1b0e0) - _Kent Crispin<EMAIL_ADDRESS>            + 1997-05-23 (Fri, 23 May 1997 21:52:52 +0800) - [SIGH Kent clueless again(was Re: spam is a good thing (was Re: Spam IS Free Speech))](/archive/1997/05/a4d99940cef098649d897a702797752c5a74fbf974b900b19a15cb85dca041b8) - _"William H. Geiger III"<EMAIL_ADDRESS>            + 1997-05-24 (Sat, 24 May 1997 16:13:58 +0800) - [Re: Geiger learns to read (was Re: spam is a good thing)](/archive/1997/05/bb5be766004943c59e486d1117580ed274c203fd9b1e18ba154f67e718df5d1e) - _Kent Crispin<EMAIL_ADDRESS>        + 1997-05-23 (Fri, 23 May 1997 11:40:09 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/bcea7337588daea3b5c23835d70d7c55c691f5b616fcd0775dd0af289cf4a465) - _Robert Hettinga<EMAIL_ADDRESS>      + 1997-05-22 (Fri, 23 May 1997 00:54:07 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/9dfe9fc8b30475d2d4fe0ebc623af7bdea816122245fe562d341c50f9191c5ec) - _John Deters<EMAIL_ADDRESS>      + 1997-05-22 (Fri, 23 May 1997 01:40:11 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/8f2bcab4f1fc23d572734e352575eaf511a6704d1512fd5f71d658a46ae46b38) - _Robert Hettinga<EMAIL_ADDRESS>        + 1997-05-22 (Fri, 23 May 1997 03:08:59 +0800) - [Re: spam is a good thing (was Re: Spam IS Free Speech)](/archive/1997/05/63073bd54c4cc36790974ce9432fb88c7eee162451852b72cf7f8141862b8151) - _"Willaim H. Geiger III"<EMAIL_ADDRESS>    + 1997-05-22 (Fri, 23 May 1997 02:49:15 +0800) - [Re: Spam IS Free Speech](/archive/1997/05/a1c4a1460e5e2ad26b9df9b10e355f0f6756535603b906105fbe7fe124c61d4e) - _Paul Bradley<EMAIL_ADDRESS>      + 1997-05-27 (Tue, 27 May 1997 15:08:50 +0800) - [Re: Spam IS Free Speech](/archive/1997/05/5074b27a43d148f4c5f0c0c88e80f937c61665abe6791ed284638dc59d403125) -<EMAIL_ADDRESS>(Roy M. Silvernail)_


text:
# BasemapGallery

BasemapGallery displays a collection of basemaps from ArcGIS Online, a user-defined portal, or a custom collection. When a basemap is selected from the gallery, the basemap used in the connected GeoModel is replaced.

![BasemapGallery List View](https://user-images.githubusercontent.com/29742178/124198151-f2dc6380-da84-11eb-8e78-4e705d14c33d.png)

![BasemapGallery Grid View](https://user-images.githubusercontent.com/29742178/124198175-ff60bc00-da84-11eb-9a41-6b85a6ed89fd.png)

> **NOTE**: BasemapGallery uses metered ArcGIS basemaps by default, so you will need to configure an API key. See [Security and authentication documentation](https://developers.arcgis.com/documentation/mapping-apis-and-services/security/#api-keys) for more information.

## Features

BasemapGallery:

- Can be configured to use a list, grid, or automatic layout. When using an automatic layout, list or grid presentation is chosen based on a defined width threshold.
    - Note: Grid layout is not supported on MAUI WinUI. Regardless of settings, the list layout will always be used.
- Shows basemaps from a portal, and allows manually adding and removing basemaps from the collection.
- Shows a representation of the map or scene's current basemap if that basemap exists in the gallery.
- Shows a name and thumbnail for each basemap.
- Shows a tooltip on hover on WPF and UWP.
- Supports templating.

## Key properties

BasemapGallery exposes the following properties:

- `GeoModel` - References the connected Map or Scene (optional).
- `Portal` - Controls which portal is used to find basemaps. Setting the portal will reset the basemap collection.
- `AvailableBasemaps` - Collection of basemaps being shown.

The following properties enable customization of the gallery's appearance:

- `GalleryViewStyle` - Controls whether the gallery is displayed as a list or a grid.
- `GridItemTemplate` - Template used to display basemaps when using a grid presentation.
- `ListItemTemplate` - Template used to display basemaps when using a list presentation.
- `ListItemContainerStyle` - Container style used when displaying items as a list. Does not apply to MAUI.
- `GridItemContainerStyle` - Container style used when displaying items as a grid. Does not apply to MAUI.