[issue31880] subprocess process interaction with IDLEX GUI causes pygnuplot silent failures

[Roger Serwy]

Roger Serwy  added the comment:

I am closing this issue. For future reference, IDLEX is a separate project from 
IDLE. Please refer IDLEX bugs to the project developer (me).

--
assignee:  -> terry.reedy
components: +IDLE -Interpreter Core, Windows
nosy: +roger.serwy, terry.reedy
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31880] subprocess process interaction with IDLEX GUI causes pygnuplot silent failures

[John Brearley]

John Brearley  added the comment:

I retested with Python 3.6.4 upgrades and the issue no longer occurs. You may 
want to close this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31880] subprocess process interaction with IDLEX GUI causes pygnuplot silent failures

[John Brearley]

John Brearley  added the comment:

The owner of PyGnuplot figured out that for Python 3.4+ that a flush on stdin 
is needed. IDLEX GUI now runs example.py and my own test code correctly.

proc.stdin.flush()  # send the command in python 3.4+

This leaves the interesting behavior of IDLEX GUI. What is it doing differently 
re stdin from the command line terminal behavior? There is probably something 
to be learned here, if someone wants to dig into it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31880] subprocess process interaction with IDLEX GUI causes pygnuplot silent failures

[John Brearley]

John Brearley  added the comment:

Additonal testing shows that the subprocess.run command will reliably interact 
directly with gnuplot, either from the IDLEX GUI or the Python terminal window.

import subprocess
def run_cmd(cmd):
   print("run_cmd cmd:", cmd)
   # MUST explicitly ask for stdout, stderr. timeout is in seconds
   p1 = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, 
timeout=20)
   # print("run_cmd p1:", p1, type(p1))
   print("run_cmd p1.stdout:", p1.stdout, type(p1.stdout), 
p1.stdout.decode("utf-8"))
   print("run_cmd p1.stderr:", p1.stderr, type(p1.stderr), 
p1.stderr.decode("utf-8"))
   print("run_cmd p1.returncode:", p1.returncode, type(p1.returncode))

cmd = "gnuplot.exe "+self+"_candles.gnu"
run_cmd(cmd)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31880] subprocess process interaction with IDLEX GUI causes pygnuplot silent failures

[John Brearley]

New submission from John Brearley :

There is an interesting interaction between the IDLEX GUI and subprocess module 
that causes pygnuplot silent failures. The example.py script below works fine 
when run from the WinPython Command Prompt.exe terminal window. The script will 
popup a new window from gnuplot with the desired graph, and in the same 
directory save the generated raw data as example.out and the generated graph as 
example.pdf. If you erase the generated files and then run the same script via 
the IDLEX GUI, there is no graph window created and only the raw data 
example.out file is created. There are no error messages.

The PyGnuplot module sets up a subprocess.Popen pipe as persistant connection 
to the gnuplot.exe utility. This allows the top level script to send multiple 
commands to gnuplot to compose the desired graph, and then finally save the 
file to disk. This all works fine when run from the WinPython Command 
Prompt.exe terminal window. However something subtle is breaking when the same 
script is run from the IDLEX GUI environment. It is not at all obvious if the 
subprocess module is not as forgiving as it needs to be of the IDLEX GUI input 
or if the IDLEX GUI is breaking the rules somewhere. I will start by asking the 
subprocess module team to comment.

I did try adding some trace code to the PyGnuplot.py module. In particular I 
turned on stdout=subprocess.PIPE  and stderr=subprocess.PIPE. I did proc.poll() 
before/after the command is sent to gnuplot. Interestingly, when I did 
proc.communicate(timeout=0) to do an immediate read for any stdout/err data, 
this seems to cause the
 subsequent write to the pipe.stdin to fail, saying the file is already closed. 
In another learning exercise script for subprocess, the communicate() method 
does not seem to interfere with the pipe behavior.

This issue is quite repeatable on demand. I set up a second PC and reproduced 
the issue on demand on the second PC. I am using WinPython 3.6.1 on Windows 7 
with gnuplot 5.2.0 on both PC.

Here are the links to the various components needed to setup the environment to 
reproduce this issue:
1) gnuplot 5.2.0   https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.0/
2) pygnuplot 0.10.0  https://pypi.python.org/pypi/PyGnuplot/0.10.0
3) There is a one-line fix to PyGnuplot.py needed   
https://github.com/benschneider/PyGnuplot/blob/master/PyGnuplot.py
4) example.py script  
https://github.com/benschneider/PyGnuplot/blob/master/example.py

WinPython 3.6.1 installer comes with subprocess.py as part of the package, no 
version info that I can find.

When installing gnuplot there is an advanced option to check on that will 
automatically update your PATH variable. If you dont do this, then you must 
manully add "C:\gnuplot\bin" (or whatever the directory is)
 to your PATH variable. To check if gnuplot is correctly installed, from a DOS 
prompt terminal window, type "gnuplot -V". You should get a one line response 
"gnuplot 5.2 patchlevel 0".

--
components: Interpreter Core, Windows
messages: 305073
nosy: jbrearley, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess process interaction with IDLEX GUI causes pygnuplot silent 
failures
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com