Re: Any simple way to create for loops?

[Mojca M. <moj...@gm...>]

On Fri, May 22, 2009 at 16:27, Juergen Wieferink wrote:
> Hello,
>
>> Is there some way to do something like this in gnuplot apart from
>> using external script?
>>
>>     for [i in "0.01 0.1 1 2 3 10"]
>>         filename=sprintf("name-%g.png", i)
>>         command=sprintf("./script %g", i)
>>         set output filename
>>         plot command using 1:3 with lines
>>     endfor
>
> There is a patch at sourceforge (2652184):
>
>
> https://sourceforge.net/tracker/?func=detail&aid=2652184&group_id=2055&atid=302055
>
> It allows something like:
>
> for [str in "0.01 0.1 1 2 3 10"] {
>  i = real(str)
>  filename=sprintf("name-%g.png", i)
>  command=sprintf("./script %g", i)
>  set output filename
>  plot command using 1:3 with lines
> }
>
> I haven't had too much feedback, though.

I'm sorry that it took me so long to answer this, but I'm a bit
confused. Two different solutions have been offered which has confused
me even more.

If there's a patch on sourceforge - what does that imply? What should
I do upon it?

The syntax of both patches looks fine to me and I would be glad to use
it, but I'm afraid to use it for the reports that I need to write if I
cannot be sure if that code will still work once I update gnuplot or
once I change the computer.

The problem is that I cannot tell:
- if code has a potential to break anything since I don't know the
source code well enough
- what the guidelines for extending gnuplot syntax are
Those two questions that are probably the most important when deciding
about accepting or rejecting a patch both need to be addressed by main
developers.

-----
Unrelated to original question, but related to the two patches that
have been proposed:

Approximately one half of patches on sourceforge have no resolution
(neither accept nor reject). Often something like "won't fix" or "will
fix, but needs some more testing" would help a lot.

It's a bit demotivating for authors of patches to get no feedback from
main developers and what's worse: as time passes those patches become
obsolete and probably stop working anyway because the original source
code changes. This mailing list often helps a lot to resolve problems,
but it would be great if someone with a clear vision of gnuplot future
development could review the patches and say one of the following for
each unresolved patch:

- accept it and close it
- likely to fix, needs more thinking/testing
- please provide more info/description (I don't understand what this
patch is supposed to do)
- unlikely to fix unless this or that happens
- won't fix (with explanation) and close it

(Long ago I wanted to fix and improve one of existing (almost broken)
terminals and add another one, but neither rejection nor acception of
patches or bugfixes made me lost any interest.)

Mojca