Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2005-08-25 20:32:45
|
Hi !
Petr Mikulik has just wrote the following comment on the sourceforge page=
about the wxwidgets terminal :
"please switch to "C" locale for numbers, at least when
communicating with gnuplot; otherwise, zooming wants to
execute command "set xr[1,234:5,678]" which is wrong"
I've seen this problem on my box too, which has locale fr_FR, with a comm=
a for the LC_numeric locale.
However, I see the same problem with the x11 terminal.
And the command "set locale {locale {locale_set}}" doesn't seem to do any=
thing about it...
What behaviour should I expect ?
Thanks,
Timoth=E9e Lecomte
|
|
From: <mi...@ph...> - 2005-08-26 12:21:32
|
> "please switch to "C" locale for numbers, at least when > communicating with gnuplot; otherwise, zooming wants to > execute command "set xr[1,234:5,678]" which is wrong" > > I've seen this problem on my box too, which has locale fr_FR, with a comma > for the LC_numeric locale. I reported a similar problem related to parsing .Xdefaults recently, and I think init_locale() is called inside plot.c to switch to C locale. Isn't initialization of wxterminal before this call? --- PM |
|
From: <tim...@en...> - 2005-08-26 16:19:57
|
mi...@ph... wrote: >>"please switch to "C" locale for numbers, at least when >>communicating with gnuplot; otherwise, zooming wants to >>execute command "set xr[1,234:5,678]" which is wrong" >> >>I've seen this problem on my box too, which has locale fr_FR, with a comma for the LC_numeric locale. >> >> > >I reported a similar problem related to parsing .Xdefaults recently, and I >think init_locale() is called inside plot.c to switch to C locale. Isn't >initialization of wxterminal before this call? > > > No, it isn't : I initialize the wxwidgets library just before the loop on com_line(), so init_locale has already been called. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-09-12 05:24:34
|
I've been gone, and may have missed a resolution to this question.
But in case not...
On Thursday 25 August 2005 01:33 pm, Timoth=E9e Lecomte wrote:
>
> I've seen this problem on my box too, which has locale fr_FR, with a
> comma for the LC_numeric locale. However, I see the same problem with
> the x11 terminal.
>
> And the command "set locale {locale {locale_set}}" doesn't seem to do
> anything about it... What behaviour should I expect ?
The "set locale" command only affects LC_TIME.
To change the locale of the decimal sign (LC_NUMERIC) you need to
call "set decimalsign".
Does that answer your question?=20
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: <tim...@en...> - 2005-09-16 21:33:19
|
Ethan A Merritt wrote:
>I've been gone, and may have missed a resolution to this question.
>But in case not...
>
>On Thursday 25 August 2005 01:33 pm, Timoth=E9e Lecomte wrote:
> =20
>
>>I've seen this problem on my box too, which has locale fr_FR, with a
>>comma for the LC_numeric locale. However, I see the same problem with
>>the x11 terminal.
>>
>>And the command "set locale {locale {locale_set}}" doesn't seem to do
>>anything about it... What behaviour should I expect ?
>> =20
>>
>
>The "set locale" command only affects LC_TIME.
>To change the locale of the decimal sign (LC_NUMERIC) you need to
>call "set decimalsign".
>
>Does that answer your question?=20
> =20
>
It's my error : I meant "set decimalsign {locale {locale_set}}". This
command doesn't seem to affect the behaviour of the X11 terminal.
My computer's locale os "fr_FR". The locale decimal sign is "," and x11
terminal seems to use it as it draws coords with it. But it gives an
error when zooming, as a comma is rejected by the parser...
I get :
gnuplot> set xr[-6,56788793103:4,12176724138]; set
yr[-4,97885835095:3,73150105708]; set x2r[-6,56789: 4,12177]; set
y2r[-4,97886: 3,73150]
^
':' or keyword 'to' expected
Hope I'm clear enough ;-)
Timoth=E9e
P.S. : by the way, I realised that the "coords to clipboard with 2*<B1>"
doesn't work with the x11 terminal. Is it normal ?
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-09-16 23:58:06
Attachments:
decimalsign.patch
|
On Friday 16 September 2005 02:33 pm, Timoth=E9e Lecomte wrote:
> >
> It's my error : I meant "set decimalsign {locale {locale_set}}". This
> command doesn't seem to affect the behaviour of the X11 terminal.
>=20
> My computer's locale os "fr_FR". The locale decimal sign is "," and x11
> terminal seems to use it as it draws coords with it. But it gives an
> error when zooming, as a comma is rejected by the parser...
>=20
> I get :
>=20
> gnuplot> set xr[-6,56788793103:4,12176724138]; set
> ^
> ':' or keyword 'to' expected
Please try attached patch.
Keep an eye open for unexpected side-effects.
Ethan
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Juergen W. <wie...@fr...> - 2005-09-17 07:19:12
|
On Saturday 17 September 2005 03:07 Ethan A Merritt wrote:
> On the other hand this makes many gnuplot commands ambiguous
> at best:
>
> set label 1 offset 1,2
>
> I would have expected this to set the offset to (xoff=1 yoff=3 zoff=0)
> but now it instead sets (xoff=1,2 yoff=0 zoff=0).
> Is that acceptable? Is it what a user would expect, if he has gone
> to the trouble of setting a decimalsign == comma locale?
My two pence:
This example shows quite nice that the parsing of the *script* file
should never be locale dependend. The decimal point is part of the
script language specification. It might be a feature to enable the
possibility for data files with decimal commas.
> But the current, unpatched, state of the code has problems also.
> set decimalsign locale
> show locale
> LC_CTYPE is fr_FR
> LC_NUMERIC is fr_FR
> LC_TIME is C
> PI = 3.14159
> print PI
> 3.0
> print pi
> 3,14159265358979
>
> That is both wrong, and puzzling. I can understand why PI gets
> set to 3 on input - that's the effect of sscanf() or atod() with
> LC_NUMERIC set to fr_FR. But why does it revert to a dot for the
> decimal sign on output? Notice that the internal constant "pi" is
> printed with a comma, as I would have expected. Strange.
The ".0" is explicitly added to show it is a float, not an integer.
See show.c (num_to_str):
if (strchr(s[j], '.') == NULL &&
#ifdef HAVE_LOCALE_H
strchr(s[j], ',') == NULL &&
#endif
strchr(s[j], 'e') == NULL &&
strchr(s[j], 'E') == NULL)
strcat(s[j], ".0");
> Perhaps a better way is to force LC_NUMERIC to C during the
> scanning of a gnuplot input line. That means all numbers on a
> gnuplot command line must use dot rather than comma as a
> decimal sign. Then to fix the original bug report, any code
> that *constructs* a gnuplot command line, must *also* set
> LC_NUMERIC to C while it operates.
> That would include both the built-in functions like zoom and the
> interpretation of key bindings.
ACK.
Juergen
|
|
From: V. <gae...@no...> - 2005-09-17 12:23:41
|
On Sat, Sep 17, 2005 at 09:18:28AM +0200, Juergen Wieferink wrote:
> This example shows quite nice that the parsing of the *script* file
> should never be locale dependend. The decimal point is part of the
> script language specification.=20
I totally do agree with this point. Especially a I am from a part of
the world in which the coma is the decimal separator, on paper. On
calculators, for instance, it is the full stop :".".
--
Ga=EBl
|
|
From: Petr M. <mi...@ph...> - 2005-09-17 13:23:20
|
> This example shows quite nice that the parsing of the *script* file > should never be locale dependend. The decimal point is part of the > script language specification. It might be a feature to enable the > possibility for data files with decimal commas. I agree (locale cs_CZ.UTF-8): optionally allow "," via a set command only for data files and for output graphs. --- PM |
|
From: Petr M. <mi...@ph...> - 2005-09-17 14:18:39
|
> gnuplot> set xr[-6,56788793103:4,12176724138]; set > yr[-4,97885835095:3,73150105708]; set x2r[-6,56789: 4,12177]; set > y2r[-4,97886: 3,73150] > ^ > ':' or keyword 'to' expected I think this has been already fixed -- it does not happen for my cs_CZ locale. > P.S. : by the way, I realised that the "coords to clipboard with 2*<B1>" > doesn't work with the x11 terminal. Is it normal ? Copying to xterm, nedit, gedit works. Copying to anything using Qt (thus, any Qt/KDE application) does not work. How can this be allowed? --- PM |
|
From: <tim...@en...> - 2005-09-17 17:51:24
|
Petr Mikulik wrote: >> gnuplot> set xr[-6,56788793103:4,12176724138]; set >> yr[-4,97885835095:3,73150105708]; set x2r[-6,56789: 4,12177]; set >> y2r[-4,97886: 3,73150] >> ^ >> ':' or keyword 'to' expected > > > I think this has been already fixed -- it does not happen for my cs_CZ > locale. Indeed, it was a problem caused by wxwidgets, in my patched gnuplot only. > >> P.S. : by the way, I realised that the "coords to clipboard with 2*<B1= >" >> doesn't work with the x11 terminal. Is it normal ? > > > Copying to xterm, nedit, gedit works. > > Copying to anything using Qt (thus, any Qt/KDE application) does not > work. > How can this be allowed? You're right, I was pasting to Konsole... but unfortunately I can't help you to allow this in Qt. (In my wxwidgets terminal, I use the clipboard object, and it just works) Greetings, Timoth=E9e Lecomte |
|
From: Petr M. <mi...@ph...> - 2005-09-27 13:51:13
|
>>> P.S. : by the way, I realised that the "coords to clipboard with 2*<B1>" >>> doesn't work with the x11 terminal. Is it normal ? >> >> Copying to xterm, nedit, gedit works. >> >> Copying to anything using Qt (thus, any Qt/KDE application) does not >> work. >> How can this be allowed? > > You're right, I was pasting to Konsole... but unfortunately I can't help > you to allow this in Qt. (In my wxwidgets terminal, I use the clipboard > object, and it just works) I've just filled in a bug report so that "someone" could search for a solution. Accidentaly, I've found this amazing feature: having double-clicked MB1, sequent MB2 copied the cursor position into gvim, but into OpenOffice.org it copied png image of the graph! What's the magics behind?? --- PM |
|
From: <tim...@en...> - 2005-09-27 14:27:19
|
Petr Mikulik wrote: >>>> P.S. : by the way, I realised that the "coords to clipboard with >>>> 2*<B1>" >>>> doesn't work with the x11 terminal. Is it normal ? >>> >>> >>> Copying to xterm, nedit, gedit works. >>> >>> Copying to anything using Qt (thus, any Qt/KDE application) does not >>> work. >>> How can this be allowed? >> >> >> You're right, I was pasting to Konsole... but unfortunately I can't he= lp >> you to allow this in Qt. (In my wxwidgets terminal, I use the clipboar= d >> object, and it just works) > > > I've just filled in a bug report so that "someone" could search for a > solution. "Someone" could look in gtk code, to see where's the trick... > > Accidentaly, I've found this amazing feature: having double-clicked > MB1, sequent MB2 copied the cursor position into gvim, but into > OpenOffice.org it copied png image of the graph! What's the magics > behind?? > > --- > PM I also found such a "feature" as I was implementing the same for my wxwidgets terminal. When I was playing with double-click, the X11 plot appeared in klipper, the kde clipboard handler ! I think that it's a feature of the window manager (kwin), but I'm not sure at all... Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2005-09-27 14:44:42
|
> I also found such a "feature" as I was implementing the same for my > wxwidgets terminal. When I was playing with double-click, the X11 plot > appeared in klipper, the kde clipboard handler ! I think that it's a > feature of the window manager (kwin), but I'm not sure at all... I've tried to open Konsole and Kate in Blackbox. It behaves as in KDE. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-09-17 01:07:41
|
On Friday 16 September 2005 04:57 pm, Ethan Merritt wrote:
>
> Please try attached patch.
> Keep an eye open for unexpected side-effects.
The side-effects may outweigh the benefit.
I really don't know what the correct thing to do is here,
partly because I'm from part of the world that doesn't use
a comma for a decimal point.
The patch changed gnuplot's scanner routine to accept
commas as part of a number. That is necessary if the user
has used "set decimalsign locale", because in this case numbers
belonging to a gnuplot command line are interpreted according
to the current LOCALE_NUMERIC.
On the other hand this makes many gnuplot commands ambiguous
at best:
set label 1 offset 1,2
I would have expected this to set the offset to (xoff=1 yoff=3 zoff=0)
but now it instead sets (xoff=1,2 yoff=0 zoff=0).
Is that acceptable? Is it what a user would expect, if he has gone
to the trouble of setting a decimalsign == comma locale?
But the current, unpatched, state of the code has problems also.
set decimalsign locale
show locale
LC_CTYPE is fr_FR
LC_NUMERIC is fr_FR
LC_TIME is C
PI = 3.14159
print PI
3.0
print pi
3,14159265358979
That is both wrong, and puzzling. I can understand why PI gets
set to 3 on input - that's the effect of sscanf() or atod() with
LC_NUMERIC set to fr_FR. But why does it revert to a dot for the
decimal sign on output? Notice that the internal constant "pi" is
printed with a comma, as I would have expected. Strange.
Anyhow, while I can see some attraction to being able to type
contants into gnuplot using a locale-modified decimal sign, e.g.
PI = 3,14159
I suspect that it breaks too many other commands.
Perhaps a better way is to force LC_NUMERIC to C during the
scanning of a gnuplot input line. That means all numbers on a
gnuplot command line must use dot rather than comma as a
decimal sign. Then to fix the original bug report, any code
that *constructs* a gnuplot command line, must *also* set
LC_NUMERIC to C while it operates.
That would include both the built-in functions like zoom and the
interpretation of key bindings.
Let's have some input from people using a locale with a comma
for LC_NUMERIC. Should gnuplot command line syntax be affected
by LC_NUMERIC, or not?
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: <tim...@en...> - 2005-09-17 17:47:45
|
Ethan A Merritt wrote: >The patch changed gnuplot's scanner routine to accept >commas as part of a number. That is necessary if the user >has used "set decimalsign locale", because in this case numbers >belonging to a gnuplot command line are interpreted according >to the current LOCALE_NUMERIC. > >(...) > >Perhaps a better way is to force LC_NUMERIC to C during the >scanning of a gnuplot input line. That means all numbers on a >gnuplot command line must use dot rather than comma as a=20 >decimal sign. Then to fix the original bug report, any code >that *constructs* a gnuplot command line, must *also* set >LC_NUMERIC to C while it operates. >That would include both the built-in functions like zoom and the >interpretation of key bindings. > >Let's have some input from people using a locale with a comma >for LC_NUMERIC. Should gnuplot command line syntax be affected >by LC_NUMERIC, or not? > Thanks for your deep investigation ! I finally found that the original bug was *my* problem. In fact, current cvs is not broken and in particular x11 terminal works properly on my "french box". It was a problem of my wxwidgets terminal : the wxwidgets library uses GTK+, which changes the locale itself, so that the default locale "C" was changed to "fr_FR". I have added setlocale(LC_NUMERIC, "C"); to my code, where the locale was changed. I agree that the command line syntax should not be affected by LC_NUMERIC, and so should always require a dot as a decimal sign. However, the way numbers are written in the terminal output might be tweaked with an option. Greetings, Timoth=C3=A9e Lecomte |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-09-17 22:53:30
|
On Saturday 17 September 2005 10:48 am, you wrote: > > I finally found that the original bug was *my* problem. In fact, current > cvs is not broken and in particular x11 terminal works properly on my > "french box". Actually, it is broken, and in exactly the way you pointed out. But it does not enter the broken state by default; only if you explicitly say set decimalsign locale where the current locale is, say, fr_FR. So we still need to fix it. I'm working on a patchset that forces LC_NUMERIC back to C during command line parsing and during "save" commands, as well as for the mouse zoom and the "test palette" command. There may be other places that need it as well, but those are the ones I have found so far. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
