The setup we want
At the end of this episode, the Tinox compiler will report its version, a small project will run, and the editor will be able to report a type error. We will use the frozen course source snapshot, rather than an unpinned latest checkout. That choice matters because the compiler and the standard library evolve together. All commands shown here were checked in the course environment; your Linux distribution may use different package names for the same underlying tools.

Check the native toolchain
Start with a Linux machine and the build tools required by the snapshot. The Rust toolchain builds the Tinox compiler and language server. LLVM tools and Clang participate in generating native application code. Native builds also need the relevant development headers and libraries, including the garbage collector, compression, and TLS dependencies used by this configuration. The companion setup instructions list the detected tools and the pinned source. Install equivalent development packages using your distribution, then confirm the tools are on your command path.

Use the frozen course sources
The course bundle includes the exact Tinox source archive used for these lessons. Extract that archive into a directory named toolchain. This is a course snapshot of version two point nine point five, not an instruction to assume that a release tag with that name exists. Keep the source tree available while following the early lessons. It contains the runtime sources, core modules, and editor integration used by the compiler and the examples.

Build the compiler and language server
From the extracted toolchain directory, build the compiler and the language server in release mode, using the included Cargo lockfile. This is a real source build, so the first invocation may take longer than later ones. Wait for it to finish successfully before moving on. The resulting executables live under target slash release. A compiler binary alone is not a replacement for all the native application tools we checked in the previous step.

Make the compiler easy to call
For the current terminal session, add the release directory to your command path. The command on screen assumes that you are still inside toolchain. Then ask Tinox for its version. It should match the compiler field in the course examples. If your shell finds another installation first, fix the path before debugging the examples themselves. Version mismatches are configuration problems to resolve, rather than errors to work around by mixing unrelated package sources.

Install the VS Code integration
This course uses the repository's VS Code extension, packaged as a V S I X file. The checked extension is included in the companion materials. In VS Code, choose Install from V S I X in the Extensions menu, and select that file. This extension is installed directly; the lesson does not assume a Marketplace listing. We also tested installation into an isolated editor profile, keeping the normal user profile separate from the course setup.

Tell the editor where the LSP lives
The extension communicates with the Tinox language server. If automatic discovery does not find the intended binary, set tinox dot l s p dot path to its location. For the supplied course directory layout, the workspace settings use a relative path from the setup example to the toolchain binary. Keep that path aligned if you move folders. Syntax colors come from the extension, while type diagnostics and symbol information come from the language server.

Open the smallest working project
Open the setup example from the episode materials. It contains a package manifest and a source directory with Main dot t n x. The manifest pins compiler version two point nine point five and names the entry file. The class in the entry file is called Main, and its static main method returns an integer exit status. We will explain that structure in detail in episode three. For now, use it as a small test of the complete setup.

Check and run it
Inside the example directory, run Tinox check first. This verifies the source without building a native executable. Then run Tinox run. The output should contain Hello, Tinox. This sequence separates language errors from native build and runtime problems. If checking succeeds but running fails, inspect the actual build message and native tool availability. Do not change the source randomly when the missing piece is a tool or a library in the environment.

Verify an editor diagnostic
Now introduce one deliberate error: assign the text three to a variable declared as an integer. The language server should underline the incompatible value. The diagnostic shown here was captured from a real language server request, not invented for the animation. We also checked the same source with the command line compiler. Both report the same expected and actual types. This gives us a useful connection between editor feedback and the compiler's own understanding.

Repair the source and keep going
Undo the deliberate error and run the program again. At this point, the compiler, native tools, project layout, and editor integration have each been exercised. The setup notes record one snapshot-specific detail: the project generator duplicates the compiler field, so the course provides a valid minimal manifest instead. That issue is tracked separately. Your exercise is to change the greeting, verify it in the editor, and run the new result. Next, we will build this program one line at a time.
