Alexander Wagner a écrit : > But I still don't understand. If you centralise it in CE > code and TCL is as portable as you always stress it, why on > earth isn't this common code for scid? It should then be the > same for both versions, not? > Hi, As I already said there are differences that are not "portable" : user interface (the screen resolution is different on a Pocket PC), memory allocation don't work well also on Pocket PC and needs specific code, etc. > >> E.g. in > >> your example, I strongly hope that ::novag::connected is not > >> checked at any other place then within the novag code as > >> otherwise one would have to add checking of quite some > >> flags. This will get a bit unmaintainable. > >> > > > > Of course ::novag::connected is read from other places, > > but only written in Novag handling code. > > Why should I need to ask that variable in any other part of > scid? Sorry, but here I've some problem with the design > approach. (Never thought I'd ever write such a sentence.) > It doesn't make sense that each and every new functionality > that has something to do with the move list has to check > wether this or that or this one is connected. Well, just try to code it in a different way. You will see it is not so easy. You don't have object oriented features or signal/events mechanism in Tcl. > > > I don't think it will be possible to have a single flag : > > the behavior is different when playing FICS, a board is > > connected etc., and you will not trigger the same actions. > > Here I disagree entirely. Wether you enter a game, play FICS > or play against another engine, all that happens is that > some moves are entered. IMHO the problem consists of > essentially two input streams (lets leave comments at the > moment for simplicity, they'd be another stream): one for > black moves and one for white moves. So one could think of > it that way > > > black moves ----> Handler <---- white moves > | > | > V > scids internal > processing of moves > > Now I've several sources of moves. They could come from > > - Keyboard > - Mouse > - a Chess Engine > (user against engine, engine against engine; note that > this is the _SAME_...) > - HID > - Socket (FICS etc.) > - maybe others I don't think off at the moment Be aware that we are not talking about the design of a new program, but the re-design of an existing one, with three major constraints :
- when changing something, regressions must be carefully checked, and due to Scid's complexity, this is a long and hard part. When changing something in Scid you often have tricky side effects; - the former behavior of Scid must remain the same (see previous posts on people used to click on destination square before start square to enter a move : I encountered several times weird requests like this); - time is limited (at least mine). So whatever is the quality of a new design, it will have to fit in current Scid's reality. > > What I've to do in "Handler" is to connect the input streams > ot the proper location. Say the user uses the DGT to play > with white a chess engine playing black. Handler would have > to connect input engine events to white moves, and the input > stream from the chess engine to black moves. Additionally it > would have to pass through blacks moves to the input engine > processing function (which just throws them away), and > whites moves to chess engine stream where the engine does > something with them. Additionally we'd allow general input > via mouse and keyboard. This streams are also connected to > the handler. Say the user plays the first move on the HID, > it walks though Handler to scid and the engine is informed > about the moves. It calculates the answer, it is passed to > Handler which passes it along to scid and to the HID. The > HID module (input engine in the above case) could now use > this move to check the HID against scids position, or if that > is not possible (e.g. on the citrine), silently ignore the > info as if it where the mouse e.g. Now if the user enters > his move not by the HID but by the mouse or keyboard this > move entry has to be passed along to the HID and the engine, > well the same is done as above. So, if I develop my driver > part I'm not interested in where and how the black moves are > generated at all. This is another part of scid, I've an > interface to scid, which gives me the necessary information > for further processing and where I deliver the information > to. > > So, from this point of view, there is absolutely no need in > whatever other part of scid except Handler to know what > device is used to input, and all problems in scid for > connecting either hardware or other services like FICS are > reduced to what they should be: interfaces. The FICS > interface is not interested at all wether you play on your > Citrine or click e2e4. All it needs to know is "move e2e4" > to send it to the server. Then it will get back something > like "move e7e6" which Handler will take and pass along to > scids internal. > Suppose that you are playing against an engine, and you want to switch sides. Actually you press the "flip" button, or use the menu command. So it is engine's turn to play. How do you detect this ? Suppose that when playing on FICS the user press "move back" or press the left arrow : what to do ? Look at the code to see how it is implemented and how things are rarely factorised. Suppose that when you play against an engine, the user go back 3 moves by pressing on the PGN window : how do you handle and detect this and inform all stuff that should be aware of the event ? Also suppose that 2 seconds later the same user press on a move in the Tree window #5, when Tree windows 1,2,3 are opened, and Tree window #4 is opened and locked : how do you handle this ? I found solutions for most of cases, I think, and when thinking about a new design all those are to be taken into account. HID just add some extra complexities to something that is already quite complex. > Now if you followed me that far you might understand why I > wondered so much when looking into the game play mode. The > first thing I was searching was where I could switch e.g. > the coach engine. I did not found anything in the GUI, so I > looked into the source and what I saw were hard wired calls > to crafty. Hm. I do not think that this is a very good way > to do it but it works so I'd not touch it. I consider it the best approach in this case, as it is a reliable one. When parsing engine's output, if you let the user choose the engine for coaching, you may encounter dead locks. For example I use Crafty because I am sure it will end its variation with a "#" if it finds a mate. So the "Mate in N moves" is reliable. I found engines that did not conform to protocols. If I want to detect a "Mate in N moves" in training mode, I will wait for the info. What to do if the engine never sends the info when I know it should because the score is +327 ? How long will you wait for it ? 1 second ? 1 minute ? With Crafty 21.6 (not 21.7 or 21.5 or any other engine) I am sure it works. This is why I embedded some engines I know pretty well with Scid, and I hardwired them in some places because they make the whole thing more reliable. > But I do not > believe that you should follow that way as e.g. the coach in > the above approach is, hm, I repeat myself, just another > stream that gets all moves and runs an engine in analysis > mode. > > The coach engine itself should then be connected by some > "engine interface". That one itself should again be an > abstract thing returning moves and stuff in a unified form. > It calls an engine using the command set that is specified > by the engines parameters, that is UCI or xboard. But at the > output of this interface I don't want to know anymore wether > the connected engine is UCI or xboard. Why should I care > there and code all the xboard and the uci handling again and > again and again? This is an ideal approach, forgetting that engines are sometimes a bit tricky. This is why there is a wbdetect.tcl file that detects engines by their names and version (not protocol, as it is not sufficient) and sets some vars accordingly. For example : I want to setup a position with your universal interface : what to do with Phalanx that does not support the "setboard" command ? How will your universal interface manage this case, knowing only that it is an xboard engine ? My solution is to detect that the engine's name is Phalanx, and I detect at runtime if it is a Phalanx version that I patched myself, or not. Depending on that I send different commands, because I have to. > > To come back to the point above: If I have to check within > the FICS code wether there is a citrine connected or a dgt > or the user enters moves by the mouse or by the keyboard or > <whatever I can imagine> this will give the biggest portion > of spaghetti I ever saw. Just imagine, Ben is adding support > for his board, and you've to check in FICS code wether it > has to care about this... In about 8 weeks you'll just have > forgotten that you'll have to check there as this is the > farest remote spot of scids code imaginable for developing a > hardware driver interface. > > So I suggest to reconsider the current approach. I'm not > saying that the above is the only and perfect solution, but > IMHO we really _NEED_ to have interfaces in scid. Adding > functionality to scid at the current stage of the program is > IMHO reduced 90% implementing interfaces and 10% at the most > for the actual code there. > I still agree with you about the need of interfaces and general cleanup. But as I said there is some legacy code here and we have to do with it, with the constraints quoted above. Pascal ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
