This is memory that's loaded from an inode (file) but not modified in
memory, so still identical to what's on disk. This kind of memory can
be freed and reloaded transparently from disk if needed.
Dirty private memory is all memory in non-inode-backed mappings that's
process-private, meaning it's not shared with any other process.
This patch exposes that number via SystemMonitor, giving us an idea of
how much memory each process is responsible for all on its own.
Commit 0b50133 makes use of flock command inside makefiles.
Unfortunately it's not a core macOS command, so it must be installed explicitly using brew.
Palette is now a value wrapper around a NonnullRefPtr<PaletteImpl>.
A new function, set_color(ColorRole, Color) implements a simple
copy-on-write mechanism so that we're sharing the PaletteImpl in the
common case, but allowing you to create custom palettes if you like,
by getting a GWidget's palette, modifying it, and then assigning the
modified palette to the widget via GWidget::set_palette().
Use this to make PaintBrush show its palette colors once again.
Fixes#943.
The dependency tracking still doesn't need any specific ordering to
build, but it's better to build DevTools and Libraries first so it
doesn't try to build two Applications that each need to wait for
libraries to be built, wasting a make child sitting around trying to
acquire the lock on the library directory.
Build them if they don't exist, but don't care about them being
newer or older than the target.
I believe this is what was causing build loops where IPCCompiler was
being run a second time, rebuilding its .h file, then a library
would depend on that .h file and get re-archived, then an
application would need relinking, and something in that whole
process would trigger IPCCompiler running again touching its .h
file.
Lock each directory before entering it so when using -j, the same
dependency isn't built more than once at a time.
This doesn't get full -j parallelism though, since one make child
will be sitting idle waiting for flock to receive its lock and
continue making (which should then do nothing since it will have
been built already). Unfortunately there's not much that can be
done to fix that since it can't proceed until its dependency is
built by another make process.
When filling in some missing part of a window (typically happens during
interactive window resize) we now use the ColorRole::Background from
the system theme palette instead of expecting the clients to send us
the same information when creating windows.
WindowServer now tracks whether windows are occluded (meaning that
they are completely covered by one or more opaque windows sitting above
them.) This state is communicated to the windows via WindowStateChanged
messages, which then allow GWindow to mark its backing store volatile.
This reduces the effective memory impact of windows that are not at all
visible to the user. Very cool. :^)
This program takes JSON input and turns it into JavaScript statements
that construct the same data step by step. This format is much more
greppable than what "jp" gives us. :^)
Tests fail to compile for a mix of reasons, some due to macOS file systems being by default case-insensitive and some specific to clang. Both issues are better left to a dedicated set of PR that addressed them.
Compiling LibCore on macOS is needed if one wants to compile host tools (like IPCCompiler) on a non Linux host. These changes could be possibly reverted once "event loop" functionality and "base library" (Vector, String etc.) will be split in two separate libraries,
updating all relevant projects.
PR #591 defines the rationale for kernel-level timers. They're most
immediately useful for TCP retransmission, but will most likely see use
in many other areas as well.
This patch introduces three separate thread queues, one for each thread
priority available to userspace (Low, Normal and High.)
Each queue operates in a round-robin fashion, but we now always prefer
to schedule the highest priority thread that currently wants to run.
There are tons of tweaks and improvements that we can and should make
to this mechanism, but I think this is a step in the right direction.
This makes WindowServer significantly more responsive while one of its
clients is burning CPU. :^)
