Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-13 18:01:23
|
> On Tuesday 12 October 2004 11:37 pm, Petr Mikulik wrote: >> The string patch is cool, and looks like complete -- is there still some >> functionality missing? Should we think to put it to cvs soon? > > I was expecting more feedback, but maybe "no news = good news". > Yes, the core code can probably go into cvs. The add-ons should > get more discussion. I'll start separate threads for each. The string variables "extra features" patch (#1043790) only contains two features right now: 1) String variables are auto-promoted to numbers if they are encountered during evaluation of an arithmetic expression. e.g: (3 == "1" + "2") evaluates to TRUE 2) Integers are auto-promoted to strings if they are encountered during evaluation of a string expression. e.g.: N = N + 1 filename = "run_" . N . ".dat" print filename run_4.dat I am not aware of any problems introduced by either feature, but comments are welcome. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Juergen W. <wie...@fr...> - 2004-10-14 19:29:19
|
Am Mittwoch, 13. Oktober 2004 20:01 schrieb Ethan Merritt: > > I was expecting more feedback, but maybe "no news = good news". > > Yes, the core code can probably go into cvs. The add-ons > > should get more discussion. I'll start separate threads for > > each. > > The string variables "extra features" patch (#1043790) > only contains two features right now: > > 1) String variables are auto-promoted to numbers if they are > encountered during evaluation of an arithmetic expression. > e.g: (3 == "1" + "2") evaluates to TRUE > > 2) Integers are auto-promoted to strings if they are encountered > during evaluation of a string expression. > e.g.: > N = N + 1 > filename = "run_" . N . ".dat" > print filename > run_4.dat > > I am not aware of any problems introduced by either feature, > but comments are welcome. I'm not sure if this one is really needed. I would rather like to have a builtin function "atof" to explicitly cast strings to numbers. The other way round is done by sprintf. This patch makes the difference between numerical and string variables less clear. Juergen |
|
From: Petr M. <mi...@ph...> - 2004-10-15 07:01:50
|
> > N = N + 1
> > filename = "run_" . N . ".dat"
> > print filename
> > run_4.dat
> >
> > I am not aware of any problems introduced by either feature,
> > but comments are welcome.
>
> I'm not sure if this one is really needed. I would rather like to
> have a builtin function "atof" to explicitly cast strings to
> numbers.
I like this, it is like in awk.
> I think the extra features patch can give parse errors. Consider
>
> x = "5"
> set label x, 7
I think that these problems may arise only if there is a "default" option
expected for a given value (like "font" option for "set term post", where
just a string is OK). But this can always be avoided by a particular
keyword.
> file = "input.dat"
> value = `some-command @file`
I would propose to ignore macro expansion in `blabla1` and
!blabla2
but allow them in
system('blabla2')
and in
value = execute('blabla1');
Where the execute() is a new command. The user could use what he wants.
> set label sprintf("foo %f %f",var1,var2)
I really prefer the sprintf() way as it is a function like in C & friends.
>> gnuplot> print sprintf("%i", 5.)
>> 0
>This example doesn't work in C either.
But it works in Octave and awk; I use it there to print an integer part of
the value. I would rather prefer an inteligent version that returns in the
above example 5.
> FOO = floor(FOO)
> "see man page for sprintf"
Well, "man floor" says that result of floor() and ceil() is also a double
value, so it does not help. Just in gnuplot it returns an integer.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-15 16:25:22
|
On Friday 15 October 2004 12:01 am, Petr Mikulik wrote:
> I would propose to ignore macro expansion in `blabla1` and
> !blabla2
>
> but allow them in
> system('blabla2')
> and in
> value = execute('blabla1');
>
> Where the execute() is a new command. The user could use what he wants.
I think that would be possible.
The string expansion routine would be called in two places.
When called to process the entire command line it would not expand inside
back-tics. When called to expand the argument to a particular function, in
this case system() or execute(), then it *would* expand in backtics.
Anyone else have an opinion on that point?
Another alternative is to provide a run-time option
set macro$expansion {none|all|nobacktics}
> >> gnuplot> print sprintf("%i", 5.)
> >> 0
> >This example doesn't work in C either.
>
> But it works in Octave and awk; I use it there to print an integer part of
> the value. I would rather prefer an inteligent version that returns in the
> above example 5.
If Octave does that, I'd say it's a bug, or at least an unreliable behaviour.
Auto-conversion of an ambiguous variable type is one thing, but
refusing to do what the user asks for is quite another.
You have explicitly given a floating point number, and explicitly
given an integer format. That is user error. Is it "intelligent"
for a program to over-ride what the user has explicitly asked for?
> > FOO = floor(FOO)
> > "see man page for sprintf"
>
> Well, "man floor" says that result of floor() and ceil() is also a double
> value, so it does not help. Just in gnuplot it returns an integer.
I was not justifying gnuplot's use of floor; I was just responding
to the request for a way to insure that a gnuplot variable was an
integer. That command happens to work already.
I have no objection to adding a built-in function int(x).
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Petr M. <mi...@ph...> - 2004-10-15 16:33:36
|
> back-tics. When called to expand the argument to a particular function, in
> this case system() or execute(), then it *would* expand in backtics.
I though that instead of using
a=`runme`
there would be an alternative with macro expansion:
a=command('runme')
> > >> gnuplot> print sprintf("%i", 5.)
> > >> 0
> > >This example doesn't work in C either.
> >
> > But it works in Octave and awk; I use it there to print an integer part of
> > the value. I would rather prefer an inteligent version that returns in the
> > above example 5.
>
> If Octave does that, I'd say it's a bug, or at least an unreliable behaviour.
> Auto-conversion of an ambiguous variable type is one thing, but
> refusing to do what the user asks for is quite another.
I think that all numbers in Octave are double, so it's not unexpected.
Awk knows how to convert numbers and strings, according to user
"expectation".
The result of the above being "5" is more expected than "0".
---
PM
|
|
From: Juergen W. <wie...@fr...> - 2004-10-16 11:00:33
|
Petr Mikulik wrote:
> I though that instead of using
> a=`runme`
> there would be an alternative with macro expansion:
> a=command('runme')
Yes, yes, I'd love that. The variable "a" contains a string
afterwards, doesn't it?
Currently, I'm trying to extract some information from comments in
datafiles. The crucial thing is that information is to be passes
from gnuplot to the script and vice versa. I need something like
gawkcall = sprintf("gawk -f getname %i %s", this_index, filename)
name = execute(gawkcall)
For numerical values, you can already do this with
getvalcall = sprintf("getval %i %s", this_index, filename)
value = `@getvalcall`
but something like
gawkcall = sprintf("gawk -f getval %i %s", this_index, filename)
value = atof(execute(gawkcall))
or
value = 0 + execute(gawkcall)
is cleaner, I think.
Juergen
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-24 22:37:41
|
On Saturday 16 October 2004 03:59 am, Juergen Wieferink wrote:
> Petr Mikulik wrote:
> > I though that instead of using
> > a=`runme`
> > there would be an alternative with macro expansion:
> > a=command('runme')
>
> Yes, yes, I'd love that. The variable "a" contains a string
> afterwards, doesn't it?
I did figure out how to implement a gnuplot function
<string-value> = command(<string-expression>)
but I have serious reservations about it.
(1) it leaks memory (probably fixable, but so far I haven't
figured out how)
(2) it makes me really uneasy that you could trigger evaluation
of this function from, say, inside a plot statement:
plot <foo> 1:using (command("something expensive"))
This could, to say the least, consume system resources.
So instead I offer the following alternative proposal.
I have updated the patchset on SourceForge to include the
following variant syntax
@"stringvar" evaluates to "contents of stringvar"
That is, it evaluates the stringvar and places the value in
double-quotes.
For string constants this is a complicated no-op.
E.g.
a = "string constant blah blah"
b = a
c = @"a"
a, b, and c now contain identically the same string.
But when back-tics are involved it becomes more interesting.
> I need something like
>
> gawkcall = sprintf("gawk -f getname %i %s", this_index, filename)
> name = execute(gawkcall)
With the new syntax, you would do this as follows:
gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
show var
gawkcall = ` gawk -f getname ... `
name = @"gawkcall"
Note that the sprintf call uses single-quote + back-tic to delimit
the command string.
name becomes a string variable containing the output from
executing the shell command in gawkcall.
What do you think? Is this sufficient, or is there still a need for
an actual function command("foo")?
|
|
From: Petr M. <mi...@ph...> - 2004-10-25 13:33:03
|
> > > I though that instead of using
> > > a=`runme`
> > > there would be an alternative with macro expansion:
> > > a=command('runme')
>
> I did figure out how to implement a gnuplot function
> <string-value> = command(<string-expression>)
> but I have serious reservations about it.
> (1) it leaks memory (probably fixable, but so far I haven't
> figured out how)
> (2) it makes me really uneasy that you could trigger evaluation
> of this function from, say, inside a plot statement:
> plot <foo> 1:using (command("something expensive"))
> This could, to say the least, consume system resources.
It could whatever syntax is used, couldn't it?
> So instead I offer the following alternative proposal.
> I have updated the patchset on SourceForge to include the
> following variant syntax
> @"stringvar" evaluates to "contents of stringvar"
> That is, it evaluates the stringvar and places the value in
> double-quotes.
>
> But when back-tics are involved it becomes more interesting.
>
> > I need something like
> >
> > gawkcall = sprintf("gawk -f getname %i %s", this_index, filename)
> > name = execute(gawkcall)
>
> With the new syntax, you would do this as follows:
> gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> show var
> gawkcall = ` gawk -f getname ... `
> name = @"gawkcall"
>
> Note that the sprintf call uses single-quote + back-tic to delimit
> the command string.
Well, this needs a lot of thinkinkg to understand this syntax, but looks
feasible if enough examples are given in the docs. (BTW, there should be
"help string" and "help quotes" added to gnuplot.doc to easily find them.)
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-25 18:02:24
|
On Monday 25 October 2004 06:32 am, Petr Mikulik wrote:
> > (2) it makes me really uneasy that you could trigger evaluation
> > of this function from, say, inside a plot statement:
> > plot <foo> 1:using (command("something expensive"))
> > This could, to say the least, consume system resources.
>
> It could whatever syntax is used, couldn't it?
No. Because the proposed syntax is only relevant at the
time the input line is first lexically parsed.
var = @"command"
Only executes once.
An executable function could be triggered as part of the
point-by-point evaluation of a "using" spec. That is arguably
a legitimate use, but my initial reaction is that this is very ugly.
If you need some external program or shell command to
process each data point, then it would be better to process
the whole input stream at one go prior to plotting rather than
trigger the external program all over again for each point.
plot "foo" using (command)
executes once per line of data in "foo"
> > Note that the sprintf call uses single-quote + back-tic to delimit
> > the command string.
>
> Well, this needs a lot of thinkinkg to understand this syntax, but looks
> feasible if enough examples are given in the docs. (BTW, there should be
> "help string" and "help quotes" added to gnuplot.doc to easily find them.)
I agree. I have updated all 3 patchsets on SourceForge to contain
documentation entries in gnuplot.doc
see
"help string"
"help substitution"
"help macro"
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Juergen W. <wie...@fr...> - 2004-10-25 18:19:46
|
On Monday 25 October 2004 00:38, Ethan Merritt wrote:
> I did figure out how to implement a gnuplot function
> <string-value> = command(<string-expression>)
> but I have serious reservations about it.
> (1) it leaks memory (probably fixable, but so far I haven't
> figured out how)
> (2) it makes me really uneasy that you could trigger evaluation
> of this function from, say, inside a plot statement:
> plot <foo> 1:using (command("something expensive"))
> This could, to say the least, consume system resources.
I didn't thought of that, you're right. There could be a warning in
the docs to command(), and anybody dumb enough to try it
nevertheless gets what he deserves. But this probably is indeed not
an ideal solution.
> So instead I offer the following alternative proposal.
> I have updated the patchset on SourceForge to include the
> following variant syntax
> @"stringvar" evaluates to "contents of stringvar"
> That is, it evaluates the stringvar and places the value in
> double-quotes.
>
> For string constants this is a complicated no-op.
> E.g.
> a = "string constant blah blah"
> b = a
> c = @"a"
>
> a, b, and c now contain identically the same string.
> But when back-tics are involved it becomes more interesting.
>
> > I need something like
> >
> > gawkcall = sprintf("gawk -f getname %i %s", this_index,
> > filename) name = execute(gawkcall)
>
> With the new syntax, you would do this as follows:
> gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> show var
> gawkcall = ` gawk -f getname ... `
> name = @"gawkcall"
>
Which does essentially the same as
gawkcall = sprintf('"` gawk -f getname %i %s `"', ...)
name = @gawkcall
right? I haven't thought of this before seeing your @"var" syntax.
> Note that the sprintf call uses single-quote + back-tic to
> delimit the command string.
>
> name becomes a string variable containing the output from
> executing the shell command in gawkcall.
>
> What do you think? Is this sufficient, or is there still a need
> for an actual function command("foo")?
It suffices /my/ needs. Obviously, it was OK before, too, I just
didn't see it. Thus, should be some examples in the docs.
But I like the syntax of command("foo") much more. It seems cleaner
to me because there is no detour through the parser. There are
no problems if the input or output contains quotes. And it's easier
to
understand. But once more: It's fine as it is.
Juergen
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-25 18:47:13
|
On Monday 25 October 2004 11:19 am, Juergen Wieferink wrote:
> >
> > With the new syntax, you would do
> > gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> > show var
> > gawkcall = ` gawk -f getname ... `
> > name = @"gawkcall"
> >
>
> Which does essentially the same as
>
> gawkcall = sprintf('"` gawk -f getname %i %s `"', ...)
> name = @gawkcall
>
> right? I haven't thought of this before seeing your @"var" syntax.
Yes, it seems so. I didn't think of it either.
So the @"foo" variant is not needed after all.
It is amazing how complicated this stuff becomes, starting with
something rather simple.
> But I like the syntax of command("foo") much more. It seems cleaner
> to me because there is no detour through the parser. There are
> no problems if the input or output contains quotes. And it's easier
> to understand.
Yes. I thought it was a very nice idea. But I had second thoughts while
I was in the middle of implementing it. I was reminded of the discussion
a month or so back sparked by someone who wanted a "secure" version
or wrapper for gnuplot. The idea was to allow use by untrusted, possibly
malicious users. One the one hand I don't think we should cripple gnuplot
just because someone could use it to issue arbitrary shell commands.
But on the other hand I do think we should think twice before adding a
feature that could encourage poor scripting via over-use of shell
intervention. But I could be convinced by a real-world example where shell
intervention for every point plotted was required.
Anyway, this is really a separate issue and can be pursued later.
The command("foo") syntax by itself does not address the problem of
storing the result in a string. For that you need these other tricks.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-03-07 22:45:55
Attachments:
double-backquote.patch
|
Juergen Wieferink wrote (apropos RFE 1108413):
> The proper syntax would be a string function
> "command('blabla1')" returning the standard output as a
> string (as suggested by Petr in October 2004). I still think
> this would be a useful feature.
The suggestion from the previous discussion was:
> > On Friday 15 October 2004 12:01 am, Petr Mikulik wrote:
>
> >> I would propose to ignore macro expansion in `blabla1` and !blabla2
> >> but allow them in system('blabla2') and in value = execute('blabla1');
>
> >> Where the execute() is a new command. The user could use what he
> >> wants.
The syntax command(`blabla`) is difficult to implement in gnuplot's
parser, because it will try evaluate the contents of the parantheses
before recognizing the particular function being called. This just
pushes back the original problem by one layer of function call.
There may be a way around this, but so far I haven't been able to see it.
What I *can* see how to do easily is to distinguish between
single back-quotes and double back-quotes. The system command would be
executed in either case. The single back-quote case would then
return the output directly into the gnuplot input line, just as it does
now. The double back-quote case would also return the output into
the gnuplot input line, but it would wrap it in double quotes.
This makes it suitable for string variable assignment.
This is implemented by the attached patch.
gnuplot> numvar = `uname -mo`
undefined variable: i686
gnuplot> stringvar = ``uname -mo``
gnuplot> show var
Variables:
pi = 3.14159265358979
stringvar = i686 GNU/Linux
What do you think. Can we live with this syntax?
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-03-08 00:24:45
|
On Monday 07 March 2005 02:45 pm, Ethan Merritt wrote:
> Juergen Wieferink wrote (apropos RFE 1108413):
>
> > The proper syntax would be a string function
> > "command('blabla1')" returning the standard output as a
> > string (as suggested by Petr in October 2004). I still think
> > this would be a useful feature.
>
>
> What I *can* see how to do easily is to distinguish between
> single back-quotes and double back-quotes.
And then there is the very unix-style solution:
Create an external script named "quote"
#!/bin/csh
echo '"'
$*
echo '"'
and then issue the command as
gnuplot> numvar = `mycommand $1 $2 $3`
gnuplot> stringvar = `quote mycommand $1 $2 $3`
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Juergen W. <wie...@fr...> - 2005-03-08 06:44:20
|
On Monday 07 March 2005 23:45, Ethan Merritt wrote:
> Juergen Wieferink wrote (apropos RFE 1108413):
> > The proper syntax would be a string function
> > "command('blabla1')" returning the standard output as a
> > string (as suggested by Petr in October 2004). I still think
> > this would be a useful feature.
[...]
> The syntax command(`blabla`) is difficult to implement in gnuplot's
> parser, because it will try evaluate the contents of the parantheses
> before recognizing the particular function being called. This just
> pushes back the original problem by one layer of function call.
> There may be a way around this, but so far I haven't been able to see it.
>
> What I *can* see how to do easily is to distinguish between
> single back-quotes and double back-quotes. The system command would be
> executed in either case. The single back-quote case would then
I didn't propose backtics. And the double quotes were not meant
literally. Sorry for such ambiguous suggestions.
I meant an ordinary function which takes a string (the system
command) and returns another one---the output of the system command.
Using the backtics wouldn't work for RFE#1108413.
Juergen
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-03-08 17:03:45
|
On Monday 07 March 2005 10:42 pm, Juergen Wieferink wrote:
> I meant an ordinary function which takes a string (the system
> command) and returns another one---the output of the system command.
> Using the backtics wouldn't work for RFE#1108413.
Ah, sorry.
I assumed you were continuing the previous discussion, which
involved also the substitution of macro values into the command
passed to the system. For example
result = system("grep @key @file")
The problem there is that macro substitution doesn't happen
inside quoted strings.
If you don't care about macro substitution, then I think it
would be possible. I was earlier very worried about memory leaks
from such an operation, but I think I now understand how to
avoid leaking memory.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742
|
