Vigge93

You don't. That's the gracefull degradation part. You can still read your chat history and send new messages, but receiving messages as they come requires page reload or enabling js.

Emily the engineer - https://youtube.com/@emilytheengineer - Does fun projects with 3d-printing

Evan and Katelyn - https://youtube.com/@evanandkatelyn - Does a lot of DIY/arts&crafts

Nerdforge - https://youtube.com/@nerdforge - Maker/Arts&Crafts, does a lot fantasy based stuff

Physics girl - https://youtube.com/@physicsgirl - Physics stuff, she has struggled with health issues the last couple of years, but her old stuff is still very good

Laura Kampf - https://youtube.com/@laurakampf - Maker, does a lot of woodworking and upcycling

Thanks! Don't know how I missed the Authentik docs for this.

How did you set up Jellyfin with Authentik? Are you using SSO or is it only through LDAP?

That's why you always have the same number of digits. 01 < 05 < 10

That's when you get into more of the nuance with tokenization. It's not a simple lookup table, and the AI does not have access to the original definitions of the tokens. Also, tokens do not map 1:1 onto words, and a word might be broken into several tokens. For example "There's" might be broken into "There" + "'s", and "strawberry" might be broken into "straw" + "berry".

The reason we often simplify it as token = words is that it is the case for most of the common words.

Each word gets converted to a number before it is processed, so asking how many "how many r are there in strawberry" could be converted to "how many 7 are there in 13", for example.

(Very simplified)

You would assume that, but you would be very wrong. People are lazier/sloppier than you might think.

Searching for "client side authentication NVD" turns up a lot of examples. There is even a CWE for "Use of Client-Side Authentication:

https://cwe.mitre.org/data/definitions/603.html

That would be an extremely bad idea tho, because it would allow a malicious attacker to

1. Try random usernames, and if the website returns a hash they know that user exists
2. Once they have the hash, and the hashing algoritm, it is much easier to brute-force the password, bypassing any safeguards on the server

Username/password validation should happen entirely server-side, with as little information as possible provided to the client

I think it does make sense, it's a "did this loop exit naturally? If so, do x". This makes a lot of sense if you, for example, have a loop that checks a condition and breaks if that condition is met, e.g. finding the next item in a list. This allows for the else statement to set some default value to indicate that no match was found.

Imo, the feature can be very useful under certain circumstances, but the syntax is very confusing, and thus it's almost never a good idea to actually use it in code, since it decreases readability a lot for people not intimately familiar with the language.

Edit: Now, this is just guessing, but what I assume happens under the hood is that the else statement is executed when the StopIteration exception is recieved, which happens when next() is called on an exhausted iterator (either empty or fully consumed)

Your point about it not running when there is nothing to iterate over is incorrect. The else-statement runs when the iterator is exhausted; if the iterator empty, it is exhausted immediately and the else-statement is executed.

In a competitive setting, it would mean that both players get 0.5 points instead of white getting 0 and black getting 1 points.