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
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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
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
> Matplotlib-users@lists.sourceforge.net
> matplotlib-users List Signup and Options
-------------------------------------------------------
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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd55@...163...
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
···
On Wed, 27 Apr 2005, Darren Dale wrote:
What happens if you run the script on a windows machine, no ssh?
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
> > Matplotlib-users@lists.sourceforge.net
> > matplotlib-users List Signup and Options
>
> -------------------------------------------------------
> 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
> Matplotlib-users@lists.sourceforge.net
> matplotlib-users List Signup and Options
--
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd55@...163...
-------------------------------------------------------
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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
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