Next | Query returned 34 messages, browsing 31 to 40 | previous

History of commit frequency

CVS Commit History:


   2003-03-29 13:43:15 by Julio Merino | Files touched by this commit (795)
Log message:
Place WRKSRC where it belongs, to make pkglint happy; ok'ed by wiz.
   2002-09-25 14:32:00 by Dan McMahill | Files touched by this commit (1)
Log message:
lower optimization level on sparc.  With -O2, crafty segfaults immediately,
with -O1 it compiles and seems to run ok.  This is on NetBSD-1.6/sparc,
gcc-2.95.3.
   2002-09-11 12:52:10 by Johnny C. Lam | Files touched by this commit (4)
Log message:
Update games/crafty to 18.15.  Changes from version 18.13 include:

18.14   Minor bug in ResignOrDraw() code caused Crafty to not offer draws
        although it would accept them when appropriate.  Rook vs Minor
        is now evaluated as "neither side can win" an oversight in the
        EvaluateWinner() code.  minor bug in ResignOrDraw() would fail to
        offer draws due to the +0.01/-0.01 draw scores returned by the
        EGTB probe code.

18.15   change in endgame draw recognition to handle the case where one
        side appears to be in a lost ending but is stalemated.  the code
        now evaluates such positions as "DrawScore()" instead.  the code
        to accept/decline draws has been modified.  when a draw offer is
        received, a global variable "draw_offer_pending" is set to 1.
        when the search for a move for crafty terminates, crafty then
        uses this value to decide whether to accept or decline the draw.
        this means that the accept/decline won't happen until _after_ the
        search has a chance to see if something good is happening that
        should cause the draw to be declined, closing a timing hole that
        used to exist that let a few "suspects" get away with draws that
        should not have happened (ie crafty has - scores for a long time,
        the opponent suddenly fails low and sees he is losing and offers
        a draw quickly.  Crafty would accept before doing a search and
        noticing that it was suddenly winning.)  minor evaluation change
        to notice that K+B+right RP vs K+B is not necessarily won if the
        weaker side has a bishop of the right color.
   2002-04-04 21:28:11 by James Chacon | Files touched by this commit (2)
Log message:
Provide a FirstOne and LastOne implemention for archs without hand crafted
assembly substitutes.

Next | Query returned 34 messages, browsing 31 to 40 | previous