Hi,
Tcl/Tk 8.5 had a huge refactoring in order to become locale-independent.
The problem is that I'm using an extension which calls :
setlocale(LC_ALL, "")
on a french desktop, and this causes Tk to report an error.
There are still some 'sprintf' calls in tk's source which are causing this issue.
The code to reproduce the error, as well as it's output is here : http://pastebin.com/m14756d67
You can replace the 'package require farsight' by a 'load' to any extension doing a :
setlocale(LC_ALL, "fr_FR.UTF-8@euro");
I did a grep on tk's 8.5.4 source and here's the list of sprintf's being used :
kakaroto% grep -r printf * | grep "%g"
generic/ttk/ttkScroll.c: sprintf(args, " %g %g",
generic/ttk/ttkScroll.c: sprintf(buf, "%g %g",
generic/tkScrollbar.c: sprintf(buf, "%g", fraction);
generic/tkScrollbar.c: sprintf(buf, "%g", fraction);
generic/tkArgv.c: sprintf(tmp, "%g", *((double *) infoPtr->dst));
generic/tkEntry.c: sprintf(buf, "%g %g", first, last);
generic/tkEntry.c: sprintf(args, " %g %g", first, last);
generic/tkEntry.c: sprintf(buf, "%g %g", first, last);
generic/tkCanvText.c: sprintf(buffer, "] %d %g %g %s %s DrawText\n",
generic/tkListbox.c: sprintf(buf, "%g %g", fraction, fraction2);
generic/tkListbox.c: sprintf(buf, "%g %g", fraction, fraction2);
generic/tkListbox.c: sprintf(string, " %g %g", first, last);
generic/tkListbox.c: sprintf(string, " %g %g", first, last);
macosx/tkMacOSXScrlbr.c: sprintf(valueString, "%g", newFirstFraction);
macosx/tkMacOSXScrlbr.c: sprintf(valueString, "%g",
macosx/tkMacOSXScrlbr.c: sprintf(valueString, "%g",
win/tkWinScrlbr.c: sprintf(valueString, "%g", pos);
Thanks,
KaKaRoTo
Hi,
it seems dkf updated the category to Themed Tk (ttk?), but I'm not sure how your categorization works, but it looks to me like it's wrong. Yes, the ttk/ttkScroll.c has this sprintf issue, but there are other native Tk widgets with the same issue (tkScrollbar, tkArgv, tkEntry, tkCanvText, tkListbox and windows/mac scrollbars).
Anyways, I hope this gets fixed soon!
The category you picked was definitely wrong (l10n refers to our message catalogs) and so it was assigned to exactly the wrong person. We'll probably bounce this around between various groups as it gets sorted out (alas, there's no single group that's right).
ah ok, makes more sense. Now that I think about it, it makes sense that the l10n category was definitely wrong.
Thanks!
Fixed in Tk HEAD. Ought to be backported so not closing yet.
thanks for fixing it!
Fixed on 8.5 branch. Can't be bothered to backport to 8.4!
Note that this change ties the
string result produced to the
value of ::tcl_precision, so creates
some real potential for incompatibility.
Also, when ::tcl_precision is
not the default value of 0, it appears
this patch is ineffective, since in
that case sprintf() is still at the
heart of Tcl_PrintDouble().
This also introduces a minor incompatibility (and is the cause of multiple test suite failures), even for applications that don't set ::tcl_precision or call setlocale(), in that "1" and "0" are now formatted as "1.0" and "0.0". Example:
==== entry-17.1 EntryUpdateScrollbar procedure FAILED
---- Result was:
0.0 1.0
---- Result should have been (exact matching):
0 1