Author: Robert Hyatt
Date: 10:07:15 06/20/98
Go up one level in this thread
On June 20, 1998 at 12:00:10, Stuart Cracraft wrote: > >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. it's only good software engineering, *if* you explain every odd bit of behavior, rather than just changing something to fix it. Because changing things may only hide the bug, not fix it. > >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. > simplest and POSIX compatible solution to this is to simply open the file "rb+"... says it must already exist, open for read and write, and in binary mode. It works perfectly on every platform known to man.. >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. I wasn't talking about just the code that does this. You can have stores *elsewhere* that can effect such a piece of code... > >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.