Сборка и поставка

Состояние инструментария

Текущая идентичность продукта Топаза, доступные продукты поставки и важные для выбора ограничения.

Топаз 5.20.0 — текущий продукт. Текущий режим языка — topaz-5.20.

Снимок исходников, стоящий за 5.20.0, опубликован на github.com/studiohaze/topaz как замороженное зеркало. Разработка продолжается закрыто, а официальные релизы выходят на topaz.ooo и в npm.

Проверьте установку командой:

BASH
topaz version --verbose

Эта команда выводит сведения об идентичности компилятора, режима языка, среды выполнения и генератора Rust. При сообщении о проблеме с установкой приложите полный вывод.

Выбор компилятора

Топаз использует Rust Stage 0 по умолчанию для каждой команды, использующей компилятор. Установленный Stage 2 self-компилятор остается доступным при его явном выборе с помощью --compiler self на допустимых маршрутах текущего режима:

BASH
topaz check app/main.tpz
topaz check app/main.tpz --compiler self
topaz test --root app --locked --compiler self
topaz emit app/main.tpz --compiler self
topaz emit app/main.tpz --target python --compiler self --out-dir python-source
topaz build app/main.tpz --compiler self --out-dir app-product
topaz build app/main.tpz --target web --compiler self --out-dir web-product
topaz dev --root web-app --locked --compiler self
topaz fmt app/main.tpz --compiler self
topaz lsp --compiler self
topaz doc --root app --locked --compiler self --out-dir api-docs
topaz compiler observe app/main.tpz --compiler self --out-dir observation
topaz check app/main.tpz --compiler rust
topaz compiler status --json

Пропущенный выбор означает, что при отсутствии флага --compiler Топаз по умолчанию выполняет Rust Stage 0. Явный self указывает --compiler self для вызова установленного Stage 2 self-компилятора на допустимых маршрутах текущего режима. Выполнение происходит выбранным компилятором, без автоматического повтора или скрытого отката. Явный self поддерживает parse, dump-ast, check, текущие профили, отчёты об экспорте, run, test, bench, заблокированные пакеты, compiler observe, проверенный вывод Rust и Python, нативные и Web-сборки, Web/service dev, форматирование, LSP и документацию пакета. Один процесс LSP сохраняет один выбор компилятора; после его изменения перезапустите сеанс редактора.

Флаг --verbose для команды, использующей компилятор, показывает, являлся ли разрешённый выбор явным, текущим значением по умолчанию или режимом совместимости.

Намерение выбора компилятора сохраняется до определения фактического режима языка. Для пакетной команды CLI сначала читает и проверяет только корневой topaz.toml. Разрешение зависимостей, проверка файла блокировки, чтение исходных файлов, работа с кэшем и формирование результата выполняются позже. Пакет со старым режимом языка использует Rust при пропущенном выборе или явном rust, а явный self отклоняется до дальнейшей обработки. Поэтому выбор по умолчанию для текущего режима и объявленный выбор совместимости с Rust остаются раздельно отслеживаемыми.

Установленный процесс один раз проверяет и декодирует точный неизменяемый образ самокомпилируемого компилятора, после чего подготовленная программа совместно используется рабочими потоками self-компилятора и LSP. Ключ кэша включает идентичность образа, набора исходных файлов, схемы, шаблона среды выполнения и набора инструментов. Любое расхождение останавливает self-компиляцию. Исходные файлы цели, диагностика, сгенерированный код и управляемые результаты по-прежнему вычисляются для каждого запроса и не переиспользуются как подготовленное состояние компилятора. Подготовка укладывается в задокументированные пределы холодного запуска, LSP и памяти.

compiler status --json — машиночитаемый источник сведений об установленном производителе, идентичности образа программы и набора исходных файлов, поддерживаемых и отклоняемых маршрутах, решении при пропущенном выборе для каждого маршрута, выборе по умолчанию, совместимости, восстановлении и запрете скрытого отката. Управляемые артефакты также сообщают, являлся ли выбор явным, текущим значением по умолчанию или режимом совместимости.

Граница восстановления установленного продукта

В установленном продукте проверки пакетов, тесты, сборки и запуск без исходного кода используют значение по умолчанию Rust Stage 0. Явный self остается доступным для отдельного выбора путем указания --compiler self на допустимых маршрутах текущего режима. Повторная сборка одного управляемого каталога через Rust и self атомарно заменяет происхождение.

С тем же установленным выбором по умолчанию двухмодульное учебное приложение проходит проверку, выбранный тест и нативную релизную сборку, а затем запускается без исходников. Полевой реестр закрывает только решённые проблемы продукта. Широкие проверки компилятора и интеграций остаются за кандидатом.

Установленные маршруты Stage 1 и Stage 2 создают из нового исходника отдельные свежие проверенные наблюдения. Явный self может затем собрать новый нативный продукт, который запускается без исходников.

Точный npm-продукт содержит оба варианта компилятора в одном исполняемом файле и не требует checkout репозитория. Продукт, собранный любым вариантом, запускается после удаления исходников Топаза. Если установленный образ самокомпилируемого компилятора отсутствует или повреждён, запрос self завершается ошибкой, не повторяет работу через Rust и не переиспользует его результат. Повторяйте исходную команду с --compiler rust только при явном выборе восстановления. Rust остаётся независимо доступен, а опубликованный комплект восстановления Stage 0 служит отдельным путём офлайн-реконструкции, а не автоматическим откатом.

Установленный self-компилятор теперь владеет полным версионированным продуктом компиляции текущего режима: упорядоченными модулями, токенами и AST, разрешением имён и экспортами, типизированной профильной диагностикой, пониженным представлением и требованиями среды выполнения, а также созданным Rust точным происхождением вызова и результата. Адаптер среды лишь проверяет и декодирует эти факты, не воссоздавая отсутствующие решения компилятора. Для допущенных команд общие пакетные и исполняющие компоненты потребляют один и тот же проверенный продукт.

Вывод Rust через self сохраняет таблицу IR фиксированной точки и добавляет только обычный фасад приложения. Таблицу исполняет общая целевая среда без образов компилятора. Она не может запускать парсер, разрешитель, проверку, понижение или генератор Rust. Манифест нативного артефакта фиксирует выбранный компилятор, производителя, наборы исходников компилятора и цели, продукт компиляции, хеш созданного исходника и targetCompilerFallback: false.

Доступные пути продукта

  • CLI форматирует, проверяет, тестирует, запускает, генерирует исходный код и собирает файлы либо пакеты.
  • Платформенная сборка создаёт исполняемый файл для текущей системы.
  • Python-сборка создаёт program.py и topaz_py_rt.py. Для их выполнения требуется Python 3.11 или новее.
  • Raw Web и Web Worker создают WASM-пакеты для существующей среды выполнения JavaScript.
  • Web Application создаёт полноценный управляемый статический продукт для браузера.
  • HTTP-сервис создаёт управляемый платформенный процесс HTTP/1.1 с фиксированными параметрами приёма соединений, запросов, очереди, времени выполнения, логирования и завершения.
  • Пакетные команды используют манифесты, lock-файлы, зависимости по пути и проверенные зависимости, сохранённые вместе с проектом.
  • topaz lispex embed run выполняет один запрос Лиспекса через точный вычислитель внутри установленного бинарного файла. topaz lispex embed info --json выводит сведения об идентичности компонента, профиля, контракта, среды выполнения и политики без fallback.
  • Браузерная песочница предоставляет проверку и выполнение через интерпретатор без установки CLI Топаза.

Запуск вычислителя Лиспекса

Продукт принимает четыре именованных обычных файла или пути. Каталог результатов не должен существовать заранее:

BASH
topaz lispex embed run \
  --source rule.lspx \
  --input value.lpxvalue \
  --limits limits.json \
  --output lispex-result

Успешно завершённое вычисление записывает result.lpxvalue и report.json. При детерминированной семантической ошибке или исчерпании лимита записывается только report.json. При отказе запроса, нарушении контракта или ошибке движка каталог не создаётся. Предварительный результат и транскрипт не пересекают границу.

Вычислитель, профиль, политика среды выполнения и допуск зафиксированы в установленном продукте. Выбор вычислителя или профиля, загрузка sidecar, callback, импорт и fallback отсутствуют. Отчёт фиксирует выполнение и допуск Топаза, а переносимые ядра в формате Лиспекса создаёт API артефактов приложения. Подробности описаны в разделе Вычислитель Лиспекса и LIT.

Топаз предоставляет API полного текущего профиля std.lispex через интерпретатор и все пять нативных релизных платформ. Процесс работы с манифестом, lock-файлом, сборкой, артефактом и повтором описан в разделе Запуск правил Лиспекса. Маршруты generated-python, raw-web, worker-web, managed-web, http-service, no-capability и mcp-empty-component-set отклоняют эту возможность до записи артефакта или выполнения. Fallback отсутствует.

Наблюдения за компилятором

Снять наблюдение установленного компилятора

Установленный CLI позволяет записать текущий проверяемый конвейер компилятора вплоть до сгенерированного исходного кода Rust в единый канонический управляемый пакет:

BASH
topaz compiler observe --root my-app --locked --out-dir compiler-observation
topaz compiler validate compiler-observation

Результат следует размещать вне my-app. В противном случае при следующем наблюдении управляемый каталог результата может войти в состав фактов о каталогах пакета. Пакет содержит точные байты исходных файлов, набор исходных текстов, исходные и выровненные токены, AST, сведения о разрешении имён, структурированные типы, вызовы, захваты замыканий, пониженное представление без исходного текста, операции среды выполнения, сгенерированный код Rust, диагностику, запрос, ответ и происхождение. Обеспечивайте его защиту так же, как и для исходного пакета.

Проверить пакет наблюдения

Команда validate работает только на чтение. Она проверяет каноническую кодировку, схемы, порядок, перекрёстные ссылки, полноту, размеры и хеши без повторной компиляции и чтения исходного дерева файлов. В сведениях о происхождении производителем указан Rust Stage 0. Это описывает конкретный маршрут наблюдения, но не определяет язык реализации остальных этапов компилятора.

Использовать явное превью фронтенда

Явный предварительный маршрут запускает текущие лексер, обработчик раскладки, парсер, логическое замыкание импортов, разрешение имён и статическую проверку, написанные на Топазе и размещённые в Rust Stage 0:

BASH
topaz compiler preview --root my-app --locked --out-dir typed-preview
topaz compiler validate typed-preview

Формирование пакета завершается на типизированной фазе и содержит указание engine: topaz-front-end-preview, стадии производителя и результата 0/0, а также Rust Stage 0 в качестве хоста начальной загрузки. Фронтенд Топаза охватывает текущую грамматику и канонический AST, логическое замыкание модулей пакета, подключённых зависимостей и стандартной библиотеки, а также точные области видимости, объявления, ссылки, экспорты, статические типы, вызовы, захваты и структурированную диагностику. Число фактов об исходных файлах, узлов AST и Typed, глубина анализа и объём обмена с оболочкой имеют документированные пределы. Этот маршрут завершается на типизированной фазе; понижение, генерация, сборка и запуск принадлежат обычным командам компилятора, а Stage 1 Preview представлен отдельным маршрутом ниже. При сбое маршрут останавливается без повторной работы фронтенда через Rust. Обычные команды компилятора используют установленное для маршрута значение по умолчанию.

Запустить превью компилятора Stage 1

Установленный продукт также предоставляет явно выбираемый Stage 1 Compiler Preview:

BASH
topaz compiler preview main.tpz --producer stage1 --terminal rust-source --out-dir stage1-observation
topaz compiler validate stage1-observation

Stage 1 Preview принимает версионируемый формат обмена и закрытый IR без исходного текста, сформированные подсистемами понижения и генерации Rust на Топазе. Он компилирует обычный пакет без повторного подключения или вызова целевых парсера, разрешения имён, проверки, понижения, генератора или интерпретатора на Rust. Управляемый пакет фиксирует стадии производителя и результата 1/1, идентичность набора исходных текстов компилятора, сгенерированного кода и шаблона среды выполнения, а также параметр targetCompilerFallback: false.

Release tool regenerate_stage1_c1 разбирает параметры CLI за один проход в типизированные режимы producer и владеющие пути. Interpreted применяется по умолчанию только при отсутствии --producer, для linked-c1 обязателен входной manifest, а неиспользуемые manifests, пропущенные значения, дубликаты и неизвестные опции отклоняются до генерации. Release-наблюдения Rust 1.96 записали Stage 0→1 как 98 301 332 байта с null input SHA за 1343,36 секунды, а Stage 1→2 — как 98 289 249 байт с точными SHA input manifest и program image и targetCompilerFallback: false за 2122,96 секунды.

Release tool generate_stage2_r2 теперь разделяет с regenerate_stage1_c1 владение опциями CLI генератора, SHA-256 и atomic write. Он получает три обязательных пути R2 за один типизированный проход и отклоняет пропущенные значения, дубликаты и неизвестные опции до генерации. Одно наблюдение Rust 1.96 --release --locked сформировало 98 289 249 байт за 2087,51 секунды с точными SHA входных C2 manifest и program image, targetCompilerFallback: false и сгенерированным Rust, совпадающим по байтам и SHA с существующим продуктом linked C2.

Устаревший workspace binary run_stage1_c1_canary не имел действующих потребителей среди scripts, CI или explicit Cargo targets и дублировал собственный fact-цикл на 64 раунда, чувствительные к форматированию проверки provenance в JSON, разбор response и вывод SHA. Этот binary удалён; официальные генерация и сравнение C1 продолжают выполняться через regenerate_stage1_c1 и check_stage1_comparison, использующие общий typed product.

Точка входа проверки stage2_fixed_point_case теперь принимает строго один OS-native входной путь и отклоняет пропущенные или лишние входы до обработки source. Его host заимствует канонический source и создаёт владеющие source facts только при ответе на запрос; независимое соглашение front-end C1/C2 и выходная запись не изменились.

Сборка Stage 1 runtime теперь читает массивы operands, labels и module operations через borrowed exact-size iterators и сериализует их напрямую, не создавая три временных вектора только для получения длины. Байты compact image и identities C1/C2 остаются наблюдаемой границей продукта; это изменение build-time ownership, а не заявление о производительности runtime.

Admission манифеста Stage 1 runtime, producer манифеста C1 и admission identity установленного C2 теперь получают точное значение Rust toolchain из metadata своих пакетов Cargo вместо трёх дополнительных literals. Оба пакета наследуют workspace rust-version; значения и байты sealed manifests не изменились. Это изменение build-time ownership metadata, а не обновление toolchain, расширение поддержки или общее заявление о reproducibility.

Сборка Stage 1 runtime теперь передаёт предварительно вычисленные неизменяемые SHA-256 identities программных образов C1/C2 в embedded compiler descriptor. Публичные helpers identity и descriptors манифестов продуктов заимствуют эти статические значения без повторного хеширования полных images и allocation строк descriptor с префиксом; независимое runtime-хеширование admission C2 по-прежнему отклоняет повреждения и дрейф ожидаемой identity до выполнения.

Планирование конвейерных плейсхолдеров теперь просматривает все исполняемые формы выражений-аргументов стадии, относя RHS каждого вложенного конвейера к его собственной стадии. Стадии без плейсхолдера используют inserted-lead, а стадии с плейсхолдером сохраняют записанный список аргументов и однократно вычисляют pipe-lead, связанный с _, сохраняя форму аргументов, исходный порядок, захват замыканиями и изоляцию вложенных стадий в Stage 0, self-host lowering, product runtime Stage 1, сгенерированных Rust и Python. Это исправление существующего поведения SPEC §11 и расширение только внутреннего словаря call evaluation без изменения ID схемы.

Роли ключевых слов как полей после точки или безопасной точки и перед явным двоеточием поля записи больше не открывают construct-state для let, const, case, for или concurrent. Stage 0 и live self-host layout source сохраняют последующие многооператорные блоки и фигурные скобки вложенных record patterns, не меняя подлинные заголовки конструкций и все 21 существующее имя поля-ключевого слова.

Окружение дифференциального тестирования Python теперь проходит отдельный workspace Rust 1.96 strict clippy после удаления двух повторных заимствований временных String и упрощения одного вложенного условия и одного одноплечевого match. Компилятор продукта, среда выполнения, self-host исходный код Топаза и поведение существующих тестов не изменены.

Rust Stage 0 и текущий live self-host исходный код parser теперь применяют существующее правило TPZ2012 для имён привязок к объявлениям констант, поэтому const None: Option<int> = None отклоняется на имени None. Запечатанный embedded image self-компилятора не изменён и остаётся историческим до регенерации кандидата.

Stage 0 на Rust и рабочий self-host парсер Топаза теперь обнаруживают дубликаты в селективных импортах с помощью единого прохода в порядке исходного кода, отслеживая встреченные экспортированные имена источника и локальные имена привязки вместо попарного сравнения всех элементов. Это обеспечивает выдачу ровно одного диагностического сообщения TPZ2011 для каждого последующего конфликтующего элемента в порядке токенов исходного текста с сохранением приоритета имени источника при одновременном дублировании по обеим осям, сохраняя прежние коды, сообщения и диапазоны токенов без перегенерации запечатанного встроенного образа C2.

Крейт topaz_parser теперь делает функцию parse_layout_tokens закрытой, удаляя неиспользуемый публичный вспомогательный элемент вместе с тестом самосравнения, который сопоставлял отладочные представления с самими собой. Функция parse_staged и её четыре записи этапов остаются открытой границей продукта, используемой путями наблюдений resolver и kernel. Синтаксический анализ продукта, структуры AST, диагностика, исходный код self-host и семантика языка не изменились.

Stage 0 Rust и рабочие self-host resolver и checker Топаза теперь применяют существующую границу немедленных и отложенных вычислений инициализатора к дочерним условным выражениям. Левый операнд &&, ||, ?? и receiver опционального вызова по-прежнему сканируются на опережающие ссылки верхнего уровня, а правый операнд короткого замыкания и аргументы опционального вызова считаются отложенными, поскольку runtime может их пропустить. Фактическое достижение такой позиции до появления привязки по-прежнему вызывает существующую динамическую ошибку unbound. SPEC §17 и ADR-086 теперь явно называют обе группы. Это исправление статического избыточного отклонения, а не новая функция языка или гарантия runtime-безопасности.

Крейт topaz_resolve и интерфейс FileProvider теперь используют типизированную границу SourceRead (Present, Missing, Unreadable, InvalidUtf8) вместо прежнего свёртывания в Option<String>, ошибочно сообщавшего о нечитаемых файлах и недопустимом UTF-8 как об отсутствии модулей через TPZ3001. Разрешение импортов и воспроизведение фактов хоста в ядре теперь выдают существующую диагностику допуска загрузчика TPZ3003 для нечитаемых и не являющихся UTF-8 входных данных, централизуя классификацию физического чтения в resolver. Коды диагностики, схемы, структуры AST, исходный код self-host и состояние публичного релиза не изменились.

Тесты корпуса parser и предназначенная только для репозитория команда CLI check-corpus теперь напрямую используют единый источник правил corpus-extract для фиксированных количеств 5.1 и таблицы шести областей 5.2. Избыточный assertion списка областей 5.2 удалён, а комментарии к phases описывают текущее владение parse, resolve, check и exec. Байты fixtures, поведение языка продукта и состояние публичного релиза не изменились.

Понять границу сравнения

Граница сравнения раздельно оценивает семантические наблюдения, диагностику, сгенерированный исходный код, поведение созданного продукта и происхождение. Rust Stage 0 и Stage 1 Preview дают совпадающие результаты на заявленных многомодульном и отклоняемом диагностическом примерах. Для заявленного продукта сравнения скомпонованный и интерпретируемый маршруты Stage 1 формируют идентичный исходный код Rust, тогда как сгенерированный код Stage 0 и Stage 1 различается. Скомпилированный продукт Stage 1 выводит ровно 42. Неверная идентичность производителя или повреждённый управляемый продукт Stage 1 отклоняются без повторной компиляции целевого объекта через Stage 0.

Сравнить без клонирования репозитория

Установленный продукт позволяет выполнить точное сравнение без наличия рабочей копии репозитория:

BASH
topaz compiler observe main.tpz --terminal rust-source --out-dir rust-observation
topaz compiler preview main.tpz --producer stage1 --terminal rust-source --out-dir stage1-observation
topaz compiler validate rust-observation
topaz compiler validate stage1-observation
topaz compiler compare --layer semantic rust-observation stage1-observation

После записи двух управляемых наблюдений операции проверки и сравнения больше не обращаются к исходному файлу программы. Если Stage 1 отклоняет запрос или завершается с ошибкой, резервное наблюдение не создаётся. Команда лишь выводит отдельную команду восстановления compiler observe, никогда не выполняя её неявно. Для явного выбора Rust Stage 0 следует указать --compiler rust в обычной команде check или сборки.

Отделить происхождение сгенерированного Rust

Сгенерированный компилятором код Rust хранит сведения о производителе и сборке за пределами канонических байтов исходного текста. Благодаря этому последующие стадии могут сравнивать сгенерированный исходный код побайтно, сохраняя информацию о его происхождении. Установленная команда Stage 1 остаётся явным Preview производителя и изолирована от параметров по умолчанию для обычных маршрутов.

Проверить сгенерированный исходный код компилятора

С помощью публичной реализации Rust Stage 0 верификатор компилирует 14 файлов исходного кода компилятора Топаза и побайтно воспроизводит зафиксированный в репозитории сгенерированный исходный код Rust. На этом маршруте зафиксированный сгенерированный код используется только как эталон для сравнения.

Отдельно верификатор извлекает образ программы компилятора, закодированный в зафиксированном сгенерированном коде Rust, и выполняет его в публичной среде выполнения. На тех же 14 файлах исходного кода этот образ воспроизводит те же байты сгенерированного Rust. Поскольку образ получен из зафиксированного результата, эта проверка подтверждает согласованность кругового прохода, а не независимую начальную загрузку и не неподвижную точку Stage 2.

Публичный верификатор в настоящее время не собирает новый артефакт компилятора из R1 по объявленному шагу rust_build(R1) и не выполняет его для получения R2. Поэтому мы не заявляем неподвижную точку Stage 2.

Запись об исправлении заявления о Stage 2

Выбрать границу сравнения

Два полных наблюдения можно сравнить на рубеже, соответствующем решаемой задаче:

BASH
topaz compiler compare --layer semantic observation-a observation-b
topaz compiler compare --layer generated-source observation-a observation-b
topaz compiler compare --layer provenance observation-a observation-b
topaz compiler compare --layer native-binary program-a program-b

Команда выводит одну каноническую запись JSON в пределах документированного лимита размера и завершается с ошибкой при расхождении в выбранном слое. Семантическое сравнение прекращается на первом отличающемся этапе компилятора. Сгенерированный исходный код и происхождение сравниваются независимо, поэтому смена производителя не меняет результат сравнения семантики языка.

Восстановление исходной реализации Rust Stage 0

Выпуск, прошедший проверку для самокомпиляции, содержит отдельный манифест восстановления и детерминированный архив исходного кода наряду с пятью стандартными платформенными файлами. Архив включает в себя исходный код компилятора на Rust, файл блокировки, сохранённые зависимости и лицензии, шаблоны среды выполнения, схемы протокола, нагрузку компилятора и инструменты реконструкции. В нём также отдельно зафиксирован набор встроенных файлов компилятора, написанных на Топазе. Две сборки архива из одинаковых входных данных дают идентичный побайтовый результат.

Сам комплект не содержит инструментария Rust. Для реконструкции закреплённая версия Rust должна быть установлена заранее. Далее сборка выполняется автономно, исключительно из каталога зависимостей в архиве. Это независимый путь восстановления и проверки происхождения, а не стандартный способ установки. Он не делает цепочку восстановления Rust самокомпилируемой.

Проверка исходников компилятора для начальной загрузки

Bootstrap Profile — машиночитаемое ограничение на использование текущего языка в исходном коде ядра компилятора. Оно не вводит новый синтаксис или диалект. Профиль принимает только заблокированный детерминированный пакет, в котором разрешённые операции не используют неявные полномочия среды, extern-модули, числа с плавающей точкой, конкурентность, ресурсы, тестовые API и другие зависящие от хоста операции:

BASH
topaz check --profile bootstrap --locked --root compiler-kernel

Человекочитаемая диагностика содержит стабильное правило bootstrap/*. При использовании --format json поток stderr содержит машиночитаемую диагностику профиля, а stdout — итоговую сводку. Разрешение идентификатора классифицирует пользовательскую функцию с именем print как локальное значение. Запрещённая операция хоста сохраняет идентичность хоста при переименовании или создании псевдонима.

Ограничения, важные для выбора

Все цели используют общий синтаксический анализ, разрешение модулей и статическую проверку, но операции, зависящие от среды, доступны не везде. Цель, которая не может сохранить операцию, должна отклонить её до записи продукта. В частности, сгенерированный Python не поддерживает текущее сжатие DEFLATE с фиксированными кодами Хаффмана, фиксированный zlib и вспомогательную функцию RS(255,223). Генерация завершается явной ошибкой. Перед выбором цели для двоичных медиа проверьте страницы Rust и Python.

HTTP-продукт реализует управляемый HTTP/1.1 с фиксированными настройками слушателя, запросов, очереди, дедлайна, журналирования и завершения. TLS, HTTP/2, WebSocket, исходящие сетевые запросы, неявные полномочия окружения, общее изменяемое состояние Топаза и универсальный веб-фреймворк находятся вне этого продукта.

Web Application использует объявленные возможности браузера. Raw Web и Worker требуют хост JavaScript. Playground запускает исходный код в браузере; развёртывание проверяется сгенерированным продуктом вне рабочего пространства исходного кода.

Порядок выполнения параллельных задач не определён. Объединяйте задачи перед упорядоченным выводом.

Установленный вычислитель обрабатывает topaz lispex embed, а выбор цели Топаза остаётся отдельной поверхностью. --target lispex отклоняется до записи артефакта. LIT — поверхность тестирования и интеграции Лиспекса из одной линии исходного кода, отделённая от установленного вычислителя и выходных бэкендов.

Рекомендуемый порядок

Начните с fmt --check, check и test. Используйте run для приложения командной строки и dev для веб-приложения или HTTP-сервиса. Соберите только необходимую цель и скопируйте весь её управляемый каталог.

Связанная документация