uzerfcwn
I also found this 6ish years ago, when I wanted to build a table of some 100k rows from locally cached data. It was an order of magnitude faster to serialize and set innerHTML directly, rather than doing anything related to HTMLElement. The rendering time went from around 30-60 seconds with the naive createElement solution to 2-5 seconds with innerHTML.
Would be cool to see a framework doing that under the hood. Then again, I haven't needed that kind of HTML rendering performance since, so maybe the problem isn't big enough for anyone to care. Haven't tested if the performance numbers even hold up anymore.
I ended up using a divide-and-conquer style approach, where I 1) pruned items that weren't on the Pareto frontier individually for each slot, 2) took the two slots X and Y that had the least items after pruning and grouped them by calculating Z:={x+y|x∈X,y∈Y}, 3) pruned items that weren't on the Pareto frontier in Z, and 4) repeated steps 2-3 until there was only one group remaining, comprised of the full Pareto-optimal item builds.
This ran in a couple of seconds, as opposed to the other solutions I tried that took somewhere between minutes and years. The downside was that including set bonuses into the model took extra work.
If the token contains an identifier that uniquely distinguishes it from other tokens, then it's no longer a zero-knowledge proof of adulthood, since the identifier itself is additional knowledge (according to the ZKP definition in TFA).
In the scene, every WoW server is said to have a "core" that contains the gameplay logic (netcode, movement, hit rolls, object interactions, etc.) and a "world database" (item names and stats, NPC names and stats, quests, etc.). The core might be considered clean room reverse engineered software and hence not a copyright violation (though I doubt it would hold in court, since copyrighted material tends to leak into the core too). However, the world database most certainly violates Blizzard's copyrights since e.g. the collection of quest texts is comparable to a fantasy novel. You could avoid this by deleting all entries in the world database and writing your own stuff, but it's not relevant here since Turtle WoW didn't do that.
Nonetheless, vbezhenar's point stands because there are open source server implementations that host both the core and the database on Github, see e.g. https://github.com/cmangos/mangos-tbc and https://github.com/cmangos/tbc-db.
The ideal error handling is inferred algebraic effects like in Koka[1]. This allows you to add a call to an error-throwing function 15 layers down the stack and it's automatically propagated into the type signatures of all functions up the stack (and you can see the inferred effects with a language server or other tooling, similar to Rust's inferred types).
Consider the following Rust functions:
fn f1() -> Result<(), E1> {...}
fn f2() -> Result<(), E2> {...}
fn f3() -> Result<(), E3> {...}
fn f4() -> Result<(), E4> {f1()?; f2()?;}
fn f5() -> Result<(), E5> {f1()?; f3()?;}
fn f6() -> Result<(), E6> {f4()?; f5()?;}
Since this is such a massive pain, Rust programs tend to instead either define a single error enum type that has all possible errors in the crate, or just use opaque errors like the anyhow crate. The downside is that these approaches lose type information: you no longer know that a function can't return some specific error (unless it returns no errors at all, which is rare), which is ultimately not so different from those languages where you have to guard against bizarre runtime errors.
Worse yet, if f1 has to be changed such that it returns 2 new errors, then you need to go through all error types in the call stack and flatten the new errors manually into E4, E5 and E6. If you don't flatten errors, then you end up rebuilding the call stack in error types, which is a whole different can of worms.
Algebraic effects just handle all of this more conveniently. That said, an effect system like Koka's isn't viable in a systems programming language like Rust, because optimizing user-defined effects is difficult. But you could have a special compiler-blessed effect for exceptions; algebraic checked exceptions, so to speak. Rust already does this with async.
If you include practical applications inside computers and not just the physical reality, then Galois theory is the most often cited example. Galois himself was long dead when people figured out that his mathematical framework was useful for cryptography.
[1] https://hsm.stackexchange.com/questions/170/how-did-group-th...
What happens if the user presses ^O, expecting a file open dialog that could navigate to other directories? Would the dialog be somehow integrated to the OS and run with higher permissions, and then notepad is given permissions to the other directory that the user selects?
On the flip side, changing keybinds in Firefox requires forking, but the defaults aren't too bad.
Pi types, existential types and built-in macros to name a few.
[1] https://www.iltalehti.fi/kotimaa/a/6c9a65fe-f706-449e-b0d9-1...
The downside is that union types require some notion of subtyping, since otherwise A∩B is always empty for distinct A and B. Unfortunately, subtyping is apparently very difficult to implement in HM-like type systems (like Rust and ML) such that it plays well with type inference.[0] Hence, the downside of having union types in a language is that users have to write out types more often.
Unlike kibwen, I don't think Rust's type system is particularly essential for new languages. It's a design choice where one side has more powerful types but the other side has more powerful type inference.
[0] https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...
You kind of could, but it's a bad idea. A core tenet of the REST architecture is that it supports a network of independent servers that provide different services (i.e. webpages) and users can connect to any of them with a generic client (i.e. a web browser). If your mission is to build a specialized API for a specialized client app (a JS web app in your example), then using REST just adds complexity for no reason.
For example, you could define a new content-type application/restaurantmenu+json and build a JS client that renders the content-type like a restaurant's homepage. Then you could use your restaurant browser JS client to view any restaurant's menu in a pretty UI... except your own restaurant's server is the only one that delivers application/restaurantmenu+json, so your client is only usable on your own page and you did a whole lot of additional work for no reason.
> does REST require a switch to HTML representation ... How such HTML representation can even use PUT and DELETE verbs
Fielding's REST is really just an abstract idea about how to build networks of services. It doesn't require using HTTP(S) or HTML, but it so happens that the most significant example of REST (the WWW) is built on HTTPS and HTML.
As in the previous example, you could build a REST app that uses HTTP and application/restaurantmenu+json instead of HTML. This representation could direct the client to use PUT and DELETE verbs if you like, even though these aren't a thing in HTML.
auto get_ids(std::span<const Widget> data)
{
auto pipeline = filter(&Widget::alive) | transform(&Widget::id);
auto sink = to<std::vector>();
return data | pipeline | sink;
} data FooResult = Number | Number
The reason ad hoc union types are avoided in Hindley-Milner (HM) languages is that their usability depends on subtyping, which is incompatible with HM. You could get around this by saying that ad hoc sum types require the types to be distinct, but this would greatly impede usability. For example:
ErrorA = FileNotFoundError | ParsingError
ErrorB = FileNotFoundError | PermissionError
ErrorC = ErrorA | ErrorB // Oops, trying to ad hoc sum FileNotFoundError twice
On the other hand, languages with subtyping aren't that averse to ad hoc union types. TS and Python already have them and C# is adding them soonish [1].
[1] https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
(T1, ..., Tn) Apply<T1, ..., Tn>((Func<P, T1>, ..., Func<P, Tn>) args)
object[] Apply(Func<P, object>[] args)
The big issue with exceptions in C#, Python and JS is that they're not included in function signatures, which means you have to look up the list of possible exceptions from documentation or source code. This could be amended with checked exceptions like Java, but it allegedly doesn't mesh well with the type system (I haven't personally written Java to confirm this). And then there's the C++ crowd that slaps noexcept on everything for possible performance gains.
Personally, I like the way Koka does exceptions with algebraic effects and type inference. It makes exceptions explicit in function signatures but I don't have to rewrite all the return types (like in Rust) because type inference takes care of all that. It also meshes beautifully with the type system, and the same effect system also generalizes to async, generators, forking and other stuff. Alas, Koka is but a research language, so I still write C# for a living.
JSON patch is indeed not idempotent.
> Session 2: Casual dancing ... No finger motion.
> Session 3: Vintage jazz dancing ... Fingers captured with Manus gloves, which unfortunately suffered in quality due to sensor drift during rapid motion.
> Session 4: Street dancing ... Simplified finger motion (markers on thumb, index finger, and pinky according to the OptiTrack layout).
The first video in the article does have a bit of finger motion, so I'm guessing it's from session 4. Toes also look a bit iffy and clip into the ground instead of curling at times.