Stockfish on github

[mcostalba]

Hi Ingo, we are quite confident a possible 2.2 release will show a very little increase, we have improved our testing skills

Let's see how it goes the Github experiment, if nothing happens in say some months, we will release what we have, if we are lucky and people contribute (or even me and Joona if we find some time) we will do the usual release.

@Jouni: I was referring to the recently released Pascal sources:

http://talkchess.com/forum/viewtopic.php?t=40414

@david: We didn't write the wiki when we had time. I think it will be difficult we do it now anyhow the best documentation is that on chessprogramming.wiki, once you have read and understood that then reading SF sources becomes very clear.

[Don]

Me and Joona are fading out from this wonderful chess engine world.

I have recently changed my job and I have almost no more time to dedicate to this hobby and Joona is in a similar condition. This is a pity somewhat but, hey, it is how things go, nothing is forever. We will continue with Stockfish but at a much reduced effort. So we were wondering what we could do now. And we had the idea to push our private git repository to github, so that everybody is free and even encouraged to contribute with patches, like it is common practice in open source development. We think our git tree is very valuable, not only for contributors but also for all the developers, especially the ones of strong engines, that will see in great detail what has been done, what has been proven to work and why: our git tree is really a kind of detailed diary of more than 2 years of developing of a world class engine. In my opinion is more valuable than sources or documentation and is the best gift we can give to this community.

In our dreams maybe it will attract some talent and create a little developer community around SF. I don't know if this will turn real or is just wishful thinking, but anyway me and Joona will continue to maintain SF and will gladly apply the patches that we will receive.

The rule to apply patches are very simple:

- If a patch is a "non functional change", for instance a clean up or a code simplification (we care a lot about code cleanups) will be applied without testing, just after a quick scrutiny to verify that actually does not change functionality and is really a code improvement.

- If a patch is advertised as an ELO increase stuff, then should be backed up with serious testing data and anyhow will be tested again by us before to be applied.

- Patches that add big chunks of code will not be accepted, in particular I am not willing to add tablebase support thank you.

- As common with git, patches will be applied with the author name of the submitter, that is the author of the patch.

Probably we will do a last release before pushing to github, so to avoid fostering wild compiles directly from the tree and also to have a clean starting point.

Now it's up to you, we'd really love to hear comments from you. If this idea can be interesting, there is someone wondering to contribute or is just business as usual.

Thanks
SF Team

It's not going to be the same at all with you guys "fading out" as you say. I hope you don't completely drop off the face of the earth and that you pop in once in a while to comment.

I have to say I'm a little disappointed as it was my hope to see several original programs take the lead on the rating lists. Stockfish is one of the best candidates for this. However, it's quite likely that people will contribute to stockfish and that it will continue to improve and I hope you guys continue to stay at least partially involved.

Don

[Graham Banks]

Hi Marco,

Stockfish gave me so much fun over the past few years and I learned at least a little bit from it. So many thanks for a wonderful engine to the whole SF Team!

And all the best to you and Joona in your new jobs.

Joerg.

Ditto.

[UncombedCoconut]

I'd like to echo everyone else's sentiments: I've enjoyed Stockfish a lot, for both its use as a world-class engine and its very nice code. I hope everything goes well for all of you, and that in time you may return to this addictive hobby (before withdrawal sets in ).

I have a nitpick though. Commit 1036cadcecc43737a1234eec00960a5a81073971 breaks the UCI spec's rule "in k-best mode always send all k variants in k strings together." Are you sure that's a good idea? It sounds hard to test exhaustively that no GUI will have a problem.
To compare with what other engines do:
Houdini 1.5, Critter, SF 2.11, Komodo, and Spike are all compliant.
Spark is similar to SF-dev.

[mcostalba]

Are you sure that's a good idea?

I am sure it is a good idea, I am not sure it doesn't break UCI protocol. Thanks for pointing this out, I will think about reverting the patch....

[mcostalba]

Are you sure that's a good idea?

I am sure it is a good idea, I am not sure it doesn't break UCI protocol. Thanks for pointing this out, I will think about reverting the patch....

Actually on a second thought I see that all the GUIs should handle cases in which the output lines are less then the multi pv number because they should handle cases in which there is only one possible reply. So although perhaps not fully conformant (to a weakly defined protocol) I don't think this can break anything.

[UncombedCoconut]

Are you sure that's a good idea?

I am sure it is a good idea, I am not sure it doesn't break UCI protocol. Thanks for pointing this out, I will think about reverting the patch....

Actually on a second thought I see that all the GUIs should handle cases in which the output lines are less then the multi pv number because they should handle cases in which there is only one possible reply. So although perhaps not fully conformant (to a weakly defined protocol) I don't think this can break anything.

What if after each set of MultiPV lines it thinks it has the engine's full opinion?
You would see flickering at low depths as the GUI changes its mind about how many lines are being considered. At high depths, you might lose valuable information from the lower depth.
This is an issue that the GUI and the engine can both prevent. I think the UCI spec makes this one the engine's problem.

[mcostalba]

This is an issue that the GUI and the engine can both prevent. I think the UCI spec makes this one the engine's problem.

Ok I have reverted the patch, could you please verify it works for you ?

Thanks
Marco

[UncombedCoconut]

It works perfectly again. Thanks!

Sadly, the LTO patch broke compilation for me and might for others. -flto works just fine, but adding -static tells the linker to use static versions of all system libraries. For most programs this is undesirable. But I can live with it. I'd say you needn't take action unless you agree with me or somebody else complains.

I just wish you could have seen the look on my face when I saw

Code: Select all

‎/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc

I think it would have made you smile.

[mcostalba]

It works perfectly again. Thanks!

Sadly, the LTO patch broke compilation for me and might for others. -flto works just fine, but adding -static tells the linker to use static versions of all system libraries. For most programs this is undesirable. But I can live with it. I'd say you needn't take action unless you agree with me or somebody else complains.

I just wish you could have seen the look on my face when I saw

Code: Select all

‎/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc

I think it would have made you smile.

Tom (the patch author) says:

Code: Select all

Ubuntu 11.04 works fine with -flto. I am currently not at home but the
ubuntu 11.10 beta2 on my notebook needs -static as an additional flag. I
think that is a bug but -static is ok for distributing the binary any way.

What do you mean by "broke compilation" ? You needed to remove -static to compile ? And also what is your environment ?

Thanks
Marco