Call for help for ChessX

[whp]

ChessX is meant to be modern free chess database. It has been developed since about 2006 spring and the response it quite good - version 0.5 was downloaded 1442 times only for Windows (and few hundreds more for Linux and MacOS X). The problem is ChessX lacks manpower.

So if you are interested/skillful in: C++, Qt 4.2+ and want to help develop nice looking, usable, chess database please consider ChessX as your next open source project .

Check the ChessX website and its Source Forge project site (go for mailing lists - forums are not used).

I myself believe ChessX is a good candidate to become next SCID. Unfortunately I am not into C++ and Qt (rather a Java amateur programmer).

[Dann Corbit]

ChessX is meant to be modern free chess database. It has been developed since about 2006 spring and the response it quite good - version 0.5 was downloaded 1442 times only for Windows (and few hundreds more for Linux and MacOS X). The problem is ChessX lacks manpower.

So if you are interested/skillful in: C++, Qt 4.2+ and want to help develop nice looking, usable, chess database please consider ChessX as your next open source project .

Check the ChessX website and its Source Forge project site (go for mailing lists - forums are not used).

I myself believe ChessX is a good candidate to become next SCID. Unfortunately I am not into C++ and Qt (rather a Java amateur programmer).

It is abysmally slow. So slow, in fact, that it cannot be used for serious real-life sized databases.

Something that calls itself a chess database should (in fact) use some sort of database mechanism.

ChessX is not a database at all. It's a nice looking GUI on top of a very, very inefficient flat-file mechanism.

Unless someone bolts a database interface of some kind to that thing, it's not going anywhere.

SCID uses a proprietary database file format, but it's a good one.
Jose uses MySQL.
The commercial systems use their own ISAM type database interfaces.
The ChessX approach is simply not going to work.

[whp]

Thank you Dann for your post . As I wrote ChessX is meant to be a modern chess database. Sure, it is in the early stages of development, but how awkward would it be to call every piece of software in its infancy to-be-free-something ? I remember you pointed out performance problems in your previous responses to my posts. I am sure those would be sorted out faster if only ChessX got more developers hence my post.

[shiv]

Chessx currently only supports PGN and thus is not a database yet.

I am surprised you call the SCID database format proprietary. They provide source code accessing the database and the program is open source too. It is not a closed format.

[Dann Corbit]

Proprietary in the sense of privately owned format. It is not a standard database format. The API for the database is peculiar to SCID.

Perhaps 'unusual' or 'non-standard' would have been a better word.

[Dirt]

'Custom format' seems to fit.

[whp]

Yes, I agree - ChessX is not yet database, but it would be silly to call to-be-chess-database wouldn't it? Anyway, language problems away I'd like to thank you all for your suggestions - I've passed them to the developer's mailing list. Hopefully problems with performance and file format will get some attention, but given that there is only one active developer working on ChessX (at least this is what he told me) it'll take a while. Please, help ChessX find new developers!

[pijl]

ChessX is meant to be modern free chess database. It has been developed since about 2006 spring and the response it quite good - version 0.5 was downloaded 1442 times only for Windows (and few hundreds more for Linux and MacOS X). The problem is ChessX lacks manpower.

So if you are interested/skillful in: C++, Qt 4.2+ and want to help develop nice looking, usable, chess database please consider ChessX as your next open source project .

Check the ChessX website and its Source Forge project site (go for mailing lists - forums are not used).

I myself believe ChessX is a good candidate to become next SCID. Unfortunately I am not into C++ and Qt (rather a Java amateur programmer).

It is abysmally slow. So slow, in fact, that it cannot be used for serious real-life sized databases.

Something that calls itself a chess database should (in fact) use some sort of database mechanism.

ChessX is not a database at all. It's a nice looking GUI on top of a very, very inefficient flat-file mechanism.

Unless someone bolts a database interface of some kind to that thing, it's not going anywhere.

The main problem is that the search/filter classes are written independent to work independent of the database. Even if the database format/class would have efficient search functions, the framework does not have the possibility to use it.

In other words: Instead of giving some sort of filter rules object to a database to yield the matching games, it will start with all games, and try to apply one filter criteria to all games in that database by loading the game. If it is a match, the game stays, if it is not a match it will be removed (from the search results). If all games in the database are processed against the first criterium, the next filter criterium will be checked against all remaining games etc.

Normally, databases work the other way around: They will find the games matching a criterium (or a combination of them) quickly by having dedicated indexes. So it depends on the database (format) and its capabilities how to search most efficient. As long as the search routines themselves are unaware of the type of database used, it will never be able to search efficiently.

It is possible to do this with virtual functions, so that the Parent database class can still contain the less efficient search methods (for use in eg the PGN database class and similar structures).

I've discussed this before with Michal (one of the chessx designers), and apparently this was either not understood, or not found to be important.
Richard.

[whp]

I see your point. Reparsing big collections of games is time consuming for sure. I've already written to the developers mailing list about this discussion - let's hope they'll read it. And let's hope that it would be 'they' not 'he' .

Did you consider coding the solution for ChessX?

[pijl]

Did you consider coding the solution for ChessX?

The short answer is no.

My interest in the database has been reduced to only fast position search, which I use in my opening book. I already have my own native database format that I use in the openingbook of the Baron. My database format with all indexes that I defined active still uses less space than a PGN file with the same number of games, and is able to find a position in a 4 million games database within seconds.

The format I use depend on a move generator (moves are stored as the nth generated move, reducing space used to max 1 byte, with a possibility to use 2 bytes when the nr of possible moves in a position exceeds 250) and other structures that are already present inside chessx. Adding these components just to support a 'native' database format would not be a nice solution, but I do not have the time to rewrite it for chessx. And it would be quite a bit of work anyway, as the chessx coding style is not compatible with mine.

Instead, I could implement interface code to my own classes so that something could be available on the short term, probably in the form of a DLL for windows or shared library for linux. Kind of a plug-in database module. But it is up to the chessx designers to put in the required changes to be able to use database native search methods. I'm willing to discuss that further. But perhaps transplanting the SCID format would be simpler?

Richard.