Discussions among XBoard and WinBoard developers ()

h.g. muller | 21 Aug 2009 21:14

Picon

Polyglot 2.0

I prepared a Polygot version that behaves exactly as I want it,
optimalized for WinBoard 4.4.0. Basically it is Michel's 1.4.38b
version, with two additions: I suppress the sending of option
features for all options that I consider damaging or undesirable
for a WinBoard engine (and re-ordered the remaining options
so they pack more compactly in the Engine-Settings dialog).
And I export the name of the IniFile, and provided an option
that makes Polyglot save the current settings on this file.
I named this version Polyglot 2.0.38b, and want to distribute
it with the WinBoard 4.4.0 installer.

The question is how we should distribute it for XBoard. And
as Polyglot is GPL'd, we would have to provide source as well.
Can we put a source tar ball of it on the GNU XBoard homepage?

Eric Mullins | 22 Aug 2009 05:38

Picon

Re: Polyglot 2.0

h.g. muller wrote:
> I prepared a Polygot version that behaves exactly as I want it,
> optimalized for WinBoard 4.4.0. Basically it is Michel's 1.4.38b
> version, with two additions: I suppress the sending of option
> features for all options that I consider damaging or undesirable
> for a WinBoard engine (and re-ordered the remaining options
> so they pack more compactly in the Engine-Settings dialog).
> And I export the name of the IniFile, and provided an option
> that makes Polyglot save the current settings on this file.
> I named this version Polyglot 2.0.38b, and want to distribute
> it with the WinBoard 4.4.0 installer.

I'm not in favor of that.  First, the major version change is not 
appropriate.  Second, I strongly recommend not using a customized 
polyglot.  Doing so will cause users issues when they try to use 
versions they find elsewhere, particularly if they can't find compatible 
ones anywhere else.  If UCI support is that important, integrate it into 
winboard instead.  I'm all in favor of making the two projects 
compatible with each other, but making a unique one for a winboard 
release seems very bad.

>
> The question is how we should distribute it for XBoard. And
> as Polyglot is GPL'd, we would have to provide source as well.
> Can we put a source tar ball of it on the GNU XBoard homepage?

h.g. muller | 22 Aug 2009 08:13

Picon

Re: Polyglot 2.0


>
>I'm not in favor of that.  First, the major version change is not 
>appropriate.  Second, I strongly recommend not using a customized 
>polyglot.  Doing so will cause users issues when they try to use versions 
>they find elsewhere, particularly if they can't find compatible ones 
>anywhere else.  If UCI support is that important, integrate it into 
>winboard instead.  I'm all in favor of making the two projects compatible 
>with each other, but making a unique one for a winboard release seems very bad.

The problem is that almost all Polyglot versions that are around do
not support the extensions of WB protocol offered by 4.4.0.
It is unavoidable there will be user issues when they use such
some versions. The version now supplied by Debian and Ubuntu
is as obsolete as WinBoard 4.2.7. If WinBoard protocol is extended,
the extensions wil not be effective for UCI engines unless there will
be a new Polyglot implementing those exensions. I don't see how this
could be avoided.

Why would we want to intentionally ship them a Polyglot version that
breaks part of the functionality of WinBoard?

I don't see this as a matter of customizing. This Polyglot 2.0 (or whatever
we would call it, that is really a separate, not so important issue) is a
universally applicable Polyglot. It is not that I want to completely overhaul
Polyglot for every future XBoard release we are going to do, and change
things back and forth just because they are slightly more convenient
for the particular XBoard version. But we are the ones responsible for
developing WB protocol, and this unavoidably strongly affects Polyglot
and any other adapter. So the future will see a gradual evolution of

(Continue reading)

Arun Persaud | 23 Aug 2009 02:55

Re: Polyglot 2.0

Hi

Eric wrote:
> >I'm not in favor of that.  First, the major version change is not 
> >appropriate.  Second, I strongly recommend not using a customized 
> >polyglot.[...]
> 
> The problem is that almost all Polyglot versions that are around do
> not support the extensions of WB protocol offered by 4.4.0.

My take on this would be to supply a patch for polyglot along with the source code and perhaps a new
pre-compiled polyglot with that patch with the installer along with a note in the README or so...

The best would be to add those changes upstream, but as I understand it HGM was/is trying to do just that, but
for some reason or the other the author of polyglot doesn't want to add them.

I also think that releasing a new version number has lots of problems associated with it and is better to be avoided.

ARUN

Tim Mann | 23 Aug 2009 03:07

Re: Polyglot 2.0

On Sat, 22 Aug 2009 17:55:52 -0700, Arun Persaud <APersaud <at> lbl.gov> wrote:
> Hi
> 
> Eric wrote:
> > >I'm not in favor of that.  First, the major version change is not 
> > >appropriate.  Second, I strongly recommend not using a customized 
> > >polyglot.[...]
> > 
> > The problem is that almost all Polyglot versions that are around do
> > not support the extensions of WB protocol offered by 4.4.0.
> 
> My take on this would be to supply a patch for polyglot along with the source code and perhaps a new
pre-compiled polyglot with that patch with the installer along with a note in the README or so...
> 
> The best would be to add those changes upstream, but as I understand it HGM was/is trying to do just that, but
for some reason or the other the author of polyglot doesn't want to add them.
> 
> I also think that releasing a new version number has lots of problems associated with it and is better to be avoided.

If the upstream author doesn't want the changes and wants to continue
to release new versions of his own, then this is a fork of Polyglot, so
it needs something special to identify it as a fork -- maybe a suffix
to the name, or a prefix or suffix to the version number, whatever.
I'd suggest not simply picking a larger version number.  (That worked
OK for xboard/WinBoard since I wasn't going to be releasing a 4.3.x and
didn't really care, but it sounds like this is a different case.)

--

-- 
Tim Mann  tim <at> tim-mann.org  http://tim-mann.org/

(Continue reading)

Eric Mullins | 23 Aug 2009 03:22

Picon

Re: Polyglot 2.0

Tim Mann wrote:
> If the upstream author doesn't want the changes and wants to continue
> to release new versions of his own, then this is a fork of Polyglot [...]

That's exactly the problem as I see it.  Unless we intend to maintain 
that fork, people will move to versions that are maintained.  If doing 
that causes problems for some reason, then those who require polyglot 
will simply not use 4.4.0.  I'm in that category for sure.

h.g. muller | 23 Aug 2009 06:31

Picon

Re: Polyglot 2.0


>
>That's exactly the problem as I see it.  Unless we intend to maintain that 
>fork, people will move to versions that are maintained.  If doing that 
>causes problems for some reason, then those who require polyglot will 
>simply not use 4.4.0.  I'm in that category for sure.

I don't think this is a problem. For one, the ptach is simple
and localized wel enough that I could apply it to any new
Polyglot version in a matter of minutes.

In the second place, the only problems that people would
have that want to switch to another Polyglot fork, is that they
lose part of the functionality of 4.4.0. If they switch to another
WinBoard version they would exactly lose that same functionality,
and three times more. So why would they do it?

It is important to realize that _all_ Polyglots that are currently
maintained are forks. The original author (Fabien Letouzy)
is no longer active in computer chess. Currently active forks
are those of Fonzy Bleumers and Michel van den Bergh.
So far thir versions did not make it into any of the Linux
repositories, but for Windows the original version has been
completely replaced (as it was dependent on cygwin1.dll,
a problem that was solved by Morning Yellow, whose version
served as a basis for the current forks).

If we would built native UCI support into WinBoard, (e.g. by
incorporating most of the Polyglot code into it) we would
have to maintain that code for sure, as no one else would

(Continue reading)

Arun Persaud | 23 Aug 2009 08:41

Re: Polyglot 2.0

Hi

From: "h.g. muller" <h.g.muller <at> hccnet.nl>
>[...] It wil be far easier to apply a simple patch to any
> new Polyglot that might surface because others are maintaining
> it.

in that case we can just distribute a patch file together with some instructions and perhaps a patched
executable for the winboard installer... seems to avoid all the mentioned problems IMO.

ARUN

h.g. muller | 23 Aug 2009 10:15

Picon

Installer

Are there any suggestions how to handle the WinHelp vs HtmlHelp
issue in the Installer? Should we make this automatic, based on
the presence of C:\WINDOWS\winhlp32.exe (and pick the .chm
file if it is not there)? Problem is that on other systems it might
be in a different folder (e.g. \WINNT), or on a different disk.

Alternatives would be to make it dependent on the Windows version
and give them .chm on Vista and .hlp otherwise. Bbut I don't know
how to do that, and people with Vista might have especially installed
the WinHelp32, and would not get the .hlp file they really wanted.

We could also move the help files out of the core components,
and make them optional, and provide a screen to ask which
version they want. (Cumbersome both for us and the user.)

Finally we could always give them both. WinBoard is programmed
to use WinHelp32 if it is there and the .hlp file is found; in all
other cases it tries the .chm help file.

Although it is not very elegant, I lean to the last option.

One other matter:

I see that every file that goes in the install pakage is now in
the git repository. Is this wise policy? Many of the files are
already obsolete, and we won't maintain most of them ourselves.
(E.g. I received a new Pulsar version by e-mail today, the Polyglot
might still be 1.4w10UCIb22 unless Eric replaced it, etc.)

In addition I can imagine that there could be legal issues:

(Continue reading)

Arun Persaud | 23 Aug 2009 21:10

Re: Installer

Hi

HGM wrote:
> Perhaps it is better to leave files that come from external sources
> simply out of the repository, so that we can obtain them from
> the original source when we want to re-build the installer.
> I understand now that the files to be included in the installer
> need not be in the same tree as they will be unpacked (unlike
> when I was distributing by zip file). So a simple method to
> upgrade the installer would be to simply use the downloads of,
> e.g. Pulsar, Fruit and Elephant Eye as they are distributed,
> and unpack them in the installer folder subdirectories. This
> would include lots of files we won't include in the installer, but the
> script will pick out what we need.

If the installer can download the files that would be the best option IMO. If not, and if the license doesn't
prohibit it, we should keep a copy of the program in git, if only to be able to check which version we shipped
and if possible bugs are reproducable.

ARUN

h.g. muller | 23 Aug 2009 22:06

Picon

Re: Installer

I succeeded in decompiling the .chm file, changing the html, and compiling 
it again.
So I should have an updated .chm file now. The fishy thing is that it has 
shrunk from
129KB to 77KB in the process??? Didn't notice something that was obviously 
missing,
though. But the difference is so large that I should make a thorough check...

The problem with the Engine-Settings dialog is for sure a Polyglot problem.
Polyglot sends many engines double. It actually launches double in the task 
manager,
when it does this, and then one of the two tasks hangs. All very bad. Michel's
latest version (from which I derived mine) all suffer from this. We must 
wait for this.

I beefed up the test for th Polyglot info-string kludge, so that the 
leading numbers in
the Engine-Output window now are only omitted if they are indeed all zero 
(except
depth, which is now always printed).

I had a few misspellings in the winboard.ini that goes with the install 
("polygolt"...),
so I corrected those.

I added a logo for SMIRF.

I guess everything is pretty much ready, except for Polyglot, and a 
winboard.exe
that I want to build from sources directly downloaded from git. (What I

(Continue reading)

h.g. muller | 23 Aug 2009 22:53

Picon

Re: Installer

OK, the problem with Polyglot is solved. In fact it never existed.
The problem was that there was a typo in the options of the second
engine, -fUCI in stead of -sUCI, which cause a polyglot to be invoked
for the frst engine no matter what, so that I was actually running two
Polyglots in series if I was invoking Polyglot for the first engine explicitly.

I will wrap up the installer tomorrow; I am out of stamina for today...

Arun Persaud | 23 Aug 2009 23:29

Re: Installer

Hi

From: "h.g. muller" <h.g.muller <at> hccnet.nl>
> I will wrap up the installer tomorrow; I am out of stamina for 
> today...

sounds good. I fixed the bug on OS X, which also surfaces some other bugs in the configure script. So that
should be all good now.

Waiting for the last updates this week and then we can release beta2 including a windows installer... I
think after that we just wait a bit for people to test it and then hopefully release the final version
without many changes ;)

ARUN

Eric Mullins | 23 Aug 2009 15:34

Picon

Re: Installer

h.g. muller wrote:
> [...]
> Finally we could always give them both. WinBoard is programmed
> to use WinHelp32 if it is there and the .hlp file is found; in all
> other cases it tries the .chm help file.
>
> Although it is not very elegant, I lean to the last option.

I don't see anything wrong with that.  I would prefer Htmlhelp over 
Winhelp though when both can work.

>
> One other matter:
>
> I see that every file that goes in the install pakage is now in
> the git repository. Is this wise policy? Many of the files are
> already obsolete, and we won't maintain most of them ourselves.
> (E.g. I received a new Pulsar version by e-mail today, the Polyglot
> might still be 1.4w10UCIb22 unless Eric replaced it, etc.)

They are just the files we use for building the installer.  So that they 
are obsolete doesn't matter, they will always be the same ones as in the 
current installer build.

If there are legal issues with hosting those files in git, then I 
suggest we not include them at all.  (on site, nor in the installer)

>
>
> In addition I can imagine that there could be legal issues:

(Continue reading)

h.g. muller | 23 Aug 2009 17:17

Picon

Re: Installer


>
>I don't see anything wrong with that.  I would prefer Htmlhelp over 
>Winhelp though when both can work.

This would be logical, except that the html help file initially was not as 
good as the old help file.
I think the work of Charles Browne largely corrected that, (at least, if he 
can also incorporate the
update we committed recently), but future updates might create differences 
again.
I am a bit hesitant to designate the file that is least likely to be 
up-do-date as the primary choice.

>They are just the files we use for building the installer.  So that they 
>are obsolete doesn't matter, they will always be the same ones as in the 
>current installer build.

I can imagine you would want to keep them there for documentation purposes 
once the installer is finished and released.
But what I was thinking is this: while we are working on it, the git cannot 
be used to pull our files from, as the files
are maintained by upstream developers who will not commit to our git. So if 
there is a difference between the files
in git and the files I obtain elsewhere, it is those in git that I should 
discard. But never mind.

>If there are legal issues with hosting those files in git, then I suggest 
>we not include them at all.  (on site, nor in the installer)
>

(Continue reading)

Eric Mullins | 24 Aug 2009 00:00

Picon

Re: Installer

h.g. muller wrote:
> [...]
> Lack of a smart bundling strategy is the prime cause of the decline of 
> WinBoard amongst Windows users. They move
> to other GUIs that do provide all-in-one. People demand that nowadays.

I'm not sure I agree with that.  What evidence is there?

I know winboard has declined in popularity among players on chess 
servers.  In that demographic, the problem isn't bundling, but that the 
opposition is more appealing, generally more intuitive, and more 
cross-platform  (babas works great in wine).  That's not going to change 
no matter what how we bundle winboard.  Jin and BabasChess pretty much 
dominate the free category, and there is Arena too.

For running engines on a chess server, winboard is still very popular 
for casual users.  The only other reasonable choices for them are 
ChessPartner and Arena.  Those running winboard already may even decide 
there's too much hassle to switch to 4.4.0 because it's set up so 
differently from the way they currently run.  I personally know a few 
people who have tried 4.4.0, and are back to running 4.2.7.  I haven't 
asked them why-- I guess I should.    Again, a bundling strategy isn't 
going to change much here.

Some advanced engine operators may run winboard.  But I think icsdrone 
and xboard are a lot more popular for advanced 24/7 types.  There are 
several  custom icsdrone versions out there, most of which you would 
never know were icsdrone at all.  Nobody in this category is going to 
change how they operate.

(Continue reading)

Arun Persaud | 24 Aug 2009 03:51

Re: Installer

Hi

Eric wrote:
> Face it.  Winboard is an advanced program for relatively advanced 
> users.  You can try to make it easier for them by bundling, but I 
> don't  think that's really the job of the winboard project.  And I don't 
> see it  having any significant impact on "winboard market share."  I'm not 
> sure  that's really a concern of the winboard project anyway.

Since I'm only using xboard, my opinion doesn't really count I guess ;) anyway, the way I see it is that
bundling a lot of extra software in a nice installer can't hurt and it seems as if you already got most of it
bundled and HGM seems to have finished the gold-pack(tm) installer. Seems like the effort wasn't really
that much to get the installer working, so I say we should use it...

I guess everyone agrees that making an installer isn't our main concern and most effort does go into
xboard/winboard. Once we have the installer though, it should be relatively easy to update it, so from now
on the effort to create new packages should be even less...

One question would be if we should use the GNU homepage to ship the installer or if we should just put
winboard.exe up there and have a link to the WBforum (or some other place) for the gold-pack(tm) installer
(and tell everyone to use that link)... that way we would run into no problems with GNU and non-GNU
software. Might be the cleanest solution if it is ok to host the installer on the forum... which I guess
should be ok, since the old versions of winboard were available through it too AFAIK.

ARUN

Eric Mullins | 24 Aug 2009 07:25

Picon

Re: Installer

Arun Persaud wrote:
> Eric wrote:
>   
>> Face it.  Winboard is an advanced program for relatively advanced 
>> users.  You can try to make it easier for them by bundling, but I 
>> don't  think that's really the job of the winboard project.  And I don't 
>> see it  having any significant impact on "winboard market share."  I'm not 
>> sure  that's really a concern of the winboard project anyway.
>>     
>
> Since I'm only using xboard, my opinion doesn't really count I guess ;) anyway, the way I see it is that
bundling a lot of extra software in a nice installer can't hurt and it seems as if you already got most of it
bundled and HGM seems to have finished the gold-pack(tm) installer. Seems like the effort wasn't really
that much to get the installer working, so I say we should use it...
>   

My problem is just associating the winboard project with extras that we 
need permission to bundle or to host on git.  I don't have any problem 
with the installer itself  (I'm happy to assist when possible).  I have 
less problem with software we don't need permission to distribute, but 
still that includes timestamp and timeseal which are both closed source.

Basically by bundling, we are tying winboard with certain software, 
essentially choosing which versions to include.  I realize end users can 
change, for example, polyglot to one they like better.  But this 
situation is analogous  to  Microsoft bunding IE.   Other browsers are 
hurt that way.   Similarly, other polyglot forks suffer if we decide to 
make our own custom one.  This is a different problem than requiring 
permission, but equally valid, IMO.

(Continue reading)

Eric Mullins | 23 Aug 2009 23:34

Picon

Re: Installer

h.g. muller wrote:
>> If there are legal issues with hosting those files in git, then I 
>> suggest we not include them at all.  (on site, nor in the installer)
>>
>> Because of problems with various external programs, maybe it's best 
>> to focus on winboard all by itself.  If you want to host your own 
>> "Gold Pack" you still can.  What did 4.2.7 include?  Gnuchess, 
>> crafty, timeseal and timestamp.
>>
>> Now that I think of it, I like this a lot.  Make winboard basically 
>> standalone and thus a relatively small install file.
>
> Except that "relatively small" in fact means more than 2x larger 
> (5.9MB for 4.2.7b vs 2.8MB for 4.4.0 as I have it now).
> Most of it spend on components that were not really of much interest 
> to any user. (Two mediocre Chess engines they
> would never even have looked at if they did not come with WinBoard.) I 
> think that is a really bad idea.
>

I don't understand.  Logically, focusing on winboard would be smaller 
than including extra stuff.  That's what I suggested.

>> That would allow you to make your Gold pack and not worry about legal 
>> issues on git.  And anyone else with a different view of winboard use 
>> could make his own package with external components.
>
> Anyone can do that anyway. They could even regress to a package with 
> GNU Chess + Crafty, not capable of running
> UCI engines, and perhaps they will do just that. They could even host

(Continue reading)

Return

Return to gmane.comp.gnu.xboard.devel.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane