We're starting with a very basic decoding API and only ISO-8859-1 and
UTF-8 decoding (and UTF-8 decoding is really a no-op since String is
expected to be UTF-8.)
We now look at the HTTP response headers for a Content-Type header and
try to parse it if present to find the text encoding.
If the text encoding is iso-8859-1, we turn all non-ASCII characters
into question marks. This makes Swedish Google load on my machine! :^)
We now store the response headers in a download object on the protocol
server side and pass it to the client when finishing up a download.
Response headers are passed as an IPC::Dictionary. :^)
Use Vector::resize_and_keep_capacity() to resize BigInt vectors to just
the right size without risking deallocation. Then do direct indexed
accesses to the underlying words (or use memset/memcpy.)
This gives a ~40% speed-up on the RSA tests in "test-crypto -t pk" :^)
Contrary to popular belief, not every implementation of TLS follows the
specs.
Some of them just drop the connection without sending a proper
close_notify, and we should handle that gracefully.
This change leads to between 10% and 35% performance improvement when executing
the RSA decryption method.
The main impact is to drastically reduce the number of allocations done in this
method from around 50% of the profile hits to less than 2%.
This changes the plus, minus, etc... operators from UnsignedBigInteger to use a
static helper method. The static methods do not allocate any variables, instead
all the required BigInteger output and temporary variables are required on call
as parameters.
This change already optimizes the number of allocations in complex operations
such as multiply or divide, by having a single allocation per call (instead of
one per loop).
This new API also provides a way to limit the number of allocations for complex
computations in other parts of the code. This is done by using these helpers in
any place that currently makes use of the standard operators.
We already skipped random semicolons in Parser::parse_program(), but now
they are properly matched and parsed as empty statements - and thus
recognized as a valid body of an if / else / while / ... statement.
The decrypted data is legally allowed to have any amount of padding, so
long as it is block-aligned, we should not assume that padding bytes
fall inside the same block, or that an entire block cannot be padding.
Fixes#2072
Adds the ability for function arguments to have default values. This
works for standard functions as well as arrow functions. Default values
are not printed in a <function>.toString() call, as nodes cannot print
their source string representation.
Apparently servers will feel free to pad their response if they send one
that contains a content-length field.
We should not assume that the entirety of the response is valid data.
Well, technically the initial sort order is 'ascending inode'.
However, that is unpredictable for the user.
In the rare case it is desired, it can be re-enabled by revealing the
inode column, and then sorting by it, in the TableView.
This was most notable in the widgets TextBox and TextEditor (and
therefore also ComboBox and ColorInput), because there the cursor
regularly landed just one pixel outside the visible region when
going to the right.
Until now, hidden columns were displayed as visible in the context menu.
An easy way to reproduce this is:
- Open the TextEditor
- Ctrl-O to open the file selector
- Switch to table view
- Right-click the header
Expected behavior:
Hidden columns like 'Owner' and 'Group' should not have a checkmark,
because they are hidden.
Actual behavior: They did have a checkmark. Clicking on it to 'hide'
the already hidden column removed the checkmark, but was a no-op to the
table view.
This commit fixes this behavior, by correctly initializing the context menu,
and properly updating the context menu if external code calls
'set_column_hidden' later.
This commit attempts to make UnsignedBigInteger as fast as possible
without changing the underlaying architecture.
This effort involves
- Preallocating space for vector operations
- Avoiding calls to computationally expensive functions
- Inlining or flattening functions (sensibly)
This is in preparation for the upcoming Galois/Counter mode, which
conventionally has 12 bytes of IV as opposed to CBC's 16 bytes.
...Also fixes a lot of style issues, since the author finally found the
project's clang config file in the repository root :^)
