matplotlib-devel Mailing List for matplotlib

Darren Dale wrote:
>>If anyone on the mpl team wants to test the new ipython
> 
> 
> I updated from svn, rc8 seems to have cleared it up for me as well.
Great, thanks for the confirmation.
Please keep me posted on any problems as soon as you see them. The diff I 
committed was over 5000 lines in one week, so I'm a little apprehensive here 
about bugs lurking beneath (though I've already caught and killed quite a few).
Cheers,
f

On Wednesday 04 January 2006 15:01, Fernando Perez wrote:
> Charlie Moad wrote:
> >>the next thing to try would be to change
> >>
> >> > + if self.gtk.pygtk_version >= (2,4,0):
> >> > + import gobject
> >> > + gobject.idle_add(self.on_timer)
> >>
> >>into
> >>
> >> if self.gtk.pygtk_version >= (2,4,0):
> >> import gobject
> >> gobject.timeout_add(self.TIMEOUT, self.on_timer)
> >
> > Yup, that does it.
>
> Great, thanks for the help. Fix committed to SVN and uploaded as rc8
> (along with a few other fixes I had in waiting).
>
> If anyone on the mpl team wants to test the new ipython
I updated from svn, rc8 seems to have cleared it up for me as well.

Charlie Moad wrote:
>>the next thing to try would be to change
>>
>> > + if self.gtk.pygtk_version >= (2,4,0):
>> > + import gobject
>> > + gobject.idle_add(self.on_timer)
>>
>>into
>>
>> if self.gtk.pygtk_version >= (2,4,0):
>> import gobject
>> gobject.timeout_add(self.TIMEOUT, self.on_timer)
> 
> 
> Yup, that does it.
Great, thanks for the help. Fix committed to SVN and uploaded as rc8 (along 
with a few other fixes I had in waiting).
If anyone on the mpl team wants to test the new ipython, downloads are here:
http://ipython.scipy.org/dist/testing/
I plan on making an official release next week, so please let me know of any 
problems you may encounter (matplotlib-related or not).
Cheers,
f

> the next thing to try would be to change
>
> > + if self.gtk.pygtk_version >=3D (2,4,0):
> > + import gobject
> > + gobject.idle_add(self.on_timer)
>
> into
>
> if self.gtk.pygtk_version >=3D (2,4,0):
> import gobject
> gobject.timeout_add(self.TIMEOUT, self.on_timer)
Yup, that does it.
Thanks,
 Charlie

[ moving over to the mpl list, this isn't really ipython-user material]
Fernando Perez wrote:
> Charlie Moad wrote:
> 
>>Works fine with 0.6.15, but it spins with 0.7.0. It does work with
>>0.7.0, but it just busy waits. 0.6.15 gives a warning:
> 
> 
> Aha! This is very, very good. I tried 0.6.15 on my box to see if the 
> segfault also went away, but no luck there. So we're stuck with debug-by-proxy.
> 
> I've attached the diff for the relevant file, Shell.py, between .6.15 and 
> .7.0. It's kind of big, but the part that I think matters is only this:
> 
> 
> 
> - def mainloop(self):
> + def mainloop(self,sys_exit=0,banner=None):
> +
> + self._banner = banner
> 
> - self.gtk.timeout_add(self.TIMEOUT, self.on_timer)
> + if self.gtk.pygtk_version >= (2,4,0):
> + import gobject
> + gobject.idle_add(self.on_timer)
> + else:
> + self.gtk.idle_add(self.on_timer)
> 
> 
> See if you can revert back to the timeout_add method and if that helps.
Furthermore, keeping the warning you got in mind:
/usr/lib/python2.4/site-packages/ipython-0.6.15-py2.4.egg/IPython/Shell.py:627:
GtkDeprecationWarning: gtk.timeout_add is deprecated, use
gobject.timeout_add instead
 self.gtk.timeout_add(self.TIMEOUT, self.on_timer)
the next thing to try would be to change
 > + if self.gtk.pygtk_version >= (2,4,0):
 > + import gobject
 > + gobject.idle_add(self.on_timer)
into
 if self.gtk.pygtk_version >= (2,4,0):
 import gobject
 gobject.timeout_add(self.TIMEOUT, self.on_timer)
that might do it.
Cheers,
f

Charlie Moad wrote:
> Works fine with 0.6.15, but it spins with 0.7.0. It does work with
> 0.7.0, but it just busy waits. 0.6.15 gives a warning:
Aha! This is very, very good. I tried 0.6.15 on my box to see if the 
segfault also went away, but no luck there. So we're stuck with debug-by-proxy.
I've attached the diff for the relevant file, Shell.py, between .6.15 and 
.7.0. It's kind of big, but the part that I think matters is only this:
- def mainloop(self):
+ def mainloop(self,sys_exit=0,banner=None):
+
+ self._banner = banner
- self.gtk.timeout_add(self.TIMEOUT, self.on_timer)
+ if self.gtk.pygtk_version >= (2,4,0):
+ import gobject
+ gobject.idle_add(self.on_timer)
+ else:
+ self.gtk.idle_add(self.on_timer)
See if you can revert back to the timeout_add method and if that helps.
If so, we can try to understand better what the right call to make should be.
Cheers,
f

Hi Fernando, Charlie,
I just updated my svn checkout, and can confirm this behavior with the gtkagg 
backend. If I fall back to ipython 0.6.15, cpu usage remains normal.
Darren
On Wednesday 04 January 2006 13:29, Fernando Perez wrote:
> [ I'm cc-ing the matplotlib list here, in case anyone can help us with this
> one. The context is: testing the new ipython release candidate from
>
> http://ipython.scipy.org/dist/testing/
>
> Charlie is havig problems with -pylab and the gtk backend.]
>
>
> Hi Charlie,
>
> Charlie Moad wrote:
> > First of all, thanks as always. I can't remember the last time I
> > have used the vanilla python shell.
> > I am trying the rc, and I get 100% cpu usage just by running
> > ipython -pylab. This is on ubuntu/mpl-cvs/gtkagg.
>
> This has been reported before, and I am not yet sure if the problem is
> ipython or matplotlib. Unfortunately, on all of my boxes,
> matplotlib/gtkagg just segfaults instantly, so I can't even debug this one.
>
> Help me a little: can you please test back and forth ipython 0.6.15 and
> 0.7.0.rc, without changing anything else? Is the problem ONLY with 0.7.0?
>
> If that is the case, then I can try to track down what the threading call
> causing the problem might be. IPython has no C code in it, it only
> initializes the threads system for GTK, but perhaps I'm making an incorrect
> call there.
>
> Any help here would be very welcome.
>
> Cheers,
>
> f
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Works fine with 0.6.15, but it spins with 0.7.0. It does work with
0.7.0, but it just busy waits. 0.6.15 gives a warning:
/usr/lib/python2.4/site-packages/ipython-0.6.15-py2.4.egg/IPython/Shell.py:=
627:
GtkDeprecationWarning: gtk.timeout_add is deprecated, use
gobject.timeout_add instead
 self.gtk.timeout_add(self.TIMEOUT, self.on_timer)
I will try to look into it some more.
- Charlie
On 1/4/06, Fernando Perez <Fer...@co...> wrote:
> [ I'm cc-ing the matplotlib list here, in case anyone can help us with th=
is
> one. The context is: testing the new ipython release candidate from
>
> http://ipython.scipy.org/dist/testing/
>
> Charlie is havig problems with -pylab and the gtk backend.]
>
>
> Hi Charlie,
>
> Charlie Moad wrote:
> > First of all, thanks as always. I can't remember the last time I
> > have used the vanilla python shell.
> > I am trying the rc, and I get 100% cpu usage just by running
> > ipython -pylab. This is on ubuntu/mpl-cvs/gtkagg.
>
> This has been reported before, and I am not yet sure if the problem is ip=
ython
> or matplotlib. Unfortunately, on all of my boxes, matplotlib/gtkagg just
> segfaults instantly, so I can't even debug this one.
>
> Help me a little: can you please test back and forth ipython 0.6.15 and
> 0.7.0.rc, without changing anything else? Is the problem ONLY with 0.7.0=
?
>
> If that is the case, then I can try to track down what the threading call
> causing the problem might be. IPython has no C code in it, it only
> initializes the threads system for GTK, but perhaps I'm making an incorre=
ct
> call there.
>
> Any help here would be very welcome.
>
> Cheers,
>
> f
>

[ I'm cc-ing the matplotlib list here, in case anyone can help us with this 
one. The context is: testing the new ipython release candidate from
http://ipython.scipy.org/dist/testing/
Charlie is havig problems with -pylab and the gtk backend.]
Hi Charlie,
Charlie Moad wrote:
> First of all, thanks as always. I can't remember the last time I
> have used the vanilla python shell.
> I am trying the rc, and I get 100% cpu usage just by running
> ipython -pylab. This is on ubuntu/mpl-cvs/gtkagg.
This has been reported before, and I am not yet sure if the problem is ipython 
or matplotlib. Unfortunately, on all of my boxes, matplotlib/gtkagg just 
segfaults instantly, so I can't even debug this one.
Help me a little: can you please test back and forth ipython 0.6.15 and 
0.7.0.rc, without changing anything else? Is the problem ONLY with 0.7.0?
If that is the case, then I can try to track down what the threading call 
causing the problem might be. IPython has no C code in it, it only 
initializes the threads system for GTK, but perhaps I'm making an incorrect 
call there.
Any help here would be very welcome.
Cheers,
f

Hi Darren,
Darren Dale <dd...@co...> writes:
>On Tuesday 03 January 2006 10:48, Chris Walker wrote:
>>Darren Dale <dd...@co...> writes:
>>
>>>However, mpl uses a latex package called PSFrag to
>>>render the text in an intermediate postscript file, which is not
>>>compatible with pdflatex. Unfortunately, if you embed that intermediate
>>>postscript file in a new document, the text will frequently be upside
>>>down, because PSFrag uses some commands that are illegal in embedded
>>>documents. So by default, mpl uses ghostscript to "distill" the
>>>intermediate postscript file, converting the fonts to outlines and
>>>circumventing the problem.
>>
>>I attach a patch against matplotlib 0.85 that uses a picture
>>environment to position text instead of using psfrag.
>>
>>It isn't complete, and therefore probably shouldn't be applied just yet,
>>but may be a useful starting point. In particular, I haven't taken out
>>the distill code, but suspect that it could be replaced by using the
>>right options to dvips.
It looks like the right command is 'dvips -E'
>>
>>If I had the right dvips command instead of the ghostscript distilling
>>process, would this result in a legal eps file? Ie is this worth pursuing?
>
>Here is a post from way back describing the embedding issue: 
>http://sourceforge.net/mailarchive/message.php?msg_id=12030448
>
>"PSFrag was not designed to do what I am trying to do: 
> generate an eps file that can later be embedded in a document. It uses a 
> number of PostScript operators that are illegal in an eps file: setglobal, 
> statusdict and userdict. Here is the blurb from PostScript Language 
> Reference, Second Edition, Appendix I: setglobal disrupts page independence 
> and nesting of included documents. [...] Creation and modification of global 
> objects are uneffected by save-restore operators."
>
>So, to answer your question, if you need to use a PostScript operator that is 
>illegal in an eps file, it is not worth pursuing. 
Unfortunately, dvips -E always seems to generate files with illegal
operators (see below).
> I think your patched 
>backend_ps.py still generates a .tex file that uses the PSFrag package, which 
>will unavoidably end up using illegal PostScript operators. Is this correct?
>
No. I don't use PSFrag at all (the aim was to avoid the problems you
mention above).
I am however unable to generate a file from tex without statusdict or
userdict in it.
Take the following trivial tex file:
	\documentclass{article}
	\pagestyle{empty}
	\begin{document}
	foo
	\end{document}
If I run
latex
dvips -E
then it still uses statusdict and userdict, though not setglobal:
$ grep statusdict 20d9640a1b4e20b0a71da122eaf41ca7.ps
statusdict/manualfeed true put}B/@copies{/#copies X}B/FMat[1 0 0 -1 0 0]
/Ry X/Rx X V}B statusdict begin/product where{pop false[(Display)(NeXT)
$grep userdict 20d9640a1b4e20b0a71da122eaf41ca7.ps
}if put/ctr ctr 1 add N}B/I{cc 1 add D}B/bop{userdict/bop-hook known{
SI restore userdict/eop-hook known{eop-hook}if showpage}N/@start{
userdict/start-hook known{start-hook}if pop/VResolution X/Resolution X
userdict /end-hook known{end-hook}if
Both are in the section beginning /TeXDict.
In which case, trying to use dvips -E to generate an eps file seems
doomed to failure. Perhaps I have misunderstood the restrictions on 
using statusdict and userdict - if they are really a problem, then what 
is the point of dvips -E?
Chris