Good Morning!
>> > Even when scidpocket runs on Linux, I have to check on
>> > which OS I am in order to have all Tcl code work.
>>
>> Just for my understanding: you mean you run sicd on a pocket
>> PC (some ARM machine), but this ARM runs on Linux, not on
>> WinCE? Just asking out of curiosity. I did not follow the
>> Pocket PC stuff at all as it is entirely out of my interests
>> as long as it requires CE. (I had very bad experiences with
>> that stuff, and I'm myself using PalmOS for years).
>
> When compiling scidpocket for Pocket PC I use a cross
> compiler (arm-gcc) to generate ARM code. When compiling
> for Linux (mainly for debugging), I simply use gcc for
> x86.
That is you develop for CE only and the rest ist just, hm,
well... Thats a bit sad news, for me at least.
>> >> Why again only for CE?
>> >>
>> > Simply because the code is slightly different between the
>> > two, and there are functions I prefer to have on Pocket
>> > PC, and others on PC.
>>
>> I do not see the latter. IMHO the functionality should be in
>> both versions. Otherwise its two different programs.
>
> It is like Pocket Word and MS Word : 2 different programs
> that are able to share files.
Plainly I never understood M$, and this is one of the very
bad parts in that desert...
> I agree most functionalities
> should be in both versions, but I have limited time for
> this, and I put high priority on features that pleases me
> the most (for the moment Citrine support). But anybody can
> work on this (features synchronization between the two
> versions) : this is not hard work as all difficult part is
> common (the C/C++ back office).
Point here is that I believe you're about the only one that
understands the scids internals. And frankly I do some
coding for some time but never in TCL (would never be the
lang of my choice either) and I admit that I've quite some
difficulties with your way of coding things in large complex
blocks of code.
>> Is there somewhere some comprehensive list of the flags? You
>> did all this coding you know them of course.
>
> No, there is no doc, but the code and some "grep" always
> did the trick for me.
Funny you ;) YOU know what you're looking for. THEN I can
also use grep. But I have to find what I'm not knowing that
I'm searching for. You understand my problem?
> Yes, I am trying to centralize things on Pocket PC as I
> wrote the code from scratch myself. Scid was iteratively
> coded, hence some complexities.
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?
>> 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.
> 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
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.
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. 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?
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.
--
Kind regards,
Alexander Wagner
Universitaetsbibliothek Ilmenau
Langewiesener Str. 37
98693 Ilmenau
Tel.: 03677/69-4521 , Fax.: 03677/69-4617
-------------------------------------------------------------------------
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
