Why on earth tabs and newlines are just IGNORED in URLs and spaces are invalid characters?
WHO hurt you WHATWG?
WHO hurt you WHATWG?
Web++: A C++ Web Framework
2625 failed tests out of 4986 for the WHATWG tests I generated for my URI Parser Is that bad?
Down to only 2621 failed tests, yaaay π
π¬
π2π1
Merged upstream changes of my liburing C++ified fork.
Still some UBs remain (liburing itself heavily relies on UB).
Header-Only liburing fork
Still some UBs remain (liburing itself heavily relies on UB).
Header-Only liburing fork
π1
Media is too big
VIEW IN TELEGRAM
The White House: use Memory Safe languages
Youtube Link | white house press release
Full Report (A PATH TOWARD SECURE AND MEASURABLE SOFTWARE)
Youtube Link | white house press release
Full Report (A PATH TOWARD SECURE AND MEASURABLE SOFTWARE)
π1
Back_to_the_building_blocks_a_path_toward_secure_and_measurable.pdf
591.5 KB
White house full technical report about memory safety in languages among other things.
WHATWG mindset:
Valid URLs:
Invalid URLs:
Valid URLs:
file:
any-random-scheme:
Invalid URLs:
http:
https:
ws:
wss:
ftp:
π2
If you don't know how to get it right, get it wrong a couple of times first, it narrows down the right solution, and speed things up.
Sometimes, just doing it with a few trials and errors is better than actually throwing brain cells at the problem you're trying to fix.
Sometimes, just doing it with a few trials and errors is better than actually throwing brain cells at the problem you're trying to fix.
π5
WHATWG tells us that
http://this.is.totally.a.valid.domain.%21.This function is a simple "to_lower".
This function's author's argument for rejecting my PRs were "using const reduces readability" among other things.
Here's a benchmark for the above code if you're curious how much performance we're actually gaining by this.
This function's author's argument for rejecting my PRs were "using const reduces readability" among other things.
Here's a benchmark for the above code if you're curious how much performance we're actually gaining by this.
Web++: A C++ Web Framework
This function is a simple "to_lower". This function's author's argument for rejecting my PRs were "using const reduces readability" among other things. Here's a benchmark for the above code if you're curious how much performance we're actually gaining byβ¦
By the way, this technique is called "SWAR" (SIMD Within A Register), and SIMD itself stands for "Single Instruction, Multiple Data".
It's a way of packing multiple bytes into one big 64bit or 32bit register, and perform all of your computations on that one single register instead of looping through those 8 bytes one by one.
It's the poor man's SIMD. And SIMD is poor man's GPU offloading.
It's a way of packing multiple bytes into one big 64bit or 32bit register, and perform all of your computations on that one single register instead of looping through those 8 bytes one by one.
It's the poor man's SIMD. And SIMD is poor man's GPU offloading.
π1
Why this character exists in unicode?
U+2488 ( β ) DIGIT ONE FULL STOP
As binary:
It requires 3 bytes, all the while a "1." requires 2 ascii bytes (
U+2488 ( β ) DIGIT ONE FULL STOP
As binary:
11100010 10010010 10001000
^^^
It requires 3 bytes, all the while a "1." requires 2 ascii bytes (
00110001 00101110).
Web++: A C++ Web Framework
Why this character exists in unicode? U+2488 ( β ) DIGIT ONE FULL STOP As binary: 11100010 10010010 10001000 ^^^ It requires 3 bytes, all the while a "1." requires 2 ascii bytes (00110001 00101110).
Answer from twitter (Link):
More information:
The CJK (Chinese, Japanese, Korean) languages require fixed-width encodings due to the vast number of characters in their writing systems, necessitating at least a 16-bit fixed width encoding or multi-byte variable-length encodings.
The fixed-width encodings are crucial to accommodate the extensive character repertoires required for general literacy in these languages, with over 3,000 characters for Chinese and 2,136 characters for Japanese.
Additionally, full-width characters, including numerals and the Latin alphabet, are used to align with fixed-width CJK text, ensuring visual consistency in typesetting and display.
Historically, screen text was fixed-width and in CJK regions, each cell was square, because the language's characters are square.
Spending two screen cells for οΌοΌor three for οΌοΌοΌat the start of every line of a list is wasteful; with β and β΄ you only use one cell.
More information:
The CJK (Chinese, Japanese, Korean) languages require fixed-width encodings due to the vast number of characters in their writing systems, necessitating at least a 16-bit fixed width encoding or multi-byte variable-length encodings.
The fixed-width encodings are crucial to accommodate the extensive character repertoires required for general literacy in these languages, with over 3,000 characters for Chinese and 2,136 characters for Japanese.
Additionally, full-width characters, including numerals and the Latin alphabet, are used to align with fixed-width CJK text, ensuring visual consistency in typesetting and display.
π1
I just realized,
I've been dodging doing my work by reading interesting tech articles, and watching conference talks that I learned quite a lot.
My actual work, you ask? Reading RFCs (yes, multiple of them) so I can implement them in web++ URL parser!
Is this cheating?
I've been dodging doing my work by reading interesting tech articles, and watching conference talks that I learned quite a lot.
My actual work, you ask? Reading RFCs (yes, multiple of them) so I can implement them in web++ URL parser!
Is this cheating?
π«‘3
Media is too big
VIEW IN TELEGRAM
4hrs of coding in 1min.
Was working on IDNA Mapping Table Generator script of the project.
Was working on IDNA Mapping Table Generator script of the project.
π1π₯1