orca.host.ui.create_dock_panel() hosts plugin HTML in a pane of the
Plater's dock manager, next to the sidebar, and returns a UiDockPanel
handle (post/show/hide/close/is_open). The panel reuses the window.orca
bridge of plugin windows, restores its position and size from the saved
window layout, hides with the Plater off the Prepare and Preview tabs
when floating, and is closed with its plugin.
Includes a sample plugin (sandboxes/orca_dock_panel_plugin_any.py) and
binding and layout-helper tests in slic3rutils.
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
Adds a nightly workflow that runs the long parity checks from
[orca-test-repo](https://github.com/OrcaSlicer/orca-test-repo), which
are too slow for the per-build "Run external slicer regression tests"
step and are kept out of every PR and merge build.
## What it runs
`.github/workflows/parity_nightly.yml`, three jobs:
| Job | What it does |
|---|---|
| Find the build to test | Picks the latest successful `build_all.yml`
run for the branch (`main` by default) and records its commit. |
| Override sweep effect stage (shard 0 and 1) | Runs orca-test-repo's
override sweep with `--effect-full`: every config option that lands on
the CLI is re-sliced on its own to check that it actually changes the
G-code. Split into 2 shards, each with a 60-minute timeout. |
| GUI-vs-CLI parity harness | Slices a set of fixtures in the GUI
(headless under Xvfb) and on the CLI, compares the exports, and scores
divergences against a known-differences ledger. It reports only and
never fails on a divergence. |
## When it runs
- **Every night at 21:00 UTC,** after `build_all.yml`'s 17:00 UTC run
has finished.
- **By hand** through `workflow_dispatch`, with optional inputs:
- `build_branch`: the branch whose latest successful build to test;
- `test_repo_ref`: the orca-test-repo ref;
- `fixtures`: a subset of harness fixtures;
- `cli_presets`: `flat` or `raw`.
- **No `push` or `pull_request` trigger,** so nothing here runs on PRs
or merges. The per-build CI step is unchanged.
## How it tests a build
- **Binary:** the Linux x86_64 AppImage from the chosen `build_all` run.
- **Source:** OrcaSlicer checked out at that run's exact commit. The
AppImage only ships packed preset caches, so profiles and the CLI option
list come from this checkout, matched to the binary.
- **Output:** each job writes a summary to the run page and uploads its
report (`override-report-shard*`, `parity-scorecard`) for 30 days.
- **Failures:** a failing effect shard fails the run, and GitHub's usual
failure notification for scheduled workflows applies.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
- Dispatched on this branch against orca-test-repo `main` and #15693's
build ([run
34933239912](https://github.com/OrcaSlicer/OrcaSlicer/actions/runs/34933239912)).
Every job passed:
- **effect shard 0:** 19m31s; 225 options sliced, 151 effective, none
crashed or hung, every fixture sliced;
- **effect shard 1:** 19m33s; 349 options sliced, 254 effective, same;
- **harness:** 4m32s; all 13 fixtures, 0 new divergences, 0 errors.
- An earlier dispatch on this branch, testing #15693's build against
orca-test-repo's parity branch ([run
34836468900](https://github.com/OrcaSlicer/OrcaSlicer/actions/runs/34836468900)),
passed: effect shards in 20m28s and 23m30s, and the harness reported 0
new divergences.
- The workflow only runs from the default branch on its schedule, so the
nightly trigger itself takes effect once this is merged.
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
Since #15438, every CLI run that loads a system preset spends about a
second per preset file re-parsing that vendor's entire profile tree. A
slice with a machine, process and filament preset got roughly 2.5 s
slower, and a four-filament slice roughly 4 s slower. This PR loads each
vendor tree once per run instead. Resolved presets and G-code are
unchanged.
The GUI never takes this path, and no release contains #15438, so the
regression only affects CLI runs on current dev and nightly builds. That
includes print farms, slicing services and plugins that call
`orca-slicer --slice`, and CI suites.
## Changes
### Why it was slow
`PresetBundle::resolve_preset_config` resolves a system preset through
its vendor manifest by loading the whole OrcaFilamentLibrary bundle and
the whole vendor tree from JSON, then picking the one preset out. The
CLI did that separately for every `--load-settings` and
`--load-filaments` file, on a fresh `PresetBundle` each time. With BBL
presets, a machine + process + filament run opened `BBL.json` three
times and read BBL's 2,879 profile files and the library's 512 three
times over.
### Load each vendor tree once
- `PresetBundle` keeps every vendor bundle its manifest path loads,
keyed by source root, vendor and substitution rule, and reuses them for
later resolutions on the same bundle.
- OrcaFilamentLibrary is cached the same way, so vendors under one root
share a single library load and the library's own presets resolve from
that same instance. A vendor bundle only reads from its base while
loading, so sharing it is safe.
- A failed or throwing load is not kept, so error reporting is
unchanged.
- The key includes the source root, so presets from two different
profile roots still resolve separately.
- The CLI resolves every system preset through one `PresetBundle` for
the whole run, instead of creating one per file.
The resolved configurations still come from the same canonical vendor
loader, so what a preset resolves to does not change. Only the CLI calls
`resolve_preset_config`, so a long-lived GUI bundle cannot end up
holding profile trees that later change on disk.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
CLI slice of a 20 mm cube with X1 Carbon system presets. Both builds get
the same datadir, best of 3, Linux. "Before" is this PR's base from CI.
| System presets loaded | Before | After |
|---|---|---|
| machine | 0.95 s | 0.87 s |
| machine + process | 1.67 s | 0.92 s |
| machine + process + 1 filament | 2.51 s | 0.97 s |
| machine + process + 4 filaments | 5.00 s | 0.99 s |
Files opened during the machine + process + filament run (`strace -e
openat`):
| | Before | After |
|---|---|---|
| `BBL.json` | 3 | 1 |
| `OrcaFilamentLibrary.json` | 3 | 1 |
| `system/BBL/**/*.json` | 8,634 | 2,880 |
| `system/OrcaFilamentLibrary/**/*.json` | 1,536 | 512 |
Peak memory did not rise: max RSS 306 MB → 286 MB for the three-preset
run, and 305 MB → 285 MB for four filaments. The "before" figure is an
AppImage, so part of that gap is probably packaging.
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
- New test "Manifest-backed resolution reuses the vendor tree it already
loaded" in `tests/libslic3r/test_preset_bundle_loading.cpp`. It resolves
one preset, changes the parent profile on disk, then resolves a sibling.
The same bundle returns the value it already loaded, and a fresh bundle
picks up the change.
- New test "Manifest-backed resolution shares the library between
vendors under one root". It resolves through one vendor, changes a
library profile on disk, then resolves through a second vendor and a
library preset on the same bundle. Both return the value already loaded,
and a fresh bundle picks up the change.
- All `[Preset][Bundle]` tests pass (87 test cases, 1,069 assertions),
including the existing manifest-backed resolution cases for source-root
scoping, malformed vendor loads, missing parents and type mismatches.
- G-code of the three-preset slice is identical before and after, header
lines excluded.
- The external CLI regression suite passes. Two cases report as
unexpectedly passing because #15639 fixed their bug. They pass the same
way on this PR's base without the change.
- A GUI-vs-CLI parity run over 10 fixtures shows no new differences.
- Builds clean on Linux (Release, with tests).
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
The manifest resolver loaded OrcaFilamentLibrary once per vendor it
resolved through, so a run that mixes vendors parsed the library tree
again for each of them. The library is now cached like any other vendor
tree, keyed on its root and substitution rule, and doubles as the base
every vendor under that root loads against. A vendor bundle only reads
from its base while loading, so sharing the instance is safe.
The cache key carries the substitution rule as its enum, and the lookup
lambdas take a const bundle since they only read.
`--export-settings` already writes the merged config as JSON at the
right point in the CLI flow. Passing `-` now writes that same document
to stdout, so scripts can inspect the effective config without a temp
file. This replaces #14605.
- `ConfigBase::save_to_json` gains a stream overload. The file overload
serializes through it before opening the file, so the output format is
unchanged, and a config that cannot be serialized (invalid UTF-8) now
leaves the existing file untouched instead of truncating it.
- On stdout, invalid UTF-8 in string values is written as U+FFFD instead
of ending the process with an uncaught `type_error`. Files keep the
strict behaviour.
- To keep stdout pure JSON, `-` is rejected up front (stderr message,
`CLI_INVALID_PARAMS`, shell status 254) when combined with an action or
transform that can write to stdout or does real work: `--info`,
`--help`, `--orient`, slicing and exporting. Options that do nothing
without a slice (`--uptodate`, `--min-save`, `--pipe`, ...) are still
accepted.
- The one unconditional stdout write on a success path, "skip locked
instance" during arrange, now goes to the log.
- Every other value, including the default `output.json`, behaves as
before.
Tests in `tests/libslic3r/test_config.cpp`: the stream output equals the
file output and keeps the tab-indented format; invalid UTF-8 throws on
the strict path and is replaced when asked; a failed save leaves the
previous file intact.
Opening a model with a relative path, for example `orca-slicer ./some.3mf`,
failed with "Loading of a model file failed." and "The file does not contain
any geometry data.", while the same file opened by an absolute path or by
drag and drop worked.
GUI_App::init_app_config() changes the working directory to <data_dir>/log,
and it runs from the GUI_App constructor because the app config is needed
early for instance checking. The input files are opened much later, in
post_init(), so a path still relative at that point resolved against the log
directory instead of the directory OrcaSlicer was started from, and the 3MF
reader failed to open it.
Resolve the input paths in CLI::setup(), which runs before GUI_App is
constructed and therefore before the working directory moves. Absolute paths
are returned unchanged, so the forms that open today are unaffected, and
custom open protocol URLs are passed through since post_init() hands those to
the downloader rather than the file loader.
The working directory change is left alone. It was added in #3248 so the TUTK
logs land in the data directory instead of the working directory (#3209).
The U1's heated bed tops out at 100 °C, but these profiles requested
105-110 °C, which leads to print errors unless the user modifies the
printer's firmware configuration.
Affected profiles:
- Snapmaker ABS @U1 base (110/105 → 100)
- Snapmaker ASA @U1 base (110 → 100)
- Fiberon ASA-CF08 @Snapmaker U1 base (105 → 100)
- Fiberon PPS-GF20 @Snapmaker U1 base (105 → 100)
Bumps Snapmaker.json to 02.04.00.10.
Co-authored-by: yw4z <ywsyildiz@gmail.com>
--export-settings already writes the merged config as JSON at the right
point in the CLI flow. Passing - writes the same document to stdout.
- ConfigBase::save_to_json gains a stream overload. The file overload
serializes through it before opening the file, so the format is
unchanged and a config that cannot be serialized leaves an existing
file untouched instead of truncating it.
- On stdout, invalid UTF-8 in string values is written as U+FFFD instead
of ending the process with an uncaught type_error; files keep the
strict behaviour.
- - is rejected up front when combined with an action or transform that
can write to stdout or does real work, so stdout carries only the
JSON.
- The unconditional "skip locked instance" stdout write during arrange
now goes to the log.
- Tests in tests/libslic3r/test_config.cpp.
* Extract Layer::choose_ironing_extruder for unit-testable ironing routing
The ironing extruder selection in make_ironing() was a 5-line nested
conditional inlined at the top of the loop, with no isolated test
coverage. Pull the gating into a static helper so the routing decision
is unit-testable without spinning up the slicing pipeline.
Pure refactor: the helper preserves the original logic bit-for-bit
(NoIroning -> -1; AllSolid always enabled; TopSurfaces and TopmostOnly
require some top shells or, in spiral mode, more than one bottom shell;
TopmostOnly additionally requires being on the topmost layer; enabled
ironing routes to solid_infill_filament).
Add tests/fff_print/test_choose_ironing_extruder.cpp covering:
- AllSolid regardless of layer position
- TopSurfaces with top_shell_layers > 0
- TopSurfaces with top_shell_layers=0 + spiral mode + bottom_shell_layers>1
- TopmostOnly + topmost layer
- NoIroning short-circuit
- TopSurfaces with top_shell_layers=0 (and not spiral) -> disabled
- TopSurfaces, spiral, but bottom_shell_layers=1 -> disabled
- TopmostOnly on a non-topmost layer -> disabled
* Move ironing routing test into the Fill subsystem file
Rename the test to tests/libslic3r/test_fill.cpp and tag it [Fill] to
match the subsystem it covers, use flat behavioral test cases with
GENERATE for the parameterized ones, and drop the history narration from
the code comments.
* tests: move ironing routing tests into fff_print/test_fill.cpp
Keeps the Fill tests in one file, alongside the existing ironing
rotation-template test.
Cover the two cache paths the first test left open: a vendor tree that fails to load is retried on the next resolution instead of being served from the cache, and a type-probed filament resolved through resolve_preset_config_type reuses the OrcaFilamentLibrary base already loaded for a sibling.
Resolving a system preset through its vendor manifest loaded the whole vendor tree and the filament library from JSON, and the CLI did that separately for every --load-settings and --load-filaments file. A run with machine, process and filament presets parsed BBL's 2,879 profile files and the library's 512 three times over, about a second each.
Keep the library and vendor bundles loaded by the manifest path on the PresetBundle that resolved them, keyed by source root, vendor and substitution rule, and have the CLI resolve every system preset through one bundle for the whole run. A failed load is not kept, so errors are reported as before.
On a cube slice with X1C machine, process and PLA presets: 2.42 s -> 0.93 s, BBL.json opened once instead of three times, identical G-code.
A valid mixed filament already slices the same on the CLI as in the GUI;
these are the places where the CLI still skipped a rule the GUI applies.
- Keep the prime tower when a mixed filament is used, even if every
--load-filaments preset is the same. A mixed filament swaps between its
components every layer, so turning the tower off left the swaps with
nothing to purge on.
- Leave a mixed slot's row and column of the flush matrix at zero when
--filament-colour triggers a recompute, as the GUI does; a mixed slot
never reaches a nozzle.
- Refuse a mixed slot that has no filament of its own. Feature filament
ids aimed at it were past the filament count, got reset to filament 1
and the model silently printed in one colour.
- Refuse a plate that uses a mixed filament whose components are
different filament types, the type half of the GUI's
Sidebar::has_broken_mixed_filament. Missing or out-of-range components
are already rejected for the whole project by validate().
get_extruders_under_cli gains an expand_mixed_slots flag so the gate
can see mixed slots rather than their components; existing callers
keep the expanded list.
Both refusals exit with the new CLI_MIXED_FILAMENT_INVALID (-69).
update_values_to_printer_extruders_for_multiple_filaments picks each
filament's value from the flattened (filament x variant) columns of every
per-filament variant option. When a column index fell past the end of the
option's values, it skipped that filament and left the zero the output
vector was created with.
The GUI always hands this function full columns, but the CLI does not:
- a CLI override of a single value, such as --nozzle-temperature=211 on a
four-filament project, came out as 211,0,0,0, so three filaments would
print at 0 C;
- loading fewer filament presets than the project has filaments left the
remaining filaments' columns missing, so filament_cooling_before_tower
came out as 10,10,0,0 and filament_ramming_volumetric_speed as -1,-1,0,0.
An out-of-range column now keeps the option's first value, the fallback
get_at() and the sibling gather step already use. The seven per-type copies
of the loop are replaced by that same gather_option_values helper, moved
above the function; it now takes its caller's name for its log lines. An
empty option, which has no first value, is given one registered default per
filament first; it used to be replaced with zeros.
On a partial load a filament whose preset was not loaded takes the first
filament's value rather than its own preset's, which the CLI does not load;
for the options seen in practice those agree.
Runs orca-test-repo's full override-sweep effect stage (two shards) and the GUI-vs-CLI parity harness every night against the latest successful build_all Linux AppImage, with sources checked out at that build's commit. Kept out of the per-build regression step, whose time budget it would exceed, and never gates a build.
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
Adds a really basic API to push notifications to the plater.
Plugin used in demo:
[plater_notification.py](https://github.com/user-attachments/files/31293074/plater_notification.py)
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
<img width="2172" height="1241" alt="image"
src="https://github.com/user-attachments/assets/540319ca-a11a-4b48-9b80-82fb6b0849d9"
/>
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
* CLI: record command-line overrides in different_settings_to_system
Settings passed on the command line (--sparse-infill-density 25% ...) override
the loaded presets when m_extra_config is applied to m_print_config, but nothing
recorded them in different_settings_to_system. The exported project therefore
carried the new value with no mark that it was modified, and re-opening it in the
GUI reverted it to the system preset's value -- the same failure the preset-leaf
diff fixes for user presets, via a different source of override.
The key set comes from m_config, not m_extra_config. read_cli() puts only what the
user typed into m_config and setup() adds nothing but CLI-own defaults (none of
the keys run() materialises there is a preset option), whereas the CLI writes its
own values into m_extra_config (has_filament_switcher, filament_colour,
filament_map ...), which must not be reported as user overrides.
Values are snapshotted just before the apply and only keys the override actually
changed are recorded: a typed value equal to the loaded one modifies nothing, and
listing it would read as a spurious difference against what the GUI writes. Each
key lands in the column(s) whose preset type owns it -- process, every filament,
printer -- and a key already present is not duplicated. Keys no preset owns
(curr_bed_type, a project setting) land nowhere, as in the GUI.
Follow-up to #15595, split out at review.
* CLI: judge command-line overrides the way the value is read
Review follow-ups on the override recording:
- Lists were compared as whole serialized strings. read_cli() builds a fresh
one-entry list, so --nozzle-temperature 245 against 245,245,245 on a
three-filament project was recorded in every filament column although nothing
changed. Lists are now compared entry by entry with a missing entry read as the
first, as get_at() reads it (and as resize() pads).
- The log line fired for every changed key, including ones no preset owns
(curr_bed_type) and which therefore land in no column. It now fires only when a
column took the key.
- m_print_config.has(key) straight after apply(m_extra_config, true) was always
true, both configs sharing print_config_def; removed. columns.size() >= 2 also
always holds after the resize to filament_count + 2 -- different_settings_to_system
is not a CLI option, so nothing in between can shrink it -- but that rests on code
far away, so it stays a plain check rather than an assert: release builds compile
asserts out, and a _GLIBCXX_ASSERTIONS build would abort on columns[0].
Deliberately NOT done: comparing a key the loaded config lacks against its
built-in default. On reopen the GUI restores an unlisted key from the SYSTEM
preset, not the default. A 3MF written before an option existed leaves it absent
here, so --sparse-infill-density 20% (the default) against a Prusa system 15% would
go unrecorded and be reverted to 15%. Absent keys stay always-recorded:
over-recording is cosmetic, under-recording loses the value. Verified that such a
key really is absent at this point, rather than filled from the system preset.
Reported by HanifKoh and raistlin7447 in review of #15642.
* CLI: evaluate compatible_printers_condition in the compat checks
Slicing from the CLI with --load-settings exits with
CLI_PROCESS_NOT_COMPATIBLE (-17), "The selected printer is not compatible
with the process preset in the 3mf.", for process/printer pairs the GUI
accepts. Reproducible with stock, unmodified Prusa system profiles:
orca-slicer --datadir <datadir> \
--load-settings "<datadir>/system/Prusa/process/0.20mm SPEED @CORE One HF 0.4.json;<datadir>/system/Prusa/machine/Prusa CORE One HF 0.4 nozzle.json" \
--load-filaments "<datadir>/system/Prusa/filament/Prusament PETG @CORE One HF 0.4.json" \
--slice 0 --outputdir /tmp/out model.stl
The four compat checks in CLI::run did a literal name match against the
`compatible_printers` list only:
for (index ...) if (new_print_compatible_printers[index] == new_printer_system_name)
process_compatible = true;
Process profiles that declare compatibility through
`compatible_printers_condition` and leave `compatible_printers` empty are
therefore always reported incompatible -- the condition is never consulted.
For 0.20mm SPEED @CORE One HF 0.4 that condition is:
printer_notes=~/.*PRINTER_MODEL_COREONE[^_a-zA-Z0-9].*/ and
nozzle_diameter[0]==0.4 and printer_notes=~/.*HF_NOZZLE.*/
The GUI does not have this bug: is_compatible_with_printer() in Preset.cpp
treats an empty list as "no explicit constraint" and evaluates the
condition in that case.
Fix: replace the four loops with a check_compat lambda that calls
is_compatible_with_printer() -- the same helper the GUI uses -- wrapping
the already-loaded DynamicPrintConfigs in lightweight Preset /
PresetWithVendorProfile shells. The 3MF-embedded process/printer full
configs are kept in current_process_full_config /
current_printer_full_config so the condition can be evaluated for the
reprocess paths too; those fall back to the previous literal match when
the full config was not preserved.
Behaviour is unchanged where an explicit compatible_printers list exists:
is_compatible_with_printer() performs the same name match, and returns
true when both list and condition are empty, matching the existing
"old 3mf, no compatible printers, set to compatible" path.
Split out of #13731 (section 1) as a standalone, single-purpose change.
Orthogonal to the inherits-chain resolution work in #14718 / #15302 /
#15438; those decide which values a preset resolves to, this decides
whether the resulting pair is considered compatible.
* CLI: translate the 3MF's renamed compatibility keys before the compat check
The 3MF fallback fed the project config to is_compatible_with_printer() as-is,
but a project config does not carry compatible_printers or
compatible_printers_condition. PresetBundle::construct_full_config() erases both
and re-emits them as print_compatible_printers and
compatible_machine_expression_group; they are renamed back only on the
PresetBundle load path, which the CLI does not take. The check therefore saw no
list and no condition, read that as 'no constraint' and accepted every printer.
That is not just a wrong accept. An early true skips the !process_compatible
block that sets machine_switch, so the new printer is never appended to
print_compatible_printers and the exported 3MF stays marked compatible only with
the printer it came from -- which is exactly what that block exists to prevent.
Translate the two keys back before the check. Index 0 of the expression group is
the print preset; the group is filled print, filaments, printer.
Also note in the comment that profiles/BBL/{process,machine}_full/ are gitignored
and generated by nothing in-tree, so current_*_full_config is always empty and
this fallback is the only live path -- not the rare non-BBL case the original
comment implied.
Reported with measurements by HanifKoh in review of #15449.
Preset: add a config-level is_compatible_with_printer() overload
The CLI holds resolved DynamicPrintConfigs, not Presets, so it wrapped them in
throwaway Preset shells at the call site. Moving that into Preset.cpp puts the
compatibility policy -- including the documented fail-open on a malformed
compatible_printers_condition -- in one place for the GUI and the CLI, rather
than leaving a second copy of the plumbing in OrcaSlicer.cpp to drift.
Purely additive: neither existing overload changes, so no GUI behaviour moves.
Requested by HanifKoh in review of #15449.
(cherry picked from commit 14ca1972ef4d3c7d90935d159423013a40a6bd70)
* CLI: never overwrite a real compat key with an empty renamed one
7e7f0e3 translated compatible_machine_expression_group[0] into
compatible_printers_condition whenever the group vector was non-empty. A project
the CLI exported itself carries the real compatible_printers_condition AND an
all-empty group, ["", "", ""], so the valid condition was overwritten with
"", the check saw no constraint, and every printer was accepted.
That fixed GUI-shaped projects and broke CLI-shaped ones. Bisected across six
builds re-slicing one CLI-exported CORE One project with an MK4S: every build
before 7e7f0e3 gives 'compatible 0' and takes the machine-switch path; with it,
'compatible 1' and no switch.
The raw keys now win whenever they carry something; the renamed ones are only a
fallback, and an empty value is never written over a real one. Same for the list:
print_compatible_printers is used only when compatible_printers is absent or
empty and it itself is not.
Found by a peer session re-testing the installed build.
* CLI: record user overrides in different_settings_to_system for 3MF export
Three sites in CLI::run wrote an empty `different_settings_to_system` column
and left a //todo:
//todo: support user machine preset's different settings
different_settings[filament_count+1] = "";
//todo: support system process preset
different_settings[0] = "";
//todo: update different settings of filaments
different_settings[filament_index] = "";
So a 3MF exported by the CLI does not record which keys the user actually
overrode relative to the system parent. Re-opening such a project in the GUI
then shows spurious "unsaved changes", and accepting that dialog can revert
inherited process/filament/machine values to system defaults.
The column could not be filled before because the CLI had no resolved view of
the parent preset. It does now: #15438 builds a PresetBundle for inherits
resolution, so the parent can be looked up by name and diffed against the
resolved leaf. This adds no extra loading -- the bundle is the one already
built, and the helper returns "" whenever it is unavailable or the parent
cannot be found, which is the previous behaviour.
Preset metadata is filtered out of the diff: `inherits`, the three
`*_settings_id` keys, and `compatible_printers` / `compatible_prints` and
their `_condition` variants, which have their own tracking columns
(`inherits_group`, per-slot lists) and would otherwise double-count.
A value already carried by the loaded JSON still wins for the process slot, so
presets saved with a `different_settings_to_system` field behave as before;
the computed value only fills the gap where that field is absent, which is the
case for every user preset in my datadir (0 of 47 carry it).
System presets keep an empty column: there are no user overrides to record.
* CLI: diff the filament slot before load_default_gcodes_to_config
The process and machine slots compute their different_settings_to_system column
before load_default_gcodes_to_config(); the filament slot did it after. That
call materialises absent gcode keys via option(..., true), and
DynamicConfig::diff only compares keys present in both configs -- so a gcode key
the resolved leaf did not carry would go from 'not compared' to 'compared as
empty against the parent' and land in the column as an override the user never
made.
Hoisted into a local above the call, guarded by load_filament_count > 0 so the
work is skipped exactly where it was before, and assigned at the original site.
The diff now also runs before config.erase("filament_settings_id"), which is
immaterial: cli_different_settings already filters filament_settings_id along
with the other *_settings_id keys.
This is a consistency fix rather than a demonstrated defect -- resolve_preset
merges the parent config, so in practice the gcode keys are already present on
both sides and the diff is unaffected. It removes the dependence on that
invariant, which the other two slots never had.
Reported by HanifKoh in review of #15595.
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
Every CI build leg compiles the whole tree from scratch: 42 to 57
minutes of each build job, on every push and every pull request, roughly
200 runs a week. This PR caches the compiled objects with ccache so that
a run only compiles what changed since the last push to main. With a
warm cache the compile steps take 1 to 4 minutes on all six legs and a
pull-request run finishes in about 30 minutes instead of 75.
Three prerequisites landed last week and made this measurable: #15537
took `GIT_COMMIT_HASH` off the compile line, #15552 made a build without
the precompiled header work on Windows, and #15501 stopped the Flatpak
job from rebuilding its dependencies.
## Changes
### Compiler cache in `build_orca.yml`
Each build leg (Linux x86_64/aarch64, Windows x64/arm64, macOS
arm64/x86_64) restores a cache entry keyed by that leg, compiles through
`ccache` via `CMAKE_<LANG>_COMPILER_LAUNCHER`, and prints its hit
statistics at the end of the job. The macOS universal combine does not
compile and is left out.
Who writes the cache is the important part. Cache entries are immutable
and a restore always takes the newest matching one, so every save is a
new entry that is never read again once a newer one exists. Therefore:
- **Pushes save.** After a successful save, the older entries for the
same leg on the same ref are deleted, so a branch holds exactly one
entry per leg. The save comes first, so a failed save leaves the
previous entry in place.
- **Pull requests restore only.** They read main's entries (GitHub lets
a PR read the base branch's caches) and keep nothing. Saving from PRs
would add about 6 GB per run that no other run can read.
The store is therefore a flat ~7 GB (one entry per leg: Linux ~1 GB,
Windows ~2 GB, macOS ~0.6 GB), not a growing one. The
`hendrikmuhs/ccache-action` only installs and configures ccache; restore
and save go through `actions/cache` with one path string, because the
cache service only matches entries saved under the identical path and
the action spells it differently on Windows. A failed ccache install
falls back to an uncached build rather than failing the job.
### Precompiled header off when the cache is on
With `SLIC3R_PCH` left on, a warm cache hit only 19 % of compiles: Clang
stamps the PCH with the build time, CMake does not pass
`-fno-pch-timestamp`, and everything that includes the PCH (libslic3r
and libslic3r_gui, ~750 files) missed every run. `build_linux.sh -p`
exists for exactly this reason. The workflow now exports
`ORCA_EXTRA_BUILD_ARGS=-DSLIC3R_PCH=OFF` whenever ccache is enabled,
which brings the warm hit rate to 98.4–98.9 %.
The cost is on cold compiles, which are 25–60 % slower than today's PCH
build (ccache preprocesses every miss before compiling it, and the miss
compiles without PCH). Main pays this once after an image update or a
wide header change; PRs pay it only for the files their change
invalidates. A change to a header included by half the tree
(`PrintConfig.hpp`, `Preset.hpp`, `Model.hpp`) lands a run at 1.2–1.9×
today's time. `ccache`'s depend mode would remove the preprocessor pass
and is the natural follow-up.
### Includes the precompiled header was supplying on macOS
A build without PCH had never been tried on macOS. Three files used what
`pchheader.hpp` happened to include: `LocalesUtils.cpp` needs
`<sstream>` and `<iomanip>`, and `AmsMappingPopup.cpp` /
`PhysicalPrinterDialog.cpp` need `<wx/tooltip.h>`. libstdc++ and the GTK
wx port pull these in transitively; libc++ and the Cocoa port do not.
This is the macOS counterpart of #15552 and is worth merging on its own.
### `ORCA_EXTRA_BUILD_ARGS` pass-through
`build_linux.sh` already forwarded this variable to the slicer
configure. `build_release_macos.sh` now reads it into an array
(shellcheck-clean), and `build_release_vs.bat` appends it on both
configure lines, so CI can add a CMake option without editing three
scripts.
## Behaviour reviewers should know about
- **Main-only cache writes need `actions: write`** on the workflow token
to delete the previous entry. The default token already has it (the
nightly deploy steps write with it), so no `permissions:` block was
added. A fork PR's read-only token never reaches the delete step.
- **A runner image update cold-starts the cache** as configured, because
ccache keys the compiler by its mtime and every image rebuild reinstalls
it. Images updated 20260819 → 20260828 during this work, about every one
to two weeks. Keying on the compiler version string (`compiler_check`)
would avoid that; left as a follow-up since it changes every hash.
- **What is now the critical path:** the two Flatpak jobs (46–66 min,
untouched here), the orca-test-repo regression suite run inline in the
Linux job (7 min), and NSIS/PDB/MSIX packaging on Windows (6 min). Those
are the next wins.
- **Open question:** CI still drives `build_release_vs.bat`. #15552 gave
`build_win.bat` a `--cache ccache --no-pch` option; moving the Windows
job onto it would replace the batch-file change here.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
Compile step of each build leg, minutes. Main's numbers are from run
34324625046.
| Leg | main | cold, PCH on | warm, PCH on | cold, PCH off | warm, PCH
off | ~50 % of headers changed | 5 source files changed |
|---|---|---|---|---|---|---|---|
| Linux x86_64 | 48 | ~75 | (19 % hits) | ~110 | **2.6** | 91.3 (452/928
misses) | 3.4 |
| Linux aarch64 | 41.7 | 53.4 | 52.2 (178/927 hits) | 58.8 | **2.5** |
55.8 (452/928) | 2.9 |
| Windows x64 | 57 | 85.5 | — | ~105 | **2.4** | 76.8 (449/974) | 2.5 |
| Windows arm64 | ~45 | 64.4 | — | ~78 | **4.3** | 59.6 (450/974) | 4.2
|
| macOS arm64 | 51 | ~71 | — | — | **0.8** | 79.7 (453/947) | 0.9 |
| macOS x86_64 | ~43 | 70.2 | — | — | **1.0** | 68.1 (411/742) | 1.0 |
Warm hit rates: 98.4–98.9 % on every leg; the 11–14 misses are what any
commit changes (version stamp and its includers). The "50 % of headers"
column is a real event: #15251 and #15416 merged into main between two
runs, changing 20 headers that reach 453 of 870 translation units.
Whole run, before and after (a pull-request run; wall clock to the last
non-Flatpak job):
| Job | main (run 34324625046) | warm cache (run 34444305385) | what
remains |
|---|---|---|---|
| Windows arm64 | 50.0 | 15.7 | compile 4.3, NSIS 3.5, cache save 1.6,
deps restore 1.1, cache restore 1.0 |
| Windows x64 | 67.4 | 13.2 | NSIS 3.2, PDB 2.6, compile 2.4, MSIX 0.5 |
| Linux x86_64 | 57.5 | 12.6 | orca-test-repo regression 7.6, compile
2.6 |
| macOS x86_64 | 46.9 | 6.1 | free disk space 2.3, compile 1.0 |
| Linux aarch64 | 43.9 | 4.6 | compile 2.5, apt 0.9 |
| macOS arm64 | 54.9 | 4.4 | free disk space 1.7, compile 0.8 |
| macOS universal | 7.7 | 2.2 | signing and notarisation only on main |
| Flatpak x86_64 / aarch64 | 66.6 / 46.5 | unchanged | full compile
inside flatpak-builder |
| **Wall clock** | **75 min** | **31 min** (Flatpak excluded; 66 with
it) | macOS runner queueing now exceeds job time |
Cache storage: one generation per leg is 400–680 MB compressed at PCH
on, 0.6–2 GB at PCH off; six legs ≈ 7 GB. Without the delete step, 21
main pushes a week would hold ~80 GB of entries that are never read.
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
- Thirteen CI runs on this PR, one change per run, with the ccache
statistics printed by every leg: cold (34336272234), warm with PCH
(34346737197), cold and warm without PCH (34352209577, 34364791732), the
macOS include fixes (34435044411, 34435968806 with `ninja -k 0` to list
every remaining file, 34439532375), all legs warm (34444305385), the
keep-only-newest cleanup (34450381312, then 34452640274 after the
Windows CRLF fix), the half-tree invalidation (34452640274), the
five-file change (34463517683, 34464720539), and this final shape
(34466377763, restore-only).
- Unit tests on all five platforms, the profile slice check, the Windows
build-script suite, Shellcheck and the universal DMG build all pass on
the cached binaries.
- The cleanup was verified against the PR's own cache scope: 44 entries
from the earlier runs reduced to exactly one per leg, on all three
platforms, after fixing the CRLF that made `gh cache delete` fail on
Windows.
- A libc++ syntax-only pass over all 1986 C++ translation units on Linux
found the `LocalesUtils.cpp` include; the two wx includes only surface
in a real macOS build and were found with a keep-going build in one
round.
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
A miss used to cost a preprocessor pass for the hash and then the real
compile. With the depend mode ccache hashes the include list the
compiler reports, so a miss costs only the compile. Ninja already asks
every compiler here for that list.
Clang records the modification time of every input in the precompiled
header, so a fresh checkout produces a different header and every file
that includes it misses the compiler cache. -fno-pch-timestamp makes the
header reproducible, and pch_defines lets ccache cache the header itself.
The precompiled header no longer has to be turned off when the cache is
on.
Every CI leg compiled the whole tree from scratch, 42 to 57 minutes of
each build job. Objects are now cached with ccache, one entry per leg
kept on the branch that built it: a push saves the cache and drops the
previous entry, a pull request restores main's and keeps nothing.
The precompiled header is turned off whenever the cache is on: Clang
stamps it with the build time, so every file including it missed. With
it off, a warm run hits 98.5 to 98.9 % of compiles and the compile steps
take 1 to 4 minutes; a cold run costs 25 to 60 % more than before, and a
change to a widely included header lands in between.
Hanif Koh