Author: Stuart Cracraft
Date: 09:00:10 06/20/98
Go up one level in this thread
On June 17, 1998 at 15:41:32, Robert Hyatt wrote: >On June 17, 1998 at 14:06:11, Stuart Cracraft wrote: > >>On June 16, 1998 at 17:52:41, David Fotland wrote: >> >>>If this is a PC, you should open the file in binary mode. >>> >>>On the PC, end of lines are stored as CRLF, and a file opened in >>>ascii mode will convert LF to CRLF, adding an extra byte from >>>time to time. >>> >>>David Fotland >> >>File was non-text binary structs at the time the message was posted. >>Had already tried both w+b and w modes, both resulting in the extra >>byte. >> >>To fix, I've converted to a wholly text flat-file ascii which adds >>the ability for human editing and updates to the file to control learning. > >This is one of those approaches that I'd label "bad software engineering." > Well, actually I am convinced Fotland was right. Since using O_BINARY in my open (instead of just O_WRONLY|O_APPEND, the problem has gone away. My learn files's byte size if divided by my struct size now always equals the exact number of learned positions my position reports at startup. So for example, I zeroed my learn file last night and let it play overnight. The result: 72 games played by morning time and 42 learned positions. In the old days, when I had the bug, it would error somewhere in that batch of learned positions and write out an odd byte and then if the program is restarted or next time it is started it would only read up to that bad record. Sure, I could have had it do error recovery and skip, but I waited until the bug was solved instead. >IE you have a bug, so you change something and the bug goes away... or >does it? In your case, I can't imagine that this is a system problem >because my book and position files are binary, and they *never* pick up >odd bytes. If yours are, there is something going wrong, perhaps a wild >store, perhaps an undefined variable. But I wouldn't rest until I had >precisely "pinned the tail on the donkey" otherwise, such bugs have a nasty >way of coming back again and again, until they are fixed. Look, the only way I know of doing this kind of work is once the design is done first and the implementation, as long as the result looks good except for a few bugs to fix the bugs and when non-buggy behavior results, I consider it good software engineering. I am absolutely convinced Fotland's comment was appropriate. I thought I had been opening in binary mode with O_WRONLY|O_APPEND but this was not done. So occasionally, the fwrite would write out a hash key that included a \012 byte. It was rare and non-predictable. When this happened, I was scrambled. Now with O_BINARY, it's fine. No I don't have wild stores or undefined variables. The section of code that does this is very small. Same with the section that reads the result. Fotland was right. Thanks Dave. --Stuart P.S. Thanks for the vote for continuing to debug. In the presence of bad behavior I'll debug. But if things are running well, I have too many other projects to "over-debug".
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.