Menu
▾
▴
matplotlib-users
|
From: Rich D. <dr...@in...> - 2005-04-28 00:41:43
|
Hello,
I gave a colleague a matplotlib script that generated a .ps output with
savefig, and was surprised when it didn't work for him. I eventually
figured out that since he was a Windows user and didn't have DISPLAY set,
the import of the matplotlib libraries was failing with the error in this
message's subject. I eventually solved the problem by doing
"matplotlib.use('PS')" before the pylab import.
However, the script never tried to actually display anything, it only
created the plot and did a savefig at the end. So my question is: is
this "could not open display" behavior at import the way things are
supposed to work, or is this a bug? It seems like it would be better to
hold off on the "could not open display" error until someone actually
tried to display something, and if all they did was savefigs, everything
would work fine.
This is on matplotlib .80.
Thanks,
Rich
|
|
From: Rich D. <dr...@in...> - 2005-04-28 01:29:00
|
I should add that we were both ssh'd into a Linux machine, he from Windows
and I from Linux. So his DISPLAY was not set and mine was. When he ran
the script it failed for him, but worked for me, even though the script
only did a savefig and never tried to actually show() anything to a
screen. Is that expected behavior?
Rich
On Wed, 27 Apr 2005, Rich Drewes wrote:
> Hello,
>
> I gave a colleague a matplotlib script that generated a .ps output with
> savefig, and was surprised when it didn't work for him. I eventually
> figured out that since he was a Windows user and didn't have DISPLAY set,
> the import of the matplotlib libraries was failing with the error in this
> message's subject. I eventually solved the problem by doing
> "matplotlib.use('PS')" before the pylab import.
>
> However, the script never tried to actually display anything, it only
> created the plot and did a savefig at the end. So my question is: is
> this "could not open display" behavior at import the way things are
> supposed to work, or is this a bug? It seems like it would be better to
> hold off on the "could not open display" error until someone actually
> tried to display something, and if all they did was savefigs, everything
> would work fine.
>
> This is on matplotlib .80.
>
> Thanks,
> Rich
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
|
|
From: John H. <jdh...@ac...> - 2005-04-28 02:00:20
|
>>>>> "Rich" == Rich Drewes <dr...@in...> writes:
Rich> I should add that we were both ssh'd into a Linux machine,
Rich> he from Windows and I from Linux. So his DISPLAY was not
Rich> set and mine was. When he ran the script it failed for him,
Rich> but worked for me, even though the script only did a savefig
Rich> and never tried to actually show() anything to a screen. Is
Rich> that expected behavior?
If you don't use the matplotlib.use directive, matplotlib will try and
load its default backend from the rc file
(http://matplotlib.sf.net/.matplotlibrc); if you haven't customized
this on linux it is GTKAgg. My guess is that this is what is causing
your problem. You have two choices in addition to the use directive:
1) change the default backend to a non-GUI backend in the rc file,
eg "backend : PS". Copy the rc file to your HOME directory (or
working directory) and edit it.
2) use a command line arg to force the backend
> python myscript.py -dPS
Hope this helps,
JDH
|
|
From: Darren D. <dd...@co...> - 2005-04-28 02:04:59
|
Hi Rich,
What happens if you run the script on a windows machine, no ssh?
Darren
On Wednesday 27 April 2005 9:28 pm, Rich Drewes wrote:
> I should add that we were both ssh'd into a Linux machine, he from Windows
> and I from Linux. So his DISPLAY was not set and mine was. When he ran
> the script it failed for him, but worked for me, even though the script
> only did a savefig and never tried to actually show() anything to a
> screen. Is that expected behavior?
>
> Rich
>
> On Wed, 27 Apr 2005, Rich Drewes wrote:
> > Hello,
> >
> > I gave a colleague a matplotlib script that generated a .ps output with
> > savefig, and was surprised when it didn't work for him. I eventually
> > figured out that since he was a Windows user and didn't have DISPLAY set,
> > the import of the matplotlib libraries was failing with the error in this
> > message's subject. I eventually solved the problem by doing
> > "matplotlib.use('PS')" before the pylab import.
> >
> > However, the script never tried to actually display anything, it only
> > created the plot and did a savefig at the end. So my question is: is
> > this "could not open display" behavior at import the way things are
> > supposed to work, or is this a bug? It seems like it would be better to
> > hold off on the "could not open display" error until someone actually
> > tried to display something, and if all they did was savefigs, everything
> > would work fine.
> >
> > This is on matplotlib .80.
> >
> > Thanks,
> > Rich
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Tell us your software development plans!
> > Take this survey and enter to win a one-year sub to SourceForge.net
> > Plus IDC's 2005 look-ahead and a copy of this survey
> > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
--
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...
|
|
From: Rich D. <dr...@in...> - 2005-04-28 02:54:58
|
On Wed, 27 Apr 2005, Darren Dale wrote: > What happens if you run the script on a windows machine, no ssh? I don't have any Windows machines to test on :) Based on what John said, I'd guess that the backend would be defaulted to some appropriate Windows backend, and things would work. It was only this particular combination of ssh'ing in to an X based system that failed from Windows. That said, since my script never actually tried to do some display, it would be spiffy if matplotlib postponed any X oriented stuff that accesses the display until the user actually requests a show(). That way, if the script just does a savefig(.ps) at the end as mine did, things would Just Work. Rich |
|
From: Chris B. <Chr...@no...> - 2005-04-28 04:18:34
|
Rich Drewes wrote: > That said, since my script never actually tried to do some display, it > would be spiffy if matplotlib postponed any X oriented stuff that accesses > the display until the user actually requests a show(). That way, if the > script just does a savefig(.ps) at the end as mine did, things would Just > Work. I'm just guessing here, but I bet the problem comes up when importing pylab, not matplotlib. The pylab interface was designed to be an easy to use interface for interactive use, ala Matlab. It therefor is expecting to display stuff. For scripts that generate figures for printing or web apps, or whatever, pylab is not really the best option. That being said, most of the effort towards usability has goine into the pylab module, so there is alot of stuff that is easier to do that way. I ahev a goal to create a nice pythonic, OO interface for use in scripting (and would be bad in interactive use either), but haven't really had a chance to work on it. Mostly what it would require is to write helpful handy mnethods that do the things that the pylab procedural interface already does. So far all I've done is make a few suggestions, some of which John has implimented. In the meantime, I use the matplotlib.use() function, and use pylab when I need to. -Chris -Chris |
|
From: Ted D. <ted...@jp...> - 2005-04-28 03:02:58
|
What was the backend set to?
We've seen messages like this from the Qt library (just in our normal C++
work). Qt needs to connect to an X server before it can do pretty much
anything (I presume that it needs fonts, colors, etc). Just importing some
of the backends may build certain objects (like QApplication in the case of
Qt) which may need an X server.
I realize this doesn't actually help you - it's more of an explanation. If
it is Qt that you're using and this is the cause (neither of which I'm sure
of), there may not be a good fix. In our application we tried building the
QApplication with the GUI flag set to false (which stops the X server
connection) but then if someone tries to do display anything it core dumps
- not a very good behavior.
Ted
At 07:04 PM 4/27/2005, Darren Dale wrote:
>Hi Rich,
>
>What happens if you run the script on a windows machine, no ssh?
>
>Darren
>
>
>On Wednesday 27 April 2005 9:28 pm, Rich Drewes wrote:
> > I should add that we were both ssh'd into a Linux machine, he from Windows
> > and I from Linux. So his DISPLAY was not set and mine was. When he ran
> > the script it failed for him, but worked for me, even though the script
> > only did a savefig and never tried to actually show() anything to a
> > screen. Is that expected behavior?
> >
> > Rich
> >
> > On Wed, 27 Apr 2005, Rich Drewes wrote:
> > > Hello,
> > >
> > > I gave a colleague a matplotlib script that generated a .ps output with
> > > savefig, and was surprised when it didn't work for him. I eventually
> > > figured out that since he was a Windows user and didn't have DISPLAY set,
> > > the import of the matplotlib libraries was failing with the error in this
> > > message's subject. I eventually solved the problem by doing
> > > "matplotlib.use('PS')" before the pylab import.
> > >
> > > However, the script never tried to actually display anything, it only
> > > created the plot and did a savefig at the end. So my question is: is
> > > this "could not open display" behavior at import the way things are
> > > supposed to work, or is this a bug? It seems like it would be better to
> > > hold off on the "could not open display" error until someone actually
> > > tried to display something, and if all they did was savefigs, everything
> > > would work fine.
> > >
> > > This is on matplotlib .80.
> > >
> > > Thanks,
> > > Rich
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Tell us your software development plans!
> > > Take this survey and enter to win a one-year sub to SourceForge.net
> > > Plus IDC's 2005 look-ahead and a copy of this survey
> > > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Tell us your software development plans!
> > Take this survey and enter to win a one-year sub to SourceForge.net
> > Plus IDC's 2005 look-ahead and a copy of this survey
> > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>--
>Darren S. Dale
>
>Bard Hall
>Department of Materials Science and Engineering
>Cornell University
>Ithaca, NY. 14850
>
>dd...@co...
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Tell us your software development plans!
>Take this survey and enter to win a one-year sub to SourceForge.net
>Plus IDC's 2005 look-ahead and a copy of this survey
>Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
|
|
From: CompBio <rog...@CS...> - 2011-09-01 15:37:52
|
I'm trying to get a script to work in batch mode to produce a large number of
plots. I've got the following sequence of imports in a matplotlib Python
script:
import matplotlib, os, sys
...
if file_ext == 'png' :
sys.stderr.write('Using PNG output format\n')
matplotlib.use('agg')
elif file_ext == 'pdf' :
sys.stderr.write('Using PDF output format\n')
matplotlib.use('PDF')
from pylab import *
... remainder of plotting code ...
At first this appeared to work without any problems. I could kick off a job
in background, log off the machine and return later when all the graphs had
been produced.
Now I get this RuntimeError exception. Is there anything else I need to do
to convince matplotlib that it doesn't need my local display?
thanks!
--
View this message in context: http://old.nabble.com/RuntimeError%3A-could-not-open-display-tp32380449p32380449.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
|
|
From: Benjamin R. <ben...@ou...> - 2011-09-01 17:39:19
|
On Thursday, September 1, 2011, CompBio <rog...@cs...> wrote:
>
> I'm trying to get a script to work in batch mode to produce a large number
of
> plots. I've got the following sequence of imports in a matplotlib Python
> script:
>
> import matplotlib, os, sys
> ...
> if file_ext == 'png' :
> sys.stderr.write('Using PNG output format\n')
> matplotlib.use('agg')
> elif file_ext == 'pdf' :
> sys.stderr.write('Using PDF output format\n')
> matplotlib.use('PDF')
>
> from pylab import *
>
> ... remainder of plotting code ...
>
> At first this appeared to work without any problems. I could kick off a
job
> in background, log off the machine and return later when all the graphs
had
> been produced.
>
> Now I get this RuntimeError exception. Is there anything else I need to
do
> to convince matplotlib that it doesn't need my local display?
>
> thanks!
> --
Without the stack trace, it would be hard to tell. Plus, there is already
logic in the backends to switch to PDF and such for saving files. It should
only be necessary to set the backend to AGG if you want a headless batch
script.
Ben Root
|
|
From: Eric F. <ef...@ha...> - 2011-09-01 18:08:26
|
On 09/01/2011 05:37 AM, CompBio wrote:
>
> I'm trying to get a script to work in batch mode to produce a large number of
> plots. I've got the following sequence of imports in a matplotlib Python
> script:
Is the script being run standalone, from a shell, and are the following
the very first imports?
>
> import matplotlib, os, sys
> ...
> if file_ext == 'png' :
> sys.stderr.write('Using PNG output format\n')
> matplotlib.use('agg')
> elif file_ext == 'pdf' :
> sys.stderr.write('Using PDF output format\n')
> matplotlib.use('PDF')
As Ben notes, you don't need the above logic to choose between agg and
pdf; but you are correct in choosing a non-interactive backend before
any import of pylab or pyplot. That should be enough to prevent any
subsequent attempt to open a display.
I'll bet the problem is that when the code above is run, file_ext is
neither 'png' nor 'pdf', so matplotlib.use is not being executed.
>
> from pylab import *
>
And at this point pylab is simply setting the default (interactive) backend.
> ... remainder of plotting code ...
>
> At first this appeared to work without any problems. I could kick off a job
> in background, log off the machine and return later when all the graphs had
> been produced.
>
> Now I get this RuntimeError exception. Is there anything else I need to do
> to convince matplotlib that it doesn't need my local display?
No--you just have to make sure that a non-interactive backend is getting
set before the first pylab or pyplot import.
Eric
>
> thanks!
|
|
From: CompBio <rog...@CS...> - 2011-09-01 18:24:05
|
Thanks for your fast response -- faster than I could post a follow-up.
You're right about the stack trace. It occurred to me after I posted that I
should look to see exactly where the exception was triggered. As it turned
out, I'd added a new module a few days ago and wasn't careful about where I
added the import. Here at work it didn't make a difference, but launching
from home...
Once I reordered the new import the error disappeared.
BTW, the reason I specify a PDF backend is because I thought it would tell
matplotlib not to try to use anything else "behind the scenes" such as an
X-window display. It's working the way I want now, so I assume that's what
it's doing.
Benjamin Root-2 wrote:
>
> On Thursday, September 1, 2011, CompBio <rog...@cs...> wrote:
>>
>> I'm trying to get a script to work in batch mode to produce a large
>> number
> of
>> plots. I've got the following sequence of imports in a matplotlib Python
>> script:
>>
>> import matplotlib, os, sys
>> ...
>> if file_ext == 'png' :
>> sys.stderr.write('Using PNG output format\n')
>> matplotlib.use('agg')
>> elif file_ext == 'pdf' :
>> sys.stderr.write('Using PDF output format\n')
>> matplotlib.use('PDF')
>>
>> from pylab import *
>>
>> ... remainder of plotting code ...
>>
>> At first this appeared to work without any problems. I could kick off a
> job
>> in background, log off the machine and return later when all the graphs
> had
>> been produced.
>>
>> Now I get this RuntimeError exception. Is there anything else I need to
> do
>> to convince matplotlib that it doesn't need my local display?
>>
>> thanks!
>> --
>
> Without the stack trace, it would be hard to tell. Plus, there is already
> logic in the backends to switch to PDF and such for saving files. It
> should
> only be necessary to set the backend to AGG if you want a headless batch
> script.
>
> Ben Root
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
View this message in context: http://old.nabble.com/RuntimeError%3A-could-not-open-display-tp32380449p32381582.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
|
|
From: John H. <jd...@gm...> - 2011-09-01 18:27:53
|
On Thu, Sep 1, 2011 at 1:23 PM, CompBio <rog...@cs...> wrote:
> BTW, the reason I specify a PDF backend is because I thought it would tell
> matplotlib not to try to use anything else "behind the scenes" such as an
> X-window display. It's working the way I want now, so I assume that's what
> it's doing.
But at others have pointed out, your code is unnecessarily complex. Just do
import matplotlib
matplotlib.use('agg')
import pylab
and when you call savefig, you can pass ps, eps, pdf, png or svg and
the mpl code will choose the right backend, and never launch a GUI.
JDH
|
|
From: CompBio <rog...@CS...> - 2011-09-01 18:35:08
|
First, you folks respond faster than lightning -- I can't keep up!
Second, thanks for the tip -- that's definitely more elegant than my callow
approach.
John Hunter-4 wrote:
>
> On Thu, Sep 1, 2011 at 1:23 PM, CompBio <rog...@cs...> wrote:
>
>> BTW, the reason I specify a PDF backend is because I thought it would
>> tell
>> matplotlib not to try to use anything else "behind the scenes" such as an
>> X-window display. It's working the way I want now, so I assume that's
>> what
>> it's doing.
>
> But at others have pointed out, your code is unnecessarily complex. Just
> do
>
> import matplotlib
> matplotlib.use('agg')
> import pylab
>
> and when you call savefig, you can pass ps, eps, pdf, png or svg and
> the mpl code will choose the right backend, and never launch a GUI.
>
> JDH
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
View this message in context: http://old.nabble.com/RuntimeError%3A-could-not-open-display-tp32380449p32381652.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X