Compile of Sashimi engine

[kiroje]

I found this one https://github.com/zxqfl/sashimi

Which is written in Rust, but I seems interesting and a nice level of playing strength.

Couldnt find any windows compile of this, is there anyone that have that(or could make it ?)

Thanks

[mvanthoor]

I'm writing my own engine in Rust, so I have the complete development environment installed. I'll try and compile it somewhere in the next few days.

[kiroje]

I'm writing my own engine in Rust, so I have the complete development environment installed. I'll try and compile it somewhere in the next few days.

Thanks that would be great !

[mvanthoor]

Edit: about two years old. I've found something about it on Talkchess, where someone got errors regarding libc; don't know which OS. It might take some doing. It depends on what Rust features the engine uses, on the dependencies it has, and how they behave in new Rust versions.

Cicada, also written in Rust, is about 2.5 years old and is an edge case; it compiles, but with a lot of deprecation warnings. Crabby, about 5 years old, only compiles with -some- nightly/alpha Rust versions (such as 1.11 nightly) as it uses experimental features that either never made it into Rust, or not in the way they were in that nightly version.

I'll see what I can do. With some luck, if it uses Rust 2015 and no nightly features, it should just compile.

Ah, there's the reason why it's so small :p

Code: Select all

extern crate shakmaty;
extern crate chess;
extern crate mcts;

It depends on (chess) libraries that already implement a big part of the chess rules and logic

[mvanthoor]

I've tried to compile this, but failed.

I'm hitting this snag:
http://talkchess.com/forum3/viewtopic.php?t=69454

Back then, it could be resolved to install the Rust nightly beta version as available at that moment. It is still available, and I've installed it, but it still doesn't work. The crate "madvise" depends on "libc", and it can't find some of the constants in there. Madvise has a dependency of "at least libc 0.2.29", and it hasn't been updated in three years. I am therefore assuming that Cargo (Rust's package checker) is thus downloading the most recent 0.2.x libc version, and that this version isn't compatible with the madvise crate anymore.

I've tried the nightly version that worked in the thread above, and it doesn't work now. I've also tried to revert to the commit that was current at the time of that topic, and it still doesn't work.

Sorry for the dissapointing result.

I'm not going to debug the madvise crate, so even if the solution would be simple, I'm unwilling to put work and time into a project that uses dependencies that haven't been touched for three years and are now broken. (The project itself hasn't been touched for nearly two years apart from changing a dependency setting.)

This is THE main reason why I dislike the trend of Go, Rust, node/npm pulling in their dependencies from the internet. You can't just download the dependency, install them in your project, and then use them for 20 years if you so please. In the current state, a program can just suddenly break and fail to compile if a dependency changes. Therefore I'm very, VERY reluctant with regard to including dependencies in my chess engine. I only use the best maintained and most well known open source dependencies (such as the RAND crate), or dependencies that provide some functionality that make life easier and code prettier to read, but that can be stripped out of the program in half a day's work on a whim if need be (such as if_chain).

[kiroje]

Ahh too bad, but thanks alot for putting some time on it and trying to get it to work.

Again thanks for the try.

[JohnWoe]

It requires cargo to build and lots of dependencies. No wonder it doesn't work. Never understood this cargo system. Only way to fix it would be pull all that dependency crap and build a static package.

I personally stay away from all libraries, frameworks (Especially JavaScript frontend frameworks ) and complex build systems where you pull crap over internet. They are all full of bugs and slow. A major pain in the ass to maintain manifests, installers, passwords, usernames ... to packaging websites etc.

[mvanthoor]

It requires cargo to build and lots of dependencies. No wonder it doesn't work. Never understood this cargo system. Only way to fix it would be pull all that dependency crap and build a static package.

I personally stay away from all libraries, frameworks (Especially JavaScript frontend frameworks ) and complex build systems where you pull crap over internet. They are all full of bugs and slow. A major pain in the ass to maintain manifests, installers, passwords, usernames ... to packaging websites etc.

To some extent, you're correct, but Cargo (or the package managers in general) aren't the problem. Cargo is just a package manager, just like apt on Debian, npm in node, pip for python, composer for PHP, and so on. It also works the same. It looks in cargo.toml, and sees that a program needs THIS, THAT, and SUCH. And then it downloads those dependencies and evaluates them, and if necessary, downloads more dependencies (recursively).

When everything it downloaded, cargo kicks off rustc, which is the compiler, which is also configured by cargo.toml.

So in essence, cargo is "make", with a built-in dependency downloader.

The problem is the fact that you can't just download the packages, and then put them somewhere for safekeeping. (PS: there is a way to download the ENTIRE crates.io website, but who wants THAT, apart from maybe a company?)

=== PACKAGE MANAGER RANT COMING UP. STOP HERE IF NOT INTERESTED. ===

What you should NEVER do, is create a dependency A that relies on dependency B, and then state "B needs to be at least version 1.2.0" or something like that. If you do so, Cargo will happily download version 1.2.375 of B if it exists, but if something has changed that breaks A, everything depending on A will break.

A dependency maintainer should take care that nothing breaks as long as he doesn't upgrade X in the x.y.z semantic version... but many programmers don't really care. (And libc is infamous for that. Search for libc/Linus Torvalds, where he has a HUGE rant about exactly this issue.)

This is not a problem with Rust. This is a problem with ANY system that uses package managers: dependency hell.

It is the one thing I don't like about Rust. Mozilla should just go and merge the top crates (RAND, Serde, Tokio, async, crossbeam, hyper, and so on) and everything they depend on, in an additional library download. Just download and install Rust version X, and if you then install the SLEC (Standard Library Extension Crates) package, you have like... 10, 20, 30...(or how many they'll put in) of the most well maintained and important libraries. In that case, many programs could be written without EVER having to download something from Crates.io.

It has been done before. C++ has a huge standard library, but before C++11, it was basically the default to install the BOOST library because it added so many things C++ was missing as compared to newer languages. Many people programming in C basically also installed BOOST, and then used bits of pieces from it. Technically, they were writing "C++" programs, but only using the C-subset of C++, and BOOST. After C++11 and C++14, is basically becoming obsolete.

I'd love to see the same thing happen to crates.io with regard to the big important crates. Keep Crates.io for people to share their stuff if they want, but if something appears that is huge, important or great, take it off and maintain it in an extension package to the standard library.

One example would be "if_chain". Rust can't chain some types of if-statements (if let...) because they're not expressions. They've been arguing for three years on how to fix that (or if they should, even). Not being able to chain "if let" with other if-statements makes the code ugly and unreadable. if_chain solves it:

Code: Select all

if_chain! {
	if x == 5;
	if y > 10;
	if let Some(a) == stuff
	if let Some(b) != whatever
	then {
		do_something()
	}
	else {
		burn()
	}
}

if_chain is beautiful if you need a statement that checks lots and lots of different types of "if" that need to be true. Instead of having this in a downloadable crate, Rust should just incorporate it into the language, in the standard library, or at least in a standard library extension.

Uh... rant over.

[Ras]

Cargo (or the package managers in general) aren't the problem.

In a way, they are - because they make dependencies "easy". The consequence is that people use them nilly-willy so that package managers create dependencies, and lots of them recursively. That's the same in every such ecosystem. You install some small package under Linux, and before you look, 120 packages are installed. You type NPM for "hello world", and 95 GB of JS trash get downloaded, then compiled for 7 days, and you end up with "only" 2 MB of JS code by nobody knows whom from all over the world.

Now with websites, nobody cares whether the project will even build three weeks from now because by then, the whole website tech stack will have been replaced by one of the 200 new JS frameworks that will have appeared by then. Mozilla is part of this "move fast and break things" culture because nobody needs to build a three years old browser full of security holes. Even Mozilla's ESR cycle is just one year. It's the culture of an ecosystem that has neither use for nor appreciation of longevity.

[Alayan]

This is THE main reason why I dislike the trend of Go, Rust, node/npm pulling in their dependencies from the internet. You can't just download the dependency, install them in your project, and then use them for 20 years if you so please. In the current state, a program can just suddenly break and fail to compile if a dependency changes.

That's why dynamic linking with shared libraries is evil.

On modern hardware, the wasted disk space and RAM space of having multiple time the same library is negligible compared to compatibility issues. The auto-update of dependencies is not what I would call a feature.

I've contributed to a project that had to do custom changes to a lib (they were refused upstream but important for our use case). You can imagine what happened when some "smart" distro packager decided to go against our strong advice of statically linking to our dependencies, because the policy of their distro was "shared libraries everywhere"... Of course when the software gets broken like this, we get users complaining to us about the resulting bugs.