text‹
Subsequently we describe various Isabelle related utilities, given in
alphabetical order. ›
section‹Building Isabelle docker images›
text‹
Docker🪙‹🪙‹https://docs.docker.com›› provides a self-contained environment
for complex applications called 🪙‹container›, although it does not fully
contain the program in a strict sense of the word. This includes basic
operating system services (usually based on Linux), shared libraries and
other required packages. Thus Docker is a light-weight alternative to
regular virtual machines, or a heavy-weight alternative to conventional
self-contained applications.
Although Isabelle can be easily run on a variety of OS environments without
extra containment, Docker images may occasionally be useful when a
standardized Linux environment is required, even on
Windows🪙‹🪙‹https://docs.docker.com/docker-for-windows›› and
macOS🪙‹🪙‹https://docs.docker.com/docker-for-mac››. Further uses are in
common cloud computing environments, where applications need to be submitted
as Docker images in the first place.
🪙
The @{tool_def docker_build} tool builds docker images from a standard
Isabelle application archive for Linux:
Options are:
-B NAME base image (default "ubuntu:24.04")
-E set Isabelle/bin/isabelle as entrypoint
-P NAME additional Ubuntu package collection ("X11", "latex")
-W DIR working directory that is accessible to docker,
potentially via snap (default: ".")
-l NAME default logic (default ISABELLE_LOGIC="HOL")
-n no docker build
-o FILE output generated Dockerfile
-p NAME additional Ubuntu package
-t TAG docker build tag
-v verbose
Build Isabelle docker image with default logic image, using a standard
Isabelle application archive for Linux (local file or remote URL).›}
Option 🍋‹-E› sets 🍋‹bin/isabelle› of the contained Isabelle distribution as
the standard entry point of the Docker image. Thus 🍋‹docker run› will
imitate the 🍋‹isabelle› command-line tool (\secref{sec:isabelle-tool}) of a
regular local installation, but it lacks proper GUI support: 🍋‹isabelle jedit›
will not work without further provisions. Note that the default entrypoint
may be changed later via 🍋‹docker run --entrypoint="..."›.
Option 🍋‹-t› specifies the Docker image tag: this a symbolic name within the
local Docker name space, but also relevant for Docker
Hub🪙‹🪙‹https://hub.docker.com››.
Option 🍋‹-l› specifies the default logic image of the Isabelle distribution
contained in the Docker environment: it will be produced by 🍋‹isabelle build -b›
as usual (\secref{sec:tool-build}) and stored within the image.
🪙
Option 🍋‹-B› specifies the Docker image taken as starting point for the
Isabelle installation: it needs to be a suitable version of Ubuntu Linux,
see also 🪙‹https://hub.docker.com/_/ubuntu›. The default for Isabelle2025-1
is 🍋‹ubuntu:24.04›, but 🍋‹ubuntu:22.04› and 🍋‹ubuntu:20.04› also work. Other
versions might require experimentation with the package selection.
Option 🍋‹-p› includes additional Ubuntu packages, using the terminology
of 🍋‹apt-get install› within the underlying Linux distribution.
Option 🍋‹-P› refers to high-level package collections: 🍋‹X11› or 🍋‹latex› as
provided by 🍋‹isabelle docker_build› (assuming Ubuntu 24.04/22.04/20.04
LTS). This imposes extra weight on the resulting Docker images. Note that 🍋‹X11› will only provide remote X11 support according to the modest GUI
quality standards of the late 1990-ies.
🪙
Option 🍋‹-n› suppresses the actual 🍋‹docker build› process. Option 🍋‹-o›
outputs the generated 🍋‹Dockerfile›. Both options together produce a
Dockerfile only, which might be useful for informative purposes or other
tools.
Option 🍋‹-v› disables quiet-mode of the underlying 🍋‹docker build› process.
🪙
Option 🍋‹-W› specifies an alternative work directory: it needs to be
accessible to docker, even if this is run via Snap (e.g.\ on Ubuntu 24.04).
The default ``🍋‹.›'' usually works, if this is owned by the user: the tool
will create a fresh directory within it, and remove it afterwards. ›
Invoke the raw Isabelle/ML process within that image:
@{verbatim [display] ‹ docker run test/isabelle:Isabelle2025-1 ML_process -e "Session.welcome ()"›}
Invoke a Linux command-line tool within the contained Isabelle system
environment:
@{verbatim [display] ‹ docker run test/isabelle:Isabelle2025-1 env uname -a›}
The latter should always report a Linux operating system, even when running
on Windows or macOS. ›
Options are:
-I init user settings
-R URL component repository (default $ISABELLE_COMPONENT_REPOSITORY)
-a resolve all missing components
-l list status
-u DIR update $ISABELLE_HOME_USER/components: add directory
-x DIR update $ISABELLE_HOME_USER/components: remove directory
Resolve Isabelle components via download and installation: given COMPONENTS
are identified via base name. Further operations manage etc/settings and
etc/components in $ISABELLE_HOME_USER.
Components are initialized as described in \secref{sec:components} in a
permissive manner, which can mark components as ``missing''. This state is
amended by letting @{tool "components"} download and unpack components that
are published on the default component repository 🪙‹https://isabelle.in.tum.de/components› in particular.
Option 🍋‹-R› specifies an alternative component repository. Note that 🍋‹file:///› URLs can be used for local directories.
Option 🍋‹-a› selects all missing components to be resolved. Explicit
components may be named as command line-arguments as well. Note that
components are uniquely identified by their base name, while the
installation takes place in the location that was specified in the attempt
to initialize the component before.
🪙
Option 🍋‹-l› lists the current state of available and missing components
with their location (full name) within the file-system.
🪙
Option 🍋‹-I› initializes the user settings file to subscribe to the standard
components specified in the Isabelle repository clone --- this does not make
any sense for regular Isabelle releases. An existing file that does not
contain a suitable line ``🍋‹init_components›‹…›🍋‹components/main›'' needs
to be edited according to the printed explanation.
🪙
Options 🍋‹-u› and 🍋‹-x› operate on user components listed in 🍋‹$ISABELLE_HOME_USER/etc/components›: this avoids manual editing of
Isabelle configuration files. ›
If called without arguments, it lists all available documents. Each line
starts with an identifier, followed by a short description. Any of these
identifiers may be specified as arguments, in order to display the
corresponding document.
🪙
The @{setting ISABELLE_DOCS} setting specifies the list of directories
(separated by colons) to be scanned for documentations. ›
section‹Shell commands within the settings environment \label{sec:tool-env}›
text‹
The @{tool_def env} tool is a direct wrapper for the standard 🍋‹/usr/bin/env› command on POSIX systems, running within the Isabelle
settings environment (\secref{sec:settings}).
The command-line arguments are that of the underlying version of 🍋‹env›. For
example, the following invokes an instance of the GNU Bash shell within the
Isabelle environment:
@{verbatim [display] ‹isabelle env bash›} ›
section‹Inspecting the settings environment \label{sec:tool-getenv}›
text‹The Isabelle settings environment --- as provided by the
site-default and user-specific settings files --- can be inspected
with the @{tool_def getenv} tool:
@{verbatim [display] ‹Usage: isabelle getenv [OPTIONS] [VARNAMES ...]
Options are:
-a display complete environment
-b print values only (doesn't work for -a)
-d FILE dump complete environment to file (NUL terminated entries)
Get value of VARNAMES from the Isabelle settings.›}
With the 🍋‹-a› option, one may inspect the full process environment that
Isabelle related programs are run in. This usually contains much more
variables than are actually Isabelle settings. Normally, output is a list of
lines of the form ‹name›🍋‹=›‹value›. The 🍋‹-b› option causes only the values
to be printed.
Option 🍋‹-d› produces a dump of the complete environment to the specified
file. Entries are terminated by the ASCII NUL character, i.e.\ the string
terminator in C. Thus the Isabelle/Scala operation 🍋‹isabelle.Isabelle_System.init› can import the settings
environment robustly, and provide its own 🍋‹isabelle.Isabelle_System.getenv› function. ›
subsubsection‹Examples›
text‹
Get the location of @{setting ISABELLE_HOME_USER} where user-specific
information is stored:
@{verbatim [display] ‹isabelle getenv ISABELLE_HOME_USER›}
🪙
Get the value only of the same settings variable, which is particularly
useful in shell scripts:
@{verbatim [display] ‹isabelle getenv -b ISABELLE_HOME_USER›} ›
text‹
The @{tool_def hg_setup} tool simplifies the setup of Mercurial
repositories, with hosting via Phabricator (\chref{ch:phabricator}) or SSH
file server access.
Options are:
-n NAME remote repository name (default: base name of LOCAL_DIR)
-p PATH Mercurial path name (default: "default")
-r assume that remote repository already exists
Setup a remote vs. local Mercurial repository: REMOTE either refers to a
Phabricator server "user@host" or SSH file server "ssh://user@host/path".›}
The 🍋‹REMOTE› repository specification 🪙‹excludes› the actual repository
name: that is given by the base name of 🍋‹LOCAL_DIR›, or via option 🍋‹-n›.
By default, both sides of the repository are created on demand by default.
In contrast, option 🍋‹-r› assumes that the remote repository already exists:
it avoids accidental creation of a persistent repository with unintended
name.
The local 🍋‹.hg/hgrc› file is changed to refer to the remote repository,
usually via the symbolic path name ``🍋‹default›''; option 🍋‹-p› allows to
provide a different name. ›
subsubsection‹Examples›
text‹
Setup the current directory as a repository with Phabricator server hosting:
@{verbatim [display] ‹ isabelle hg_setup vcs@vcs.example.org .›}
🪙
Setup the current directory as a repository with plain SSH server hosting:
@{verbatim [display] ‹ isabelle hg_setup ssh://files.example.org/data/repositories .›}
🪙
Both variants require SSH access to the target server, via public key
without password. ›
Options are:
-F RULE add rsync filter RULE
(e.g. "protect /foo" to avoid deletion)
-R ROOT explicit repository root directory
(default: implicit from current directory)
-T thorough treatment of file content and directory times
-n no changes: dry-run
-o OPTION override Isabelle system OPTION (via NAME=VAL or NAME)
-p PORT explicit SSH port
-r REV explicit revision (default: state of working directory)
-s HOST SSH host name for remote target (default: local)
-u USER explicit SSH user name
-v verbose
Synchronize Mercurial repository with TARGET directory,
which can be local or remote (see options -s -p -u).›}
The 🍋‹TARGET› specifies a directory, which can be local or an a remote SSH
host; the latter requires option 🍋‹-s› for the host name. The content is
written directly into the target, 🪙‹without› creating a separate
sub-directory. The special sub-directory 🍋‹.hg_sync› within the target
contains meta data from the original Mercurial repository. Repeated
synchronization is guarded by the presence of a 🍋‹.hg_sync› sub-directory:
this sanity check prevents accidental changes (or deletion!) of targets that
were not created by @{tool hg_sync}.
🪙 Option 🍋‹-r› specifies an explicit revision of the repository; the default
is the current state of the working directory (which might be uncommitted).
🪙 Option 🍋‹-v› enables verbose mode. Option 🍋‹-n› enables ``dry-run'' mode:
operations are only simulated; use it with option 🍋‹-v› to actually see
results.
🪙 Option 🍋‹-F› adds a filter rule to the underlying 🍋‹rsync› command;
multiple 🍋‹-F› options may be given to accumulate a list of rules.
🪙 Option 🍋‹-R› specifies an explicit repository root directory. The default
is to derive it from the current directory, searching upwards until a
suitable 🍋‹.hg› directory is found.
🪙 Option 🍋‹-T› indicates thorough treatment of file content and directory
times. The default is to consider files with equal time and size already as
equal, and to ignore time stamps on directories.
🪙 Options 🍋‹-s›, 🍋‹-p›, 🍋‹-u› specify the SSH connection precisely. If no
SSH host name is given, the local file-system is used. An explicit port and
user are only required in special situations.
🪙 Option 🍋‹-p› specifies an explicit port for the SSH connection underlying 🍋‹rsync›; the default is taken from the user's 🍋‹ssh_config› file. ›
subsubsection‹Examples›
text‹
Synchronize the current repository onto a remote host, with accurate
treatment of all content:
@{verbatim [display] ‹ isabelle hg_sync -T -s remotename test/repos›} ›
text‹
By default, the main Isabelle binaries (@{executable "isabelle"} etc.) are
just run from their location within the distribution directory, probably
indirectly by the shell through its @{setting PATH}. Other schemes of
installation are supported by the @{tool_def install} tool:
@{verbatim [display] ‹Usage: isabelle install [OPTIONS] BINDIR
Options are:
-d DISTDIR refer to DISTDIR as Isabelle distribution
(default ISABELLE_HOME)
Install Isabelle executables with absolute references to the
distribution directory.›}
The 🍋‹-d› option overrides the current Isabelle distribution directory as
determined by @{setting ISABELLE_HOME}.
The ‹BINDIR› argument tells where executable wrapper scripts for
@{executable "isabelle"} and @{executable isabelle_java} should be
placed, which is typically a directory in the shell's @{setting PATH}, such
as 🍋‹$HOME/bin›.
🪙
It is also possible to make symbolic links of the main Isabelle executables
manually, but making separate copies outside the Isabelle distribution
directory will not work! ›
section‹Creating instances of the Isabelle logo›
text‹
The @{tool_def logo} tool creates variants of the Isabelle logo, for
inclusion in PDF{\LaTeX} documents.
@{verbatim [display] ‹Usage: isabelle logo [OPTIONS] [NAME]
Options are:
-o FILE alternative output file
-q quiet mode
Create variant NAME of the Isabelle logo as "isabelle_name.pdf".›}
Option 🍋‹-o› provides an alternative output file, instead of the default in
the current directory: 🍋‹isabelle_›‹name›🍋‹.pdf› with the lower-case version
of the given name.
🪙
Option 🍋‹-q› omits printing of the resulting output file name.
🪙
Implementors of Isabelle tools and applications are encouraged to make
derived Isabelle logos for their own projects using this template. The
license is the same as for the regular Isabelle distribution (BSD). ›
section‹Output the version identifier of the Isabelle distribution›
text‹
The @{tool_def version} tool displays Isabelle version information:
@{verbatim [display] ‹Usage: isabelle version [OPTIONS]
Options are:
-i short identification (derived from Mercurial id)
-t symbolic tags (derived from Mercurial id)
Display Isabelle version information.›}
🪙
java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "macro" is null
``🍋‹Isabelle2025-1›''.
🪙
Option 🍋‹-i› produces a short identification derived from the Mercurial id
of the @{setting ISABELLE_HOME} directory; option 🍋‹-t› prints version tags
(if available).
section‹Managed installations of 🪙‹Haskell› and 🪙‹OCaml››
text‹
Code generated in Isabelle cite‹"Haftmann-codegen"› for 🪙‹SML›
or 🪙‹Scala› integrates easily using Isabelle/ML or Isabelle/Scala
respectively.
To facilitate integration with further target languages, there are
tools to provide managed installations of the required ecosystems:
▪ Tool @{tool_def ghc_setup} provides a basic 🪙‹Haskell›cite‹"Thompson-Haskell"› environment
consisting of the Glasgow Haskell Compiler and the Haskell Tool Stack.
▪ Tool @{tool_def ghc_stack} provides an interface to that 🪙‹Haskell›
environment; use 🍋‹isabelle ghc_stack --help› for elementary
instructions.
▪ Tool @{tool_def ocaml_setup} provides a basic 🪙‹OCaml›cite‹OCaml› environment
consisting of the OCaml compiler and the OCaml Package Manager.
▪ Tool @{tool_def ocaml_opam} provides an interface to that 🪙‹OCaml›
environment; use 🍋‹isabelle ocaml_opam --help› for elementary
instructions. ›
end
Messung V0.5 in Prozent
¤ Dauer der Verarbeitung: 0.13 Sekunden
(vorverarbeitet am 2026-06-10)
¤
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.
