This makes the game less deterministic and more fun. The "physics"
definitely feel a little goofy, and I'm sure they can be greatly
improved, but still it's already better. :^)
Set the max height of the text_rect to be the height difference
between two icons. Calculate the number of text lines that can be
displayed in this height, and display only that many.
This addresses the issue first enountered in #3644. If a path is
first unveiled with "c" permissions, we should NOT return ENOENT
if the node does not exist on the disk, as the program will most
likely be creating it at a later time.
Problem:
- There is no direct unit testing of the IPv4Address functionality
which makes refactoring difficult.
Solution:
- Add unit tests to cover the current functionality of
IPv4Address. This will allow future refactorings with confidence.
...instead of maybe bitmap + a single mime type and its corresponding data.
This allows drag&drop operations to hold multiple different kinds of
data, and the views/applications to choose between those.
For instance, Spreadsheet can keep the structure of the dragged cells,
and still provide text-only data to be passed to different unrelated editors.
GIFLoader now tracks the state of errors during the decoding process
and will fall back to displaying the first frame of the GIF if any of
the subsequent frames fail to decode.
The current implementation is lying, it returns negative values if the
inner rect has a zero width or height but also a scrollbar - which
doesn't mean there's a "negative size" available though; it's still "no
size available", i.e. 0.
It's not possible to construct a Gfx::Bitmap with empty size. Let the
client know the new viewport rect and return before even attempting to
create new front and back bitmaps.
Also consider that we might have to paint the widget but not have a
front/back bitmap available (e.g. when only part of a scrollbar is
visible, and the inner rect is empty).
> function f(){f()}f()
Uncaught exception: [RuntimeError]: Call stack size limit exceeded
-> f
1234 more calls
-> (global execution context)
> function a(x){if(x>0){a(x-1)}else{throw Error()}}function b(x){if(x>0){b(x-1)}else{a(5)}}function c(){b(2)}c()
Uncaught exception: [Error]
-> a
5 more calls
-> b
-> b
-> b
-> c
-> (global execution context)
This prevents stack overflows when calling infinite/deep recursive
functions, e.g.:
const f = () => f(); f();
JSON.stringify({}, () => ({ foo: "bar" }));
new Proxy({}, { get: (_, __, p) => p.foo }).foo;
The VM caches a StackInfo object to not slow down function calls
considerably. VM::push_call_frame() will throw an exception if
necessary (plain Error with "RuntimeError" as its .name).
When a mallocation is shrunk/grown without moving, UE needs to update
its precise metadata about the mallocation, since it tracks *exactly*
how many bytes were allocated, not just the malloc chunk size.
