| Comment | File | Size | Author |
|---|---|---|---|
| #12 | chessboard-empty-squares-1269424-12.patch | 532 bytes | eric_a |
| #11 | chessboard-empty-squares-1269424-11.patch | 861 bytes | eric_a |
| #9 | chessboard-empty-squares-1269424-9.patch | 582 bytes | eric_a |
| #6 | chessboard-empty-squares-1269424-6.patch | 530 bytes | eric_a |
| #3 | chessboard-empty-squares-1269424-3.patch | 1.2 KB | eric_a |
Comments
Comment #1
eric_a commentedNeeds work, but let's see how we're doing.
Comment #3
eric_a commentedComment #4
eric_a commentedComment #5
eric_a commentedWe need a test for the new stuff. Maybe testing something like "10/pppppppp1p/10/9p".
So #1 broke our "8/3x1x2/2x3x1/4N3/2x3x1/3x1x2/8/8" test, which was mostly there for marked squares.
Before adding "9" and "10" I'd like to add another test first that captures some of the existing behavior. Maybe something like "ppppppp1/8".
Comment #6
eric_a commentedAfter recent refactorings, this has become a trivial change.
Comment #7
eric_a commentedPushed to 7.x-2.x and 6.x-2.x.
Comment #9
eric_a commentedAfter recent refactorings, this has become a trivial change.
And broken code was pushed still...
Comment #10
eric_a commentedPushed #9 to 8.x-2x, 7.x-2x, 6.x-2.x.
Comment #11
eric_a commentedThe last patch fixes the processing of "9" and "10" but introduces an issue when it comes to strings like "20". We don't want to try rendering "0".
Comment #12
eric_a commentedThis patch is smaller and leaves the regex and processing order alone.
Comment #13
eric_a commentedPushed #12 to 8.x-2.x, 7.x-2.x, 6.x-2.x.
Comment #14
eric_a commented