frida-core now reads a kernel once and answers what it names, so the
image config carries that rather than a path, and the vsock probe asks
it for the symbol instead of searching the image for the word.
That probe was never a symbol lookup: kallsyms stores its names
compressed, so the match came from whatever else in the kernel happens
to spell vsock. It took an LZ4 inflater of its own to look, which goes
with it.
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 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.
frida-swift to 141d200c, which carries FridaCore 17.18.0. frida-core
to 0602e5dc and radare2 to 84e28a44 for the Windows and Linux builds.
GRDB 7.11.1, swift-asn1 1.7.2, Sparkle 2.9.6.
frida-swift resolves the main context off a worker thread, a halted
guest can be let go, and a script that errors or overflows its stack
no longer takes the guest down. Fetch the matching barebone agents
from the 17.17.1-barebone lineage.
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.
Nothing on that path ever built one, so the bridge compiled against a
header no pkg-config could point at. Building it there took a VM that
speaks MSVC rather than pthreads, a generation VM for ARM64, and a
prefix named in every dialect of path the toolchain reads -- one
pinned bridge at the end of it, rather than the dozen the search took.
No distribution packages one, so SwiftyPharo asks pkg-config and
the Makefile builds a VM into .build when nothing answers. CI keeps
it in a prefix of its own and finds it again at run time.
The Meson-built VM replaces the CMake one, which brings the plugin
and boot fixes with it.
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.
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.
A mark's body opens as a view attachment on its own line under it,
with the rest of the send carried below, so the code reflows around
it rather than stacking under the editor. Snippets reorder and copy;
a graph or chart draws offline from its snapshot.
Draw mondrian graphs and GtPlotter charts as views rather than
pictures: bars, lines, scatter and composites, labelled axes, nodes
and points that select, walk by key, and drill.
A compile error reads in words with a dot at the failing spot.
Evaluate splits from evaluate-and-inspect, the snippet spins while
it runs, and print it, format and browse sit on GT's keys.
Snippets share their variables across runs and evaluate from the
keyboard, a page can be maximized, an empty one says what it is for,
and the columns beside it head and size their own lists.
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.
Move to the single cmd that returns an R2CommandResult with an
optional output, and handle the nil that r2 yields for commands
with no string result (e.g. an invalid command from completion).
Bump the SwiftyR2 pin to the revision with that fix.
runCommand and decompile now return R2CommandResult so callers
can see r2's log entries. r2_cmd surfaces them to the agent;
findFunctionStart treats any error log as no result.
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
