Project LemonLime: a desktop judge for OI contests on top of Lemon and LemonPlus

A judging environment for OI contests, built on Lemon and LemonPlus

Project LemonLime describes itself as a tiny judging environment for OI contests based on Lemon plus LemonPlus. That lineage is the whole point. Lemon and LemonPlus are the established command line judges used for Chinese OI and ACM style programming contests, and they already know how to run a test case, apply a time limit and compare output. What this project adds is a desktop application around them, written in C++ with Qt 6, with the contest workflow handled through windows instead of a sequence of shell commands. The description says it was born for OI competitions, and the repository carries topics for acm, acm-icpc, oi and programming-contests. The audience is therefore a contest organiser or a coach sitting in front of a laptop during a local or school competition, not a platform engineer. The title of the project still carries a Beta marker, and the version numbers, with 0.3.7 as the most recent release, are consistent with that framing.

Four problem types, with C++ as the only assured language for two of them

The feature list leads with problem type support. LemonLime now handles traditional problems, submit-answer problems, interactive problems, and communication problems, where the communication category itself splits into two shapes: one where the contestant completes only part of a function, and one where the contestant writes several complete programs. That coverage is a real differentiator for OI contests, where output-only tasks and interaction tasks appear regularly. The constraint sits right next to it: interactive and communication problems are only assured for C++. Everything else, including the traditional and submit-answer types, is described as language independent. If your contest mixes languages across interactive tasks, that guarantee stops at C++, and the judge will treat the other languages as outside what the project promises. The README does not document a fallback behaviour for those combinations, so treat C++ as the requirement rather than the recommendation for those two categories.

Judging per contestant and per problem, with a cap on re-evaluation

The second structural change is how the contestant list works. In the contestant panel you can now select a single problem for a single contestant, rather than working a row at a time, which means re-judging one submission without touching the rest of the grid. The documentation also describes one-click actions for problems that were never tested, for problems where no source file was found, and for problems that failed to compile. The re-evaluation policy moved too. Lemon's original scheme was discarded because it was too slow, and LemonLime lets you define the maximum number of re-evaluations yourself. That cap is a practical knob for a live contest: a room of machines re-judging in a loop can saturate a network share, and a fixed ceiling keeps the worst case bounded. The trade-off is that a cap set too low will not let a judge recover a result after a transient failure.

Comparison rules, stack limits and the removal of custom test data

Several judging semantics changed along with the interface. The built-in real number comparison mode now evaluates absolute error and relative error at the same time, and it makes explicit judgements for nan and inf values rather than leaving them to a generic mismatch. On Linux, the default stack space is now set to the same size as the memory limit, which removes a class of failure where a program passed on memory but died on stack. The line-by-line comparison mode reports the line number where the difference appears, and the exported HTML report has been reduced in size while gaining more navigation links. One feature was removed rather than extended: custom test data is gone, so a judge who relied on hand written cases outside the official data will have to restructure that workflow. Auto-added problems also no longer floor the total score when dividing it across data points, so score granularity is finer than in the base Lemon behaviour.

Installing on macOS, Debian, Arch and Nix

Prebuilt packages are the normal route. On macOS the project is available from the Release pages or the GitHub Actions artefacts, and it can also be installed through Homebrew Cask:

brew install lemonlime --cask

Windows users take the prebuilt package from the same Release or Actions locations. For Debian and Ubuntu the project provides precompiled deb packages, and the documentation notes they are sometimes not provided because of dependency problems, in which case the statically linked build is the alternative. Arch Linux users can install from the unofficial Arch Linux CN repository or compile from the AUR, where two packages exist: `lemon-lime` for the stable version and `lemon-lime-git` for the development version. The AUR instructions use `yay -S lemon-lime` and `yay -S lemon-lime-git`, and a separate debug information package named `lemon-lime-debug` is expected when reporting crashes. Nix is supported through nixpkgs unstable:

nix-env -iA nixpkgs.project-lemonlime

The statically linked variant is distributed as a single executable with no suffix, which you make runnable with `chmod +x` and then launch directly.

Where the caveats sit: Apple Silicon and the Debian dependency gap

Two limitations are stated plainly and both affect planning. The first is the note that for Apple Silicon users, use and judging stability is not guaranteed. The project still ships a macOS package and the tested systems table lists macOS 15.2 Beta on arm64, but the guarantee and the test matrix are not the same thing, and the sample above is a beta build of the operating system. The second is the Debian and Ubuntu dependency gap: the precompiled deb packages are sometimes not available at all, and the fallback is a static build that you have to obtain and make executable yourself. Neither caveat is fatal, but both push work back to the organiser, and a contest on a school laptop is exactly where a package that will not install and an architecture with no stability promise cause a lost morning. The tested systems table is broad otherwise, covering Windows 10 and 11, Manjaro, Arch, Ubuntu, NOI Linux 2, Linux Mint, Deepin, Debian, Fedora, openSUSE and macOS.

The source tree, the version line and what the upstream alternative gives you

The layout tells you what kind of project this is. At the root sit CMakeLists.txt, a 3rdparty directory for vendored code, src for the application, tests, translations for localisation, makespec for packaging, assets, hooks, unix build files, a BUILD.md build guide and a LICENSES directory alongside the top level LICENSE. The licence is GPL-3.0, which matters if you intend to modify and redistribute the judge: the derivative distribution carries the same licence obligations, and the Credit section notes that some components come with their own terms, including SingleApplication under MIT and the translator and log design and CI files under GPLv3. The alternative to adopting this project is to use Lemon and LemonPlus directly, which is what many OI workflows already do. The difference in approach is the interface and the contest management layer rather than the judging core: upstream is a set of command line tools you drive with data files and scripts, while LemonLime gives you a window for selecting contestant and problem pairs, a statistics column, an enhanced test point adjustor, a file organisation routine that collects answer files and cleans up unused ones, and colour themes derived from the IOI and JOI competitions. If your workflow is already scripted and unattended, that layer is what you would be giving up. On maintenance, the repository is not archived, the last push was on 2026-10-19, and the recent releases are 0.3.7 on 2026-10-08, 0.3.6.2 on 2026-04-09 and 0.3.6.1 on 2025-11-07.

Editorial conclusion

Adopt Project LemonLime when you are running an OI style contest on a machine you control and want a graphical judge instead of a command line tool, and you can accept a Beta labelled project that requires Qt 6.8 or newer. Do not adopt it for an unattended grading pipeline, and check the two documented gaps first: Apple Silicon use and judging stability are explicitly not guaranteed, and the prebuilt Debian and Ubuntu packages are sometimes unavailable because of dependency problems, in which case the statically linked executable is the path. Before you plan a contest, confirm the build guide in BUILD.md and the offline manual in the application match the problem types your contest needs, since interactive and communication tasks are only assured for C++.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project-LemonLime/Project_LemonLime on GitHub
4. README
5. Releases