almost freezes my PC

[tissatussa]

i played a few games with your engine (compiled by GTK-4 source) and it almost made my PC freeze.

it happened after my move e4-e5, which attacks Qf6 and gives Black a problem : where does the Queen go? It seemed the engine couldn't decide and went on to think for a long time and finally froze my PC (the seconds on my OS clock did no longer update) until it came back with its move : Qg6 (why not Qh6?).

[ i'm on Xubuntu 22.04 ]

[StefanSalewski]

Thanks for reporting. I have to admit that I have done nearly no Nim work in the last 8 months, and I am unsure if I will be able to touch Nim at all again. I am not too sensible, but all the unfriendly behaviour of THEM was finally too much for me.

I wonder that you have been able to install the Gintro GUI at all, some people reported that there was a tiny issue with Nim 2.0. Have THEY finally decided to fix it in the Nim compiler?

For the chess game, I am currently thinking about porting it to Rust just for fun, maybe in Christmas holidays. I have learned some Rust in the last weeks, which was a pleasant experience.

For your actual issue, my guess is that it may be related to the depth extensions which the engine makes. There are various extensions, for captures, check, and other "interesting" moves. They may accumulate too much.

If you know already some Nim, you may investigate that yourself: At the bottom of one of the two Nim files, there should be an example to set up manually a position, and there was a way to start from that position. I did that to test some endgames. I can not remember details, but should be easy. Then you would have to temporary remove some of the depth extensions.

I can not promise that I will find motivation to touch the Nim code myself again. I tried to do Nim work in the last summer multiple times, but felt tired and fully unmotivated immediately. Seems that comments like https://forum.nim-lang.org/t/10101#66729 has finally been too much for me. But I will let you know if I will have a version in Rust or another language available. I am also considering Mojo, Julia, Zig and some more. Rust is interesting, but I have still some doubts if it is really a good choice for creating application programs. Rust is not really difficult, but of course the Rust code is not as short, clean, and simple as Nim. I think I have still an old version of Nim with Gintro istalled of one of my computers, so maybe I will try the fix -- should take only a few minutes.

Best wishes,

Dr. Stefan Salewski

PS: If you still have fun with Nim, you may port the GUI to Owekettle or Figura, or one of the other 20 available toolkits. In very early days (2016) we had a NimX variant. I had always the hope that someone would extend the GUI a bit, for selecting color, setting up position, and saving games at least. But I think Nim has a few other chess engines now as well, maybe people prefer them.

[StefanSalewski]

OK, instead of watching some TV I did a short test: Obviously you are after e4-e5 in a very strong position. Qf6 is attacked, and has no escape. After your suggestion Qf6-h6 you (white) would reply with Ng5f7, and blacks rook h8 is lost.

So the engine did not make a real error. What you see as "freezing" is just a longer than average thinking time. The engine seems to notice its bad situation and tries hard to find an escape. Actually, it is some form of restriction of the very simple GUI: When the engine is running, there is no GUI update possible. To fix this, we would have to run the engine as a separate thread. That is possible, and for a real game we would do that, additional to add many more user configuration options.

For me, the more interesting question is, how you managed to archive such a strong position, and where the engine made a bad move long before to give white this advantage.

As you may know, the engine was written by me from scratch in late 2015 to learn Nim and to test my initial GTK3 bindings called oldgtk3. Later, I improved the engine and switched GUI to Gintro. In summer 2022, I finally cleaned up the engine a lot, and renamed the package from nim-chess to salewski-chess. I guess the reason for the renaming was already the unfriendly behaviour of THEM at that time. I still think that the engine is not that bad. For systematically improving the strength, one would need better debugging support with a way to set up positions and to save and load position, and to switch colors while playing. But actually, people like me who very rarely play chess may like a computer opponent that let one a chance to win. I think for the few games I did I won none, I was only able to keep a good position for a few moves, and than typically made a mistake.

[tissatussa]

..but all the unfriendly behaviour of THEM was finally too much for me..

i don't know exactly what you mean, but i read some other statements like this .. pitty, i did some programming in Nim and i like the language.

I wonder that you have been able to install the Gintro GUI at all..

i'm using Nim v1.6.12 and i had no problems installing Gintro.

I am also considering Mojo, Julia, Zig and some more.

i tried Julia also, before doing Nim, because Julia can be compiled too .. but Julia became difficult for me at some stage, so i decided to give Nim a try. And Julia does not seem to be fully open source.

i looked at Mojo too, but it doesn't seem to be public yet .. it seems interesting though.

Zig is a good alternative also .. i did not yet decide to learn it, but it seems OK.

..you may port the GUI to Owekettle or Figura..

Owlkettle is on my radar, Figura never heard of .. yes, i wil try. Most of those 20 are not really usable, i think (i did a comparison recently).

[tissatussa]

For me, the more interesting question is, how you managed to archive such a strong position, and where the engine made a bad move long before to give white this advantage.

well, i'm a club player around 1800 rating .. i played other games against your engine and most of the time i get a bad position (and i give up). I vaguely remember that game yesterday, there's a chance i can reproduce it .. you have no move log ..

indeed, just before the position of the diagram the engine seemed to realise it's in trouble and started "think" very hard ..

..we would have to run the engine as a separate thread..

recently i posted a question about threading / async in the Nim forum, https://forum.nim-lang.org/t/10613 , but i didn't get an answer which satisfied me .. i want to run an existing UCI engine (like SF) in a GUI like Owlkettle .. i can send you some code ideas to make it work, maybe you can help ?

[tissatussa]

from memory that game was like this .. i'm not fully sure about the exact move order, maybe we can reproduce it with the engine .. does it always play the same moves ?

[Event "human vs engine"]
[Site "Holland"]
[Date "2023.11.20"]
[Round "?"]
[White "Roelof Berkepeis"]
[Black "salewski-chess"]
[Result "*"]

1.d4 Nf6 2.Bg5 e6 3.Bxf6 Qxf6 4.Nc3 Bb4 5.a3 Bxc3+ 6.bxc3 Nc6 7.e4 d6 8.
Nf3 b6 9.Bd3 Bb7 10.Qd2 Kd7 11.O-O a5 12.Ng5 Ne7 13.f4 h5 14.e5 *

[tissatussa]

btw. also the language GO is worth learning, so i read .. many people are fan of it, it seems simple and complete, but.....it's from Google, so i try to avoid it --

[StefanSalewski]

i don't know exactly what you mean,

Well, I joined Nim in 2014, and from the beginning I found the behaviour of Rumpf and Picheta, and later the other guy from Croatia, very unfriendly. Not only to me, but to many more people. I guess this unfriendliness is the main reason that so many people left Nim in the last few years. We had really a few bright and friendly people in the community, but most are gone. Some have even be banned, like Disruptek, Kruxx, or Timothee.

As the language, Nim is still my favorite. And I have still the PCB/EDA tool https://github.com/StefanSalewski/SDT which I should continue in Nim, as porting to another language would be a lot of work with no benefit. In the last 9 years, I have investigated many thousand hours of unpaid work into Nim -- Gintro, the Book, RTree, Delaunay-triangulation, and some more. But when all fun and motivation is lost, it is nearly impossible to continue.

I have not yet found a real replacement for Nim. The Nim-skull fork may still be an option, but I fear it would remind me too much on all the Nim trouble.

Mojo and Switch would be language I may like, but Mojo is not really open source, and Swift is Apple. Note, that Mojo is available for Ubuntu already for local install.

Rust is not that bad. Good documentation, many packages, all just works. And people seems to be bright and friendly.

When you have still Nim 1.6.x, then Gintro may still work for you. But I got a few reports that they broke it for Nim 2.0, maybe intentionally to block Gintro. Fixing it should take only a few minutes, it is something with tuple unpacking, which was working for 8 years, and then they seems to have broken it. But when I would fix, they may find other ways to break it again. And now there is some activity with owekettle and figuro -- figuro seems to be based on fidget of Mr. Treeform. Unfortunately I can not help you by porting the chess GUI -- whenever I should have some motivation for Nim work again, I will spend that on the book, or maybe on the PCB/EDA tool. The book is basically finished, but I intent to create a printed version in the next years, and for that I should do one more complete proofreading. Not that I assume that people really buy or read it, but it may just be a good feeling to be the author of a printed book. At least one person already bought the electronic version from https://nimprogrammingbook.com/

you have no move log

Actually it is available, when compiled with -d:salewskiChessDebug, but then there is a lot of other debugging garbage.

And Julia does not seem to be fully open source.

My feeling is that Julia is fully open source. Mojo is not, and I think it may never be really open source.

language GO is worth learning,

Yes, Go has now generics, which may make it more interesting. Go is popular, easy, has a large ecosystem, short compile times, good threading support (fibers). Not really a GREAT language still.

Zig is not really interesting for me, as I need automatic memory management for desktop apps.

So I will concentrate on Rust this winter. Rust has many interesting packages, including native GUI like Iced and Druid/Xilem and some more, and even working kernels like Redox. And Rust just works -- rust-analizer works, incremental-compilation works, packages work and have high quality. The documentation is free and of good quality. But no inheritance and subclassing is still a challenge for me. And the owner and borrowing system makes some data structures like graphs or doubly linked list difficult. But the advantage is, that most packages like RTree or Delaunay triangulation just exist in high quality, so no need to spend hundreds of hours to create them from scratch.

[tissatussa]

its second and third move were "inaccurate" according to the LiChess report .. and that's also what i think : it plays the Queen too early and Nc6?! before moving the c-pawn is not common, it can often give bad piece and pawn placements in the opening :

[Event "human vs engine"]
[Site "Holland @ https://lichess.org/CiU1r6lM "]
[Date "2023.11.21"]
[Round "?"]
[White "Roelof Berkepeis"]
[Black "salewski-chess"]
[Result "1-0"]

1.Nf3 d5 2.e3 Qd6 3.d4 Nc6 4.c4 dxc4 5.Bxc4 Nf6 6.O-O Be6 7.b3 Bxc4 8.bxc4 e6 9.Bb2 Qb4 10.Qc2 Be7 11.a3 Qa5 12.Nc3 Qh5 13.e4 e5 14.d5 Nd4 15.Nxd4 exd4 16.Nb5 Bd6 17.Nxd6+ cxd6 18.f3 d3 19.Qxd3 Qg5 20.c5 dxc5 21.e5 Nd7 22.f4 Qg6 23.f5 Qa6 24.Qe4 Qb6 25.Rab1 Qc7 26.e6 Nf6 27.exf7+ Kf8 28.Qe6 Qxf7 29.Bxf6 Qxf6 30.Rxb7 Qd4+ 31.Kh1 Qf6 32.Rfb1 Qxe6 33.fxe6 a5 34.Rb8+ Ke7 35.R1b7+ Kd6 36.Rd7+ Ke5 37.Rxh8 Rxh8 38.e7 Rb8 39.h3 Kf6 40.d6 c4 41. Rd8 Rb1+ 42.Kh2 c3 43.e8=Q c2 44.Qe7+ Kg6 45.Qe4+ Kh6 46.Qxc2 Rb7 47.Qd2+ Kg6 48.Qd3+ Kh6 49.Qe3+ Kg6 50.Qe4+ Kg5 51.Qxb7 Kf5 52.Rf8+ Kg6 53.g4 h6 54.Qe4+ Kg5 55.Qf5+ Kh4 56.Qh5# 1-0

[StefanSalewski]

Thanks for the detailed analysis. Actually an opening library would (drastically) improve playing strength. But with a library, one would just play against a database for the first few moves, which I consider as boring for an average player. I know the rule from beginner chess books that one should not move the queen too early, but the engine has no support for this rule. I observed that the engine actually moves queens early, but most of the time it sees the consequences and did it well.

For your mentioned Go language, I forgot that the performance of the executables seems to have improved also. Go was often considered as not very fast, but lately I saw some examples where Go was close to Rust and C. Go is additional a good choice for network related stuff, so maybe I should learn it at some time in the future.

[tissatussa]

Actually an opening library would (drastically) improve playing strength. But with a library, one would just play against a database for the first few moves, which I consider as boring for an average player.

yes, that's why i always disable opening Books in UCI settings.

mentioning the Rust language, maybe i should take a look .. it also has the Shakmaty chess library, am i right ? I guess you're planning to (re)write a chess engine ? And can Rust be used to create a GUI ? -- i come mainly from Python, i've used TKinter and i like it.

[StefanSalewski]

Yes, I think I will port salewski-chess to Rust -- as an exercise to learn Rust better.

The GUI story is one reason that Rust is my favorite after Nim: Use of bindings to GTK like Gintro can never be the optimal choice. Most newer languages have no own native GUI, not even Julia. One exception is Dart with Flutter. Rust has some native GUIs like Iced, and Druid/Xilem. Iced is already usable, Druid was usable, but was replaced by Xilem, which is in a very early state. But Rust has even more GUIs, some are web-based. And It has the gtk-rs bindings, which may be the best GTK bindings beside the Python bindings. So for my chess game I would start with gtk-rs, and maybe port later to Xilem. But actually, gtk-rs source code looks not that clean as Python or Gintro code. But that is compensated by the fact, that gtk-rs was created by a few bright people, and so support GTK really well, while my Gintro was created just by me, I spent "only" 1600 hours on it.

[tissatussa]

thank you very much for all this detailed info -- i will save this page !

[ closing the Issue now ]