Re: Any simple way to create for loops?

[Ethan M. <merritt@u.washington.edu>]

On Sunday 24 May 2009, Mojca Miklavec wrote:

> 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 purpose of the patch tracker on SourceForge is to float ideas for
possible additions to gnuplot.  If people show interest in a patch,
then it may be refined and improved by additional discussion and 
contribution, and moved into CVS when there seems to be a consensus.

Sometimes there are patches from multiple people that address the same
or related ideas, but using different approaches.  Then the discussion
helps to settle which approach is better.  Right now there are multiple
patches illustrating different approaches to adding block-structured
syntax.  There has beeen some discussion, but not a lot.  None of the
patches is a complete solution, so more work would be needed in any case.

> 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.

It would be helpful if you were to look at both, whether or not you 
actually build and test them, and report back something like 
"Patch A would be better for my use because ....,  but I like the
idea of <foo> from Patch B".  We need to hear feedback from a variety
of users in order to guide the choice of implementation.

> 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.

Exactly. That is why we need the discussion. 

> -----
> 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.

I think you may be confusing items from two separate trackers.
"Won't fix" applies to bug reports, not to patches.  The great majority
of bug reports are dealt with relatively rapidly and then closed.

Patches are a different thing, and are rarely rejected outright.
They are collected on the tracker site in the hope that they will
generate discussion and additional  contributions. The tracker item is
closed only when the patch itself or some equivalent functionality has
been added to CVS.  

Some patches are quite old, but it is still very useful to have them
available for reference.  Sometimes there will be a request for feature X,
and we can say "So-and-so offered a patch #XYZ to implement something like
that. Please take at look and see whether that approach would provide what
you want."  In other words, often there needs to be discussion by the
potential users before a patch can be evaluated, and that discussion may
not happen until a long time has passed since the first version of the
patch was posted.

> It's a bit demotivating for authors of patches to get no feedback from
> main developers 

I can assure you that being a developer does not mean that I am familiar
with all parts and uses of gnuplot.  If someone offers a patch to part of
the program I have never used, what useful comment can I offer?
Feedback from the user community is equally, or even more, important for
evaluation of the patch's utility. Technical feedback about implementation
details can wait until there is evidence that the feature will be
generally useful.

> 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

 This sometimes happens.  Particularly if the patch addresses something that
 one or more of the developers can evaluate directly.  For instance, if
 a patch adds a feature that I can see immediately would be useful for
 application in gnuplot-based tools I am already using, I can evaluate
 for myself whether it works as advertised.  

> - please provide more info/description (I don't understand what this
> patch is supposed to do)

 That should be the default state.  Although more often the issue is not
 "what does it do?", but "why would you want to do that?".  

> - unlikely to fix unless this or that happens
> - won't fix (with explanation) and close it
> - likely to fix, needs more thinking/testing

 If the word "fix" is appropriate, then the code should probably not be 
 submitted to the patch tracker at all, but rather attached to the
 corresponding bug report.

> (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.)

 If you are talking about the context terminal, to the best of my
 recollection (a) it could not be used with the distributed version of
 context, so basically no one was in a position to try it out.
 Maybe for that reason, (b) no one ever spoke up to say "yes, it works" or
 "I would use it if it work", or best of all "this is great, but it would be
 even better if X, Y, and Z".  If my recollection is wrong, I apologize.
 Please point me to any discussion or  indications of general interest by
 other gnuplot users.  If nothing else, in the intervening time the distro I 
 use has switched to using texlive, which includes some version of context.
 If your driver now works with a common tex distribution, maybe you'll get
 more feedback now than you did the first time around?