Removing Mica

Mica keeps what it installs, and what it leaves behind while you work, in a few known places, so leaving it is as clean as arriving. This page takes each of them away: first by the road Mica came by — the VS Code extension, the Debian and Ubuntu packages, the container image, a cloud machine — and then the files the compiler, the programs it builds and the editor leave in your home and temporary folders. Take the sections for the roads you came by; a step for a road you never took finds nothing and changes nothing.

Your own work stays. The projects you wrote, their build folders and the starter repository you cloned are yours to keep or delete, and the last section says where they are.

The VS Code extension

While the extension is still installed, its own command clears what the editor’s Mica work left: Mica: Clean Editor Artifacts in the Command Palette (F1) removes the exports of the compiler’s stages, the debug builds, launch cards and profiles, the runs of files and notebook cells, and the compile profiles. It keeps a language server’s folder younger than a day, which a running server may still be using; the folders section below takes those once the editor is closed.

Then uninstall it from the Extensions view — Mica, then Uninstall — or from a terminal. In VS Code, which installs it from the Visual Studio Marketplace:

code --uninstall-extension mica-development-ug.mica-language

In VSCodium, which installs it from Open VSX:

codium --uninstall-extension mica-development-ug.mica-language

Uninstalling takes the extension itself away. The folder where it kept the exports of the compiler’s stages is its own, one per editor; remove it if it is still there:

rm -rf ~/.config/Code/User/globalStorage/mica-development-ug.mica-language

In the Mica dev container, the extension and everything it kept live inside the container and go with it, as the container image shows.

Settings you set yourself stay in your own files: the mica. entries of your settings.json, and the launch configurations of type mica in a project’s .vscode/launch.json. Nothing reads them once the extension is gone; delete them whenever you like.

The Debian and Ubuntu packages

Every Mica package needs the Dragon runtime, mica-dragon-rt, so removing that one package takes all of them, whichever are installed: the compiler mica, the Dragon SDK mica-dragon-sdk, and the optional mica-dragon-rt-sanitizers. Ask apt first what it would remove; the simulation changes nothing:

apt purge --simulate mica-dragon-rt

Purg mica [...]
Purg mica-dragon-rt [...]

Each Purg line is a package that goes, the runtime last. Then remove them:

sudo apt purge --yes mica-dragon-rt

Removing mica (...) ...
Removing mica-dragon-rt (...) ...

apt remove leaves the same machine behind: purging also deletes a package’s configuration files, and Mica’s packages install none, so either way nothing of them is left on disk and apt forgets them. That is why asking a second time answers Unable to locate package mica-dragon-rt: there is nothing left to remove.

apt installed binutils and libc6-dev for the compiler, and gcc for the sanitizer floors. When nothing else on the machine needs them, apt now offers them for removal. Read the list it shows before you answer: it names every package nothing needs any more, whoever installed it.

sudo apt autoremove

The other architecture’s binutils, C library and emulator, which building for the other architecture installs by name, stay, because apt removes nothing you named. They go the way they came — on an x86-64 machine as below, on an AArch64 machine with binutils-x86-64-linux-gnu, libc6-dev-amd64-cross and qemu-user-binfmt — and so does the QEMU_LD_PREFIX line in your shell’s profile:

sudo apt purge binutils-aarch64-linux-gnu libc6-dev-arm64-cross qemu-user-binfmt

On a machine the starter repository’s devkit set up, mica-provision remove qemu takes the emulator, the QEMU_LD_PREFIX line it wrote into /etc/environment and its file in /etc/profile.d. The devkit’s other features install tools any program may use, such as a C compiler or NVIDIA’s libraries, and mica-provision remove <feature> takes each one off when you no longer want it.

The container image

The image micalang/mica and every container made from it go with Docker’s own commands, on the machine Docker runs on: a container started with docker run, the dev container of Get started, and the starter repository’s Mica Developer. The first command lists the containers made from the image, the second removes each one by the name or the ID it shows, and the last two do the same for the image, under every tag you pulled:

docker ps --all --filter ancestor=micalang/mica
docker rm --force <container>
docker image ls micalang/mica
docker image rm --force <image id>

On Linux, VS Code’s Dev Containers may have built an image of its own from micalang/mica for a folder you opened, named vsc-<folder>-…. docker image ls --filter reference='vsc-*' lists the images Dev Containers built, and docker image rm removes the ones of your Mica folders.

A cloud machine

devkit/mica-devbox my-mica --down deletes a machine the starter repository’s devkit made, with everything it owns, and takes its entry out of your ~/.ssh/config, as Mica on a cloud machine shows. On your own machine the devkit keeps three more things for its cloud machines, which go once you have none left:

rm -rf ~/.ssh/mica-cloud* ~/.mica-cloud

The files Mica leaves behind

Every run of a file, every language server and every build the editor makes works in a folder of its own in your temporary folder and removes it when it ends. A run or a server stopped hard leaves its folder behind. So does a run that ends in an internal compiler error, a bug in the compiler: its message names the crash report written into the run’s folder as the file to send, and the folder stays so that the report is there when you send it. The folder a program opens for the editor’s runtime view stays as well:

(cd "${TMPDIR:-/tmp}" && rm -rf mica-run-* mica-lsp-* mica-debug-* mica-compile-profile-*)
rm -rf "/tmp/mica-$(id -u)" "/run/user/$(id -u)/mica"

The compiler and the editor make their folders in $TMPDIR when you set it, and in /tmp otherwise; the runtime view’s folder is always one of the two named in the table.

In your home folder, the starter repository’s devkit, mica-provision, keeps the log of each of its runs:

rm -rf ~/.local/state/mica

Nothing else stays. The compiler keeps no cache and no settings in your home folder, and a program that runs on a GPU compiles its device modules in memory, or carries them precompiled, and writes none of them to disk.

Check that nothing is left

One command looks for what the packages installed and for the folders this page names on a Linux machine, and prints whatever is still there:

! find /usr/bin/mica /usr/lib/mica-* /usr/lib/libmica-* /usr/libexec/mica /usr/include/mica_dragon.h \
    /usr/share/doc/mica* "${TMPDIR:-/tmp}"/mica-* "/tmp/mica-$(id -u)" "/run/user/$(id -u)/mica" \
    ~/.local/state/mica ~/.config/Code/User/globalStorage/mica-development-ug.mica-language \
    -maxdepth 0 2> /dev/null | grep . && echo "nothing of Mica is left"

nothing of Mica is left

A path it prints instead is still there, and the section above that names it takes it away.

What stays yours

• The projects you wrote, with the build folders the compiler wrote beside them: build/, or the folder --build named.
• The starter repository you cloned, ~/source/repos/mica-container on the short road of Get started, with whatever you changed in it, and the folder ~/source/repos you cloned it into.
• What your programs wrote, such as the file a products=FILE runtime flag names.
• A notebook’s folder may hold a .mica-notebook-….mica file: the cell a run was compiling when the editor stopped.
• The mica. settings and mica launch configurations in your VS Code files.

See also

• Installing Mica — the packages, and what they install where
• Installing the Dragon SDK — the backend as a C API, a separate package
• Get started with Mica — the container road and the editor
• Mica on a cloud machine — the devkit’s machines, and how to end them