Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 20:34:21
Attachments:
histwarn_djs_4jun2007.patch
|
The other day Petr made a change to rid the int_error() function. Rather than putting "Warning:" in the printf, could the int_warn() function be used as in the attached patch instead? Dan |
|
From: Petr M. <mi...@ph...> - 2007-06-04 21:57:56
|
> The other day Petr made a change to rid the int_error() function. Rather than > putting "Warning:" in the printf, could the int_warn() function be used as in > the attached patch instead? > gnuplot-history/src/history.c > - fprintf(stderr, "Warning: cannot open file %s for saving the history.", filename); > + int_warn(NO_CARET, "cannot open file %s for saving the history.", filename); Yes, it seems to work. Is it needed to change it? --- PM |
|
From: <tim...@en...> - 2007-06-04 22:06:24
|
>> The other day Petr made a change to rid the int_error() function. >> Rather than >> putting "Warning:" in the printf, could the int_warn() function be used >> as in >> the attached patch instead? > >> gnuplot-history/src/history.c >> - fprintf(stderr, "Warning: cannot open file %s for saving the >> history.", filename); >> + int_warn(NO_CARET, "cannot open file %s for saving the history.", >> filename); > > Yes, it seems to work. > Is it needed to change it? > Those two are equivalent.int_warn() with NO_CARET is like fprint(stderr,...) I personally would keep the fprintf as we immediately see what it's doing. int_warn is more for cases when user input (i.e. a command line) is involved. Best regards, Timothée > --- > PM |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 22:10:26
|
Timothée Lecomte wrote: >>>The other day Petr made a change to rid the int_error() function. >>>Rather than >>>putting "Warning:" in the printf, could the int_warn() function be used >>>as in >>>the attached patch instead? >> >>>gnuplot-history/src/history.c >>>- fprintf(stderr, "Warning: cannot open file %s for saving the >>>history.", filename); >>>+ int_warn(NO_CARET, "cannot open file %s for saving the history.", >>>filename); >> >>Yes, it seems to work. >>Is it needed to change it? >> > > > Those two are equivalent.int_warn() with NO_CARET is like fprint(stderr,...) > I personally would keep the fprintf as we immediately see what it's doing. > int_warn is more for cases when user input (i.e. a command line) is involved. I'll go with that logic. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 16:23:18
|
Petr Mikulik wrote:
>>Command line history may be controlled with several options described
>>below.
>>Several of these options may be overridden by similar qualifiers in the
>>history command.
>> set history {<int>}
>
>
> I tried that "set history -1" makes an error.
I get:
gnuplot> set history -1
^
Unrecognized option.
Are you getting something else? Of course, that means the following also errors:
gnuplot> set history +4
^
Unrecognized option.
Should we be recognizing the sign and then issuing an error if negative?
For "set history 0", could you
> please document whether is never forgets anything?
What should "history 0" do? In the code, n=0 means print everything but that
doesn't mean we can't issue an error.
Dan
|
|
From: Petr M. <mi...@ph...> - 2007-06-11 16:29:14
|
> > >Several of these options may be overridden by similar qualifiers in the
> > >history command.
> > > set history {<int>}
> >
> > I tried that "set history -1" makes an error.
>
> gnuplot> set history -1
> ^
> Unrecognized option.
>
> Are you getting something else?
I get the same.
Of course, that means the following also
> Should we be recognizing the sign and then issuing an error if negative?
Yes.
> For "set history 0", could you
> > please document whether is never forgets anything?
>
> What should "history 0" do? In the code, n=0 means print everything but that
> doesn't mean we can't issue an error.
I propose "set history 0" means not to store history commands to the
.gnuplot_history file.
---
PM
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 17:28:35
|
Petr Mikulik wrote: >> For "set history 0", could you >> >>>please document whether is never forgets anything? >> >>What should "history 0" do? In the code, n=0 means print everything but that >>doesn't mean we can't issue an error. > > > I propose "set history 0" means not to store history commands to the > .gnuplot_history file. Hmm, that might be OK. The documentation is a bit inconsistent. If we choose 0 to mean 0 lines go to the history file. How do we set the history to "unlimited"? The answer is "unset history". That's a bit strange in the sense that the documentation says: The value <int> indicates the value of history size when leaving gnuplot. It is used for truncating the history to at most that many lines. The default is 666. [snip] `unset history` will set history operation to its default settings: no history truncation at exit and thus allow indefinite number of lines, `condensed`, and `numbered`. In one case the default is 666 in the other it is indefinite. There is no "set history inf" or anything like that. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 18:09:40
|
Daniel J Sebald wrote: >> I propose "set history 0" means not to store history commands to the >> .gnuplot_history file. I assume you mean that the .gnuplot_history file remains as it was when the user entered gnuplot, not that the .gnuplot_history ends up empty. Dan |
|
From: Petr M. <mi...@ph...> - 2007-06-11 17:32:15
|
> The value <int> indicates the value of history size when leaving gnuplot. It > is used for truncating the history to at most that many lines. The default > is 666. > > [snip] > > `unset history` will set history operation to its default settings: no > history > truncation at exit and thus allow indefinite number of lines, `condensed`, > and > `numbered`. > > In one case the default is 666 in the other it is indefinite. There is no > "set history inf" or anything like that. 9999 could be enough... Anyway, you cannot store infinite number of commands on a PC with a finite hard disk. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 17:36:30
|
Petr Mikulik wrote: >> The value <int> indicates the value of history size when leaving gnuplot. It >> is used for truncating the history to at most that many lines. The default >> is 666. >> >>[snip] >> >> `unset history` will set history operation to its default settings: no >> history >> truncation at exit and thus allow indefinite number of lines, `condensed`, >> and >> `numbered`. >> >>In one case the default is 666 in the other it is indefinite. There is no >>"set history inf" or anything like that. > > > 9999 could be enough... Anyway, you cannot store infinite number of commands > on a PC with a finite hard disk. I'm wondering what number could represent the principle of "indefinite". We wouldn't want a syntax "set history -1"... but good point, the user could just type in a huge number. It's just slightly odd that there does exist such a setting but the way to get to it is to "unset history". Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 18:26:40
|
Petr Mikulik wrote:
>>>>Several of these options may be overridden by similar qualifiers in the
>>>>history command.
>>>> set history {<int>}
>>>
>>>I tried that "set history -1" makes an error.
>>
>>gnuplot> set history -1
>> ^
>> Unrecognized option.
>>
>>Are you getting something else?
>
>
> I get the same.
>
>
> Of course, that means the following also
>
>
>>Should we be recognizing the sign and then issuing an error if negative?
>
>
> Yes.
I began programming this, but now I hesitate to do so. It would be something like
n = 1;
if (equals(c_token,"-")) {
n *= -1;
c_token++;
} else if (equals(c_token,"+"))
c_token++;
n *= int_expression();
But to repeat this code in more than one spot wouldn't be good. There should
maybe be "signed_expression()" inside parse.h.
However, on second thought, just leaving it as is makes the user be a little
cleaner in their use of integers. I don't think it is good practice for users
to be doing
set history +3
etc. That simply clutters things. I suggest leaving it as is with the
"Unrecognized option" error.
Dan
|
|
From: Petr M. <mi...@ph...> - 2007-06-11 19:12:30
|
> > I propose "set history 0" means not to store history commands to the
> > .gnuplot_history file.
>
> I assume you mean that the .gnuplot_history file remains as it was when
> the user entered gnuplot, not that the .gnuplot_history ends up empty.
yes
> > > > >Several of these options may be overridden by similar qualifiers in the
> > > > >history command.
> > > > > set history {<int>}
> > > >
> > > >I tried that "set history -1" makes an error.
> > >
> > >gnuplot> set history -1
> > > ^
> > > Unrecognized option.
> > >
> > >Are you getting something else?
> >
> >
> > I get the same.
> >
> >
> > Of course, that means the following also
> >
> >
> > >Should we be recognizing the sign and then issuing an error if negative?
> >
> >
> > Yes.
>
> I began programming this, but now I hesitate to do so. It would be something
> like
>
> n = 1;
> if (equals(c_token,"-")) {
> n *= -1;
> c_token++;
> } else if (equals(c_token,"+"))
> c_token++;
> n *= int_expression();
I think you can use simply
if (isanumber(c_token)) {
act on integer
}
---
PM
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 23:18:01
|
I've noticed that currently for --with-realine=builtin on CVS the history stack
will be truncated upon add_history(). E.g.,
gnuplot> history
1 set his 6
2 his
3 plot x
4 plot x*x
5 history
gnuplot> set his 2
gnuplot> foo = 2
gnuplot> his
1 foo = 2
2 his
gnuplot>
The GNU readline compilation doesn't do that. Truncation is only done when
saving to file.
Which way should history behave? (I'm thinking to not truncate history list
until saved, both GNU and builtin.)
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-11 19:41:46
|
Petr Mikulik wrote:
>>n = 1;
>>if (equals(c_token,"-")) {
>> n *= -1;
>> c_token++;
>>} else if (equals(c_token,"+"))
>> c_token++;
>>n *= int_expression();
>
>
> I think you can use simply
> if (isanumber(c_token)) {
> act on integer
> }
That's what it currently does:
} else if (isanumber(c_token)) {
/* show history entries */
n = int_expression();
'+' and '-' must test negative for isanumber().
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-06-13 01:08:58
|
On Monday 11 June 2007 12:41, Daniel J Sebald wrote:
> >
> > I think you can use simply
> > if (isanumber(c_token)) {
> > act on integer
> > }
Unfortunately not.
"isanumber" is mis-named. It really acts as "isapositivenumber".
The reason is that the tokensiser places the - sign into its
own separate token. So isanumber(c_token) sees only the '-' sign,
no number.
This has annoyed me many times, but never sufficiently to
replace isanumber() with something better.
--
Ethan A Merritt
|
|
From: Petr M. <mi...@ph...> - 2007-06-13 07:19:21
|
> > > I think you can use simply
> > > if (isanumber(c_token)) {
> > > act on integer
> > > }
>
> Unfortunately not.
> "isanumber" is mis-named. It really acts as "isapositivenumber".
> The reason is that the tokensiser places the - sign into its
> own separate token. So isanumber(c_token) sees only the '-' sign,
> no number.
>
> This has annoyed me many times, but never sufficiently to
> replace isanumber() with something better.
Does this mean that it is not possible to add a function "isaninteger()"
that woul work for negative numbers as well?
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-13 15:54:40
|
On Wednesday 13 June 2007 00:19, Petr Mikulik wrote:
> > > > I think you can use simply
> > > > if (isanumber(c_token)) {
> > > > act on integer
> > > > }
> >
> > Unfortunately not.
> > "isanumber" is mis-named. It really acts as "isapositivenumber".
> > The reason is that the tokensiser places the - sign into its
> > own separate token. So isanumber(c_token) sees only the '-' sign,
> > no number.
> >
> > This has annoyed me many times, but never sufficiently to
> > replace isanumber() with something better.
>
> Does this mean that it is not possible to add a function "isaninteger()"
> that woul work for negative numbers as well?
Better to fix "isanumber()" to do what it claims.
But then you would have to check and clean up all the call sites.
Not hard, just tedious.
--
Ethan A Merritt
|
