Off Apple the xz container was unpacked by running /usr/bin/env xz,
which Windows has no answer for: Process reports that the file does
not exist, and the message reaches the user as it stands.
Decode in-process instead, the way Compression already does on
Apple, and ask for the library the platforms package.
Drop the Monaco webview. Edit in a GtkSourceView on GTK and in a
native text view on Apple, both speaking to Frida.Compiler's
in-process language server for completions, signature help,
hovers and diagnostics.
Color, complete and indent code natively, matching the GitHub
theme in light and dark.
Bootstrap provisions Frida, radare2 and the Pharo VM at their pinned
revisions and skips what is present, so a re-run resumes. The Windows
CI job drives it a component at a time. Build from a plain shell via
vcvars, and order the prefixes so a stale Frida cannot win the load.
Resolve PHARO_PREFIX alongside the vcpkg, frida-core and radare2 ones,
so pkg-config finds pharo-vm and run.ps1 finds its DLLs. Document
building it from frida/pharo-vm.
Drop build.ps1's agent bundle pre-run: it writes into
Sources/LumaCore/Generated, which the manifest excludes outside Xcode,
so LumaBundlePlugin is what feeds the build.
The app builds and runs on macOS 15.0 since the deployment target
was lowered in 375d4c5. Xcode 26 also ships without the Metal SDK
by default, so call that out next to the Xcode requirement.
Fan both platform jobs out so Luma is built for:
* macOS on macos-26 (arm64) and macos-15-large (x86_64)
* Windows on windows-latest (x64) and windows-11-arm (arm64)
fail-fast is disabled so one failure doesn't mask the other. For
Windows arm64 the frida-core configure disables the Go-based
compiler backend, since no arm64 MinGW toolchain is available on
hosted runners yet. package-msi.ps1 takes a new -Arch parameter
that feeds WiX candle and names the output Luma-<version>-<arch>.msi
accordingly.
Also convert run.bat to run.ps1 for consistency with build.ps1 and
package-msi.ps1 (and update README + setup-env.ps1 references).
FridaCore's shim.h pulls in frida-core.h, which in turn includes
json-glib/json-glib.h and libsoup transitively. vcpkg installs both
under versioned include subdirectories, so add them to CPATH in
setup-env.ps1 and the Windows CI env setup.
Also move run.bat under scripts/windows/ alongside build.ps1 and
package-msi.ps1; asymmetric layout surprised the user. The relative
path to .build/<mode>/LumaGtk.exe shifts up two levels accordingly.
Workspace is now a thin host adapter. Engine owns sessions and
notebook entries (via store observation), GitHub auth + OAuth
device flow, hook-pack discovery, address annotations and address
actions, the disassembler cache, and all instrument lifecycle.
EventLog is @Observable so SwiftUI tracks it directly; the host
no longer mirrors event arrays or version counters.
R2 (live disassembly + trace inspection) lives entirely in
LumaCore as concrete Disassembler / TraceDisassembler classes
returning portable StyledText spans. ProcessNodeViewModel and
InstrumentRuntime are gone; views read engine.processNodes /
node.instruments / engine.descriptor(for:) directly.
Reorganize Luma/Models/ — instrument UI dispatch lives under
Luma/Instruments/, Monaco editor glue under Luma/Editor/, and the
remaining UI types sit at the top of Luma/.
- Switch `frida-swift` to Swift Package Manager dependency
- Use remote dependency for `SwiftyMonaco` instead of local checkout
- Add `Makefile` for convenient command-line builds
Ole André Vadla Ravnås