pgeorges schrieb:
Hi!
> Alexander Wagner a écrit :
>> pgeorges schrieb:
>>
>> Hi!
>>
>> > It is also important to consider Pocket PC, as some people
>> > already managed to connect a DGT board with a PPC
>> > (CEboard, Pocket GrandMaster).
>>
>> Hm, though I do not use such a thing and admit that I really
>> don't like the runtime...
>>
>> I do not forget it. Why should I? It would be interesting
>> wether dgtnix would not compile on WinCE as well as it does
>> on Windows already. ;)
> [...]
>
> I did not look carefully to dgtnix and al., but on WinCE there is no
> stdin / stdout (yes, it is like that !).
Thats sad for CE. ;) Anyway I got your point.
> So it will certainly compile but will not run.
Dgtnix is a lib. It just does the hardware part of the
interaction with the board which is a bit complex.
> For example to make engines work, I first used sockets for
> IPC, but I had big sync problems due to network management
> on PDA. Then I switched to native Message Queues, and it
> works well, even if it was not a piece of cake for a
> Windows novice like me.
My point is here: You did it already to get something like
Toga to work.
My current approach to get the dgt to work is split it two
parts. There's the hardware related stuff like serial IO (or
BT or USB or whatever may come). This is the domain of
dgtnix, a pure lib in plain possix. On linux some .so, on
win some .dll on the mac some ... This part is done in C to
reuse at least the dev-header provided by DGT.
The second part is so to say an application sitting on this
one. This is dgtdrv. Actually it is pretty simple. It's just
linked against the DLL and then does some conversion. The
lib e.g. gives you a message like "King removed from e8" and
another one "King placed on e7". dgtdrv2 just takes this,
recognises this as move and makes some "e8e7" of it. In fact
I do not stick to stdio to much here.
BUT: from the past my main problem with any chess GUI I used
always was that I was not able to interface it at all. If I
wanted to do something that was not clickable I'm lost.
Resulting in the simple fact to use an bunch of tools doing
this or that. The other part was: HOW should I add
dgt-support to some GUI? I could compile every tool against
dgtnix hack the source in <place whatever language people
feel fit to use> hack again all the above mentioned "how to
identify a move" in C, in Java, in Perl, in TCL in ...
That's an awfull lot of work. Then I had the idea to reuse
what's already there. And every GUI has to have the
connection to a chess engine. Thats stdio. So IF it can talk
to a chess engine, I can create an "engine" that just sends
some commands to get what I want. And to add support to any
program is just to locate where the engine code resides and
add some string parsing. A lot simpler than compile it
against some lib... (If you ever had a look into xboard you
know what I mean ;)
Now for scid I'd _like to have_ this interface as well, I'll
do it that way now, it will give some working version of dgt
support. Actually it's already there, took me some days, but
first I had to learn some basic TCL (I never ever did a line
in that language before). So I consider this simple. :) And
now I have an interface in scid where I could hook up
"something". Thats fine.
Concerning CE: first of all I think to do the same to
dgtdrv2 as you did for an engine like toga should be pretty
simple. But you're starting to convince me that this takes
more than 10mins. (I admit that I just don't know).
So, from this point of view I'm staring to consider redoing
dgt-support in tcl. BUT: this will take time and NOT make
the interface where I could hook up anything obsolete. This
interface is IMHO quite a bit more universal. It's two ways
of doing things, and though you added fics already and
besides that I do not have a concrete idea for another app
IMHO interfaces are of great importance. (My job e.g.
involves quite a bit of work with a large DB that does not
have suitable interfaces on my level of access as I can't
use the pure SQL. And this creates a bunch of work
arrounds.)
Doing dgt support in pure TCL requires me to _recode_ the
entire dgtnix in TCL, that is all the hardware stuff, plus
recoding the entire dgtdrv. The latter is IMHO only time
consuming whereas the former is a bit more involved. Anyway,
I'm really considering this. This approach will have some
disadvantage, however: it requires quite a bit of code just
to get the dgt to work. It will require almost the same
ammount to get X to work and Y and again for Z. The really
sad thing here is that scid is in TCL. I do not speak that
language fluently. So it takes even longer.
But just to make it sure: Though I really don't like CE I'm
not forgetting that you want scid to run there as well. It
might just be beyond my possiblities to do all the above,
and it could well be that it is a lot simpler to add some
message queuing to dgtdrv2.cpp than to redo it all in TCL.
I don't really know what it requires, but I think you'd have
to touch LogString(), WriteString(), WriteInfoString() and
WriteErrorString() which are of the sort
va_list ap;
va_start(ap, text);
vfprintf(stdout, text, ap);
va_end(ap);
fflush(stdout);
And as I just see I should check wether I could reduce this
to one single function. Besides it reads two file
descriptors one for stdin and one for the boards interface.
--
Kind regards,
Alexander Wagner
Universitaetsbibliothek Ilmenau
Langewiesener Str. 37
98693 Ilmenau
Tel.: 03677/69-4521 , Fax.: 03677/69-4617
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
