Wish for a forgotten field in the game list feature

[Guenther Simon]

Hello HG, in the times when I discussed development of Winboard_X features with Alessandro it seems I forgot to request
the comment field to be added in the game list. It would be very useful and saving some time when
doing quick reports for tourneys and bug reports on web sites.
Currently there are 11 fields to chose by the user. I guess it wouldn't be too tedious to add another field
for the result comment?
BTW for unknown reason it seems the time control field is filled just with a '?' currently?

Guenther

Code: Select all

1, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.1", "CritterChess_034", "Ghost_014", "0-1", "2009.04.18", "12. +0.62   11... -0.45"
2, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.1", "Ghost_014", "CritterChess_034", "1-0", "2009.04.18", "11. +0.34   9... -0.17"
3, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.2", "Amundsen_080JA", "Warrior_103", "1-0", "2009.04.18", "2. +0.82   3... -0.28"
4, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.2", "Warrior_103", "Amundsen_080JA", "0-1", "2009.04.19", "4. +0.10   3... +0.02"
5, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.3", "Clarabit_100", "Parrot_070722", "1-0", "2009.04.19", "5. +0.20   5... +0.34"
6, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.3", "Parrot_070722", "Clarabit_100", "1-0", "2009.04.19", "4. +0.26   6... -0.24"
7, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.4", "Counter_11", "LadyGambit_10", "1-0", "2009.04.19", "13. +0.11   13... +0.04"
8, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.4", "LadyGambit_10", "Counter_11", "1/2-1/2", "2009.04.19", "13. -0.58   11... +0.19"
9, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.5", "Dirty_099OW5", "LaDameBlanche_20c", "1-0", "2009.04.19", "6. +0.36   3... +0.10"
10, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.5", "LaDameBlanche_20c", "Dirty_099OW5", "0-1", "2009.04.19", "8. +0.75   21... -0.59"
11, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.6", "EveAnn_163", "Ifrit_j1", "1/2-1/2", "2009.04.19", "9. +0.22   6... +0.19"
12, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.6", "Ifrit_j1", "EveAnn_163", "0-1", "2009.04.19", "13. -0.19   12... -0.36"
13, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.7", "FireFly_255b5", "Heracles_0616", "1/2-1/2", "2009.04.19", "13. +1.02   14... -0.42"
14, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.7", "Heracles_0616", "FireFly_255b5", "1-0", "2009.04.19", "13. +0.49   14... -0.45"
15, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.8", "Freyr_1067", "GK_090", "1-0", "2009.04.19", "10. -0.40   8... +0.10"
16, "RWBC PSWBTM RT70", "CAPPUCCINO", "1.8", "GK_090", "Freyr_1067", "1-0", "2009.04.19", "9. +0.17   9... -0.24"


[Guenther Simon]

Just for the record, I also asked for that feature now from current Scid developer Pascal Georges,
as SCID is the only other prog I know with a very customizable and useful game list output.
For now it only outputs a comment flag itself, which doesn't help much in computer games,
as all games have such a flag

Current fields in Scid:

Code: Select all

w: White            b: Black            W: White Elo        B: Black Elo       
m: Moves count      r: Result           y: Year             d: Date             
e: Event            s: Site             n: Round            o: ECO code         
g: Game number      f: Filtered number  F: Final material   S: Non-std start pos
D: Deleted flag     U: User flags       C: Comments flag    V: Variations flag 


Guenther

[H.G.Muller]

I will put it on the to-do list. I have never looked at the code in the gamelist.c sourcefile until now. I also still have to port Allessando's improvements to XBoard. When I get to doing that, I will also address this issue, as I will be acquainted with the code then.

For the immediate feature, we are quite busy merging the official GNU-Savanah fork with my code, and I don't want to delay that process by introducing new major changes before the merging is complete.

[Guenther Simon]

I will put it on the to-do list. I have never looked at the code in the gamelist.c sourcefile until now. I also still have to port Allessando's improvements to XBoard. When I get to doing that, I will also address this issue, as I will be acquainted with the code then.

For the immediate feature, we are quite busy merging the official GNU-Savanah fork with my code, and I don't want to delay that process by introducing new major changes before the merging is complete.

Hello HG, how things are going on?

Regards
Guenther

[H.G.Muller]

As far as I am concerned WinBoard 4.4.0 is ready for release. But WinBoard has to be released as an executable package, and, like WinBoard 4.2.7, we wanted it to come with an installer. So we are basically waiting for an installer to be made.

In the mean time I have been working to integrate the JAWS patch (making WinBoard into a speaking interface for the blind) with WinBoard, which has led to some improvements in the assignment of accelerator keys and navigability of the control elements through key strokes (something which sighted users almost never do, as they can use a mouse). Minor patches resulting from this that are clearly improvements I apply to the standard code as well. The major JAWS patch will be kept separate from the main line, but is now organized in such a way that it can be applied automatically to future versions.

In the mean time I also found a way to make HTML help files and call the associated help viewer, so I added that patch to WinBoard 4.4.0 as well. Charles Browne did a major job in casting the existing help file into HTML format, so that we can now release it with native Vista help files included (in stead of forcing Vista users to download the WinHelp32.exe in order to view the help files).

[Guenther Simon]

As far as I am concerned WinBoard 4.4.0 is ready for release. But WinBoard has to be released as an executable package, and, like WinBoard 4.2.7, we wanted it to come with an installer. So we are basically waiting for an installer to be made.

In the mean time I have been working to integrate the JAWS patch (making WinBoard into a speaking interface for the blind) with WinBoard, which has led to some improvements in the assignment of accelerator keys and navigability of the control elements through key strokes (something which sighted users almost never do, as they can use a mouse). Minor patches resulting from this that are clearly improvements I apply to the standard code as well. The major JAWS patch will be kept separate from the main line, but is now organized in such a way that it can be applied automatically to future versions.

In the mean time I also found a way to make HTML help files and call the associated help viewer, so I added that patch to WinBoard 4.4.0 as well. Charles Browne did a major job in casting the existing help file into HTML format, so that we can now release it with native Vista help files included (in stead of forcing Vista users to download the WinHelp32.exe in order to view the help files).

You have done a lot of work. It would be still nice if you could find a way to make the result comment appear in the game list feature.
BTW meanwhile I noticed that there is also a PGN tag for the result comment and it is called the 'Termination' tag. AFAIK it is only used
in Arena and no other GUI yet.
I want to clarify again why I think it is needed/useful. If it is there one can easily sort a huge PGN file as a list by 'buggy' result comments
for bug reports and one doesn't have to go through PGNs with an editor to find all those 'buggy' result comments.
Once in April I started the bugbase project which should list all known bugs of all ever used versions of programs in WB, but because of lack
of time and lack of an easy representation of all result comments in a 30.000 games PGN file I wanted to wait for a solution like the one
mentioned in this original post. Of course I could write my own parser or script for extracting the necessary infos but currently I don't have
enough spare time and motivation...

Regards,
Guenther

[H.G.Muller]

I absolutely believe you when you say this would be a useful addition. The problem is that it requires changes in a source file that I never even looked at, and so have literally no idea how the code is working. As the WinBoard sources are practically undocumented it requires time to study it as well as experimentation.

I don't want to do that before the 4.4.0 release. This is the first release that will be done from the official GNU-Savannah XBoard project website, and so it will reach a far larger audience than the usual bunch of computer-chess freaks, the first release in a very long time. Therefore I want it to be as reliable and stable as possible. People must not say "This new XBoard / WinBoard is crap, it has a lot of new features but these, and even the old ones, do not properly work anymore!". Making changes in parts of the code that I don't properly understand does not seem a good plan to acheive this goal.

Porting the new game-list features and the eval graph to XBoard are the top-most major jobs on my to-do list. And from working on that I should get acquanted well enough with the code to add what you request in a safe way.

[Guenther Simon]

I absolutely believe you when you say this would be a useful addition. The problem is that it requires changes in a source file that I never even looked at, and so have literally no idea how the code is working. As the WinBoard sources are practically undocumented it requires time to study it as well as experimentation.

I don't want to do that before the 4.4.0 release. This is the first release that will be done from the official GNU-Savannah XBoard project website, and so it will reach a far larger audience than the usual bunch of computer-chess freaks, the first release in a very long time. Therefore I want it to be as reliable and stable as possible. People must not say "This new XBoard / WinBoard is crap, it has a lot of new features but these, and even the old ones, do not properly work anymore!". Making changes in parts of the code that I don't properly understand does not seem a good plan to acheive this goal.

Porting the new game-list features and the eval graph to XBoard are the top-most major jobs on my to-do list. And from working on that I should get acquanted well enough with the code to add what you request in a safe way.

Hi HG, you are right and I fully agree about your priority for the 4.40 release. I hope I can cure my impatience now with a good bottle of vino rosso.

Regards
Guenther

[H.G.Muller]

OK, now that 4.4.0 has been finally released, I can turn to this.

Let me first make sure I understand what you want. The result comment is not a standrd PGN tag, so WinBoard would have to filter it out of the PGN game itself. I should look for a string between {} just before a 0-1, 1-0 or 1/2-1/2. I guess all stuff between {} counts as a comment, and WinBoard already stores all comments with the moves. So basically I would have to use the comment after the last move.

This field should then be present in the Options -> Game List... dialog, on equal footing with the PGN tags that are aready there.

[H.G.Muller]

The version at http://home.hccnet.nl/h.g.muller/winboard.zip might do what you want.

I also repaired the time-control tag: it seems this tag was simply never recognized by the PGN-tags parse routine; it grouped it with extraTags, without looking at the value.

[Michel]

Here is more trivial suggestion. XBoard recognizes a hard coded list of start up errors which
it relays to the user.

unknown host
No remote directory
not found
No such file
can't alloc
Permission denied

(this is documented in the manual)

My suggestion would be to add a more generic one (such "initialization error" or simply
some magic sequence of characters such as "@@@")
so that engines can relay fatal errors to the user before the xboard command is received.

I tried "tellusererror" but it does not work very well. The dialog box is immediately obscured
by the dialog box of the start up error (failed to start...) so it is not very clear to the user what is happening.

Besides I assume that the effect of sending tellusererror before the xboard command is received is undefined.

[H.G.Muller]

I could of course let it trigger on "tellusererror".

I noticed this too (never realized it was in the manual), and as actually very annoyed by it. This feature is apparently meant for if the engine executable cannot be found, and the OS sends an error message through the pipe. Nasty thing is that it is considered a fatal error, and WB exits before it was fully initilized. This also wrecks the window positioning; next time you start up it is a mess. It is basically a command for crashing WinBoard!

What annoyed me was that it can be unnecessarily triggered, when an engine accidentally uses the trigger phrases in an otherwise innocent error message. Like "tellusererror settings file not found, using defaults". But I guess if this is documented, this would be a fault of the engine.

This whole mechanism will have to be rethought when we eliminate the startup menu. An error to startup the engine should never be fatal. It should simply make WB switch to -ncp mode (if it was the first engine) or Edit Game mode (for the second). As long as it crashes WinBoard, I certainly do not want to encourage its use.

[Michel]

Well the fact that this feature is badly implemented is not the engine's fault....

I just would like to have a simple way of communicating fatal errors to the user (before the protocol
is initialized). Writing a specially formatted error message on stderr seems like a reasonable thing to do
and works quite nicely right now. I just would like it to be a bit more flexible.

In the future WB could handle such messages more gracefully but this has nothing to do with the engine.

EDIT: Note that I am talking about fatal engine errors which currently make WB crash anyway. So the message
on stderr makes it no worse than it was.

[H.G.Muller]

Well, it is clearly a WB problem, that's for sure. I guess the most logical thing would indeed be to define some "telluserfatalerror" command that WB should be sensitive to at all times, and change the whole error handling here to just unloading the engine, rather than crashing.
.

[Guenther Simon]

The version at http://home.hccnet.nl/h.g.muller/winboard.zip might do what you want.

I also repaired the time-control tag: it seems this tag was simply never recognized by the PGN-tags parse routine; it grouped it with extraTags, without looking at the value.

Hello HG,

Sorry for the late answer. This version does exactly what I meant with one important restriction and something cosmetical easily to repair.
The cosmetically thing is just that the result comments sometimes are very long(as you already had expected) and a very few were cut too early.
I havent looked at the source, but I guess with 10 chars more I am always safe at least for my huge >31.000 test games.
The much more important restriction is that the information for the new tag is not copied with the 'copy game list to clipboard' feature
under the file menu. It is there because there is no manual way to copy from the game list by Ctrl C or similar.

Regards,
Guenther

[H.G.Muller]

Ah, exporting the game list... Yet another feature of WinBoard I have never used before! Apparently it used its own routine to format the line, while I had expected to simply write the same as what was displayed in the game list listbox to the clipboard.

OK, try the version that is at the same link now. I enlarged the maximum field length from 64 tp 80. This seems more like a safety catch anyway; the buffer in which the line is created is 1024 bytes, so even with each field 80 long it would still only overflow when more than 12 tags are printed. And most tags, like PGN result, will always be much shorter.

I added the result comment to the full-line format used for copying to clipboard, directly behind the PGNresult, also between quotes like the rest. (I resisted making it one field together with the result, like "1-0 {xboard adjudication: checkmate}".)

[Guenther Simon]

Ah, exporting the game list... Yet another feature of WinBoard I have never used before! Apparently it used its own routine to format the line, while I had expected to simply write the same as what was displayed in the game list listbox to the clipboard.

OK, try the version that is at the same link now. I enlarged the maximum field length from 64 tp 80. This seems more like a safety catch anyway; the buffer in which the line is created is 1024 bytes, so even with each field 80 long it would still only overflow when more than 12 tags are printed. And most tags, like PGN result, will always be much shorter.

I added the result comment to the full-line format used for copying to clipboard, directly behind the PGNresult, also between quotes like the rest. (I resisted making it one field together with the result, like "1-0 {xboard adjudication: checkmate}".)

Hi again,

The new version complains about a missing jfwapi.dll? Do you know how and where I get this dll?

Regards,
Guenther

[H.G.Muller]

Oops! I had forgotten to set the switch JAWS=0 in the makefile, so it has been making a version for the blind.

Try the one that is there now. I hope it didn't mess up your winboard.ini before it crashed because of the missing DLL; if it did, you might have to delete the first 5 options from the ini file (/beepXxx=...)

[Guenther Simon]

Oops! I had forgotten to set the switch JAWS=0 in the makefile, so it has been making a version for the blind.

Try the one that is there now. I hope it didn't mess up your winboard.ini before it crashed because of the missing DLL; if it did, you might have to delete the first 5 options from the ini file (/beepXxx=...)

Thanks HG! The export and the feature itself works ok now! The only thing I noticed is that the export
has a different order than the list display(which is no prob for me, because I use the export as a csv
file for new sorting anyway).

Regards,
Guenther

[H.G.Muller]

Indeed the export has its own format, which always contains all fields. The display is fully configurable, and any number of fields can be put in any order. That they are different surprised me too, which is why initiallythe export did not contain the new field. I had expected that when I added the new feld in one format-line routine, it would be fixed everywhere. But the export format seem more designed for reading by programs like Excel, rather than for easy viewing.