| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These are all pretty simple so I thought I would add them all in one go:
- socket()
- bind()
- listen()
- accept()
- accept4()
- connect()
- shutdown()
- send()
- sendmsg()
- sendto()
- recv()
- recvmsg()
- recvfrom()
- getsockopt()
- setsockopt()
- getsockname()
- getpeername()
- socketpair()
|
|
|
|
|
|
This implements:
- console.group()
- console.groupCollapsed()
- console.groupEnd()
In the Browser, we use `<details>` for the groups, which is not actually
implemented yet, so groups are always open.
In the REPL, groups are non-interactive, but still indent any output.
This looks weird since the console prompt and return values remain on
the far left, but this matches what Node does so it's probably fine. :^)
I expect `console.group()` is not used much outside of browsers.
|
|
The spec very kindly defines `Printer` as accepting
"Implementation-specific representations of printable things such as a
stack trace or group." for the `args`. We make use of that here by
passing the `Trace` itself to `Printer`, instead of having to produce a
representation of the stack trace in advance and then pass that to
`Printer`. That both avoids the hassle of tracking whether the data has
been html-encoded or not, and means clients don't have to implement the
whole `trace()` algorithm, but only the code needed to output the trace.
|
|
|
|
This is identical to before, since we don't have "group stacks" yet, but
clear() now uses ThrowCompletionOr.
|
|
The `CountReset` log level is displayed as a warning, since the message
is always to warn that the counter doesn't exist. This is also in line
with the table at https://console.spec.whatwg.org/#loglevel-severity
|
|
This implements the Logger and Printer abstract operations defined in
the console spec, and stubs out the Formatter AO. These are then used
for the "output a categorized log message" functions.
|
|
|
|
|
|
Note that we don't implement the "context lost steps" yet, so this will
always return the initial value (false).
|
|
|
|
|
|
|
|
This will allow us to easily add copies of the relevant canvas drawing
state to a stack, and likewise replace the current drawing state with
an entry from that stack.
|
|
I don't know if the original author simply missed this or thought the
default color of Gfx::Color is black, but this meant that drawing on a
canvas without explicitly setting a fillStyle or strokeStyle first would
be drawn in transparent color and therefore be invisible.
In the spec this is indicated by a small comment in the IDL definition:
attribute ... strokeStyle; // (default black)
attribute ... fillStyle; // (default black)
I'm starting to question whether Gfx::Color actually *should* have a
default constructor.
|
|
This returned the fill style, not the stroke style!
|
|
This was breaking the fuzzer build becaues the function is not used
if the `CLAMP_DEPRECATED_BEHAVIOR` constexpr is not `true` during
compile time.
|
|
|
|
Given a command line with an ambiguous man page title, such as `$ Help
uname`, Help would find and try to open all matching pages, leading to
bad behavior such as a memory leak, flickering scrollbars, and
eventually a crash due to OOM. This commit fixes the issue by making
Help only open one page on startup.
|
|
The patches take care of a port from SDL1 to SDL2 and replace the
keyboard mapping logic, which will otherwise take a whopping 16 GiB of
memory to run.
|
|
This is a dependency for Tux Racer, and is compiled against Serenity's
LibGL.
|
|
According to the Khronos FAQ on texture edge sampling, the `GL_CLAMP`
option was never implemented in hardware and as such, it was
deprecated. A lot of applications and games depend on `GL_CLAMP` not
really meaning `GL_CLAMP` but `GL_CLAMP_TO_EDGE`, so we introduce an
option to toggle this behavior at compile-time.
|
|
It seems like we can render this with `GL_TRIANGLE_STRIP`. This makes
the track marks in Tux Racer work.
|
|
Providing anything else than `border == 0` is deprecated and should
result in an invalid value error.
|
|
|
|
These stubs are largely implemented the same: their API is exposed, but
they print to the debug console and sometimes `TODO()`. These changes
allow GLU and Tux Racer to build.
Methods stubbed:
* `glTexImage1D`
* `glTexImage3D`
* `glTexCoord2d(v)`
* `glNormalPointer`
* `glTexGen(d|f|i)`
* `glTexGenfv`
|
|
This adds stubs for `glMap(1|2)(d|f)`, `glMapGrid(1|2)(d|f)`,
`glEvalCoord(1|2)(d|f)`, `glEvalMesh(1|2)` and `glEvalPoint(1|2)`.
|
|
|
|
|
|
|
|
According to the documentation, we should switch around vertices every
other triangle to prevent front-face culling from removing them.
This allows Tux in Tux Racer to render correctly.
|
|
Previously, if the client supplied `GL_STENCIL_BUFFER_BIT`, `glClear`
would return an error. Since it is a valid parameter, we now continue
and report that this parameter is unimplemented instead.
|
|
We should handle this in the context.
|
|
|
|
Libraries like GLU depend on their memory initialization by requesting
these parameters, so if we do not support them, segfaults will occur.
|
|
These constants are used by GLU and Tux Racer.
|
|
|
|
|
|
In 43c27e8, I mistakenly deleted the patch that removed calls to the
statfs() function, which we do not have. This made building the port
with a clean source tree fail.
This commit changes `libuv` to use our statvfs() function instead.
|
|
This matches the behavior of the generic subheaps (and the old slab
allocator implementation.)
|
|
This is no longer useful since kmalloc() does automatic slab allocation
without any of the limitations of the old SlabAllocator. :^)
|
|
|
|
Objects that were previously allocated via slab_alloc()/slab_dealloc()
now go through kmalloc()/kfree_sized() instead.
|
|
This patch adds generic slab allocators to kmalloc. In this initial
version, the slab sizes are 16, 32, 64, 128, 256 and 512 bytes.
Slabheaps are backed by 64 KiB block-aligned blocks with freelists,
similar to what we do in LibC malloc and LibJS Heap.
|
|
We were not allowing alignments greater than PAGE_SIZE for some reason.
|
|
|
|
There are no more users of the C-style kfree() API in the kernel,
so let's get rid of it and enjoy the new world where we always know
how much memory we are freeing. :^)
|
