A little reminder to Stockfish Team

[Damir]

Please when you release 3-4 versions at the same time, remember to name them differently. I can not create new engine because the exe is exactly the same, and can not test these engines offline against each other, because one of them already exists. It can be really frustrating. After I have tested one engine I must delete it and create new one under the same name.
It is time consuming. Please fix this.

[Nordlandia]

Please when you release 3-4 versions at the same time, remember to name them differently. I can not create new engine because the exe is exactly the same, and can not test these engines offline against each other, because one of them already exists. It can be really frustrating. After I have tested one engine I must delete it and create new one under the same name.
It is time consuming. Please fix this.

Just look, - 6 versions released one after another.

http://abrok.eu/stockfish/

[Damir]

Yes, that is the site I was talking about.

[zullil]

Yes, that is the site I was talking about.

As I understand things, that site is not controlled in any way by the Stockfish developers.

And why can't you just rename the .exe yourself, to whatever you want?

[Damir]

Renaming inside the exe is a little more complicated than just renaming exe, would not you agree ?

[bnemias]

A bumped build / revision number instead of a date might be better. Date formats vary by region for one, confusing some. Also, build numbers (with prepended zeros) would get sorted properly in directory listings.

[zullil]

Renaming inside the exe is a little more complicated than just renaming exe, would not you agree ?

Yes, I agree. So you are referring to the uci id name---for example: id name Stockfish 180316 64 POPCNT?

The date that appears is determined at compile time, by the code below. I suppose this could be further refined using the __TIME__ macro. Then, as long as the abrok site compiles the code as soon as a functional change is committed, you should get what I think you want. Sorry for my earlier misunderstanding.

Code: Select all

/// engine_info() returns the full name of the current Stockfish version. This
/// will be either "Stockfish <Tag> DD-MM-YY" &#40;where DD-MM-YY is the date when
/// the program was compiled&#41; or "Stockfish <Version>", depending on whether
/// Version is empty.

const string engine_info&#40;bool to_uci&#41; &#123;

  const string months&#40;"Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec");
  string month, day, year;
  stringstream ss, date&#40;__DATE__); // From compiler, format is "Sep 21 2008"

  ss << "Stockfish " << Version << setfill&#40;'0');

  if &#40;Version.empty&#40;))
  &#123;
      date >> month >> day >> year;
      ss << setw&#40;2&#41; << day << setw&#40;2&#41; << &#40;1 + months.find&#40;month&#41; / 4&#41; << year.substr&#40;2&#41;;
  &#125;

  ss << &#40;Is64Bit ? " 64" &#58; "")
     << &#40;HasPext ? " BMI2" &#58; &#40;HasPopCnt ? " POPCNT" &#58; ""))
     << &#40;to_uci  ? "\nid author "&#58; " by ")
     << "T. Romstad, M. Costalba, J. Kiiski, G. Linscott";

  return ss.str&#40;);
&#125;

[MikeB]

Renaming inside the exe is a little more complicated than just renaming exe, would not you agree ?

Yes, I agree. So you are referring to the uci id name---for example: id name Stockfish 180316 64 POPCNT?

The date that appears is determined at compile time, by the code below. I suppose this could be further refined using the __TIME__ macro. Then, as long as the abrok site compiles the code as soon as a functional change is committed, you should get what I think you want. Sorry for my earlier misunderstanding.

Code: Select all

/// engine_info() returns the full name of the current Stockfish version. This
/// will be either "Stockfish <Tag> DD-MM-YY" &#40;where DD-MM-YY is the date when
/// the program was compiled&#41; or "Stockfish <Version>", depending on whether
/// Version is empty.

const string engine_info&#40;bool to_uci&#41; &#123;

  const string months&#40;"Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec");
  string month, day, year;
  stringstream ss, date&#40;__DATE__); // From compiler, format is "Sep 21 2008"

  ss << "Stockfish " << Version << setfill&#40;'0');

  if &#40;Version.empty&#40;))
  &#123;
      date >> month >> day >> year;
      ss << setw&#40;2&#41; << day << setw&#40;2&#41; << &#40;1 + months.find&#40;month&#41; / 4&#41; << year.substr&#40;2&#41;;
  &#125;

  ss << &#40;Is64Bit ? " 64" &#58; "")
     << &#40;HasPext ? " BMI2" &#58; &#40;HasPopCnt ? " POPCNT" &#58; ""))
     << &#40;to_uci  ? "\nid author "&#58; " by ")
     << "T. Romstad, M. Costalba, J. Kiiski, G. Linscott";

  return ss.str&#40;);
&#125;

and the for the exe on linux or mac- you can use this in the makefile:

Code: Select all

mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
current_dir := $(notdir $(patsubst %/,%,$(dir $(mkfile_path))))
PROGRAM= $(current_dir:.d=) 

for example name the directory with the source files Program-1.7.d

that will take the directory name, drop the ".d" and name the exe "Program-1.7"

makefiles are the same, the exe's generated are different...this is the external naming process
, not the internal but probably something similar could be used

[rainhaus]

In fact, three different engines with only one name!? That can definitely not be the builder’s intention. Let’s hope the busy FISHTEST people will take notice and take action on your message. If master Zulli's listing shows the right way, so much the better. Unfortunately I'm allergic to program code
Giving a further chance for realizing the bug, here is a little more detail:
Three Stockfish development versions were released on Fri Apr 8 by the authors DU-jdto and Alain SAVARD (http://abrok.eu/stockfish/), but unfortunately under the same file name stockfish_16040820_*.exe. This name is enclosed in all 32 Bit-, 64 Bit-, Windows-, Linux –adaptions.
It is not very difficult to guess that 160408 means YearMonthDay (I think, a very user-friendly idea) and 20 should be quasi the counter to distinguish several engines within the same date. But as you see all 3 executables are counted with number 20.
With the next versions by M. Costalba stockfish_16040909_x64.exe and “stockfish_16040910_x64.exe” the numeration is working correctly again. Temporarily or definitely, manually or automatically, these are the users questions!?
__________________________

However, your way of frustration by installing different engines with an identic name and to get them running under one GUI I couldn’t follow entirely. The procedure seems very easy to me. You must nothing delete, you must nothing “rename inside the exe” (whatever that means), you need no longer work as normal, even you need no longer time and you can let sleep all code deep below the surface.
Which Operating System, which GUI ? For example, Windows produces automatically 3 files stockfish_16040820_x64.exe, stockfish_16040820_x64(1).exe and stockfish_16040820_x64(2) in the download folder. Then you can use the executables to install the corresponding UCIs. You know, displeasuring the file names or parameters you can change it ad libidum creating a new engine. With Fritz there must be implied the original file name, under Arena must not.

So I’ve done it for testing purpose and the 3 developer-UCIs perform a proper tournament as well under Fritz 12 as under Arena 3.5. I’m sure it will also work with the Shredder Classic.

rn

[syzygy]

In fact, three different engines with only one name!? That can definitely not be the builder’s intention. Let’s hope the busy FISHTEST people will take notice and take action on your message.

As has already been explained, the abrok builder has nothing to do with the SF developers.

The SF developers are developing SF towards the next SF release. The current state of the development process can be followed on github.com. Everybody who is interested in the latest development version can pull the latest code from github and compile it. Or they can go to abrok and download the latest compile. But these are not releases and you can in no way expect the SF developers to care about what you are getting. Again: the SF developers are working towards the next release, and in the meantime you are free to look into the kitchen and mess around with development versions, and you are also free not to do that, but you cannot expect SF developers to spend any time or effort polishing those non-releases. Because they are not releases.