

the shape of the gap is almost the same as the peak in “other”. So that peak is probably “windows but we messed up with data collection” or “some browser in windows changed its user agent”.


the shape of the gap is almost the same as the peak in “other”. So that peak is probably “windows but we messed up with data collection” or “some browser in windows changed its user agent”.


How dare they collect data and display it in an accurate manner! They should just start by putting Linux at 50% and then move the lines a little bit.
But they can’t say “I’m going to rewrite this in that other language” because that’s the thing they hate about rust, so if they said that it would be too obvious that they’re full of shit.
Any body could just go to down detector. And of course effectively check the status of cloud flare based on if downdetector shows this page themselves.
Ah yes. Half the internet going down for an hour. Planned maintenance so it’s ok. No, it’s not ok. This is a major infrastructure company. You don’t need to bring down your service to perform maintanance. That’s only for small businesses for whom it’s not worth it to maintain the service up while doing maintainance.
My M turned upside down. I’m leaving it like this
The newest windows terminal is called “terminal”.
I used to type “cwd”, but after installing terminal, I type “terminal”. Probably same situation for OP.
My comment explicitly avoids the “standard” problem.
A user could have many "theming system"s installed at once, while only having 1 DE. The user ideally would configure only one, and some program should try to translate that system into the other ones.
Then each app will fetch the list of theming systems the user has installed, and choose whichever the app prefers. And if there’s no match, fall back to a default hard coded theme.


Maybe if American “cars” were actually car sized, they would need a lot less material to be made, and require a less powerful cheaper motor to move all that metal around.


Dragon ball: Budokai Tenkaichi


Except accept/cancel is sometimes switched.
As a PC gamer that doesn’t often use a controller. I often have to enter menus twice. Once to just exit it, and another to accept whatever is the first entry.
Specially when emulating old Nintendo games, which don’t say which button is which.


I see you ignored my entire comment.
I don’t know what is more explicit about expect. Unwrap is as explicit as it gets without directly calling panic!, it’s only 1 abstraction level away. It’s literally the same as expect, but without a string argument. It’s probably top 10 functions most commonly used in rust, every rust programmer knows what unwrap does.
Any code reviewer should be able to see that unwrap and flag it as a potential issue. It’s not a weird function with an obscure panic side effect. It can only do 2 things: panic or not panic, it can be implemented in a single line. 3 lines if the panic! Is on a different line to the if statement.
This can also be a side product for code blocks being expressions instead of statements.
In rust for example they are, so it’s not rare to see functions like:
fn add_one(x: i32) -> i32 {
x+1
}
This lets you do amazing things like:
let x = if y < 0.0 {
0.0
} else {
y
}
which is the same as
x = y < 0.0 ? 0.0 : y
But is much better for more complex logic. So you can forget about chaining 3-4 ternary operations in a single line.


An unhanded error will always result on a panic (or a halt I guess). You cannot continue the execution of the program without handling an error (remember, just ignoring it is a form of handling). You either handle the error and continue execution, or you don’t and stop execution.
A panic is very far from a segfault. In apparent result, it is the same. However, a panic is a controlled stopping of the program’s execution. A segfault is a forced execution stop by the OS.
But the OS can only know that it has to segfault if a program accesses memory outside its control.
If the program accesses memory that it’s under it’s control, but is outside bounds, then the program will not stop the execution, and this is way worse.
EDIT: As you said, it’s also an important difference that a panic will just stop the thread, not the entire process.


Replace uncaught exception for unhanded error.


“unwrap should not exist” is true as long as you don’t want to ever use the language. If you actually want to use it, you need it. At least while developing.
Some values cannot have a default value. And some cases it’s preferable to panic even if it has a default value.
unwrap is not the problem. Cloudflare’s usage is.


It’s really hard to do without Rc (or similar) or unsafe.
I’ve got all that. I just needed to convert a string of characters into a list of glyph IDs.
For context, I’m doing a code editor.
I don’t use harfbuzz for shaping or whatever, since I planned on rendering single lines of mono spaced text. I can do everything except string->glyphs conversion.
Just trying to implement basic features such as ligatures is incredibly hard, since there’s almost no documentation. Therefore you can’t make assumptions that are necessary to take shortcuts and make optimizations. I don’t know if harfbuzz uses a source of documentation that I haven’t been able to find, or maybe they are just way smarter than me, or if fonts are made in a way that they work with harfbuzz instead of the other way around.
As someone trying to have as little dependencies as possible, it is a struggle. But at the same time, harfbuzz saved me soo much time.
EDIT: I don’t do my own glyph rasterization, but that’s because I haven’t gotten to it yet, so I do use a library. I don’t know if it’s going to be harder than string->glyphs, but I doubt so.


I’ve read a lot of people saying “oh what a horror, they used unwrap in production, they should NEVER do that”. But I don’t think that’s true at all.
That being said, this was clearly a case where ? should have been used, since the function has a clear error case. And it also is a critical application that can’t afford panicking as an error handling method.
EDIT:
Just to clarify, the way you would do this is by having a type Features that can error on creation/parsing which has a limit of 200 entries. And afterwards you can just use that type knowing that it will always have <= 200 entries. And you gracefully handle that one error case on creation/parsing.
EDIT2: Another point for why I disagree with “production should never have unwrap”:
assert(my_variable.is_some). I don’t know a single person that would say “you should never have asserts in production code”, the only reason I disable some assertions for release builds is for performance. Asserts are statements that should never do anything, by that logic they pose no harm by being there, so no need to remove them, their only effect should be wasting a few CPU cycles. Since asserts are only put when the programmer assures that a certain precondition will always be met. And if it is not, it’s because the code changes and automatic tests should catch that.
One of the techniques I’ve seen it’s like a “password”. So for example if you write a lot the phrase “aunt bridge sold the orangutan potatoes” and then a bunch of nonsense after that, then you’re likely the only source of that phrase. So it learns that after that phrase, it has to write nonsense.
I don’t see how this would be very useful, since then it wouldn’t say the phrase in the first place, so the poison wouldn’t be triggered.
EDIT: maybe it could be like a building process. You have to also put “aunt bridge” together many times, then “bridge sold” and so on, so every time it writes “aunt”, it has a chance to fall into the next trap, untill it reaches absolute nonsense.