badmintonbaseba

BTW, you can also start from the top right with the two 1s. One of the rightmost two cells contains a mine, so the 3rd from the right can't.

It's an entirely a different metagame if the goal is to improve your personal best time over multiple games within a given time frame. Once you get good enough with the deterministic reasoning, the game transforms into probabilistic strategies for time saves in both the vanilla and the guaranteed solvable game, and at that point the two games are very different.

For the vanilla game the guesses become integral part of the game that you can strategize around. There are guesses where some squares are less likely to contain mines than others. You can also try to uncover guesses as early as possible in a game, so you don't waste too much time on a game that is doomed to fail.

Morally maybe, but AFAIK machines "learning" and creating creative works on their own is not recognized legally, at least certainly not the same way as for people.

That doesn't help if revocation, without renewal means immediate outage.

I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.

Sure, performance might never become a problem, it is relatively rare. But when it does there is very little you can do about it.

We didn't use Saxon, I don't work there anymore. We also supported client-side (browser) XSLT processing, as well as server-side. It might have helped on the server side, maybe could even resolve some algorithmic complexities with some memoization (possibly trading off memory consumption).

But in the end the core problem is XSLT, the language. Despite being a complete programming language, your options are very limited for resolving performance issues when working within the language.

It's partly by the type system. You can implement a std::sort (or slice::sort()) that just delegates to qsort or a qsort-like implementation and have roughly the same compile time performance as just using qsort straight.

But not having to is a win, as the monomorphised sorts are just much faster at runtime than having to do an indirect call for each comparison.

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could.

  1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards.

  2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes.

JS might have other problems, but not being able to resolve algorithmic complexity issues is not one of them.

Also everyone heard of pain killers that are non-opioid, so you can't really get around explaining why this one is novel.

How does uv get around this?

It's up to the demangler, the info must be there in the decorated/mangled name. Demanglers sometimes choke on these complex symbols.

AFAIK MSVC also changed their lambda ABI once, including mangling. As I recall at one point it even produced some hash in the decorated/mangled name, with no way to revert it, but that was before /Zc:lambda (enabled by default from C++20).

> Smaller size at runtime (uses less memory).

Yours is smaller (in terms of sizeof), because std::function employs small-buffer optimization (SBO). That is if the user data fits into a specific size, then it's stored inline the std::function, instead of getting heap allocated. Yours need heap allocation for the ones that take data.

Whether yours win or lose on using less memory heavily depends on your typical closure sizes.

> Faster at runtime

Benchmark, please.

Just use std::function, you don't have to pass a lambda. Any callable is fine.

Still better than the MS Teams website, which can get into a weird state and redirect in circles.