The emulator's control channel was the only thing pulling grpc-swift
in, and with it swift-nio-ssl, which does not build on Windows at all
-- it has no branch for the platform and its PosixPort reaches for
mlock, lstat and readlink. Nothing here wants TLS: the endpoint is
plaintext on the loopback, and only seven calls are ever made.
So the wire is spoken directly. GRPCConnection opens one HTTP/2
stream per call over swift-nio-http2 and frames length-prefixed
protobuf into it; EmulatorControlClient names the seven. That drops
grpc-swift-2, grpc-swift-nio-transport, grpc-swift-protobuf and
swift-nio-ssl from the graph, along with 7840 lines of generated
service stubs. The generated messages stay.
The rest is what running it on Windows turned up:
- AVD discovery split on "\n" and trimmed only .whitespaces, so
every name kept a trailing \r and every AVD was dropped.
- An AVD config spells its paths with backslashes, which URL keeps
as ordinary characters rather than separators.
- emulator and adb want .exe, and the SDK sits under LOCALAPPDATA.
- Port reservation and process lookup move into HostPort and
HostProcessLookup, which QemuMachine's two copies also wanted.
- The launcher re-execs into QEMU there, so the discovery ini is
named after that process; the one naming this launch's debug port
is taken when the launcher's own is absent.
Frames still arrive through a mapping rather than the socket:
CreateFileMapping backs the same file:// handle the emulator is
handed elsewhere.
A guest without vsock is refused outright on Windows, where the
virtio-serial fallback would ask QEMU for a QMP UNIX socket and be
told "unix sockets are not available on windows".
LUMA_EMULATOR_DISPLAY_ONLY drives launch, control and streaming
without a guest agent. Against a Pixel_2 AVD it reports a 1080x1920
first frame and nine more in three seconds.
Drive the whole Android-emulator path headless -- launch an AVD, inject
the barebone agent, run one script -- for a fast feedback loop without
the UI. Links a local frida devkit named by LUMA_FRIDA_DEVKIT.
Drive the emulator's gRPC control API: stream its screen into an
embedded display through a shared-memory frame transport sized from the
device's reported resolution, re-opened when a notification says it
changed; forward pointer and key input; and take ready snapshots with
the SnapshotService.
Boot a QEMU guest headless the way the app does -- download the
starter images and the barebone agent on demand, boot, inject, run one
script -- for a fast feedback loop without the UI, and to see the
connection stages and their timings as they arrive.
Off Apple this ran /usr/bin/env gzip, which Windows answers the way
it answered xz: no such file. The Alpine arm64 kernel is gzipped, so
that starter image could not be unpacked at all.
Drop the gzip packaging with it -- no template asks for it, and the
kernels that are wrapped come through LinuxKernelImage.
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.
QEMU's virt machine puts PCI configuration space where nobody
can guess, so the agent is told where; the kernel's own console
driver takes the port the hostlink wants, so it is kept out.
Work on frida-core itself is picked up through FRIDA_SWIFT_ROOT,
the way the Pharo VM and the shader toolchain already are.
Add a machine abstraction to LumaCore, with QEMU as its first
backend: templates mirroring frida-core's test guests, a QMP client,
and a display that maps QEMU's surface over D-Bus rather than
copying frames.
Leave readiness to the user: drive the guest, mark it ready, and come
back to that snapshot later. Keep the machine in the project, so
booting it again resumes where it was marked. Hand the stub to
addBareboneDevice, so it joins the picker beside the other devices.
Show the display while booting, and afterwards in a Machines panel,
which the side panel now models as an enum to share its slot.
The playground, the notebook cells, the source editor with its
marks, the inspector columns and the canvas are written once for
both Apple platforms, with a file naming what the two frameworks
call differently. The editor is where they really part company.
The engine owns the image and its start-up, so a mission reaches
the whole of Pharo.
The example catalogue is Smalltalk inside Swift string literals,
which no compiler reads: parse each one in the image and report the
syntax errors, the names nothing defines and the selectors nothing
implements. Play every patch offline. Draw the effects and a
lettered scene offscreen and write a PNG of each, since what goes
wrong in drawing is blank frames and mirrored glyphs.
Play a snippet in a canvas for a while and report what the process
holds as it goes, and let go of what the image lets go of.
glslang and SPIRV-Cross build under neither SwiftPM nor Xcode, so
CI makes them into an xcframework and publishes it against a tag.
The manifest names that artifact; a build downloads it and needs
nothing local.
A scene the image holds by handle and changes; the host draws it.
Each drawable carries its own vertex and fragment stages, its own
attribute layout, named uniforms, buffers, a transform and a
visibility flag -- described as objects rather than staged globals.
A value says what it should do, ramp or oscillate, rather than what
it is each frame: nothing crosses per frame, since the image has no
business in the frame path any more than in the audio callback.
Both renderers work it out on the clock that draws it.
Eight channels, each with its own patch and pattern on its own step
clock, mixed on the audio device's thread: storage allocated once,
reached through unsafe pointers, and a lock-free ring for control,
so nothing under the callback allocates, retains or locks.
The image performs a tune, names it, and sounds chords.
Write each effect body-only against a preamble the host supplies,
and let the build systems generate what each renderer needs -- a
Swift catalog for OpenGL, a Metal fragment function through glslang
and spirv-cross. Effects react to arriving events.
The image asks the host about its sessions and its event stream and
gets records back, a cell per column, declared the way GT declares
them -- not lines it would have to parse.
Boot the VM against a bundled image, evaluate from a notebook cell
or a playground snippet, and keep what each evaluation produced.
The image is staged on every build; the framework release is pinned.
CSoup system library + libsoup-backed MCPServer impl behind
canImport(CSoup). Apple keeps Network framework. Same public
API; soup_server_message_pause/unpause carries the approval
await across the request boundary.
Ubuntu 26.04's distro Swift is 6.1.3, and SwiftPM refuses to
parse a manifest declaring a higher tools version than the
installed toolchain. Drop from 6.2 to 6.1 and switch
.iOS(.v26) to .iOS("26.0") since PackageDescription 6.1 has
no .v26 enum case. Verified both Package.swift manifests parse
on Swift 6.1.3 in an ubuntu:26.04 container.
The Xcode project already required IPHONEOS_DEPLOYMENT_TARGET
26.0, but Package.swift's platforms list said .v18 and the CI
matrix passed --with-apple-min-os=ios=18.0. Align all three on
iOS 26 so the SwiftPM resolution, the IPA's LC_BUILD_VERSION
minos, and frida-core's iOS slice match the Xcode setting.
Bump swift-tools-version to 6.2, since .v26 is gated behind
_PackageDescription 6.2.
Fold matrix.min_os into the frida-core devkit cache key so the
iOS slices invalidate on min_os bumps; otherwise a same-SHA
build would silently restore the previous iOS-18-built devkit.
CollaborationSession is now @Observable. Views read its
state directly via workspace.engine.collaboration. The
notebook entry methods live on Engine. The portal cert
is a LumaCore SwiftPM resource via Bundle.module.
Workspace keeps only the auth-flow glue (showing the
sign-in sheet, signOut clearing UI state) and the deep
link join handler.
Split UI-coupled types into portable data (LumaCore) and
platform-specific editor profiles (Luma):
- TracerConfig: data struct + template stubs to LumaCore,
TracerEditorProfile stays with SwiftyMonaco in Luma
- CodeShareConfig + CodeShareProjectRef to LumaCore,
CodeShareEditorProfile stays in Luma
- CodeShareService: drop ObservableObject, move as
stateless enum with async methods to LumaCore
- HookPack: data struct to LumaCore, discovery stays
Add swift-crypto dependency for cross-platform SHA256.
Add FoundationNetworking import for Linux URLSession.
Lay the groundwork for a GTK/Adwaita frontend by extracting
shared infrastructure into a LumaCore Swift package. Agent
sources and LumaBundleCompiler move to top-level locations
so both the Xcode project and SPM can reference them.
New structure:
- Package.swift: root manifest with LumaCore lib + compiler
- Sources/LumaCore/: engine, persistence, models, and
platform-abstracted token store
- Sources/LumaBundleCompiler/: moved from LumaBundleCompiler/
- Agent/: moved from Luma/Agent/
- LumaGtk/: skeleton GTK app package
