Stockfish on github

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish on github

Post by mcostalba » Wed Oct 05, 2011 5:09 am

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.

User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 2:27 pm

Re: Stockfish on github

Post by Don » Wed Oct 05, 2011 3:52 pm

mcostalba wrote: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

User avatar
Graham Banks
Posts: 33251
Joined: Sun Feb 26, 2006 9:52 am
Location: Auckland, NZ

Re: Stockfish on github

Post by Graham Banks » Wed Oct 05, 2011 5:42 pm

Joerg Oster wrote: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. :D

Joerg.
Ditto. :)
My email addresses:
gbanksnz at gmail.com
gbanksnz at yahoo.co.nz

UncombedCoconut
Posts: 319
Joined: Fri Dec 18, 2009 10:40 am
Location: Naperville, IL

Re: Stockfish on github

Post by UncombedCoconut » Thu Oct 06, 2011 7:47 pm

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
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish on github

Post by mcostalba » Thu Oct 06, 2011 9:08 pm

UncombedCoconut wrote: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
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish on github

Post by mcostalba » Fri Oct 07, 2011 4:53 am

mcostalba wrote:
UncombedCoconut wrote: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
Posts: 319
Joined: Fri Dec 18, 2009 10:40 am
Location: Naperville, IL

Re: Stockfish on github

Post by UncombedCoconut » Fri Oct 07, 2011 8:33 am

mcostalba wrote:
mcostalba wrote:
UncombedCoconut wrote: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
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish on github

Post by mcostalba » Sat Oct 08, 2011 9:32 am

UncombedCoconut wrote: 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
Posts: 319
Joined: Fri Dec 18, 2009 10:40 am
Location: Naperville, IL

Re: Stockfish on github

Post by UncombedCoconut » Sat Oct 08, 2011 8:04 pm

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
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish on github

Post by mcostalba » Sat Oct 08, 2011 8:22 pm

UncombedCoconut wrote: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

Post Reply