scidb-users Mailing List for Scidb

Building libTkhtml3.a
Compiling tk_busy.cpp                     [-Wall -g]
tk_busy.cpp: In function ‘Busy* CreateBusy(Tcl_Interp*, Tk_Window)’:
tk_busy.cpp:960:12: error: invalid conversion from ‘void*’ to ‘char*’
[-fpermissive]
make[2]: *** [tk_busy.o] Error 1
make[1]: *** [recursive] Error 1
make: *** [all] Error 2

Tom F. wrote:
> I'm trying to mark a square from the "marks - palette" window, but I
> can't figure out how to do this. Clicking on a mark and then a square
> on the board doesn't seem to do it.

Yes, the help dialog is one of the tasks with highest priority,
unfortunately a lot of work.

You have to use the Control Key. Twice Control-Button-1 on the same
field sets or deletes a field marker. Twice Control-Button-1 on
different fields sets or deletes an arrow.
-- 
Gregor Cramer
email: <gc...@gm...>

Taking the program through its paces in annotation.

I'm trying to mark a square from the "marks - palette" window, but I
can't figure out how to do this. Clicking on a mark and then a square
on the board doesn't seem to do it.

I'm sure I'm missing something obvious, but I would appreciate being
pointed in the right direction.

Thanks,
Tom

Taking the program through its paces in annotation.

I'm trying to mark a square from the "marks - palette" window, but I
can't figure out how to do this. Clicking on a mark and then a square
on the board doesn't seem to do it.

I'm sure I'm missing something obvious, but I would appreciate being
pointed in the right direction.

Thanks,
Tom

Everything compiles fine except the file "src/tk/html/htmltcl.c
What am I missing? Here is the error message:

Compiling htmltcl.c                       [-Wall -g -DUSE_DOUBLE_BUFFERING]
htmltcl.c: In function ‘configureCmd’:
htmltcl.c:1402:9: error: ‘HTML_DEFAULT_CSS’ undeclared (first use in this
function)
htmltcl.c:1402:9: note: each undeclared identifier is reported only once
for each function it appears in
htmltcl.c: In function ‘handlerCmd’:
htmltcl.c:2164:18: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
htmltcl.c:2169:18: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
htmltcl.c: In function ‘htmlstyleCmd’:
htmltcl.c:2794:27: error: ‘HTML_DEFAULT_CSS’ undeclared (first use in this
function)
htmltcl.c:2794:5: warning: passing argument 2 of ‘Tcl_SetResult’ from
incompatible pointer type [enabled by default]
/usr/include/tcl8.5/tclDecls.h:1392:14: note: expected ‘char *’ but
argument is of type ‘struct Tk_OptionSpec *’
htmltcl.c:2796:34: error: ‘HTML_DEFAULT_QUIRKS’ undeclared (first use in
this function)
htmltcl.c: In function ‘htmlVersionCmd’:
htmltcl.c:2829:27: error: ‘HTML_SOURCE_FILES’ undeclared (first use in this
function)
htmltcl.c:2829:5: warning: passing argument 2 of ‘Tcl_SetResult’ from
incompatible pointer type [enabled by default]
/usr/include/tcl8.5/tclDecls.h:1392:14: note: expected ‘char *’ but
argument is of type ‘struct Tk_OptionSpec *’
htmltcl.c: In function ‘Tkhtml_Init’:
htmltcl.c:2999:29: error: ‘HTML_DEFAULT_TCL’ undeclared (first use in this
function)
htmltcl.c:2999:5: warning: passing argument 2 of ‘Tcl_EvalEx’ from
incompatible pointer type [enabled by default]
/usr/include/tcl8.5/tclDecls.h:1744:13: note: expected ‘const char *’ but
argument is of type ‘struct Tk_OptionSpec *’
make[2]: *** [htmltcl.o] Error 1
make[1]: *** [recursive] Error 1
make: *** [all] Error 2

About the segfaults on Ubuntu 11.10 (Oneiric) and Debian 7.0 (Wheezy):

After a couple of weeks I've found two different solutions/hacks:

Debian Wheezy: I found a proper work-around for the static object
initialization problem.

Ubuntu Oneric: This work-around is not working on Ubuntu 11.10, so I
implemented a hack (doing static object initialization "by hand").

In both cases it seems to be a problem with the linker. The GNU team has
changed the linker concept (the .ctors section is gone), and this linker
is not working properly. This assumption is based on a remote diagnosis
(and it's difficult to do a remote diagnosis).

Thanks to Lars who did many, many tests on his Ubuntu 11.10 release, and thanks to Tom who also did many tests on his Debian 7.0 release.

Finally: revision #161 should work on all distributions, even the broken
ones.
-- 
Gregor Cramer
email: <gc...@gm...>

I just realized hitting "reply" doesn't send my messages to the list.
Sorry Gregor!
Tom

---------- Forwarded message ----------
From: Tom F. <fu...@gm...>
Date: Thu, Dec 15, 2011 at 10:57 AM
Subject: Re: [Scidb-users] Position search
To: Gregor Cramer <gc...@gm...>


I'd have to agree with Gregor here. Sure, it's a small percentage of
master games that would involve, oh say for example, a king move to
Kf1 and back to e1, but like Murphy's law it will happen. In such
games, this would be a crucial point and the two positions (one as
described above with no castling rights, and one where the odd King
move did not occur but is otherwise the same) are not even close to
equal.

In addition, and perhaps more to the point, as such variants as
Random960 become more and more popular, castling rights are quite a
bit different at first blush and a sort of "flag" denoting castling
rights is needed.

As it stands now, pgn cannot handle the initial position of such games
and you will find many Random games in databases that start with an
FEN "after castling has occurred."

Tom

> In standard chess it's relatively simple, two position are
> equal if:
> ...
> - same castling rights
> ...
> Scid does not consider the castling rights.

Steve wrote:
> But does it make any practical difference ?

Definitively yes. It is possible that in a certain position the castling
right may change the position evaluation fundamentally. In a certain
position the castling may lead to win (avoids mate), but the lack of the
castling right leads to a loss (mate is unavoidable). Furthermore the
strategy in a game may depend on the castling rights. One example: The
right of a short castling may give you the possibility to a pawn storm
on the queen side, but often the lack of the short castling right
forbids a pawn storm on the queen side.

> ie - How many real games do you have with identical board setups but
> different castling rights.

Above I've pointed out that I'm not talking about the start position.
I assume that you're asking about board setups in the middle game.
Momently I don't have practical games. With my practical experience
the influence by castling rights on the strategy in a game is important,
the influence of the castling rights is more important than the
influence of en-passant rights. If you assume that the number
of real games with equal positions but different castling rights is
small, I will agree, nevertheless it is important.

The definition of position search rules is a matter of experience (or
a viewpoint), and it's not a problem if there are differences between
different chess database applications. But with my experience the
castling right is important (I was an attacking player, disregarding
any safety, but not disregarding the position). The statement
> Scid does not consider the castling rights.
is only an observation about the differences. This statement is
important; for example if you open the database Big2010.cbh (provided by
the ChessBase distribution) the opening trees of Scid and Scidb do differ
slightly, but that's not an error, it's a different point of view
(Big2010.cbh contains some games with unusual castling rights).
-- 
Gregor Cramer
email: <gc...@gm...>

> In standard chess it's relatively simple, two position are
> equal if:
> 
> - all squares do contain the same pieces
> - both positions have same en-passant possibilities
> - same sides to move
> - same castling rights
> 
> The latter (same castling rights) is also important because
> generally
> the strategy in a game considers the castling rights.

.....

> Steve: The position search in Scid/Scid-vs-PC does only use
> the first
> three conditions:
> - all squares do contain the same pieces
> - both positions have same en-passant possibilities
> - same sides to move
> This means Scid does not consider the castling rights. Try
> the appended

But does it make any practical difference ?
ie - How many real games do you have with identical board setups but different castling rights.
(Please forward games to me).

cheers, Steve

Michael G. Thomas wrote:
I just wanted to confirm this is happening on Debian Wheezy, too.

One important information is missing: which version of Scidb did you test? The public version (revision #83) is segfaulting due to an undetermined order of static object initialization, but this is solved in revision #133. Did you try the repository version?

About the current state of Ubuntu 11.10: no solution yet. The build of Scidb on Ubuntu 11.10 results in a corrupted executable (not really segfaulting, but terminating due to improper processing). Probably this happens on Debian Wheezy as well; Ubuntu is based on the Debian line.

I've planned to release a new public version, but currently the following problems/tasks are open:

- Improper build on Ubuntu 11.10; no solution yet.

- The Spanish translation is not up to date, Fernando - who did the translation - is not responding to emails anymore. I'm waiting for a volunteer who likes to update the Spanish translation, I do not like to publish an unfinished translation file. If nobody is interested I will remove Spanish (temporary until a volunteer is found).

- Currently I'm working on LaTeX print/export. I'm not sure if I will finish this task until the next public version, it depends on when a solution for the Ubuntu problem is found. The current revision #151 is containing the revised export dialog for LaTeX (but the "Save" button is not yet working, and the dialog needs more testing).

-- 
Gregor Cramer
email: <gc...@gm...>

From: Gregor Cramer <gcramer@gm...> - 2011-11-21 08:26

>> Michael G. Thomas wrote:
>> Latest scidb-beta compiles on ubuntu-11.10-amd64 but segfaults
>> when I try to run it

> I know this problem and I'm working on a solution. In advance
> (only Ubuntu 11.10 is affected):

I just wanted to confirm this is happening on Debian Wheezy, too.

Thanks for the great work!

Tom