Software Reference

You install everything once, in the Lab 1 setup. This page covers what you do every week after that.

VSCodium works the same way as VS Code for everything on this page; it installs the same extensions from Open VSX instead of the Microsoft marketplace.

The weekly loop

Every lab follows the same rhythm:

  1. Accept the week’s GitHub Classroom assignment (linked from Canvas), which creates your personal copy of the lab repository.
  2. Clone it with GitHub Desktop or git clone, into a folder that no cloud service syncs.
  3. Open the lab folder itself in VS Code (File > Open Folder), not a parent directory.
  4. Open index.qmd.
  5. Run the first code cell; the Julia extension starts a REPL for you.
  6. Work through the notebook cell by cell, editing and re-running as you go.

The Julia extension picks its environment from the folder you open. Most package errors come from opening the wrong folder.

Running cells

Each {julia} cell has a Run Cell button above it, and Shift+Enter runs the current cell and moves to the next. Code is sent to the Julia REPL that the Julia extension manages; the first run of a session is slow because Julia is compiling, and later runs are fast.

Where output appears:

  • Values (numbers, DataFrames, fitted models) render inline in the editor at the end of the cell, and also in the REPL panel.
  • Plots open in the Julia extension’s plot pane, a panel beside the editor that keeps a history of your plots.
  • Printed text (println, warnings, errors) appears in the REPL panel.

One difference from Jupyter: output attaches to expressions rather than to a saved output block under the cell. If a cell prints several things, look in the REPL, not the editor. To get inline results and REPL output together, set julia.execution.resultType to "both" in your VS Code settings.

Do not use quarto preview to work through a lab. The preview server re-renders the whole document on every save, which is slow and fragile. Work in the REPL, and render when you want to check the finished page.

Environments

Each lab ships a Project.toml (and Manifest.toml) that pins the packages it needs. Two commands cover almost every package problem, both typed at the REPL’s pkg> prompt (press ] to get there, backspace to leave):

  • activate . selects the environment in the current folder; the prompt changes to show its name.
  • instantiate installs exactly the packages the lab’s manifest lists.

Each lab repository keeps its Project.toml at the root. If you open the lab folder as your workspace, the extension selects the right environment on its own. The environment name appears in the status bar at the bottom of the window.

When a package fails to load, check pkg> status first. If the environment name in the output is not the lab’s, you are in the wrong environment. Fix that before you add packages.

Rendering

Render when you want a standalone document of your finished work. Click Render in the editor toolbar, or run quarto render index.qmd in the terminal from the lab folder. Rendering executes the whole notebook, top to bottom, in a fresh process. A clean render confirms the notebook does not depend on leftover REPL state.

When something breaks

Check these in order; they cover most failures:

  1. Wrong environment: pkg> status shows a different project than the lab. Fix with pkg> activate . from the lab folder.
  2. Packages not installed: activate succeeded but using SomePackage fails. Fix with pkg> instantiate.
  3. Stale REPL state: the code references a variable from a cell you edited or deleted. Restart the REPL (Command Palette > “Julia: Restart REPL”) and run the notebook from the top.
  4. A cell works interactively but quarto render fails: the notebook depends on state that is not created by the cells above it; run from the top in a fresh REPL to find the gap.

If none of these fit, ask an LLM, and paste the complete error message rather than paraphrasing it.

Claude Code

This page does not teach Claude Code. For that, read the official documentation and Anthropic’s best-practices guide. A few things to keep in mind when you use it on a lab:

  • Scope: start it inside the lab folder, so it sees the lab and nothing else. A session started in your home directory can read and edit far more than you intend.
  • Permissions: it asks before running commands or editing files. Read what it is asking to do before approving, and be stingy with “always allow”.
  • Small requests: ask about one exercise or one error at a time. A vague “do the lab” produces work you cannot check.
  • Verify: run the code it wrote and read it. You are responsible for whatever you submit or present, including the parts a model wrote.