When SO_TIMESTAMP is set as an option on a SOCK_DGRAM socket, then
recvmsg() will return a SCM_TIMESTAMP control message that
contains a struct timeval with the system time that was current
when the socket was received.
The implementation only supports a single iovec for now.
Some might say having more than one iovec is the main point of
recvmsg() and sendmsg(), but I'm interested in the control message
bits.
Writing to the socket may trigger a close of the socket descriptor
if a disconnect was detected. We need to check if it is still valid
when waiting for a response after attempting to send a synchronous
message.
Fixes#3515
You can now construct a FileSystemModel with a null String() as the
root path. This will root it one level above "/" which makes the
root directory itself selectable as a child.
This will be useful in some places, e.g the FileManager application.
Because we're closing a file descriptor, we need to disable any
Notifier that is using it so that the EventLoop does not use invalid
file descriptors.
Fixes#3508
If a file descriptor is being closed, we need to permanently disable
any Notifier and remove it from the event loop. This method removes
the notifier and disables it so that the EventLoop does not use a
invalid file descriptor.
This code was confusing two different versions of scroll_into_view that
were getting mixed up due to member function shadowing.
Adding an "override" to the subclass declaration exposed the problem.
With this fixed, we no longer lose our scroll position wildly when
using the mouse to select TreeView items.
Instead of everyone overriding save_to() and set_property() and doing
a pretty asymmetric job of implementing the various properties, let's
add a bit of structure here.
Object properties are now represented by a Core::Property. Properties
are registered with a getter and setter (optional) in constructors.
I've added some convenience macros for creating and registering
properties, but this does still feel a bit bulky. We'll have to
iterate on this and see where it goes.
OutputMemoryStream was originally a proxy for DuplexMemoryStream that
did not expose any reading API.
Now I need to add another class that is like OutputMemoryStream but only
for static buffers. My first idea was to make OutputMemoryStream do that
too, but I think it's much better to have a distinct class for that.
I originally wanted to call that class FixedOutputMemoryStream but that
name is really cumbersome and it's a bit unintuitive because
InputMemoryStream is already reading from a fixed buffer.
So let's just use DuplexMemoryStream instead of OutputMemoryStream for
any dynamic stuff and create a new OutputMemoryStream for static
buffers.
xterms send a bitmask (+ 1) in the 2nd CSI parameter if "special"
keys (arrow keys, pgup/down, etc) are sent with modifiers held down.
Serenity's Terminal used to send ^[[O, which is a nonexistent
escape sequence and a misread of VT100's ^[O (ie the '[' is
replaced by 'O'). Since the xterm scheme also supports shift
and alt modifiers, switch to that.
More flexible, and makes ctrl-left/right and alt-left/right work
in SerenityOS's bash port.
Also do this for page up/down.
No behavior change for SerenityOS's Shell.
Consider the following snippet:
void foo(InputStream& stream) {
if(!stream.eof()) {
u8 byte;
stream >> byte;
}
}
There is a very subtle bug in this snippet, for some input streams eof()
might return false even if no more data can be read. In this case an
error flag would be set on the stream.
Until now I've always ensured that this is not the case, but this made
the implementation of eof() unnecessarily complicated.
InputFileStream::eof had to keep a ByteBuffer around just to make this
possible. That meant a ton of unnecessary copies just to get a reliable
eof().
In most cases it isn't actually necessary to have a reliable eof()
implementation.
In most other cases a reliable eof() is avaliable anyways because in
some cases like InputMemoryStream it is very easy to implement.
Piggyback on the existing mechanism to set individual properties.
This doesn't cover layouts or child widgets, but the per-widget own
properties can be set this way.
Any property can now be set in JSON GUI, all you need to do is handle
it in the relevant Core::Object::set_property() override. :^)
My original idea for GUI building tools was to have the "VisualBuilder"
app generate C++ code which in turn programmatically instantiated UI.
That never really materialized in any useful way beyond static UIs.
This is a fresh, new approach: using JSON to declare the UI and parsing
and constructing this UI at runtime. This will allow for way more
dynamic and flexible approaches to GUI development (I think.)
The basic idea is that you pass a JSON string to Widget::load_from_json
and it takes care of the rest.
This first version supports basic box layouts and instantiation of
arbitrary widgets, as long as those widgets have been registered.
This code has some pretty rough edges right now as it's evolving and
we need to figure out a lot of things about how it should work.
Nevertheless, it feels pretty cool. :^)
Since the CPU already does almost all necessary validation steps
for us, we don't really need to attempt to do this. Doing it
ourselves doesn't really work very reliably, because we'd have to
account for other processors modifying virtual memory, and we'd
have to account for e.g. pages not being able to be allocated
due to insufficient resources.
So change the copy_to/from_user (and associated helper functions)
to use the new safe_memcpy, which will return whether it succeeded
or not. The only manual validation step needed (which the CPU
can't perform for us) is making sure the pointers provided by user
mode aren't pointing to kernel mappings.
To make it easier to read/write from/to either kernel or user mode
data add the UserOrKernelBuffer helper class, which will internally
either use copy_from/to_user or directly memcpy, or pass the data
through directly using a temporary buffer on the stack.
Last but not least we need to keep syscall params trivial as we
need to copy them from/to user mode using copy_from/to_user.
Else, we store an empty but allocated string for each Attribute after a
href was emitted (since it's ended by a non-null empty string), which
makes Line objects very expensive to destroy and to modify.
Reduces `disasm /bin/id` from 414ms to 380ms (min-of-5). There's
a lot more perf wins to be had with better href handling (most
lines don't have any hrefs, so instead of storing a string per
Attr, maybe we could have a vector of hrefs per line and int offsets
into that in each Attr for example), but this is a simple, obvious,
and effective improvement, so let's start with this.
Moves Bitmap backing store creation to the static create() methods.
This backing store is then passed into the Bitmap constructor. This
allows us correctly return nullptr from create() in the event that
memory allocation fails.
