matplotlib-devel Mailing List for matplotlib (Page 3)

Hey, and is there any sort of matplotlib market place where I could
put the file for general bashing/downloading once it can do more than
a sin-plot?
--Nico

> matplotlib. And I'm afraid that your translator will not do much more
> than converting very simple plots.
Although Pgfplots can also do ~somewhat~ fancy stuff, I think you're
definitely right on that one. When I look at the matplotlib gallery,
I'm getting dizzy.
For everyday purposes, though, I'm rather interested in somewhat
simple plots: 2D graphs, maybe an image plot, something like that.
I'll see how far I get with that..
Thanks very much for your guys' advice!
Cheers,
Nico

On Tue, Jan 12, 2010 at 5:14 PM, Nico Schlömer <nic...@gm...> wrote:
> I attached a PDF with two figures, one PDF generated and one TikZ
> (generated using my little script). There's clearly a difference in
> how seamless the two figures embed into the document, but I might not
> be using the PDF backend appropriately. Any hints on how I could get
> the fonts in place to allow for a fairer comparison?
>
Matplotlib determines the font properties when the output file is created.
But, TikZ (at least the way how your translator works) lets those
information determined when latex is run.
No doubt that TikZ result is much better than the matplotlib backends,
but that is because TikZ and maplotlib works differently. While TikZ
results looks better, this will greatly limit the functionality of
matplotlib. And I'm afraid that your translator will not do much more
than converting very simple plots.
Anyhow, good luck with your project!
Regards,
-JJ

> The only real difference I see is font size.
And the font family, and the color.
The advantage that I see with TikZ is that the font is *exactly* the
font used in the surrounding text, no matter the scaling of the axes.
A major reason for me to use TikZ was actually that I can rescale my
figures later, without having to regenerate the plots anew, tinkering
with font sizes to make them ~sort of~ match. (Also, one can use LaTeX
colors in the plots, e.g. (as in my case), corporate colors as defined
in the presentation template.)
Cheers,
Nico

Nico Schlömer wrote:
> I attached a PDF with two figures, one PDF generated and one TikZ
> (generated using my little script). There's clearly a difference in
> how seamless the two figures embed into the document
The only real difference I see is font size. I"d play with that, and 
also play with how you scale the image when you embed it in TeX.
I know when I was putting a bunch of Matlab figures into a big LaTeX doc 
(years ago) , I got the best results by drawing the figures one size, 
then scaling them to fit the LaTeX doc (scaled to \texwidth, or 
something like that).
Also psfrag is great, though I haven't found a pdffrag -- is there one?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi,
I've started something for a translator, see
http://win.ua.ac.be/~nschloe/other/websvn/filedetails.php?repname=matplotlib2tikz&path=%2Ftrunk%2Fmatplotlib2tikz.py&templatechoice=Elegant
It's my first time with Python, so there'll probably a lot of things
that you don't do (tm); hints very much appreciated!
> In my opinion, there is no reason that matplotlib can make user 100%
> happy, because matplotlib itself actually runs tex/latex in usetex
> mode. If TikZ can do that, I believe matplotlib also can do.
I attached a PDF with two figures, one PDF generated and one TikZ
(generated using my little script). There's clearly a difference in
how seamless the two figures embed into the document, but I might not
be using the PDF backend appropriately. Any hints on how I could get
the fonts in place to allow for a fairer comparison?
Cheers,
Nico

On Mon, Jan 11, 2010 at 11:53 AM, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Mon, Jan 11, 2010 at 11:09 AM, Pierre Raybaut <co...@py...>
> wrote:
>>
>> John,
>>
>> Following to your last commit on "added qt4_editor dialog" (rev 8064),
>> here is a significant (but simple) improvement adding an "Apply"
>> button to the option dialog box (very convenient) -- suggested by
>> Gökhan.
>>
>> (attached diff files should patch formlayout.py and figureoptions.py
>> as in rev. 8064)
>
> One minor update:
>
> After patching these two files, just change the 'options.svg' in
> figureoptions.py to "qt4_editor_options.svg" to suppress the icon not found
> error message.
Hey Gökhan, if you could just create an "svn diff" with the original
patches applied and your changes it will be easiest for me to apply
that way.
JDH

Good point. Fixed in r8076.
Cheers,
Mike
tcb wrote:
> Hi Mike,
>
> Sorry the long delay in replying to your mail.
>
> The changes look good, and it seems to produce good output.
>
> There is just one small change I would make- since the markers are not 
> quite properly centered on the points:
>
> Index: lib/matplotlib/lines.py
> ===================================================================
> --- lib/matplotlib/lines.py (revision 8075)
> +++ lib/matplotlib/lines.py (working copy)
> @@ -898,7 +898,7 @@
> height = ymax - ymin
> max_dim = max(width, height)
> path_trans = Affine2D() \
> - .translate(0.5 * -width, 0.5 * -height) \
> + .translate(-xmin+0.5 * -width, -ymin+0.5 * -height)\
> .scale((renderer.points_to_pixels(self.get_markersize()) 
> / max_dim))
>
>
>
> On Tue, Dec 22, 2009 at 4:44 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> It's been a while -- just curious if you've had any more thoughts
> on this. I'm considering committing your changes + my
> suggestions, since what's there is working pretty well.
>
> Mike
>
> tcb wrote:
>
>
>
> On Mon, Nov 2, 2009 at 3:47 PM, Michael Droettboom
> <md...@st... <mailto:md...@st...>
> <mailto:md...@st... <mailto:md...@st...>>> wrote:
>
> Thanks for all this work. It looks great.
>
> Do you mind if we bring this conversation back to the list? I
> think others may have some additional feedback, but I don't
> want
> to Cc the list without your permission.
>
>
>
>
>
> Hi Mike,
>
> sure- the discussion should go back to the list- I thought it
> might be better to get your feedback on it first.
>
> your comments are interesting, and I'll take a closer look
> later on today...
>
> tcb
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi Mike,
Sorry the long delay in replying to your mail.
The changes look good, and it seems to produce good output.
There is just one small change I would make- since the markers are not quite
properly centered on the points:
Index: lib/matplotlib/lines.py
===================================================================
--- lib/matplotlib/lines.py (revision 8075)
+++ lib/matplotlib/lines.py (working copy)
@@ -898,7 +898,7 @@
 height = ymax - ymin
 max_dim = max(width, height)
 path_trans = Affine2D() \
- .translate(0.5 * -width, 0.5 * -height) \
+ .translate(-xmin+0.5 * -width, -ymin+0.5 * -height)\
 .scale((renderer.points_to_pixels(self.get_markersize()) /
max_dim))
On Tue, Dec 22, 2009 at 4:44 PM, Michael Droettboom <md...@st...> wrote:
> It's been a while -- just curious if you've had any more thoughts on this.
> I'm considering committing your changes + my suggestions, since what's
> there is working pretty well.
>
> Mike
>
> tcb wrote:
>
>
>>
>> On Mon, Nov 2, 2009 at 3:47 PM, Michael Droettboom <md...@st...<mailto:
>> md...@st...>> wrote:
>>
>> Thanks for all this work. It looks great.
>>
>> Do you mind if we bring this conversation back to the list? I
>> think others may have some additional feedback, but I don't want
>> to Cc the list without your permission.
>>
>>
>>
>>
>>
>> Hi Mike,
>>
>> sure- the discussion should go back to the list- I thought it might be
>> better to get your feedback on it first.
>>
>> your comments are interesting, and I'll take a closer look later on
>> today...
>>
>> tcb
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

On Mon, Jan 11, 2010 at 11:09 AM, Pierre Raybaut <co...@py...>wrote:
> John,
>
> Following to your last commit on "added qt4_editor dialog" (rev 8064),
> here is a significant (but simple) improvement adding an "Apply"
> button to the option dialog box (very convenient) -- suggested by
> Gökhan.
>
> (attached diff files should patch formlayout.py and figureoptions.py
> as in rev. 8064)
>
One minor update:
After patching these two files, just change the 'options.svg' in
figureoptions.py to "qt4_editor_options.svg" to suppress the icon not found
error message.
>
> Thanks,
> Pierre
>
> 2010年1月3日 John Hunter <jd...@gm...>:
> > On Sun, Jan 3, 2010 at 2:41 PM, Gökhan Sever <gok...@gm...>
> wrote:
> >> You seemed like forgetting to check-in the qt4_editor_options.svg,
> because I
> >> get file not found error:
> >>
> >> I[2]: Cannot open file
> >> '.../matplotlib/lib/matplotlib/mpl-data/images/qt4_editor_options.svg',
> >> because: No such file or directory
> >
> >
> > Oops, just added. Thanks for the head's up.
> >
> > JDH
> >
>
-- 
Gökhan

John,
Following to your last commit on "added qt4_editor dialog" (rev 8064),
here is a significant (but simple) improvement adding an "Apply"
button to the option dialog box (very convenient) -- suggested by
Gökhan.
(attached diff files should patch formlayout.py and figureoptions.py
as in rev. 8064)
Thanks,
Pierre
2010年1月3日 John Hunter <jd...@gm...>:
> On Sun, Jan 3, 2010 at 2:41 PM, Gökhan Sever <gok...@gm...> wrote:
>> You seemed like forgetting to check-in the qt4_editor_options.svg, because I
>> get file not found error:
>>
>> I[2]: Cannot open file
>> '.../matplotlib/lib/matplotlib/mpl-data/images/qt4_editor_options.svg',
>> because: No such file or directory
>
>
> Oops, just added. Thanks for the head's up.
>
> JDH
>

Hi Claus,
I fixed the non-Textmate issues (i.e. everything before the P.S. in my original email), but the TextMate issue remains.
I've had a friend confirm this issue (i.e. hanging on plot calls when scripts are run in Textmate) on his system, and it sounds like you're confirming the issue as well. 
I keep meaning to write to the TextMate list, but haven't yet done so. Let me know if you have any luck with this issue.
Best,
-Tony
On Jan 7, 2010, at 10:02 AM, Claus13 wrote:
> 
> Hi Tony,
> 
> have you solved this issue?
> What was the problem?
> 
> I just installed the ScipySuperpack
> http://macinscience.org/?page_id=6
> on a clean OSX 10.6 machine
> 
> running
> http://matplotlib.sourceforge.net/plot_directive/mpl_examples/pylab_examples/date_demo_rrule.py
> for example from the command line works awesome, but not from TextMate.
> 
> This sounds like the same problem you had..
> I'd appreciate any pointers!
> 
> Cheers,
> Claus
> 
> 
> 
> 
> 
> 
> Tony Yu-3 wrote:
>> 
>> I updated to the newest release of OS X---10.6.2---last night and I've
>> been getting a weird windowing error for certain backends. 
>> 
>> I'm able to reproduce the error with the following: run a simple plot
>> script (which calls plt.show) from the terminal. Close the figure. The
>> problem is:
>> 
>> * tkagg: window closes, but it doesn't return control to the terminal
>> (i.e. terminal hangs).
>> * macosx: axis is cleared from the figure window, but the window (w/o
>> axis) remains and terminal hangs.
>> * qt4agg: works fine.
>> 
>> Alternatively, I can run the script from ipython. In this case, tkagg and
>> qt4agg work as normal. The macosx backend hangs, the window does not
>> close, and control is not returned to ipython.
>> 
>> In all cases, the plot shows up fine (it just doesn't always close
>> properly). Running the script with python -vv doesn't help: All the debug
>> code it prints stops before plt.show is called. I wish I could provide
>> more debug output, but I'm not sure how.
>> 
>> Any ideas?
>> 
>> -Tony
>> 
>> PS. To add another piece to the mystery, I've been having problems running
>> plot scripts from my text editor (Textmate): python hangs **before**
>> plotting. I've traced the hang to a call to
>> matplotlib.backends.pylab_setup.new_figure_manager, but I really don't
>> understand where exactly hangs. Again: this only happens when running from
>> Textmate, and started happening about a week ago (following a Textmate
>> update). My guess is that this is a Textmate-related issue, but I thought
>> I'd mention it in case these two issues combined suggest a more
>> fundamental problem with my python install.
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing. 
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
> 
> -- 
> View this message in context: http://old.nabble.com/Weird-windowing-issues-since-last-update-of-OS-X-10.6-tp26658846p27061342.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Matplotlib, by design, needs to know the exact dimension (height,
width and descent) of texts that the backend will produce (before the
output is produced), and I wonder if that's going to be possible with
TikZ.
Unless you can solve this problem, I don't think tikz backend will be feasible.
Some form of simple translator like "matplotlib2tikz(myFigure)" should
certainly be possible. But things like legends and annotations will be
very tricky, if not impossible.
In my opinion, there is no reason that matplotlib can make user 100%
happy, because matplotlib itself actually runs tex/latex in usetex
mode. If TikZ can do that, I believe matplotlib also can do. If you're
not 100% happy with the output, please report why it is so. If you're
using matplotlib with usetex mode, and somehow the fonts does not
match with other texts in your document, it only means that there is a
room for improvement in matplotlib. At least to me.
Regards,
-JJ

> That sounds more feasible -- however, keep in mind that anything without a
> public interface (a get_* method) is free to change in a future version of
> matplotlib. I suspect (though haven't thought it all the way through) that
> you may be required to dig into private members to get everything you need.
That may be possible, particularly I suppose for the actual plot data
(x, y(, z) values). I'm going to have to look into what
matplotlib.get* can offer me. Is there a list with all the methods
available?
> I also suspect that this will be a lot of work to support all of the kinds
> of plots that matplotlib supports, and problems are likely to arise when the
> semantics of Pgfplot and/or TikZ don't mesh well. For example, does Pgf
> plot support the same set of nonlinear transformations as matplotlib?
matplotlib and Pgfplots certainly have a different feature set, but
for a couple of common simple plots (e.g., 2D x, y data, log-scaled
axes, lines, markers, and so forth) it should be possible to write a
very basic extendible translator.
> Other people have suggested TikZ support in the past, and I, personally,
> haven't been very convinced of the usefulness of such a thing.
Well, yeah, I guess it is possible to export PDF files in such a way
that it looks sort of nice if you watch out what you do with the font
sizes, and font family in general. Over the years I've become somewhat
tired of that whole tinkering with the fonts, and eventually I'd be
about 80% happy with the result I got. If you don't want to do that
every time, and you want 100%, TikZ/Pgfplots can come in quite handy;
especially if a simple module can be written rather quickly. If you
have a simple 2D plot and you would like to get it cleanly into your
LaTeX file, why not use TikZ if it's available?
Cheers,
Nico

Nico Schlömer wrote:
> Hi,
>
> I'm looking into replacing my MATLAB(R) plotting routines by something
> slicker, and quite naturally found matplotlib. It has all the
> capabilities that I would need, except that I can't yet transform my
> plots into TikZ.
> For MATLAB(R), I used this rather elaborate script
> <http://win.ua.ac.be/~nschloe/content/matlab2tikz>.
>
> Well, I thought I can just go ahead and start writing and equivalent
> backend; the documentation is really nice and clear (quite unlike
> MATLAB's!) so it was no big problem to get into the concepts of the
> backend. I played around a little and thought about how I could
> implement this and that, and some questions arose which can maybe best
> answered here.
>
> For the sake of clarity, let me just give a snippet of Pgfplots (TikZ)
> code that I would like the backend to produce
>
> ===================== *snip* =====================
> [...]
> \begin{semilogyaxis}
> [axis on top,
> xtick={2,4,6,8,10,12,14,16},
> ytick={1e-15,1e-10,1e-05,1,100000},
> xmin=0.000000e+00,xmax=1.700000e+01,
> ymin=1.000000e-15,ymax=1.000000e+05,
> xmajorgrids,
> ymajorgrids,
> title={$\norm{F(\psi)}_2$},
> xlabel={$k$},
> width=\figurewidth,
> height=\figureheight,
> scale only axis
> ]
> % Line plot
> \addplot [color=red,only marks,mark=*,mark options={solid,fill=red}]
> coordinates{
> (1.000000e+00,3.206000e+01) (2.000000e+00,3.860000e+01)
> (3.000000e+00,1.421000e+03) (4.000000e+00,4.143000e+02)
> (5.000000e+00,1.445000e+02) (6.000000e+00,3.775000e+01)
> (7.000000e+00,7.455000e+00) (8.000000e+00,7.228000e-01)
> (9.000000e+00,2.275000e-02) (1.000000e+01,4.953000e-05)
> (1.100000e+01,9.718000e-10) (1.200000e+01,5.534000e-07)
> (1.300000e+01,4.217000e-11) (1.400000e+01,3.930000e-03)
> (1.500000e+01,2.067000e-07) (1.600000e+01,7.231000e-12)
> };
> \end{semilogyaxis}
> [...]
> ===================== *snap* =====================
>
> This yields a purely marker plot (without lines) on a coordinate
> system where the y-coordinate is log-scaled. You see that the code is
> rather semantic and can easily be edited (which is think is the whole
> point of Pgfplots as opposed to pure TikZ).
>
> Now, if for a matplotlib plot I had query functions for the the axes
> ranges, ticks, grids, titles, data values, and so on and so forth, it
> would be a more or less complicated parsing of those and creating what
> we see above.
>
> However, it seems to me that the concept of backends is different.
> draw_path() would be called to plot the graph itself, the coordinate
> axes, and basically everything that resembles a line, giving its
> outline (color, shape, markers, start and end points) but *no*
> semantic information, that is, whether the path is part of an axis, an
> arrow or whatever.
> Is that correct?
> 
Yes -- the backend interface is designed for "dumber" output formats 
that don't know anything about the semantics of plots -- PDF, PS, SVG 
etc. are basically "draw a line here, put some text there" sorts of 
things. Of course, you could probably write a TikZ backend without much 
semantic detail fairly easily.
> Considering this, what do matplotlob masterbrains :) think would be a
> good way to extract Pgfplots code out of a matplotlib figure? Is a
> backend feasible at all? Would a function as "matplotlib2tikz(
> myFigure )" be more advisable, making use of all sorts of query
> functions? (Such as myFigure.axes.get_xlim() -- Does something like
> that exist at all?)
> 
That sounds more feasible -- however, keep in mind that anything without 
a public interface (a get_* method) is free to change in a future 
version of matplotlib. I suspect (though haven't thought it all the way 
through) that you may be required to dig into private members to get 
everything you need. I also suspect that this will be a lot of work to 
support all of the kinds of plots that matplotlib supports, and problems 
are likely to arise when the semantics of Pgfplot and/or TikZ don't mesh 
well. For example, does Pgf plot support the same set of nonlinear 
transformations as matplotlib?
Other people have suggested TikZ support in the past, and I, personally, 
haven't been very convinced of the usefulness of such a thing. It's 
just as easy to include a PDF or EPS in LaTeX, and the mathtext and/or 
usetex functionality goes a long way to making the plots blend in nicely 
-- though it does take some care to control the size of the plots to 
make the font sizes match, it's by no means impossible. Jae-Joon's work 
with fancy arrow styles brings in a lot of the finesse features of TikZ 
to matplotlib. What do you see as the use cases for a TikZ backend?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I'm looking into replacing my MATLAB(R) plotting routines by something
slicker, and quite naturally found matplotlib. It has all the
capabilities that I would need, except that I can't yet transform my
plots into TikZ.
For MATLAB(R), I used this rather elaborate script
<http://win.ua.ac.be/~nschloe/content/matlab2tikz>.
Well, I thought I can just go ahead and start writing and equivalent
backend; the documentation is really nice and clear (quite unlike
MATLAB's!) so it was no big problem to get into the concepts of the
backend. I played around a little and thought about how I could
implement this and that, and some questions arose which can maybe best
answered here.
For the sake of clarity, let me just give a snippet of Pgfplots (TikZ)
code that I would like the backend to produce
===================== *snip* =====================
[...]
\begin{semilogyaxis}
[axis on top,
xtick={2,4,6,8,10,12,14,16},
ytick={1e-15,1e-10,1e-05,1,100000},
xmin=0.000000e+00,xmax=1.700000e+01,
ymin=1.000000e-15,ymax=1.000000e+05,
xmajorgrids,
ymajorgrids,
title={$\norm{F(\psi)}_2$},
xlabel={$k$},
width=\figurewidth,
height=\figureheight,
scale only axis
]
% Line plot
\addplot [color=red,only marks,mark=*,mark options={solid,fill=red}]
coordinates{
 (1.000000e+00,3.206000e+01) (2.000000e+00,3.860000e+01)
(3.000000e+00,1.421000e+03) (4.000000e+00,4.143000e+02)
(5.000000e+00,1.445000e+02) (6.000000e+00,3.775000e+01)
(7.000000e+00,7.455000e+00) (8.000000e+00,7.228000e-01)
(9.000000e+00,2.275000e-02) (1.000000e+01,4.953000e-05)
(1.100000e+01,9.718000e-10) (1.200000e+01,5.534000e-07)
(1.300000e+01,4.217000e-11) (1.400000e+01,3.930000e-03)
(1.500000e+01,2.067000e-07) (1.600000e+01,7.231000e-12)
};
\end{semilogyaxis}
[...]
===================== *snap* =====================
This yields a purely marker plot (without lines) on a coordinate
system where the y-coordinate is log-scaled. You see that the code is
rather semantic and can easily be edited (which is think is the whole
point of Pgfplots as opposed to pure TikZ).
Now, if for a matplotlib plot I had query functions for the the axes
ranges, ticks, grids, titles, data values, and so on and so forth, it
would be a more or less complicated parsing of those and creating what
we see above.
However, it seems to me that the concept of backends is different.
draw_path() would be called to plot the graph itself, the coordinate
axes, and basically everything that resembles a line, giving its
outline (color, shape, markers, start and end points) but *no*
semantic information, that is, whether the path is part of an axis, an
arrow or whatever.
Is that correct?
Considering this, what do matplotlob masterbrains :) think would be a
good way to extract Pgfplots code out of a matplotlib figure? Is a
backend feasible at all? Would a function as "matplotlib2tikz(
myFigure )" be more advisable, making use of all sorts of query
functions? (Such as myFigure.axes.get_xlim() -- Does something like
that exist at all?)
Cheers,
Nico

Hi Tony,
have you solved this issue?
What was the problem?
I just installed the ScipySuperpack
http://macinscience.org/?page_id=6
on a clean OSX 10.6 machine
running
http://matplotlib.sourceforge.net/plot_directive/mpl_examples/pylab_examples/date_demo_rrule.py
for example from the command line works awesome, but not from TextMate.
This sounds like the same problem you had..
I'd appreciate any pointers!
Cheers,
Claus
Tony Yu-3 wrote:
> 
> I updated to the newest release of OS X---10.6.2---last night and I've
> been getting a weird windowing error for certain backends. 
> 
> I'm able to reproduce the error with the following: run a simple plot
> script (which calls plt.show) from the terminal. Close the figure. The
> problem is:
> 
> * tkagg: window closes, but it doesn't return control to the terminal
> (i.e. terminal hangs).
> * macosx: axis is cleared from the figure window, but the window (w/o
> axis) remains and terminal hangs.
> * qt4agg: works fine.
> 
> Alternatively, I can run the script from ipython. In this case, tkagg and
> qt4agg work as normal. The macosx backend hangs, the window does not
> close, and control is not returned to ipython.
> 
> In all cases, the plot shows up fine (it just doesn't always close
> properly). Running the script with python -vv doesn't help: All the debug
> code it prints stops before plt.show is called. I wish I could provide
> more debug output, but I'm not sure how.
> 
> Any ideas?
> 
> -Tony
> 
> PS. To add another piece to the mystery, I've been having problems running
> plot scripts from my text editor (Textmate): python hangs **before**
> plotting. I've traced the hang to a call to
> matplotlib.backends.pylab_setup.new_figure_manager, but I really don't
> understand where exactly hangs. Again: this only happens when running from
> Textmate, and started happening about a week ago (following a Textmate
> update). My guess is that this is a Textmate-related issue, but I thought
> I'd mention it in case these two issues combined suggest a more
> fundamental problem with my python install.
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://old.nabble.com/Weird-windowing-issues-since-last-update-of-OS-X-10.6-tp26658846p27061342.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi,
how about adding a special minor locator class like this simple one?
class AutoDateMinorLocator(AutoDateLocator):
    """An extension to the
:class:`~matplotlib.dates.AutoDateLocator` for minor locators"""
    def viewlim_to_dt(self):
        major_ticks = self.axis.get_majorticklocs()[:2]
        print num2date(major_ticks[0], self.tz),
num2date(major_ticks[-1], self.tz)
        return num2date(major_ticks[0], self.tz),
num2date(major_ticks[-1], self.tz)
    def datalim_to_dt(self):
        return self.get_view_interval()
Maybe a better implementation should exclude minor locations where
major locations are defined.
--
Stephane Raynaud

Michael Droettboom wrote:
> Cleaning the docs first seems to have fixed it.
>
> Is there a way to download the build products (i.e. the PDF file 
> produced)?
That, and testing for doc build failures, is the point, although I 
managed to screw up the uploading until now. However, I believe I have 
fixed this and we should now have auto-built docs from svn trunk at:
http://matplotlib.sourceforge.net/trunk-docs
http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf
Perhaps we should link these from somewhere. And the URLs can certainly 
be changed without much difficulty.
Thanks for finding the clean step issue -- I thought the buildbot 
software automatically cleaned the working directory on every build, but 
obviously I thought wrong.
-Andrew

Cleaning the docs first seems to have fixed it.
Is there a way to download the build products (i.e. the PDF file produced)?
Mike
Michael Droettboom wrote:
> Hmm... I can't reproduce this locally. But it looks like it's using 
> doctree files cached from a previous run.
>
> I'll try calling "python make.py clean" before "python make.py all" in 
> the _buildbot_doc.sh (at least temporarily), to try to get a complete 
> build log which might offer more clues.
>
> Mike
>
> Andrew Straw wrote:
> 
>> Hi,
>>
>> With the recent regression fixed in Pygments, the doc auto-builder is
>> closer to completing successfully. However, there's a new bug. The build
>> ends with:
>>
>> LaTeX Warning: File `/home/mpl-chslave/slave-py25/build_docs/build/doc/build/pl
>> ot_directive/mpl_examples/pylab_examples/barb_demo.pdf' not found on input line
>> 28650.
>>
>>
>> !pdfTeX error: pdflatex (file /home/mpl-chslave/slave-py25/build_docs/build/doc
>> /build/plot_directive/mpl_examples/pylab_examples/barb_demo.pdf): cannot find i
>> mage file
>> ==> Fatal error occurred, no output PDF file produced!
>>
>>
>> Anyone have a clue what is going on here?
>>
>> Feel free to check in the attempted solution and the buildbot will
>> automatically try it. (See the "
>> <http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64>Ubuntu
>> 8.04, Python 2.5, amd64 (docs)" column at
>> http://mpl-buildbot.code.astraw.com/waterfall )
>>
>> Waiting for this will take up to 20 minutes before the build is
>> triggered (10 minute polling on the svn repo, and a 10 minute timeout
>> before any build is started in case another commit comes in). So you can
>> also force a build by clicking the column title ("Ubuntu 8.04, Python
>> 2.5, amd64 (docs)" and then clicking the "Force Build" button.
>>
>> It will be great to get the buildbot automatically building the svn docs
>> successfully.
>>
>> -Andrew
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev 
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hmm... I can't reproduce this locally. But it looks like it's using 
doctree files cached from a previous run.
I'll try calling "python make.py clean" before "python make.py all" in 
the _buildbot_doc.sh (at least temporarily), to try to get a complete 
build log which might offer more clues.
Mike
Andrew Straw wrote:
> Hi,
>
> With the recent regression fixed in Pygments, the doc auto-builder is
> closer to completing successfully. However, there's a new bug. The build
> ends with:
>
> LaTeX Warning: File `/home/mpl-chslave/slave-py25/build_docs/build/doc/build/pl
> ot_directive/mpl_examples/pylab_examples/barb_demo.pdf' not found on input line
> 28650.
>
>
> !pdfTeX error: pdflatex (file /home/mpl-chslave/slave-py25/build_docs/build/doc
> /build/plot_directive/mpl_examples/pylab_examples/barb_demo.pdf): cannot find i
> mage file
> ==> Fatal error occurred, no output PDF file produced!
>
>
> Anyone have a clue what is going on here?
>
> Feel free to check in the attempted solution and the buildbot will
> automatically try it. (See the "
> <http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64>Ubuntu
> 8.04, Python 2.5, amd64 (docs)" column at
> http://mpl-buildbot.code.astraw.com/waterfall )
>
> Waiting for this will take up to 20 minutes before the build is
> triggered (10 minute polling on the svn repo, and a 10 minute timeout
> before any build is started in case another commit comes in). So you can
> also force a build by clicking the column title ("Ubuntu 8.04, Python
> 2.5, amd64 (docs)" and then clicking the "Force Build" button.
>
> It will be great to get the buildbot automatically building the svn docs
> successfully.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> John Hunter wrote:
> 
>> On Sat, Jan 2, 2010 at 12:34 AM, Eric Firing <ef...@ha...> wrote:
>> 
>>> Jae-Joon Lee wrote:
>>> 
>>>> Maybe we need something like "python make.py clean"?
>>>> 
It already does have "clean", but from the looks of it, it is currently 
broken (I just fixed this in SVN). It used to call out to svn-clean, 
but it was pointed out that only works if you're building from SVN, not 
from a tarball (which is a problem for the Linux distros). So there is 
explicit code in make.py to delete all of the generated files.
> Do you know why the plot directive (I assume that is the cause of the 
> problem) cannot put all generated output in build? Or is this a more 
> general Sphinx wart?
> 
The problem is not in the plot_directive (though I suppose it could be 
more helpful when the file isn't found) -- it does in fact put 
everything under build. The problem is in gen_rst.py, which generates 
pages for all of the examples, and puts them in doc/examples. At the 
time, it wasn't clear how to generate these pages under the build tree 
and then have Sphinx pick them up. That may have predated all of the 
"hooks" that Sphinx now has, however, and it may now be possible to 
solve that problem.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Jan 4, 2010 at 5:48 PM, Dag Sverre Seljebotn
<da...@st...> wrote:
>
> Rolling this into the Python package distribution scheme seems backwards
> though, since a lot of binary packages that have nothing to do with Python
> are used as well
Yep, exactly.
>
> To solve the exact problem you (and me) have I think the best solution is
> to integrate the tools mentioned above with what David is planning (SciPI
> etc.). Or if that isn't good enough, find generic "userland package
> manager" that has nothing to do with Python (I'm sure a dozen
> half-finished ones must have been written but didn't look), finish it, and
> connect it to SciPI.
You have 0install, autopackage and klik, to cite the ones I know
about. I wish people had looked at those before rolling toy solutions
to complex problems.
>
> What David does (I think) is seperate the concerns.
Exactly - you've describe this better than I did
David

Nathaniel Smith <nj...@po...> wrote:
> On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau <cou...@gm...>
> wrote:
>> Another way is to provide our own repository for a few major
>> distributions, with automatically built packages. This is how most
>> open source providers work. Miguel de Icaza explains this well:
>>
>> http://tirania.org/blog/archive/2007/Jan-26.html
>>
>> I hope we will be able to reuse much of the opensuse build service
>> infrastructure.
>
> Sure, I'm aware of the opensuse build service, have built third-party
> packages for my projects, etc. It's a good attempt, but also has a lot
> of problems, and when talking about scientific software it's totally
> useless to me :-). First, I don't have root on our compute cluster.
I use Sage for this very reason, and others use EPD or FEMHub or
Python(x,y) for the same reasons.
Rolling this into the Python package distribution scheme seems backwards
though, since a lot of binary packages that have nothing to do with Python
are used as well -- the Python stuff is simply thin wrappers around what
should ideally be located in /usr/lib or similar (but are nowadays
compiled into the Python extension .so because of distribution problems).
To solve the exact problem you (and me) have I think the best solution is
to integrate the tools mentioned above with what David is planning (SciPI
etc.). Or if that isn't good enough, find generic "userland package
manager" that has nothing to do with Python (I'm sure a dozen
half-finished ones must have been written but didn't look), finish it, and
connect it to SciPI.
What David does (I think) is seperate the concerns. This makes the task
feasible, and also has the advantage of convenience for the people that
*do* want to use Ubuntu, Red Hat or whatever to roll out scientific
software on hundreds of clients.
Dag Sverre

On Mon, Jan 4, 2010 at 8:42 AM, Nathaniel Smith <nj...@po...> wrote:
> On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau <cou...@gm...> wrote:
>> On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith <nj...@po...> wrote:
>>> What I do -- and documented for people in my lab to do -- is set up
>>> one virtualenv in my user account, and use it as my default python. (I
>>> 'activate' it from my login scripts.) The advantage of this is that
>>> easy_install (or pip) just works, without any hassle about permissions
>>> etc.
>>
>> It just works if you happen to be able to build everything from
>> sources. That alone means you ignore the majority of users I intend to
>> target.
>>
>> No other community (except maybe Ruby) push those isolated install
>> solutions as a general deployment solutions. If it were such a great
>> idea, other people would have picked up those solutions.
>
> AFAICT, R works more-or-less identically (once I convinced it to use a
> per-user library directory); install.packages() builds from source,
> and doesn't automatically pull in and build random C library
> dependencies.
As mentioned by Robert, this is different from the usual virtualenv
approach. Per-user app installation is certainly a useful (and
uncontroversial) feature.
And R does support automatically-built binary installers.
>
> Sure, I'm aware of the opensuse build service, have built third-party
> packages for my projects, etc. It's a good attempt, but also has a lot
> of problems, and when talking about scientific software it's totally
> useless to me :-). First, I don't have root on our compute cluster.
True, non-root install is a problem. Nothing *prevents* dpkg to run in
non root environment in principle if the packages itself does not
require it, but it is not really supported by the tools ATM.
> Second, even if I did I'd be very leery about installing third-party
> packages because there is no guarantee that the version numbering will
> be consistent between the third-party repo and the real distro repo --
> suppose that the distro packages 0.1, then the third party packages
> 0.2, then the distro packages 0.3, will upgrades be seamless? What if
> the third party screws up the version numbering at some point? Debian
> has "epochs" to deal with this, but third-parties can't use them and
> maintain compatibility.
Actually, at least with .deb-based distributions, this issue has a
solution. As packages has their own version in addition to the
upstream version, PPA-built packages have their own versions.
https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
Of course, this assumes a simple versioning scheme in the first place,
instead of the cluster-fck that versioning has became within python
packages (again, the scheme used in python is much more complicated
than everyone else, and it seems that nobody has ever stopped and
thought 5 minutes about the consequences, and whether this complexity
was a good idea in the first place).
> What if the person making the third party
> packages is not an expert on these random distros that they don't even
> use?
I think simple rules/conventions + build farms would solve most
issues. The problem is if you allow total flexibility as input, then
automatic and simple solutions become impossible. Certainly, PPA and
the build service provides for a much better experience than anything
pypi has ever given to me.
> Third, while we shouldn't advocate that people screw up backwards
> compatibility, version skew is a real issue. If I need one version of
> a package and my lab-mate needs another and we have submissions due
> tomorrow, then filing bugs is a great idea but not a solution.
Nothing prevents you from using virtualenv in that case (I may sound
dismissive of those tools, but I am really not. I use them myselves.
What I strongly react to is when those are pushed as the de-facto,
standard method).
> Fourth,
> even if we had expert maintainers taking care of all these third-party
> packages and all my concerns were answered, I couldn't convince our
> sysadmin of that; he's the one who'd have to clean up if something
> went wrong we don't have a big budget for overtime.
I am not advocating using only packaged, binary installers. I am
advocating using them as much as possible where it makes sense - on
windows and mac os x in particular.
Toydist also aims at making it easier to build, customize installs.
Although not yet implemented, --user-like scheme would be quite simple
to implement, because toydist installer internally uses autoconf-like
directories description (of which --user is a special case).
If you need sandboxed installs, customized installs, toydist will not
prevent it. It is certainly my intention to make it possible to use
virtualenv and co (you already can by building eggs, actually). I hope
that by having our own "SciPi", we can actually have a more reliable
approach. For example, the static dependency description + mandated
metadata would make this much easier and more robust, as there would
not be a need to run a setup.py to get the dependencies.
If you look at hackageDB
(http://hackage.haskell.org/packages/hackage.html), they have a very
simple index structure, which makes it easy to download it entirely,
and reuse this locally to avoid any internet access.
> Let's be honest -- scientists, on the whole, suck at IT
> infrastructure, and small individual packages are not going to be very
> expertly put together. IMHO any real solution should take this into
> account, keep them sandboxed from the rest of the system, and focus on
> providing the most friendly and seamless sandbox possible.
I agree packages will not always be well put together - but I don't
see why this would be worse than the current situation. I also
strongly disagree about the sandboxing as the solution of choice. For
most users, having only one install of most packages is the typical
use-case. Once you start sandboxing, you create artificial barriers
between the sandboxes, and this becomes too complicated for most users
IMHO.
>
> Maybe I was unclear -- proper build directory handling is nice,
> Cython/Pyrex's distutils integration get it wrong (not their fault,
> distutils is just impossible to do anything sensible with, as you've
> said), and I've never found build directories hard to implement
It is simple if you have a good infrastructure in place (node
abstraction, etc...), but that infrastructure is hard to get right.
> But what I'm really talking about is
> having a "pre-build" step that integrates properly with the source and
> binary packaging stages, and that's not something waf or scons have
> any particular support for, AFAIK.
Could you explain with a concrete example what a pre-build stage would
look like ? I don't think I understand what you want,
cheers,
David