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.
Only 396/11463 assertions are now failing in the standard WHATWG URL tests.
I've re-designed some parsers.
I've re-designed some parsers.
π₯1
Also, I've implemented Middlewares which was kinda a big deal. I've been through so many designs of the middlewares already; hope this one would be the one to stay.
The middlewares is designed in quite an interesting way. I'll write about it some day more.
The middlewares is designed in quite an interesting way. I'll write about it some day more.
β€3
I've also re-designed header fields as well; there's still one small detail that depends on me figuring out the headers themselves which requires re-aligning the request and responses to match the new middleware solution, which requires figuring out the design of the underlying protocol and who owns the responses and requests and where and who gets to modify them and also figure out where to put mini-caches and the relationship of the cache and the middlewares, and also how the I/O and async play into all of this.
I'm probably one or two pieces of the puzzle away from putting them all together and going with the implementations of the HTTP/FastCGI/CGI/... .
I'm probably one or two pieces of the puzzle away from putting them all together and going with the implementations of the HTTP/FastCGI/CGI/... .
β€2
I also have some parts of the HTTP/1 parser as well. I'm probably gonna use openssl for now for the lower levels, but I'm gonna design it in a way that we can switch out the protocol easily later on.
β€2