gnuplot-py-users Mailing List for Gnuplot.py

On Wed, Apr 18, 2007 at 11:26:21AM -0500, Grant Edwards wrote:

> I feel like I've spent the past 3 days beating my head against
> a wall: no matter what I do, I can't get gnuplot-py to work
> reliably on Win2K or WinXP.
[...]
> What refuses to work is when the program is started by clicking
> on a file whose type has been associated with the program.  In
> that case, I always get an "invalid parameter" IOError when
> gp_win32.py writes to the pipe in its __call__ method.

The base cause of Gnuplot.py failing is that os.popen() can't
be used if the CWD is a UNC network path.  See the link below
if you're interested in Microsoft's half-assed rationalization
of this particular bit of Windows breakage:

  http://support.microsoft.com/kb/156276/EN-US/

The answer is to change gp_win32.py so that instead of
os.popen() it uses subprocess.Popen() with shell=False.
However, there are bugs in the subprocess module that you have
to work-around:

  http://www.py2exe.org/index.cgi/Py2ExeSubprocessInteractions

Using subprocess.Popen() with the above work-arounds seems to
work.  

It also eliminates the requirement to double-quote a path that
contains a string.

After I've tested it a little more, I'll submit a patch.
  
-- 
Grant Edwards
gr...@vi...

On Wed, Apr 18, 2007 at 08:44:23PM +0200, Michael Haggerty wrote:
> Grant Edwards wrote:
> > [...]
> > What refuses to work is when the program is started by clicking
> > on a file whose type has been associated with the program.  In
> > that case, I always get an "invalid parameter" IOError when
> > gp_win32.py writes to the pipe in its __call__ method.
> 
> I think that is the error that results if Gnuplot.py is not able to
> start the "pgnuplot.exe" binary.  Perhaps you have a PATH problem?

I'm setting the complete path to pgnuplot.exe in GnuplotOpts.

The program works fine when started by:
  
 1) command line from any directory (local or networked).

 2) desktop shortcut icon with any 'start in' directory (local
    or networked).

 3) double-clicking an associated file in any local directory.
 
It only fails when one double-clicks an associated fine in a
network directory. I've verified that in all cases the correct
path to pgnuplot.exe is being used.  The program doesn't try to
open or access any files in the current directory.  All it does
is this:

#!/usr/bin/env python
import sys,math,tempfile,os,itertools,wx
from wx.lib.floatcanvas import NavCanvas, FloatCanvas, Resources
import wx.lib.colourdb
from sectionedFile import SectionedFile
import Gnuplot

# if we're on a Windows system and there's a pgnuplot.exe file
# in our "install" directly, tell the Gnuplot module to use
# that instead of whatever's in our PATH

sys.stderr.write("cwd: %s\n" % os.getcwd())
if sys.platform == 'win32':
    installpath = os.path.abspath(os.path.dirname(sys.argv[0]))
    gnuplotpath = os.path.join(installpath,'pgnuplot.exe')
    sys.stderr.write("installpath '%s'\n" % installpath)
    sys.stderr.write("gnuplotpath '%s'\n" % gnuplotpath)
    if os.path.isfile(gnuplotpath):
        if ' ' in gnuplotpath:
            gnuplotpath = '"' + gnuplotpath + '"'
        Gnuplot.GnuplotOpts.gnuplot_command = gnuplotpath;
        sys.stderr.write( "using pgnuplot at %s\n" % Gnuplot.GnuplotOpts.gnuplot_command)
    else:
        sys.stderr.write("didn't find pgnuplot at %s -- hope it's in your path...\n" % gnuplotpath);

import time
gp = Gnuplot.Gnuplot(debug=1)
gp('plot sin(x)')
time.sleep(1)
gp('plot cos(x)')
time.sleep(1)
gp('plot tan(x)')
time.sleep(1)
sys.exit(0)

-- 
Grant Edwards
gr...@vi...

Grant Edwards wrote:
> [...]
> What refuses to work is when the program is started by clicking
> on a file whose type has been associated with the program.  In
> that case, I always get an "invalid parameter" IOError when
> gp_win32.py writes to the pipe in its __call__ method.

I think that is the error that results if Gnuplot.py is not able to
start the "pgnuplot.exe" binary.  Perhaps you have a PATH problem?

> It's really not possible to describe how much I hate working
> with Microsoft Windows...

I feel your pain, but I don't share it :-).  Perhaps a Windows user has
more insight into your problem.

Michael

I feel like I've spent the past 3 days beating my head against
a wall: no matter what I do, I can't get gnuplot-py to work
reliably on Win2K or WinXP.

It seems to work fine in the following situations:

 * Program called "normally" (e.g. python foo.py) with current
   directory containing pgnuplot.exe and wgnuplot.exe.

 * Program bundled via py2exe and called via shortcut icon
   starting in directory containing [pw]gnuplot.exe

 * Program bundled via py2exe and called via shortcut icon
   starting in different directory.

 * Program bundled via Py2exe and called via command-line from
   anywhere.

What refuses to work is when the program is started by clicking
on a file whose type has been associated with the program.  In
that case, I always get an "invalid parameter" IOError when
gp_win32.py writes to the pipe in its __call__ method.

I've switch gp_win32.py so that it uses subprocess instead of
os.popen, and that doesn't seem to help. I get either the same
error or I get an "invalid handle" when the process is being
started.

Can anybody point me towards documentation on how to get
reliable operation on Win32?

It's really not possible to describe how much I hate working
with Microsoft Windows...

-- 
Grant Edwards
gr...@vi...