gnuplot-py-users Mailing List for Gnuplot.py

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

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

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