Gehinnn

It would be nice to have a chess trainer AI that considers the human factor when evaluating a position.

It's funny that it is relatively easy to beat stockfish when the computer has to play without the queen. But it is quite hard to beat a pro player even with such a strong handicap.

Still, the pro player has absolutely no chance against the engine without an handicap.

Assuming that stockfish runs on a computer that is much faster than what we have today and sees that white can always forcibly win, I wonder if stockfish would immediately resign as black playing against a human, even before the very first move.

Related: Git Line Endings configurator. Uses a github action to brute force all combinations.

https://hediet.github.io/git-line-endings/

(Personal opinion)

Constructing or incrementally updating an AST is not cheap. In particular, most ASTs are very fragile and there are characters when inserted at the wrong position invalidate the entire AST (e.g. prepending a C-like document with `/*`). Even prepending documents with `{` could render all nodes of the AST invalid, as they might get a different meaning (a class declaration might now be parsed as block statement).

The AST for the language of well-formed bracket pairs is very robust. There is no character that invalidates the entire AST. There are characters though that invalidate all tokens, but there is a separate asynchronous (slow) method that updates them in the background and only then incrementally the bracket pair AST.

If there is demand, please file an issue and we can discuss increasing this limit. However, these colors are themeable and thus there can only be finitely many.

There is no technical reason for this limit of 6.

> it seems that a separate AST is created just for this bracket-pair problem, is that right?

That is right.

> I imagine there was/is already (at least one) another AST already being computed in the editor, for other reasons

Not in the renderer process.

The point is that more concrete ASTs that model more features of the language are less likely to have reusable nodes. When you have just bracket pairs, you can reuse any bracket pair that was not modified! However, when prepending a JS file with `[`, a class declaration probably does not parse as class declaration anymore, so you cannot just reuse it and make it child of the array expression (what you could do if it was just another bracket pair).

> So then is the recursive descent parser mentioned language-independent or language-dependent?

The parser is language-independent, but the tokenizer used by the parser looks up the tokens of syntax highlighting to decide if a bracket character is an opening/closing bracket or just text.

(author of the blog post here, personal opinion)

Tree-sitter is much more general (and I guess way more complex) and most likely cannot use some tricks we use for "simple" bracket pair parsing. For example, we can almost always re-use nested bracket pairs when characters are inserted/deleted, because the bracket pair language is so simple and it does not matter where a bracket pair is in the AST. But when parsing C# and adding a single opening bracket at the beginning of the file, I doubt namespace/class declarations stay namespace/class declarations.

Also, long lists in Tree-sitter seem to cause linearly growing incremental parsing time - that's why we use balanced (2,3) trees. You can try it out on their playground [1] by selecting JavaScript and adding some 100k `{}`s. On my machine, adding a single character takes 50ms. When there are 200k bracket pairs, it takes 100ms. When all these brackets are contained in a single bracket pair however, adding characters after this single root pair is fast again (<1ms). But to be honest, Tree-sitter is still mind boggling fast.

[1] https://tree-sitter.github.io/tree-sitter/playground

As far as I know though, tree sitter has problems with really long lists and even incremental parsing gets slower linearly when extending the list.

Also, to my knowledge, tree sitter cannot move nodes around (which is also very hard for languages that are not as simple as the Dyck language [1]).

For bracket pairs, you can easily reuse all (...)-pairs in the following example, even though their height in the AST changes significantly: old text: (...)[(...)] new text: {{(...)}(...)}

[1] https://en.wikipedia.org/wiki/Dyck_language

Author of the blog post here.

We openly discussed various approaches with CoenraadS and other extension authors here: https://github.com/microsoft/vscode/issues/128465#issuecomme...

i or some hyper real numbers are neither irrational nor rational. Basically all crazy extensions of R used to solve even more crazy problems. They don't really exist naturally (and you can make up your own field extension of R as you wish), but they are handy if you want to compute stuff.

But by definition there are no real numbers that are neither rational or irrational.

You can easily define + on natural numbers and * on integer numbers without running into problems! Thus there is no cirularity here.

It is only solid as long as you don't define irrational numbers literally as everything that is not rational.

I'm sure there are more elegant approaches, but I would start like this:

A number is an imaginary (as in made up by humans, not as in complex numbers) object that solves certain equations. It is not well defined and should not be used as basis for other definitions.

"Natural numbers" can be constructed directly and have a well known notation. Integer numbers are used to make the equation "a + x = b" solvable by x for every natural number a and b.

Rational numbers (Q) make the equation "ax = b" solvable by x for any non-zero integer a and b.

The algebraic closure of Q (=: Q*) makes the equation P(x)=0 solvable by x for any polynomial P.

The definition of R is more complex. I guess I would simply say it contains numbers to solve equations like sin(x)=0 by x.

This makes it very clear that -3 or 0 apples don't exist. These numbers just have the purpose to solve equations which makes them handy if you want to compute stuff.

Well, the peano arithmetic can be described directly as first order logic without set theory ;)

I'm fine with having an intuition for sets, but I think reals really should be defined properly. At least, R should not be confused with the algebraic closure of Q.

You are right, I didn't teach low level math courses, but this brain washing is also precisely why I didn't understand math in high school. You cannot argue with this kind of definitions. Everything feels as if it was randomly defined by the teacher. This "intuition" simplifies teaching, but makes understanding harder. It is like a game where you invent rules as you play. No student can win this game.

> Irrational numbers are defined as any numbers that cannot be written as a ratio of two integers.

> Finally, the set of real numbers, denoted R, is defined as the set of all rational numbers combined with the set of all irrational numbers.

I'm sorry, this is not how math works. Reals are basically defined as number. But what is a number?

Also the definition of Q is missing the quotient construction (or any motivation of how to deal with ka/kb = a/b).

Btw if you are interested in configuring line endings in the git config for good, you might find this tool handy:

https://hediet.github.io/git-line-endings/

A github action brute forces all combinations of line endings and tries out what happens on checkout etc.

It is a nice twist, but I would still consider the title click bait. I like hn for having no click bait.

With today's TypeScript, a lot more crazy stuff is possible now than what was used to demonstrate turing completeness in the issue.

While it was surprising in 2017 that TypeScript types could be used to run turing machines, with the addition of conditional types, proper support for recursively mapped types, string pattern matching and property renaming, it no longer surprises me at all.

Heck, someone implemented a static string parser + compiler + VM on top of TypeScript types.

If you are into visualizations, you also might find my debug visualizer extension for vscode helpful:

https://github.com/hediet/vscode-debug-visualizer

When debugging JS, there is a nice way to provide visualizations for application specific objects without touching the application code.

Combined with time travel debugging which allows to step backwards, it is really easy to understand complex algorithms:

https://github.com/hediet/vscode-delorean-js-debug

The visualization library is independent and open source. There is also a rust cli and a web playground. I'm very open for contributions! (especially new visualizations)

I love such visualizations, nice work! Does this work for any git repository?

Btw. for a visualization of all the git line endings settings, you might find this tool helpful: https://hediet.github.io/git-line-endings/ (just finished this tool this week)

Author of the drawio extension here, nice to see you using it!

I can highly recommend using the *.drawio.svg extension though! Svgs also work in Github readmes and perform much better overall. They also work much better over liveshare!

I have heard the same but also made the same observations. Something seems to be off.

TL;DR: Compile SQLite to JS with emscripten, implement a virtual fs in JS to stream chunks of a statically hosted (readonly) SQL database.

If queries make use of indices, only a fraction of the database needs to be downloaded.

Also, you can use SQLite to query the DOM.

Sadly, this is a known problem. Theoretically, you can use Chrome headless to render such SVGs into PDFs.

Afaik they only wanted to get rid of the io tld, as it is quite insecure.

You can find it here: https://marketplace.visualstudio.com/items?itemName=hediet.v...

Like draw.io, it is open source! (https://github.com/hediet/vscode-drawio)

I use drawio, as those diagrams are quite future proof (drawio is open source, very old and you can embed diagrams in svg files) but also very expressive (you can even use latex inside drawio diagrams).

Since I created a drawio integration extension for VS Code, I tend to create much more diagrams during coding, as they are really cheap to create. There is also an extension for IntelliJ and the diagrams work nicely in github readme files. After moving diagrams closer to code, I noticed that it is much easier to keep them in sync with the code base. Especially as PRs changing the code structure can include diagram changes at the same time.

I use them to model simplified class diagrams for documentation purposes, to model data flows, to create primitive mockups, to show the relationship between UI components (as embedded screenshots) and to show component dependencies. I try to follow UML, but I don't care about machine readability and prefer readability over UML compliance.

You can find some uses-cases of those diagrams here (https://dev.to/hediet/create-diagrams-in-vs-code-with-draw-i...).

I guess the entire entertainment industry burns much more money every year than all space missions combined. I would definitely prefer to see mankind visiting another planet over some stupid reality show.

I'm quite happy that I have absolutely no idea what kind of argument could possibly be employed to solve any of those problems. No danger of wasting an endless amount of time here.