Winboard Forum

I am considering to support UCI and I want to know if I am allowed to copy code in glaurung1.5 that supports UCI(I plan to mention tord in notes about it and release the relevant code)

I could ask by email but I think that it may be relevant also for other programmers.

I am talking about the files
strcase.c and part of the file uci.c

Uri

I prefer to save time of reading about what exactly I need to do and dealing with possible bugs.
I also copied some code to support winboard from posts of Dieter.

I am interested in the engine and not in following instructions of some interface that I may misunderstand.

Uri

There is no point in reinventing the wheel.

I can also add that I do not consider myself as a good programmer in supporting interfaces and I am sure that the code of almost every programmer is going to be better than me in these tasks so it is better if I copy code from another programmer in order not to waste too much time in deterministic tasks that have nothing to do with the chess engine.

Uri

From my point of view, there's no problem as long as you give credit to Tord. You said you'll do, so IMO it is fine that you use the code (of course if Tord gives you permission).
It is possible that it could be a problem if you enter a world champs, where the rules say no code from other programs, but many people use EGTBs code from Nalimov, and that doesn't seem to be a problem...

Jos? Carlos wrote:From my point of view, there's no problem as long as you give credit to Tord. You said you'll do, so IMO it is fine that you use the code (of course if Tord gives you permission).
It is possible that it could be a problem if you enter a world champs, where the rules say no code from other programs, but many people use EGTBs code from Nalimov, and that doesn't seem to be a problem...

I think that it is not what is meant by not using code from other people.

By these rules
I was not allowed to enter WCCC because of using some code of Dieter to support winboard and to evaluate draws in kpk positions[(he posted the relevant code in CCC or in the old winboard forum(note that the code for evaluating KPK did not effect the results of movei in the tournament)].

I think that the main problem is one of the following cases:
1)people who copy significant evaluation code from another program(reading tablebases or bitbases for endgames is not included).
2)people who copy significant search code from another program.
3)people who copy book choice code from another program(it means not only code to help them to find the next move or the next position in a pgn file or code to translate pgn notation to move).
4)people who copy significant time management code from another program.
5)people who copy parallel search code from another program.

Uri

I forgot 6)people who use significant code from another program for their move generator or for making moves.

Uri

From my experience you don't earn much time from copying extracts from other programs. The UCI protocol is so easy that the time you need to adapt Tord's code to your own and to be sure that there are no bugs in total package is maybe even more than writing it yourself.
In addition you have full "knowledge control" of code you wrote yourself.
/Peter

Uri Blass wrote:I am considering to support UCI and I want to know if I am allowed to copy code in glaurung1.5 that supports UCI(I plan to mention tord in notes about it and release the relevant code)

I could ask by email but I think that it may be relevant also for other programmers.

I am talking about the files
strcase.c and part of the file uci.c

Hi Uri,

You are of course welcome to use the UCI code from Glaurung, and it is not even important that you mention my name in your release notes.

The readme file distributed with the Glaurung source code was written in just a few minutes, and some sections should probably have been expanded and clarified. In particular, this applies to the use of my code in other programs. The restrictions I describe for use of my code apply only to the engine code itself, and not to interface code and similar trivialities. Code which is obviously completely irrelevant for playing strength can used without any restrictions.

On the other hand, I am not sure using Glaurung's UCI code is a very good idea. The UCI code was just a quick hack job, and is neither very well-written nor flexible. Some parts of the UCI protocol are not supported at all (no support for fixed-depth levels, for instance). The engine options code is so poorly written that my limited English vocabulary does not contain words capable of giving it the description it deserves.

It is likely that most of the other open-source UCI engines would serve you better as a starting point.

Tord

Uri Blass wrote:I am talking about the files
strcase.c and part of the file uci.c

One more thing I ought to have mentioned in my first reply: The code in strcase.c is not even mine. This file was added by Dann Corbit when he ported Glaurung to Windows. The Unix versions of Glaurung do not use this file at all. The strcasecmp and strncasecmp functions, which perform case-insensitive string comparison, are available on all Unix dialects I have used, but apparently they are not supported by all Windows C compilers. Therefore, Dann had to add the strcase.c file, containing portable versions of these two functions. I know nothing about the origin of the file, apart from the short copyright notice at the beginning of the file.

Something similar is true for the file timeoday.c, which I have never touched, and which is also not used by Glaurung on Unix systems. Dann also added some code to make input polling work in Windows, found near the end of io.c. The Mersenne Twister random number generator, found in mersenne.c, is of course also not written by me.

Tord

Tord, just some minor pedantic nit pickings. Portable code should not define functions str[a-z]..., that are not defined in the ISO C-Standard. Neither should maximal portable code use such functions. These names are reserverd. Using names like str_casecmp (the underscore makes the difference) is safe, however. I did not look at your source, so I cannot judge, how you really use it.

I agree, with your comment about writing UCI interface code yourself. Should be much easier, than adapting foreign code. Only little programming skill and experience (say in parsing and string handling) should be needed.

Regards,
Dieter

I don't like the idea of an engine supporting two protocols especially
UCI and WinBoard when there are reliable utilities for porting one
in to the other. But if you have to do so, there is no point in reinventing the wheel. After all that's why the GUI,the adapters ,Nalimov TB(i really hope somebody writes a public DLL to do this) etc are for.
daniel

Dieter B?r?ner wrote:Tord, just some minor pedantic nit pickings. Portable code should not define functions str[a-z]..., that are not defined in the ISO C-Standard. Neither should maximal portable code use such functions. These names are reserverd. Using names like str_casecmp (the underscore makes the difference) is safe, however. I did not look at your source, so I cannot judge, how you really use it.

Hi Dieter,

I appreciate your nit pickings. I have never really learned the C programming language, and as a consequence I program in a mixture of ANSI C, GNU-specific extensions, and Unix system calls, without really knowing what is what. When I wrote my code, I thought the strncasecmp function was part of the standard C library. Evidently I was wrong. I suppose I should add something like;

Code: Select all

#if defined(UNIX)
#  define str_casecmp strcasecmp
#  define str_ncasecmp strncasecmp
#endif


to my header file, and at the same time change the names of the functions in Dann's strcase.c file.

Tord

Hi Tord,

has the idea of publishing sources been to provide a ready to use piece of code "patchwork" or should it only support the understanding of underlaying ideas?

I am just wondering about such critical postings demanding for ready to compile and run source code packages.

Reinhard.

Hi Reinhard,
I think that the idea of open source code is also to provide basic tools
at least in part of the program that is not competitive.

programmers do not need to invent everything and can use library functions that other people invented.

I see no reason not to let people to use existing code that is not about competition that they can start from it.

Some code to use the UCI interface or the winboard interface are examples and another example is code to read pgn.

The code that I am talking about is not code that can work by itself and
in order to use it the programmer need to have chess functions

The function that I have to read pgn that I have no problem to share is not function that work by itself because functions like makemove need to be defined by the programmer in order to use it.

code for UCI can also not work by itself because it is using chess functions
and if I have other names for my chess functions I can also not copy and paste from other code with no changes.

Uri

Hi Uri,

concernimg interfaces I think that you are right. Interfaces and protocols should be open to use and well documented.

Concerning UCI embedding within a chess program I am in doubt whether that could be handled independently from the data structure and move generator. But it could be that today that dense relationship is easily to be overseen because chess programs may tend to become more and more related by the mass of published code.

Nevertheless patchworking a UCI implementation is not really problematic. It normally is not changing the playing strength of a program. But it could improve its testabiliy.

Looking at my Smirf using its own 10x8 and 8x8 GUI and TCMI protocol I have big problems to have a relevant number of test games. And there is no model to be copied. But it will finally end in writing a UCI to TCMI adapter. That are those consequences coming when deciding to stay on one's own.

Reinhard.

Tord Romstad wrote:I appreciate your nit pickings. I have never really learned the C programming language, and as a consequence I program in a mixture of ANSI C, GNU-specific extensions, and Unix system calls, without really knowing what is what. When I wrote my code, I thought the strncasecmp function was part of the standard C library. Evidently I was wrong. I suppose I should add something like;

Code: Select all

#if defined(UNIX)
#  define str_casecmp strcasecmp
#  define str_ncasecmp strncasecmp
#endif


to my header file, and at the same time change the names of the functions in Dann's strcase.c file.

Tord

Really, I am very pedantic I guess, when you compile your code with strictest Standard C conformance flags, this still can have problems. Under these conditions the compiler may choose to hide strcasecmp from string.h. Also, of course, the compiler will not define UNIX then (I guess you are aware of this).

Anyway, this really is too much nit picking. I did not look at your code yet. When I looked at free code earlier, I was always a bit dissapointed. I am convinced, that it is possible to write a decent chess engine in pure Standard C, with the exception of very few routines (only timing code and input polling comes to my mind), that can be well seperated. In a learning engine, I think it would be nice to have Standard C. When I first looked at TSCP: it assumes 32 bit int, IIRC also some issues with signedness, etc. Things that are not guaranteed in Standard C (but of course will work under most environments nowadays, although at that time I still used old Borland C 3.5, under which TSCP would not work, and it would be quite some effort to make it work).

BTW. For what do you need strcasecmp (in the context of UCI)? Aren't UCI commands case sensitive?

Cheers,
Dieter

Dieter B?r?ner wrote:

Tord Romstad wrote:I appreciate your nit pickings. I have never really learned the C programming language, and as a consequence I program in a mixture of ANSI C, GNU-specific extensions, and Unix system calls, without really knowing what is what. When I wrote my code, I thought the strncasecmp function was part of the standard C library. Evidently I was wrong. I suppose I should add something like;

Code: Select all

#if defined(UNIX)
#  define str_casecmp strcasecmp
#  define str_ncasecmp strncasecmp
#endif


to my header file, and at the same time change the names of the functions in Dann's strcase.c file.

Tord

Really, I am very pedantic I guess, when you compile your code with strictest Standard C conformance flags, this still can have problems. Under these conditions the compiler may choose to hide strcasecmp from string.h. Also, of course, the compiler will not define UNIX then (I guess you are aware of this).

No, I was not aware of this at all. Thanks for telling me!

Anyway, this really is too much nit picking. I did not look at your code yet. When I looked at free code earlier, I was always a bit dissapointed. I am convinced, that it is possible to write a decent chess engine in pure Standard C, with the exception of very few routines (only timing code and input polling comes to my mind), that can be well seperated. In a learning engine, I think it would be nice to have Standard C. When I first looked at TSCP: it assumes 32 bit int, IIRC also some issues with signedness, etc. Things that are not guaranteed in Standard C (but of course will work under most environments nowadays, although at that time I still used old Borland C 3.5, under which TSCP would not work, and it would be quite some effort to make it work).

You would probably be disappointed by Glaurung, too. I am not the right person to write a decent engine in pure Standard C, for the simple reason that I do not know Standard C. As far as I know, I do not assume 32 bit ints or anything similar, but it would surprise me if you could not find some compiler and platform where my code does not work. It has only been tested on various Unix platforms.

If you ever decide to take a look at my source code (but frankly, I doubt that it would be worth the effort for an experienced programmer like you), I would of course be very happy to receive all the pedantic feedback you can give me.

BTW. For what do you need strcasecmp (in the context of UCI)? Aren't UCI commands case sensitive?

If I recall correctly (which I very possibly do not), this is not specified in the UCI protocol. I no longer remember clearly why I chose to use strcasecmp rather than strcmp, but I think I was afraid that different GUIs would use different case conventions. Case insensitivity also makes it easier to interact with the engine from the console while debugging.

Tord

Uri Blass wrote:programmers do not need to invent everything and can use library functions that other people invented.

Do you think it would be usefull to have a free library with popular functions in chess programming, like bitboard move generation, pgn reading, san decoding, and other things? Is there any such library available?