gnuplot-py-users — A mailing list for the users of Gnuplot.py.

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

[Fernando P. <fp...@co...>]

Michael Haggerty wrote:
> Hi,
> 
> I just implemented some accumulated suggestions in the CVS version of 
> Gnuplot.py.
> 
> Fernando Perez wrote:
> 
> 
>>>Some quick comments regarding your specific ideas:
>>>
>>> > -plot(y) -> plot a NumPy array against its indices 
>>
> 
> Done.

Great!
>>> > -plot(x,y) -> plot y vs x
>>
> 
> I will not implement this (because of the ambiguity).  But since this 
> seems to be a popular feature, maybe I'll implement it with another name 
> (like 'qplot()', as suggested by Leo Milano).

Fair enough.  I agree that it's ambiguous.  I did it simply because _I_ use it 
a lot, and I know how to handle it.  But for a general public tool, it's much 
cleaner to have a different function.  However, qplot() should keep the same 
interface as plot() in regards to options, etc.

>>> > -plot(y1,None,y2) -> plot y1,y2 vs their indices (None is a 
>>>separator) 
>>
> 
> Ditto.

good.

>>> > -plot(y,filename='out.eps') -> make eps output reliably
>>> >  (there's a tricky timing issue which requires
>>> >  retrying the print command with a sleep()) 
>>
> 
> I still don't understand the timing issue.  But I see the need to be 
> able to plot directly to a "hardcopy" file (be it PS or EPS or PNG or 
> ...) without first plotting to a graphics window.  It would be very 
> nearly possible now, if Gnuplot._add_to_queue() were a documented part 
> of the interface.

Agreed on the auto-plotting to file without plotting window.  This was 
critical to me, but I only implemented eps output.

Re. the timing issue: honestly, I don't understand it either.  I only know I 
wasted an entire Saturday trying to find any pattern to it, and finally 
decided to brute-force a solution with the 20 tries approach.  Inelegant as 
hell, but so far it's done the job for me ;)

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

Good.

As far as I can see, you've pretty much brought into the Gnuplot.py mainline 
almost everything which IPython's gnuplot support added.  This is great news, 
since I didn't want to fork your code, but simply offer functionality which I 
felt was needed for daily work.

Once you make a release (hopefully with hardcopy-without-window in, which I 
consider critical), perhaps we can comb over what's left and I could deprecate 
IPython's gnuplot stuff in favor of your mainline code.

Best regards,

Fernando.

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

[<kai...@t-...>]

Hi,

I just implemented some accumulated suggestions in the CVS version of 
Gnuplot.py.

Fernando Perez wrote:

>> Some quick comments regarding your specific ideas:
>>
>>  > -plot(y) -> plot a NumPy array against its indices 
>

Done.

>>  > -plot(x,y) -> plot y vs x
>

I will not implement this (because of the ambiguity).  But since this 
seems to be a popular feature, maybe I'll implement it with another name 
(like 'qplot()', as suggested by Leo Milano).

>>  > -plot(y1,None,y2) -> plot y1,y2 vs their indices (None is a 
>> separator) 
>

Ditto.

>>  > -plot(y,filename='out.eps') -> make eps output reliably
>>  >  (there's a tricky timing issue which requires
>>  >  retrying the print command with a sleep()) 
>

I still don't understand the timing issue.  But I see the need to be 
able to plot directly to a "hardcopy" file (be it PS or EPS or PNG or 
...) without first plotting to a graphics window.  It would be very 
nearly possible now, if Gnuplot._add_to_queue() were a documented part 
of the interface.

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

Done.

Michael

-- 
Michael Haggerty
mh...@al...

[Gnuplot-py-users] Re: Generating graphics in a web server with Gnuplot.py

[<kai...@t-...>]

John,

I'm cc'ing the gnuplot-py-users mailing list...

[The original question was whether it is practical to use Gnuplot.py to 
generate graphics in a web server.]

John Draper wrote:

>>Hello,
>>
>>Sure, gnuplot + Gnuplot.py can do that.
>>
>>I would suggest you get the latest CVS version of Gnuplot.py; then you 
>>can do something like
>>
>>   g = Gnuplot.Gnuplot()
>>   ips = list of 4-tuples of ip octets from your database like 
>>[(192,168,1,1), (198,137,240,92),...]
>>   g.title('Spam sources')
>>   g.xlabel('First octet')
>>   g.ylabel('Second octet')
>>   g.plot(ips, cols=(0,1), with='dots')
>>   g.hardcopy('file.png', terminal='png', fontsize='large', color=1)
>>
>>This writes the output to a file called "file.png" in the current 
>>directory.  Then you just need to get your web server to insert the 
>>image into the web page and somehow arrange for old files to be cleaned 
>>up once in a while.
>>    
>>
>
>Wow - most excellent.
>  
>
>>Through some more magic it would be possible to create the output on the 
>>fly and pump it straight to the client, but that's a little bit 
>>trickier.  
>>    
>>
>
>Yes- I'm going to need to know how to do that.  So,  when you say "trickier" what do you mean by that.
>  
>

It might be possible (I'm not sure) to have gnuplot write its png output 
to stdout by using g("set term png ...") before generating the original 
plot.  I'm not sure if gnuplot outputs other stuff on standard out that 
would confuse the output.

Another alternative would be to create a named pipe and have gnuplot 
write its output to that "file".  Another thread or process could 
capture the output and pump it out of the web server.

>>It should also be possible to omit the initial output to the 
>>monitor but I haven't tried that before.
>>    
>>
>
>I have no "monitor" as there is no graphical device on the server at all.
>

Well then you would want to g("set term png [...]") before creating the 
initial plot.  It means you can't use the hardcopy() method (at least 
not without first making some minor changes) but that's not such a problem.

Michael

-- 
Michael Haggerty
mh...@al...

Re: [Gnuplot-py-users] curve fitting

[<kai...@t-...>]

Ido Yehieli wrote:

>Hello,
>   is it possible to use gnuplot's 'fit' command
>throw Gnuplot.py?
>  
>

As the others have pointed out, you can call any gnuplot command from 
Gnuplot.py.  The other issue with "fit", however, is how do you get the 
results of the fit back into Python?  This is a problem because 
Gnuplot.py doesn't have access to gnuplot's standard output.

Luckily this is easy--you write the parameters to a "parameters file" 
(which fortuitously is valid python code) then read them back into 
python.  This is untested but should approximately work:

 >>> g = Gnuplot.Gnuplot()
 >>> open('fit.par', 'w').write('m=0\nb=0\n')
 >>> g('fit m*x+b "data.in" via "fit.par"')
 >>> g('update "fit.par" "fit2.par"') # saves fitted parameters to fit2.par
 >>> parameters = {}
 >>> execfile('fit2.par', globals(), parameters)
 >>> print parameters
{'b': 1.5015, 'm': 1e-30}
 >>> print parameters['m'], parameters['b']
1e-30 1.5015

In principle you could also parse "fit.log" to get the gory details 
about the fit (standard errors, correlation matrix, etc).

Hope this helps,
Michael

-- 
Michael Haggerty
mh...@al...

Re: [Gnuplot-py-users] curve fitting

[Leonardo M. <lm...@ud...>]

Hi Ido

> Hello,
>    is it possible to use gnuplot's 'fit' command
> throw Gnuplot.py?

Yes, my favorite feature in gnuplot is that you can
use ANY gnuplot command:

    g = Gnuplot.Gnuplot(debug=1)
    g('set data style lines')
    g('set logscale xy')
    g('set logscale x2')

Etc.

What I do is to use a combination of Gnuplot methods and
simple gnuplot calls like I showed in the example

Hope this helps,
-- Leo

[Gnuplot-py-users] curve fitting

[<ido...@ya...>]

Hello,
   is it possible to use gnuplot's 'fit' command
throw Gnuplot.py?

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

[Gnuplot-py-users] Re: Problems with Gnuplot.py under Windows XP

[<kai...@t-...>]

Hello,

I don't use Windows, so I won't be of much help.  Therefore, I am 
forwarding your question to the gnuplot-users mailing list, where 
several windows users are subscribed and might have ideas.

It sounds vaguely like the gnuplot program was never started.  One thing 
appears incorrect in your attempt:

> I also tried to type:
> Gnuplot.GnuplotOpts.gnuplot_command = "C:\Programmi\gp373w32\pgnuplot"


Because of Python's treatment of backslashes in strings, I think you 
want to type either

Gnuplot.GnuplotOpts.gnuplot_command = "C:\\Programmi\\gp373w32\\pgnuplot"

or


Gnuplot.GnuplotOpts.gnuplot_command = r"C:\Programmi\gp373w32\pgnuplot"


Maybe that will help.

Michael

Giorgio Fagiolo wrote:

>Dear Michael: I've just successfully completed the installation of
>Gnuplot.py on a machine running Windows XP Home. I followed all your
>instuctions but something seems not working properly. In particular, I've
>been trying to type the following lines (in the Pythonwin interactive
>window):
>
>  
>
>>>>import Gnuplot
>>>>import Gnuplot.funcutils
>>>>g = Gnuplot.Gnuplot(debug=1)
>>>>g.plot([[0,1.1], [1,5.8], [2,3.3], [3,4.2]])
>>>>        
>>>>
>
>But then it gives me the following:
>
>Traceback (most recent call last):
>  File "<interactive input>", line 1, in ?
>  File "c:\python22\Lib\site-packages\Gnuplot\_Gnuplot.py", line 281, in
>plot
>    self.refresh()
>  File "c:\python22\Lib\site-packages\Gnuplot\_Gnuplot.py", line 222, in
>refresh
>    self(self.plotcmd + ' ' + string.join(plotcmds, ', '))
>  File "c:\python22\Lib\site-packages\Gnuplot\_Gnuplot.py", line 206, in
>__call__
>    self.gnuplot(s)
>  File "c:\python22\Lib\site-packages\Gnuplot\gp_win32.py", line 122, in
>__call__
>    self.write(s + '\n')
>IOError: [Errno 22] Invalid argument
>
>Just to give you more info: I have Gnuplot.py correctly installed under
>C:\Python22\Lib\site-packages\Gnuplot while GnuPlot (windows version
>including pgnuplot.exe) is installed under C:\Programmi\gp373w32.
>
>I also tried to type:
>Gnuplot.GnuplotOpts.gnuplot_command = "C:\Programmi\gp373w32\pgnuplot"
>but it does not work.
>Could you possibly help me out with this problem? Thanks in advance,
>Giorgio Fagiolo
>
-- 
Michael Haggerty
mh...@al...

Re: [Gnuplot-py-users] Re: fifo pipe thread

[Leonardo M. <lm...@ud...>]

Hi Jonathan, Michael, all

I thinkg that the new method based on named pipes is
the a robust solution to the problem of temp files
deletion we had before.

Moreover, multithreading is the way to go because
it naturally scales well when you have multiple
processors. People will eventually migrate to
apache 2 after all ;-)

But in the meantime, how about this:

> You realize, of course, that you can use the old-fashioned method of
> temporary files even in the new version of Gnuplot.py?  But then you
> have the old problems, too.

Before Michael implemented the named pipes, I temporarily used
a dirty hack: I inherited a class from Gnuplot, and overloaded
the destructor, where I put a "sleep" statement, with a preset
waiting time before a Gnuplot objet gets destructed. For that
I estimated the time it usually takes me to generate
a typical plot, but this is of course a quick and dirty solution.

Best luck
-- leo

[Gnuplot-py-users] Re: fifo pipe thread

[<kai...@t-...>]

Hi,

I don't think it would be as easy to implement named pipes without using 
threads.  To prevent deadlocks, there needs to be a process ready to 
write to any existing named threads when gnuplot wants to read it.  I 
suppose this could be done by polling, but I don't quite know when the 
polling should take place.  In any case, it would not be nearly as easy 
to implement as the multithreaded version, and probably not as robust.

You realize, of course, that you can use the old-fashioned method of 
temporary files even in the new version of Gnuplot.py?  But then you 
have the old problems, too.

I've forwarded this answer to the gnuplot-py-users mailing list, in case 
anybody else has any thoughts on this issue.  I would suggest that you 
subscribe to the list and send future questions there as a number of 
active users monitor this list.

Yours,
Michael

Jonathan Ricketson wrote:

> Hi Michael, I am trying to implement the new version of Gnuplot-py at 
> the moment after being very happy with the old version, but having 
> some problems that would be fixed by the new named pipes.
>
> Background: I am using debian linux, python 2.2.1 has threading 
> compiled in and I am using the version of Gnuplot-py from the cvs from 
> a couple of weeks ago (you don't seem to have committed any changes 
> since then). I have been using Gnuplot-py as part of a web application 
> using mod-python and apache.
>
>
> The problem is that apache 1.3 does not support threading, and your 
> new changes utilise threads. Could you explain the neccessity of 
> threading here, and do you think that it is possible to get away with 
> not using it?
>
>         def __init__(self, content, mode='w'):
>             self.content = content
>             self.mode = mode
>             self.filename = tempfile.mktemp()
>             threading.Thread.__init__(
>                 self,
>                 name=('FIFO Writer for %s' % (self.filename,)),
>                 )
>             os.mkfifo(self.filename)
>             self.start()
>
>         def run(self):
>             f = open(self.filename, self.mode)
>             f.write(self.content)
>             f.close()
>             os.unlink(self.filename)
>
> Thanks for your help.
>
>
> Jonathan


-- 
Michael Haggerty
mh...@al...

[Gnuplot-py-users] Re: Gnuplot from sourceforge, comment and question

[<kai...@t-...>]

Hi,

Thanks for your email.

lmc...@ts... wrote:

>	- There is a circularity problem in the sourceforge web page. "index.html" leads only to itself and there is no email address in the footer.
>	http://gnuplot-py.sourceforge.net/doc/index.html
>

It's true that the header and footer have circular links, but there is a 
useful link under the "Modules and Packages" section that leads to more 
content.  I used happydoc to generate those pages, and I guess it uses 
the same header and footer on each page.  So we should probably report 
it as a bug in happydoc :-)

>	- When I installed gnuplot I found it was in a "1.5" subdirectory and the rest of my python libraries were in a "1.6" subdirectory.
>
>	What is a good way to deal with this? Move files or alter PYTHONPATH ?
>	I have been working around the problem by simply giving the full path name to gnuplot.
>

Hmmm.  Gnuplot.py installs itself with distutils, which invokes whatever 
python is on your path then deduces the install directory from 
sys.prefix and sys.version.  Could it be that you are accidentally 
running and old version of python when installing?  For example, could 
it be that you are installing as root, and root has a different path 
than your normal user?

Just some ideas.  For further ideas, I suggest you provide more 
information (like which OS you are using!) and send your question to the 
Gnuplot-py-users mailing list (see sourceforge for details).  I have 
CCed this response there, too.

Good luck,
Michael

-- 
Michael Haggerty
mh...@al...

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

[Fernando P. <fp...@co...>]

Michael Haggerty wrote:
> Well, I have to say that I would like to keep a "clean" interface on the 
> Gnuplot class--that is to say, easily understandable, straightforward to 
> implement, and without too many special cases.  This can include some of 
> the features suggested but not all of them.  Then I think it would be 
> excellent to derive from it an "interactive Gnuplot" class with any 
> other hairy and terse convenience features, special cases, and whatever 
> else that people want.  Of course we can make any reasonable changes to 
> the Gnuplot class that are needed to allow the derived class to be 
> implemented.

That makes perfect sense.  My ipython code is _somewhat_ structured in that 
matter, with GnuplotInteractive and GnuplotRuntime modules meant for easier 
interactive/scripting use respectively.  I'm sure you can organize things 
somewhat differently, but that might be a start (after all, the code is 
already written and works).

> 
> Let's put together a wish list for the "interactive Gnuplot" class and 
> then decide how to split the implementation between the old and the new 
> class.
> 
> One feature that definitely can go into the Gnuplot class is the special 
> conversion of 1-D arrays into datasets with one column.

My personal 'wishlist' is basically the existing code in ipython.  I've pretty 
much put in everything I wanted (or most things, at least) in there. The files 
are:

[IPython]> ls Gnu*py
Gnuplot2.py -- rewrite of the code I wanted to actually modify
GnuplotInteractive.py  GnuplotRuntime.py  -- thin wrappers for 
interactive/scripting use.

You (whoever does the actual work :) would probably want to move some of my 
more intrusive changes out of the Gnuplot2 code and put them into the upper 
layers, and keep some of the less intrusive stuff (and bugfixes like the 
hardcopy one) in Gnuplot.py-mainline.

> Based on recent performance, it is pretty clear that I won't have time 
> for a lot of new implementation soon, so ideally somebody would 
> volunteer to work on "interactive Gnuplot" features.  (I could commit to 
> make any necessary changes to the main Gnuplot classes.)  I can give 
> that person write permission on CVS at sourceforge so you can work 
> independently.  Anyone?

Unfortunately, my hands are more than full with ipython.  Ipython is about as 
much as I can handle right now beyond 'real work', and there are some 
substantial changes I want to do which will take all of my available time.

But the existing code in ipython could be hopefully used to jumpstart things, 
and I'll gladly assist with discussion/changes to that.  If there are any 
licensing/copyright changes that you may want done, I'm perfectly happy making 
them.

Cheers,

f.

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

[<kai...@t-...>]

Fernando Perez wrote:

> Leonardo Milano wrote:
>
>> So, in short, I agree there is a need for the functionality
>> Fernando is suggesting, the question is HOW to implement it.
>
>
> Well, your approach and mine are slightly different in the details.  
> But ultimately it's Michael's call.  I just recently put out 
> 'officially' ipython 0.4.0 with all the recent enhancements (some of 
> which are related to Gnuplot support).  When Michael has a chance, 
> he'll probably have a look and decide how much to use/change for the 
> mainline code.


Well, I have to say that I would like to keep a "clean" interface on the 
Gnuplot class--that is to say, easily understandable, straightforward to 
implement, and without too many special cases.  This can include some of 
the features suggested but not all of them.  Then I think it would be 
excellent to derive from it an "interactive Gnuplot" class with any 
other hairy and terse convenience features, special cases, and whatever 
else that people want.  Of course we can make any reasonable changes to 
the Gnuplot class that are needed to allow the derived class to be 
implemented.

Let's put together a wish list for the "interactive Gnuplot" class and 
then decide how to split the implementation between the old and the new 
class.

One feature that definitely can go into the Gnuplot class is the special 
conversion of 1-D arrays into datasets with one column.

Based on recent performance, it is pretty clear that I won't have time 
for a lot of new implementation soon, so ideally somebody would 
volunteer to work on "interactive Gnuplot" features.  (I could commit to 
make any necessary changes to the main Gnuplot classes.)  I can give 
that person write permission on CVS at sourceforge so you can work 
independently.  Anyone?

Michael

-- 
Michael Haggerty
mh...@al...

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

[Fernando P. <fp...@co...>]

Leonardo Milano wrote:

> So, in short, I agree there is a need for the functionality
> Fernando is suggesting, the question is HOW to implement it.

Well, your approach and mine are slightly different in the details.  But 
ultimately it's Michael's call.  I just recently put out 'officially' ipython 
0.4.0 with all the recent enhancements (some of which are related to Gnuplot 
support).  When Michael has a chance, he'll probably have a look and decide 
how much to use/change for the mainline code.

In the meantime, ipython users still can use those enhancements (if they like 
them :)

Best,

f.

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

[Leonardo M. <lm...@ud...>]

Hi Michael, Hola Fernando, All :-)

I have done some tricks very similar to Fernando's
independently, there is perhaps some real need for
a set of simplified methods in gnuplot, to make its
use a little friendlier. But I am not sure what is the
best way to go. Add some methods ? Create a higher
level interface to gnuplot ?. Don't know.

I'll post my solutions briefly:

[1] I inherit my own myGnuplot(Gnuplot) to extend Gnuplot as I need
[2] I wrote an external functions to do quick plots

In the first case I handle the terminal setting to postscrip, x,
etc. I use reasonable (for my use) default values. So a ps plot goes
like this:

    g.set_ps('filename.ps')
    g.plot(whatever)
    g.set_x()

In the second case I am able to do quick plots from an interactive
shell, just call qplot(y), or qplot(x,y), or plot(x,y1,y2) ... etc

So, in short, I agree there is a need for the functionality
Fernando is suggesting, the question is HOW to implement it.

Thank you all for your time. Cheers,
-- Leo

PS: So, here is the code:


[1] #### Gnuplot extension methods

class myGnuplot(Gnuplot.Gnuplot):
    # [...]
    def set_eps(self, filename, options = 'enhanced color "Times-Roman" 22'):
        self('set terminal postscript eps ' + options)
        self('set output "' + filename + '"')

    def set_ps(self, filename, options = 'enhanced color "Times-Roman" 22'):
        self('set terminal postscript ' + options)
        self('set output "' + filename + '"')

    def set_x(self):
        self('set terminal x11')

[2] #### quick plot function

def qplot(x, y1=arange(0), y2=arange(0), y3=arange(0)):
    """
    Quick plot Routine

    USAGE::

        qplot(y)          # plots y as a function of a vector [0,1,...,size(y)]
        qplot(x,y)        # plots y(x)
        qplot(x,y1,y2)    # plots y1(x) and y2(x)
        qplot(x,y1,y2,y3) # plots y1(x), y2(x) and y3(x)
    """

    g  = myGnuplot(persist=1, debug=1)
    g('set data style lines')

    if  size(y1) == 0:
        d1 = Data(arange(size(x)), x)
        g.plot(d1, xlabel = "x", ylabel="y")
    elif size(y2) == 0:
        d1 = Data(x, y1, title="y1")
        g.plot(d1, xlabel = "x", ylabel="y")
    elif size(y3) == 0:
        d1 = Data(x, y1, title="y1")
        d2 = Data(x, y2, title="y2")
        g.plot(d1, d2, xlabel = "x", ylabel="y")
    else:
        d1 = Data(x, y1, title="y1")
        d2 = Data(x, y2, title="y2")
        d3 = Data(x, y3, title="y3")
        g.plot(d1, d2, d3, xlabel = "x", ylabel="y")

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

[Fernando P. <fp...@co...>]

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.

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

[<kai...@t-...>]

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 :-(

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.

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.

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.

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

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

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

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

Please let me know what version of Gnuplot.py was your starting point so 
that I can download IPython and use diff to see your changes.

Thanks again!
Michael

Fernando Perez wrote:

> I've been a longtime user of your Gnuplot.py modules, so much so that 
> I've written a fair amount of stuff which wraps around them and 
> extends them to make everyday life easier.  First, thanks a lot for 
> putting out such a useful tool.
>
> Some of the changes I've made are for example a rewrite of the plot 
> command to handle cases like
>
> -plot(y) -> plot a NumPy array against its indices
> -plot(x,y) -> plot y vs x
> -plot(y1,None,y2) -> plot y1,y2 vs their indices (None is a separator)
> -plot(y,filename='out.eps') -> make eps output reliably (there's a 
> tricky timing issue which requires retrying the print command with a 
> sleep())
>
> - 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.
>
> ... plus a bunch of other stuff I don't remember now.  I made all of 
> these changes with the main objective of easing interactive use as 
> much as possible, so that the least amount of typing at the command 
> line would produce the most results.
>
>
> I've been including all of this in IPython for a long time 
> (http://ipython.scipy.org), and I wrap it in such a way as to make its 
> use fairly transparent.  But I think that most of this code should go 
> into the mainline of your project.  This would ease my maintenance 
> burden :), plus it would benefit all users of Gnuplot.py who don't 
> necessarily use IPython.  I could then leave a very thin layer in 
> IPython, mainly just for interactive use (though perhaps even that 
> should be a Gnuplot.py sub-module, something like Gnuplot.Interactive 
> or somesuch).
>
> Anyway, if you think you are interested in this, why don't you take a 
> look at IPython?  If you download it, you'll immediately see the 
> Gnuplot-related files.  You can then have a look and we can discuss if 
> you want to integrate the code, and what the best approach would be.
>
> [...]
>
> Best regards,
>
> Fernando Perez. 


-- 
Michael Haggerty
mh...@al...

Re: [Gnuplot-py-users] Re: Using gnuplot.py under cygwin

[Jim K. <jek...@kl...>]

Well, when I run "python demo.py" I get something like:
   gnuplot> plot '/cygdrive/c/DOCUMENT~1/Jim/LOCALS~1/Temp/@1540.0' notitle
      can't read data file 
"/cygdrive/c/DOCUMENT~1/Jim/LOCALS~1/Temp/@1540.0"
      (No such file or directory)

My guess is that python, which is compiled under cygwin
is passing a cygwin file path to pgnuplot.exe.  Since
neither pgnuplot.exe or wgnupl32.exe is compiled
"under cygwin" they don't understand that file path.
"under cygwin" means that cygwin is the platform.
Typing to python:
     /cygdrive/c/cygwin: python
     Python 2.2.2 (#1, Mar  9 2003, 08:18:26)
     [GCC 3.2 20020927 (prerelease)] on cygwin
     Type "help", "copyright", "credits" or "license" for more information.
     >>> import sys
     >>> print sys.platform
     cygwin
     >>>

If you build gnuplot using makefile.cyg, it uses the
"-mno-cygwin" compile option to build a windows program
that does not use the cygwin dll.  This should more
properly be called makefile.mingw.  There isn't a port
of gnuplot to the "cygwin platform" that I have seen yet.

If I rebuild gnuplot with makefile.cyg, I get the same
results but the gnuplot file name is wgnuplot.exe
instead of wgnupl32.exe.  It still doesn't understand
file paths that begin /cygdrive/c/user/...

Jim


Michael T. Colee wrote:

> No worries.  I did compile under cygwin, pretty much just followed the 
> instructions.  Had to include numeric.py.  If you could be a little more 
> specific with the details you'd like more info that'd help me be helpful.
> 
> mtc
> 
> Jim Kleckner wrote:
> 
>> Yes, please.
>>
>> I'm also curious as to whether you have a
>> cygwin-compiled (not mingw cross compiled from
>> cygwin) version of gnuplot.
>>
>> Thanks - Jim
>>
>> ====
>>
>> I use it from cygwin called from a python script which is called from a
>>  cron job.  I've had good luck with using symlinks to other drives so I
>>  refer to thing like:
>>
>>  /home/username/dataspace/whatevir
>>
>>  Let me know if you'd like more details...
>>
>>  mtc
>>
>>  Jim Kleckner wrote:
>>
>>  > Has anyone used gnuplot.py under cygwin?
>>  > The pgnuplot.exe file doesn't understand /cygdrive/c/...
>>  >
>>  > Thanks! Jim

Re: [Gnuplot-py-users] Re: Using gnuplot.py under cygwin

[Michael T. C. <mt...@ic...>]

No worries.  I did compile under cygwin, pretty much just followed the 
instructions.  Had to include numeric.py.  If you could be a little more 
specific with the details you'd like more info that'd help me be helpful.

mtc

Jim Kleckner wrote:

> Yes, please.
>
> I'm also curious as to whether you have a
> cygwin-compiled (not mingw cross compiled from
> cygwin) version of gnuplot.
>
> Thanks - Jim
>
> ====
>
> I use it from cygwin called from a python script which is called from a
>  cron job.  I've had good luck with using symlinks to other drives so I
>  refer to thing like:
>
>  /home/username/dataspace/whatevir
>
>  Let me know if you'd like more details...
>
>  mtc
>
>  Jim Kleckner wrote:
>
>  > Has anyone used gnuplot.py under cygwin?
>  > The pgnuplot.exe file doesn't understand /cygdrive/c/...
>  >
>  > Thanks! Jim
>  >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Michael Colee                        Internet: mt...@ic...
ICESS & Bren SESM                    Phone   : (805) 893-2883
University of California             Fax     : (805) 893-6113
Santa Barbara CA 93106-3060          Office  : 1001 Bren Hall
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[Gnuplot-py-users] Re: Using gnuplot.py under cygwin

[Jim K. <jek...@kl...>]

Yes, please.

I'm also curious as to whether you have a
cygwin-compiled (not mingw cross compiled from
cygwin) version of gnuplot.

Thanks - Jim

====

I use it from cygwin called from a python script which is called from a
  cron job.  I've had good luck with using symlinks to other drives so I
  refer to thing like:

  /home/username/dataspace/whatevir

  Let me know if you'd like more details...

  mtc

  Jim Kleckner wrote:

  > Has anyone used gnuplot.py under cygwin?
  > The pgnuplot.exe file doesn't understand /cygdrive/c/...
  >
  > Thanks! Jim
  >

Re: [Gnuplot-py-users] Using gnuplot.py under cygwin

[Michael T. C. <mt...@ic...>]

I use it from cygwin called from a python script which is called from a 
cron job.  I've had good luck with using symlinks to other drives so I 
refer to thing like:

/home/username/dataspace/whatevir

Let me know if you'd like more details...

mtc

Jim Kleckner wrote:

> Has anyone used gnuplot.py under cygwin?
> The pgnuplot.exe file doesn't understand /cygdrive/c/...
>
> Thanks! Jim
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Michael Colee                        Internet: mt...@ic...
ICESS & Bren SESM                    Phone   : (805) 893-2883
University of California             Fax     : (805) 893-6113
Santa Barbara CA 93106-3060          Office  : 1001 Bren Hall
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[Gnuplot-py-users] Using gnuplot.py under cygwin

[Jim K. <jek...@kl...>]

Has anyone used gnuplot.py under cygwin?
The pgnuplot.exe file doesn't understand /cygdrive/c/...

Thanks! Jim

Re: [Gnuplot-py-users] [BUGFIX] possible fix for the tempory file deletion problem

[Leonardo M. <lm...@ud...>]

Dear Hendrik

Thanks a lot for your message. What version of
gnuplot are you running?. I suspect 1.6

This problem with temporary files was fixed by
Michael a while ago in CVS (at least for UNIX),
but I think there was no release after that.

He fixed it by using FIFOs, please do a CVS checkout
and see:  http://sourceforge.net/cvs/?group_id=17434
(or just browse the web-cvs interface)

Michael: how about a new release ?

Best,
-- Leo

On Mon, 17 Mar 2003, Hendrik Muhs wrote:

> Hi,
>
> the problem is described in the FAQ of the gnuplot-package.
>
> (You will get the same problem if you use Gnuplot in function which returns
> before gnuplot is finished, for example:
>
> def makeimage(data, file):
> 	g=Gnuplot.Gnuplot()
> 	g('set term png')
> 	g('set output \'' + file+ '\'')
> 	g.plot(data)
> 	return
>
> you will get something like this:
>
>     gnuplot> plot  '/tmp/@24463.2'
>                    ^
>              can't read data file "/tmp/@24463.2"
>              line 0: (No such file or directory)
> )
>
> A possible fix would be to use popen2(available on unix and windows)  instead
> of os.popen and to define __del__(self) to savely shutdown the gnuplot
> process.
>
> the last part of my gp_unix.py looks like this:
>
>
> #from os import popen
> from popen2 import Popen3
>
> def test_persist():
>     """Determine whether gnuplot recognizes the option '-persist'.
>
>     If the configuration variable 'recognizes_persist' is set (i.e.,
>     to something other than 'None'), return that value.  Otherwise,
>     try to determine whether the installed version of gnuplot
>     recognizes the -persist option.  (If it doesn't, it should emit an
>     error message with '-persist' in the first line.)  Then set
>     'recognizes_persist' accordingly for future reference.
>
>     """
>
>     if GnuplotOpts.recognizes_persist is None:
>         import string
>         g = Popen3('echo | %s -persist 2>&1' % GnuplotOpts.gnuplot_command,
> 'r')
>         response = g.readlines()
>         g.close()
>         GnuplotOpts.recognizes_persist = (
>             (not response) or (string.find(response[0], '-persist') == -1))
>     return GnuplotOpts.recognizes_persist
>
>
> class GnuplotProcess:
>     """Unsophisticated interface to a running gnuplot program.
>
>     This represents a running gnuplot program and the means to
>     communicate with it at a primitive level (i.e., pass it commands
>     or data).  When the object is destroyed, the gnuplot program exits
>     (unless the 'persist' option was set).  The communication is
>     one-way; gnuplot's text output just goes to stdout with no attempt
>     to check it for error messages.
>
>     Members:
>
>         'gnuplot' -- the pipe to the gnuplot command.
>
>     Methods:
>
>         '__init__' -- start up the program.
>
>         '__call__' -- pass an arbitrary string to the gnuplot program,
>             followed by a newline.
>
>         'write' -- pass an arbitrary string to the gnuplot program.
>
>         'flush' -- cause pending output to be written immediately.
>
>     """
>
>     def __init__(self, persist=None):
>         """Start a gnuplot process.
>
>         Create a 'GnuplotProcess' object.  This starts a gnuplot
>         program and prepares to write commands to it.
>
>         Keyword arguments:
>
>           'persist=1' -- start gnuplot with the '-persist' option,
>               (which leaves the plot window on the screen even after
>               the gnuplot program ends, and creates a new plot window
>               each time the terminal type is set to 'x11').  This
>               option is not available on older versions of gnuplot.
>
>         """
>
>         if persist is None:
>             persist = GnuplotOpts.prefer_persist
>         if persist:
>             if not test_persist():
>                 raise ('-persist does not seem to be supported '
>                        'by your version of gnuplot!')
>             self.gnuplot = Popen3('%s -persist' % GnuplotOpts.gnuplot_command,
>                                  'w')
>         else:
>             self.gnuplot = Popen3(GnuplotOpts.gnuplot_command, 'w')
>
>
>         # forward write and flush methods:
>         self.write = self.gnuplot.tochild.write
>         self.flush = self.gnuplot.tochild.flush
>
>     def __call__(self, s):
>         """Send a command string to gnuplot, followed by newline."""
>
>         self.write(s + '\n')
>         self.flush()
>     def __del__(self):
> 	self.write('exit\n')
> 	self.flush()
> 	self.gnuplot.wait()
>
> Regards,
>
> Hendrik Muhs
> P.S. for answers: Please CC me, because I am not subscribed to this list
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>

[Gnuplot-py-users] [BUGFIX] possible fix for the tempory file deletion problem

[Hendrik M. <Hen...@we...>]

Hi,

the problem is described in the FAQ of the gnuplot-package.

(You will get the same problem if you use Gnuplot in function which returns 
before gnuplot is finished, for example:

def makeimage(data, file):
	g=Gnuplot.Gnuplot()
	g('set term png')
	g('set output \'' + file+ '\'')
	g.plot(data)
	return

you will get something like this:

    gnuplot> plot  '/tmp/@24463.2'
                   ^
             can't read data file "/tmp/@24463.2"
             line 0: (No such file or directory)
)

A possible fix would be to use popen2(available on unix and windows)  instead 
of os.popen and to define __del__(self) to savely shutdown the gnuplot 
process.

the last part of my gp_unix.py looks like this:


#from os import popen
from popen2 import Popen3

def test_persist():
    """Determine whether gnuplot recognizes the option '-persist'.

    If the configuration variable 'recognizes_persist' is set (i.e.,
    to something other than 'None'), return that value.  Otherwise,
    try to determine whether the installed version of gnuplot
    recognizes the -persist option.  (If it doesn't, it should emit an
    error message with '-persist' in the first line.)  Then set
    'recognizes_persist' accordingly for future reference.

    """

    if GnuplotOpts.recognizes_persist is None:
        import string
        g = Popen3('echo | %s -persist 2>&1' % GnuplotOpts.gnuplot_command, 
'r')
        response = g.readlines()
        g.close()
        GnuplotOpts.recognizes_persist = (
            (not response) or (string.find(response[0], '-persist') == -1))
    return GnuplotOpts.recognizes_persist


class GnuplotProcess:
    """Unsophisticated interface to a running gnuplot program.

    This represents a running gnuplot program and the means to
    communicate with it at a primitive level (i.e., pass it commands
    or data).  When the object is destroyed, the gnuplot program exits
    (unless the 'persist' option was set).  The communication is
    one-way; gnuplot's text output just goes to stdout with no attempt
    to check it for error messages.

    Members:

        'gnuplot' -- the pipe to the gnuplot command.

    Methods:

        '__init__' -- start up the program.

        '__call__' -- pass an arbitrary string to the gnuplot program,
            followed by a newline.

        'write' -- pass an arbitrary string to the gnuplot program.

        'flush' -- cause pending output to be written immediately.

    """

    def __init__(self, persist=None):
        """Start a gnuplot process.

        Create a 'GnuplotProcess' object.  This starts a gnuplot
        program and prepares to write commands to it.

        Keyword arguments:

          'persist=1' -- start gnuplot with the '-persist' option,
              (which leaves the plot window on the screen even after
              the gnuplot program ends, and creates a new plot window
              each time the terminal type is set to 'x11').  This
              option is not available on older versions of gnuplot.

        """

        if persist is None:
            persist = GnuplotOpts.prefer_persist
        if persist:
            if not test_persist():
                raise ('-persist does not seem to be supported '
                       'by your version of gnuplot!')
            self.gnuplot = Popen3('%s -persist' % GnuplotOpts.gnuplot_command,
                                 'w')
        else:
            self.gnuplot = Popen3(GnuplotOpts.gnuplot_command, 'w')
	
	
        # forward write and flush methods:
        self.write = self.gnuplot.tochild.write
        self.flush = self.gnuplot.tochild.flush

    def __call__(self, s):
        """Send a command string to gnuplot, followed by newline."""

        self.write(s + '\n')
        self.flush()
    def __del__(self):
	self.write('exit\n')
	self.flush()
	self.gnuplot.wait()
	
Regards,

Hendrik Muhs
P.S. for answers: Please CC me, because I am not subscribed to this list

Re: [Gnuplot-py-users] clean exit

[<kai...@t-...>]

William Baxter wrote:

>When I try to quit from my python programs that called gnuplot.py, they
>complain "The program is still running; do you wish to kill it?" 
>
>Even if I click "ok" they still won't go away. 
>
>How do I clean up the gnuplot processes that I've started in python?
>

What operating system?

It should be that when the Gnuplot.Gnuplot object is destroyed, then its 
self.gnuplot object should run out of reference counts and be destroyed. 
 That object is a GnuplotProcess object which holds a popen file object. 
 When the GnuplotProcess object is destroyed, the popen file object 
should be closed and destroyed, which should end the gnuplot process.

At least that's the theory, and I've never had any trouble with it under 
Linux.  It could be that the close-on-delete behavior of popen is not 
the same on your platform, or it could be that you are somehow holding a 
reference to the Gnuplot.Gnuplot object when your program ends (maybe 
via a circular reference?)  Anyway, I should probably add a close() 
method to the Gnuplot.Gnuplot object to insist that the process is ended 
NOW (this will also be required if I ever get around to finishing off 
Jython support for Gnuplot.py).

Yours,
Michael

-- 
Michael Haggerty
mh...@al...

[Gnuplot-py-users] clean exit

[William B. <bb...@wa...>]

When I try to quit from my python programs that called gnuplot.py, they
complain "The program is still running; do you wish to kill it?" 

Even if I click "ok" they still won't go away. 

How do I clean up the gnuplot processes that I've started in python?

Bill Baxter 
----
Wadsworth Center
Empire State Plaza, PO Box 509
Albany, NY 12201-0509