Small compilation problem with Polyglot 1.4w23

[Olivier Deville]

Well... believe me, life is too short for such sterile arguments.

I am sure the end user does not want so many Polyglot forks.

Olivier

[Marc Lacrosse]

... then I cannot work with you.

Then you could consider switching back to other paths for improving Polyglot ...

May I suggest resuming our discussions regarding polyglot book-making heuristics and book tuning utilities ?

Marc

[H.G.Muller]

Well... believe me, life is too short for such sterile arguments.

I am sure the end user does not want so many Polyglot forks.

Olivier

The end user will only want one Polyglot. One that works well with WinBoard. (That is not overestimating the importance of WinBoard, but a logical consequence of the fact that other GUIs hardly need Polyglot, as they support UCI protocol natively.) I will do whatever it takes to make it available to them. If others, more qualified than I, think it is a good idea to sabotage their Polyglot so that it doesn't work well with WinBoard... Well:

1) I cannot prevent that, so why would I worry about it?
2) It is upto the users to decide what version they prefer.

I am sorry about this state of affairs, but it is not me that chooses it. I have _never_ made any insulting or derogatory remark, only well-founded criticism based on good arguments. People that cannot distinguish the two should indeed better ignore me than seek cooperation. And they better not utter threats unless they really mean it, as I will _always_ call any bluff. That is my (quite simple and straightforward) attitude, and if others think that is a problem, I consider it _their_ problem.

To come back to the point that seemed to trigger all this: I happen to think that if there exists a 1:1 translation of moves between WB and UCI protocol, because they both specify long-algebraic notation to be used, a UCI2WB adapter is totally out of line if it refuses to pass the message. That is not the task of an adapter. It is the task of the GUI to decide if it is going to accept the move. Not of the adapter. If someone disagrees with that, it would be interesting if he presented his arguments here as to why.

If someone, however, thinks that the fact that I have this opinion is a good reason to (out of the blue) "punish" the computer Chess community by sabotaging any future joint effort, ... Well I think that makes it clear to any reader which of us is out of line and putting his own interest above that of the community!

[Volker Pittlik]

... sabotage ...
...
2) It is upto the users to decide what version they prefer.

Saboteurs, rogues, cheaters. I as a user would prefer another tone in this forum primarily.
If that style of communication is the price of an improved xboard its to high.

... I will _always_ call any bluff...

I see such experts running into the nuts regularly.

[H.G.Muller]

Well, I don't play any poker. I do all my gmbling on the stock exchange, where the real money is...

I am sorry if you dislike my style of communication. Fixing the outcome of a game to your liking in violation of the rules _is_ cheating. How would you define cheating?

[Volker Pittlik]

.... How would you define cheating?

Changing the subject doesn't work with me.

[Eric Mullins]

No biggy guy.

In the makefile of Winboard, past and present versions, which compiles with Cygwin is an option that forces Cygwin to compile Winboard with the mingw compiler so that a dll file is not required to be used with Winboard. That's all I was asking for, I can whip a makefile up for myself some day to use with Polyglot. Cheers.

Take it easy man.

I wrote those makefiles for both winboard and polyglot.

For winboard, if you examine makefile.gcc, you will see a section about using mingw. You can enable or disable it, and winboard will build fine either way. There was a bug in winboard itself that prevented cygwin builds from working proplerly. I fixed it, so either way you choose to compile should work fine.

For polyglot, it's going to depend on where you got the source. I probably wrote the one Fonzy has in his tree, but there may not be a way to change if it uses cygwin or not, I really can't remember. Assuming there isn't a way, then I'm pretty sure it defaults to using -mno-cygwin, thus using mingw to produce a native win32 build.

If you got recent source from Michel, then the option to use MingW or not should already be present. It defaults to using a native win32 build, eg using mingw instead of cygwin.

[Charles Browne]

I wrote those makefiles for both winboard and polyglot.

Yes, I am aware you had a big hand in redoing/making the Winboard makefile and the Polyglot makefiles, too. I saw your name associated with them.

For polyglot, it's going to depend on where you got the source. I probably wrote the one Fonzy has in his tree, but there may not be a way to change if it uses cygwin or not, I really can't remember. Assuming there isn't a way, then I'm pretty sure it defaults to using -mno-cygwin, thus using mingw to produce a native win32 build.

No reference to mingw (-mno-cygwin) that I can see in any of Fonzy's B.'s Polyglot sources. All executables compiled with the makefile (I haven't tried the .ms one) require the dll file to function.

If I compile it with

g++ (-O2 or -O3) -mno-cygwin -o polyglot *.cpp

it functions fine as far as I can tell and does not require the dll file to work. I just need to really know if the above used to compile F. Bluemers' Polyglot is/are the best commands to use.

or...

am I safe in using the makefile in Michel's Polyglot sources to compile F. Bluemers' sources. Yea I could try it but the thing is that depending on how and what I use to compile it (the Polyglot sources), though I may not receive any compiler errors, I always come out with different size executable files.

If you got recent source from Michel, then the option to use MingW or not should already be present. It defaults to using a native win32 build, eg using mingw instead of cygwin.

Yes, I use "make -f makefile.gcc" with Michel's Polyglot and it compiles fine and does not require a dll file to operate.

[Eric Mullins]

No reference to mingw (-mno-cygwin) that I can see in any of Fonzy's B.'s Polyglot sources. All executables compiled with the makefile (I haven't tried the .ms one) require the dll file to function.

Ok. That means it defaults to a cygwin build, apparently. Sorry about that. That was back when I felt polyglot was best as cygwin build. I've since changed my mind on that subject.

If I compile it with

g++ (-O2 or -O3) -mno-cygwin -o polyglot *.cpp

it functions fine as far as I can tell and does not require the dll file to work. I just need to really know if the above used to compile F. Bluemers' Polyglot is/are the best commands to use.

Building it that way is fine, and probably best overall. The reason is that makefile.gcc isn't maintained. IIRC, I gave it to Fonzy near his w10 version. As he said earlier in this thread, he doesn't use gcc, so it's very likely that makefile is out of sync with current source anyway. So your own solution would mitigate all these problems.

or...

am I safe in using the makefile in Michel's Polyglot sources to compile F. Bluemers' sources. Yea I could try it but the thing is that depending on how and what I use to compile it (the Polyglot sources), though I may not receive any compiler errors, I always come out with different size executable files.

You could, but it will be a pain because in addition to various file name changes, the project is now in C instead of C++. I'd say it's more trouble than it's worth compared to your solution above.

Another alternative would be to add -mno-cygwin into the makefile you had been using at both the compile and link stages. You might run into sync problems with the latest source, but if you successfully built it (needing cygwin1.dll), then I would expect it to still be basically up to date with the source for a mingw build.

[Charles Browne]

Thank you for the indepth reply. I am content with what I am doing now and good to go.

I had forgotten about the language being changed in Michel's Polyglot (at your suggestion I believe) but I was aware of it.

As he said earlier in this thread, he doesn't use gcc...

Yes, a wrong assumption on my part. I figured that anyone that could program anything knows everything about everything; whereas people like me that can't program anything know nothing about nothing.


Like I wrote, I'm good to go and again I thank you for the explanation.

[H.G.Muller]

Changing the subject doesn't work with me.

So, you insist pressing it on, do you?

Very well, then, read back what you wrote: You prefer XBoard is not further developed because it might expose you to now and then reading words like "cheating", or "sabotage". It is difficult to sugar-coat it, so I will give it to you straight:

This borders on the most ridiculous thing I have ever read in my entire life!

If your sensitive nature doesn't bear exposure to horrible words like that, then simply don't read any posts of mine, so that others, who are less squeamish, can continue to enjoy an improved XBoard. If it is any consolation to you, your style of posting is at least an order of magnitude more offensive to me as mine is to you. But I never complained about it, because I am a grown-up, and I can take the abuse.

Is that enough 'on-topic' for you?

[Roger Brown]

Hello Gentlemen,

I just saw this discussion.

I would like the freedom to moderate the board so please, no assistance.

Volker, I consider you a friend in this world as well as in the real one - you are one of the few persons who has real world data on me. Step away from this please.

H.G. - well I have to say that you do seem to generate a lot of heat but I really have not seen anything which requires moderating. The fact is, I have seen you admit to numerous bugs (unforseen features) in your code, admit to hacks, admit to ignorance and generally just take on critical comments by improving Winboard. That is sufficient humility to me, you certainly don't have to lose your usual, ah, effervescence.



Let us just take a step back and realise that all of this is a hobby, supposed to be fun and damnit, will not matter as much as taking time to love our significant others, smell a flower and appreciate the beauty of a sunset.

Breathe in and out.

Again.

See?

Later.

[F. Bluemers]

Well... believe me, life is too short for such sterile arguments.

I am sure the end user does not want so many Polyglot forks.

Olivier

The end user will only want one Polyglot. One that works well with WinBoard. (That is not overestimating the importance of WinBoard, but a logical consequence of the fact that other GUIs hardly need Polyglot, as they support UCI protocol natively.) I will do whatever it takes to make it available to them. If others, more qualified than I, think it is a good idea to sabotage their Polyglot so that it doesn't work well with WinBoard... Well:

1) I cannot prevent that, so why would I worry about it?
2) It is upto the users to decide what version they prefer.

I am sorry about this state of affairs, but it is not me that chooses it. I have _never_ made any insulting or derogatory remark, only well-founded criticism based on good arguments. People that cannot distinguish the two should indeed better ignore me than seek cooperation. And they better not utter threats unless they really mean it, as I will _always_ call any bluff. That is my (quite simple and straightforward) attitude, and if others think that is a problem, I consider it _their_ problem.

To come back to the point that seemed to trigger all this: I happen to think that if there exists a 1:1 translation of moves between WB and UCI protocol, because they both specify long-algebraic notation to be used, a UCI2WB adapter is totally out of line if it refuses to pass the message. That is not the task of an adapter. It is the task of the GUI to decide if it is going to accept the move. Not of the adapter. If someone disagrees with that, it would be interesting if he presented his arguments here as to why.

If someone, however, thinks that the fact that I have this opinion is a good reason to (out of the blue) "punish" the computer Chess community by sabotaging any future joint effort, ... Well I think that makes it clear to any reader which of us is out of line and putting his own interest above that of the community!

It not the task of an engine to play illegal moves either.
Maybe you don't like it but polyglot does nothing against the winboard protocol,even with a winboard gui disabled legality checking.

Best
Fonzy

[Zach Wegner]

To come back to the point that seemed to trigger all this: I happen to think that if there exists a 1:1 translation of moves between WB and UCI protocol, because they both specify long-algebraic notation to be used, a UCI2WB adapter is totally out of line if it refuses to pass the message. That is not the task of an adapter. It is the task of the GUI to decide if it is going to accept the move. Not of the adapter. If someone disagrees with that, it would be interesting if he presented his arguments here as to why.

1. It is bad design for an adapter to try and maintain a board state for a game after a move that it knows is illegal. It should simply reject such moves, rather than risk corrupting its data structures.

2. UCI engines are required to output coordinate moves, but Polyglot is not. You cannot have Polyglot output SAN (a very desirable feature IMO) without interpreting the moves and rejecting illegal ones.

3. Polyglot has always worked like that, and it would be silly to try and redesign it just to accept illegal moves. A much better idea, if you want Polyglot to handle Shatranj, would be to simply create a new move generator. If Shatranj has complex repetition rules governing move legality (which it does, IIRC), they can simply be ignored. This doesn't create any danger for corrupting data structures, since Shatranj would still be a valid, consistent game without it.

4. A legal move generator for chess is very trivial, and Polyglot handling illegal moves itself might make it easier to debug. As an easy example, the bug in Tornado mentioned, with an illegal move in the PV, would never have been caught since XBoard doesn't look at the PV.