[Gnuplot-py-users] Re: Contributions to Gnuplot.py

Michael Haggerty wrote:
> Hi Fernando,
> 
> Thanks for your message!  I will download IPython and look at what 
> you've done.  Unfortunately, it might take a while as I'm really busy 
> with work and an infant :-(

No problem, there's no rush whatsoever (some of this code is over a year old, 
I just hadn't gotten around to contacting you).  Congratulations on fatherhood :)

> I'm forwarding this message to the Gnuplot-py-users mailing list so that 
> other users can see your ideas and comment on them.  If you haven't 
> already done so, I suggest you subscribe to this list.

Done.  In fact, I'm cc-ing the list here.

> 
> By the way, are your changes relative to version 1.6 or relative to some 
> CVS version?  CVS has lots of changes and new features that I haven't 
> gotten around to releasing yet so you might want to have a look at it.

Everything I've done is against 1.5, but I haven't really modified your code 
at all.  All of my changes live inside ipython, and I just import the 
unmodified Gnuplot module, and then at runtime overwrite a few methods here 
and there with my own.  The beauty of python's dynamism :)  This approach 
means that all Gnuplot.py users can get my modifications without having to 
patch their installation or get a special version.

I tried to do as much as I could with subclassing, but in a few places I had 
to pick up your code and put in the modified version straight inside ipython.

> Some quick comments regarding your specific ideas:
> 
>  > -plot(y) -> plot a NumPy array against its indices
> 
> I guess this is a special case if y has only one dimension?  Sounds good.

Right.  Quite useful to get a quick look at an array without having to do the 
plot(Data(zip(range(len(y)),y))) dance. plot(y) is easier :)

>  > -plot(x,y) -> plot y vs x
> 
> I find this special case confusing because each argument to plot() is 
> usually a single PlotItem.  Instead of this you can type 
> plot(Data(x,y)), which isn't much more typing and is unambiguous.

I do this because plots of the type y vs x are such a common occurrence, that 
I wanted a 'zero-effort' syntax to do the 'right thing'.  When I'm playing 
with numerical stuff at the command line, even typing the additional Data() 
every time seems like too much.  Call me lazy :)

I'd like you to give it a try before you make up your mind.  The way I wrote 
it, it doesn't break any of the existing usage cases at all, but it offers a 
lighter syntax for many common situations.  I've used it extensively for over 
a year, and I really like it.  I can always keep the modifications inside 
ipython for my own use if you really disagree, since I won't give them up :) 
But after playing with them a bit, you may get to like them.

>  > -plot(y1,None,y2) -> plot y1,y2 vs their indices (None is a separator)
> 
> This even more confusing special case wouldn't be necessary if not for 
> the previous one.

Well, it's just that I'm often computing things in various ways and need to 
quickly see all of them.  This allows me to plot a bunch of arrays of the same 
length without having to build Data() objects with zip(range(len...)) calls 
every time.  Again, this is all about having a very light syntax that I can 
use repeatedly at the command-line.

>  > -plot(y,filename='out.eps') -> make eps output reliably
>  >  (there's a tricky timing issue which requires
>  >  retrying the print command with a sleep())
> 
> Isn't this what hardcopy() does?  What is the advantage of this call vs. 
> hardcopy()?  If hardcopy has the timing problem you mention, I would be 
> very interested to hear more details.  (By the way, hardcopy() has 
> really been improved in CVS; you should check it out if you haven't 
> already.)

Yes, it ultimately calls (my modified) hardcopy.  The point was to allow one 
to make hardcopy _without_ having built a plot before (think of the case where 
you are running a script which batch-generates tens of plots).  The previous 
system would require

plot(....)  -> may fail if the there is no x-server in a batch job
hardcopy()

Quoting the ipython docs:

     PostScript generation through plot() is useful mainly for scripting
     uses where you are not interested in interactive plotting. For
     interactive use, the hardcopy() function is typically more convenient:

I've found this option to be very convenient after extensive use.  I had a 
large make-type file which was in reality a python script for generating all 
of the plots in my thesis from the raw data.  I could change some global 
options (fonts, color/mono, etc) and simply type ./plots.py, and get every 
single plot rebuilt in a few minutes.  In this kind of situation, I don't want 
to see a few hundred gnuplot windows pop up :)

I ran into the timing problem and spent a _lot_ of time trying to debug it. 
Basically, under Linux hardcopy turned out to be randomly unreliable. 
Sometimes it would exit without having truly created the eps file.  My 
brute-force solution was to force a loop which tries to make the file 20 times 
with a small sleep() delay.  If after 20 attempts it can't make it, it gives 
up and informs the user.  After I put that in, I haven't seen any more 
problems.  The bug is subtle and annoying enough (when it pops up, which is 
rather random) that I wanted a bulletproof fix, even if ugly.

> 
>  > - Added the 'index' keyword arg to File, similar to Gnuplot's
>  >   index option to select a dataset from a file with multiple
>  >   datasets in it.
> 
> Sounds good.

Best regards,

Fernando.