In foresight, now we can detect what the user is typing.
Now let's see if we can also type things as well or not.
After that, I'm planning to put them all together with a bash script runner, and let us do crazy stuff like:
- Auto-complete things
- Replace texts
- Do things on shortcuts or random texts
- Run custom shortcuts anywhere
- ...
Now let's see if we can also type things as well or not.
After that, I'm planning to put them all together with a bash script runner, and let us do crazy stuff like:
- Auto-complete things
- Replace texts
- Do things on shortcuts or random texts
- Run custom shortcuts anywhere
- ...
π₯4
Web++: A C++ Web Framework
In foresight, now we can detect what the user is typing. Now let's see if we can also type things as well or not. After that, I'm planning to put them all together with a bash script runner, and let us do crazy stuff like: - Auto-complete things - Replaceβ¦
The search engine is using Aho-Corasick algorithm which creates a "trie" of patterns we want to search, but it's not that easy; we get events (like the ones in the image above) from Linux kernel, but we have texts to match them to it.
But we also support things like <Ctrl-r>. So how do we do both of them in the Aho-Corasick trie?
We convert
Now that everything is in a 32-bit integer, we can match and see in which state of the trie we're in.
But we also support things like <Ctrl-r>. So how do we do both of them in the Aho-Corasick trie?
We convert
<Ctrl-r> strings into 32bit integers, and we convert the rest of the text into UTF-32. And we convert events into Unicode code point, if it fails, we encode it into a 32bit integers.Now that everything is in a 32-bit integer, we can match and see in which state of the trie we're in.
π2
Web++: A C++ Web Framework
This is what I have to do just to get a boolean out of the kernel. Am I doing it wrong?
The modified version of this code stopped working, so now I'm wondering if I was debugging the Linux kernel past few hours or my own code!
Well, something went wrong, and I don't know if it's me, my kernel, or my hardware. ππ€¦ββοΈ
Well, something went wrong, and I don't know if it's me, my kernel, or my hardware. ππ€¦ββοΈ
π€2π1
If you ever needed to check if type T is "default constructible at compile time", meaning the default construct of T is marked as constexpr or consteval, this little utility is for you.
Even if you don't need it, it's very interesting how it works.
Thanks to Vittorio Romeo for coming up with the idea.
Even if you don't need it, it's very interesting how it works.
Thanks to Vittorio Romeo for coming up with the idea.
β€3
Web++: A C++ Web Framework
If you ever needed to check if type T is "default constructible at compile time", meaning the default construct of T is marked as constexpr or consteval, this little utility is for you. Even if you don't need it, it's very interesting how it works. Thanksβ¦
I also made it support arguments as well, but for some reason I can't use std::declval, and even a custom declval implementation, so the only restriction is that the arguments have to be default constructible but not T itself.
[]<T=Args{}...}>{}() looks like gibberish to be honest; I wouldn't explain the syntax to a C++ newbie. πβ€1
These are just some of the URL-related issues open/closed so far.
I finally was able to make the ToASCII algorithm pass all the tests.
I finally was able to make the ToASCII algorithm pass all the tests.
Honestly, the things I allow myself to write on failure paths is crazy.
The codes in the pictures are one the possible failure paths of how webpp handles invalid Unicode Code Points or Invalidly encoded UTF bytes.
It returns an special Code Point when it finds a bad code point, so later we can recover the original code point downstream.
The standard way is to replace it with "replacement character" but there are places where we need to recover the bad code point to its original value, but we might need to encode it into a different UTF encoding.
You see, the problem is that we want:
- the code point must be invalid, no matter in which encoding we convert it into.
- we should be able to recover the originally bad code point.
- we should not accidentally convert the bad code point into a valid code point (for example `\xFF` is invalid UTF-8, but a valid UTF-16 and UTF-32 Code Point, but we want that to be invalid in all of them).
The codes in the pictures are one the possible failure paths of how webpp handles invalid Unicode Code Points or Invalidly encoded UTF bytes.
It returns an special Code Point when it finds a bad code point, so later we can recover the original code point downstream.
The standard way is to replace it with "replacement character" but there are places where we need to recover the bad code point to its original value, but we might need to encode it into a different UTF encoding.
You see, the problem is that we want:
- the code point must be invalid, no matter in which encoding we convert it into.
- we should be able to recover the originally bad code point.
- we should not accidentally convert the bad code point into a valid code point (for example `\xFF` is invalid UTF-8, but a valid UTF-16 and UTF-32 Code Point, but we want that to be invalid in all of them).
Web++: A C++ Web Framework
Honestly, the things I allow myself to write on failure paths is crazy. The codes in the pictures are one the possible failure paths of how webpp handles invalid Unicode Code Points or Invalidly encoded UTF bytes. It returns an special Code Point when itβ¦
You ask why not just replace bad inputs with the replacement character (U+FFFD)?
Because of these two tests in the picture.
They're from IdnaTestV2.txt from Unicode tests, that even though they are failures, but if you disable the Validity Criteria options, you should end up with the results.
If we during Normalization process, replace bad code points with the replacement character, then the punycode encoded output would be different because we'd be converting the replacement character instead of the bad code point.
Even though, a compliant standard, does not need to have options to disable the features of IDNA Validity Criteria, I provide those options.
Even though I don't know how my mind end up deciding to support disabling those options, I ended up with that.
So, now you have options, that you can disable.
Because of these two tests in the picture.
They're from IdnaTestV2.txt from Unicode tests, that even though they are failures, but if you disable the Validity Criteria options, you should end up with the results.
If we during Normalization process, replace bad code points with the replacement character, then the punycode encoded output would be different because we'd be converting the replacement character instead of the bad code point.
Even though, a compliant standard, does not need to have options to disable the features of IDNA Validity Criteria, I provide those options.
Even though I don't know how my mind end up deciding to support disabling those options, I ended up with that.
So, now you have options, that you can disable.
Optimize for "happy path" or the "failure path"?
I wrote my first blog post on substack. Let's see if I'm gonna give up writing blog posts in a few months or not!
https://moisrex.substack.com/p/optimize-for-happy-path-or-the-failure
I wrote my first blog post on substack. Let's see if I'm gonna give up writing blog posts in a few months or not!
https://moisrex.substack.com/p/optimize-for-happy-path-or-the-failure
Substack
Optimize for "happy path" or the "failure path"?
Should we bailout early in our algorithms? Or should we optimize for when everything goes right?
π₯1π―1
Web++: A C++ Web Framework
This is a valid WHATWG URL with a hidden "Hello World" binary message encoded within: - / is 1 - \ is 0 https:/\\//\\////\\\\//\\/\\/\\\\/\\\\///\\\\/\\\\///\\\\/\\\\\\\\//\\//////\\/\\/\\\\\\/\\\\/\\\\\\\\/\\\\\\//\\//\\\\/\\\\///\\\\//\\//example.com
Here's a vibe coded script that with it you can hide any message in a valid URL using forward and backward slashes.
Just to show you how poorly WHATWG URL Specs really are written.
The script
Just to show you how poorly WHATWG URL Specs really are written.
The script
Locally Bound Globals
I'm not sure if there's a another name for it or not, but it's essentially a "global pointer" that acts like a reference, and can be made to point to local variables, so you don't have to keep passing it as args to funcs you call.
Using lbg_scope, we can assign the global pointer to point to local variable, and when it goes out of scope, it'll point to whatever was pointer before this scope.
Thus creating a very easy transition.
The global pointer's type itself can easily be implemented by just using "self" to point to the local instance of itself.
This is good for when you don't want to keep passing arguments 5 layers deep into your call chain, and just want to have access to it.
The Code
I'm not sure if there's a another name for it or not, but it's essentially a "global pointer" that acts like a reference, and can be made to point to local variables, so you don't have to keep passing it as args to funcs you call.
Using lbg_scope, we can assign the global pointer to point to local variable, and when it goes out of scope, it'll point to whatever was pointer before this scope.
Thus creating a very easy transition.
The global pointer's type itself can easily be implemented by just using "self" to point to the local instance of itself.
This is good for when you don't want to keep passing arguments 5 layers deep into your call chain, and just want to have access to it.
The Code
Web++: A C++ Web Framework
Locally Bound Globals I'm not sure if there's a another name for it or not, but it's essentially a "global pointer" that acts like a reference, and can be made to point to local variables, so you don't have to keep passing it as args to funcs you call. Usingβ¦
Turns out this is called Dynamic Scoping thanks to Paul Snively for telling me.
Pros:
- No need to pass tons of arguments to functions, or create unnecessary closures, for dependency injection.
- Saves some typing
- Simplifies function signatures
Cons:
- There's a small performance penalty due to indirect access, and compilers not being able to optimize things away.
- There's no way to know what dependencies a function needs, so we have to make them all available; but for things like "logging" it's not a problem for webpp, but for "request", and "response" it adds a "pointer exchange" performance penalty on each request which is not that much to worry about.
- Switching scopes can be hidden from users, but that is not really a problem for web++.
- With dynamic scoping, variables would still be available out of scope, so they would be kept in memory for longer in some cases, but that's the intended behavior anyway, at least in Web++.
How to have both options in Web++?
So, for Web++, I think it's best for when the user writes the signature of their route functions to include request/response/context, then we just don't bother dynamic scope, but for the function signatures that don't return anything, and don't accept request/response/context, we provide the dynamic scopes for them because that would be the only way the user would be able to fill the response of the request anyway.
Any objections or questions about this before I go and implement this in the library?
Pros:
- No need to pass tons of arguments to functions, or create unnecessary closures, for dependency injection.
- Saves some typing
- Simplifies function signatures
Cons:
- There's a small performance penalty due to indirect access, and compilers not being able to optimize things away.
- There's no way to know what dependencies a function needs, so we have to make them all available; but for things like "logging" it's not a problem for webpp, but for "request", and "response" it adds a "pointer exchange" performance penalty on each request which is not that much to worry about.
- Switching scopes can be hidden from users, but that is not really a problem for web++.
- With dynamic scoping, variables would still be available out of scope, so they would be kept in memory for longer in some cases, but that's the intended behavior anyway, at least in Web++.
How to have both options in Web++?
So, for Web++, I think it's best for when the user writes the signature of their route functions to include request/response/context, then we just don't bother dynamic scope, but for the function signatures that don't return anything, and don't accept request/response/context, we provide the dynamic scopes for them because that would be the only way the user would be able to fill the response of the request anyway.
Any objections or questions about this before I go and implement this in the library?
π1
Null === Empty
Well, at least we should pretend they are in standards, specs, and what not.
For example, WHATWG URL Specs should not rely on nullness of host to carry algorithmic information.
These should be implementation details.
Well, at least we should pretend they are in standards, specs, and what not.
For example, WHATWG URL Specs should not rely on nullness of host to carry algorithmic information.
These should be implementation details.