+1
Best,
-Michiel
On Wed, 1/21/15, Michael Droettboom wrote:
Subject: [Matplotlib-users] Matplotlib and Numfocus Fiscal Sponsorship
Agreement (FSA)
To: "matplotlib-devel@lists.sourceforge.net"
, "matplotlib-users"
Date: Wednesday, January 21,
s discussion of getting Michiel de Hoon on
today (which I
just saw, unfortunately). Is there another time in the
future that
works for you, Michiel?
Mike
--
_
|\/|o _|_ _. _ | | \.__ __|__|_|_ _
_ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(
The crash occurs in the call to get_text_width_height_descent(self, s, prop,
ismath) due to the fact that
family = prop.get_family() previously returned a list of strings, while now it
returns a list of unicode strings. The backend then fails to find the font, and
crashes over a NULL pointer. I
Hi all,
Cocoaagg could solve a lot of problems, but it depends on whether pyojbc is
being actively maintained. I seem to remember that that was not always the case
in the past. If we do decide pyobjc, we may consider a agg-free backend that
does not require any compilation.
Best,
-Michiel.
Hi all,
Don't get me wrong, I am not thrilled with the macosx backend,
especially that can't-draw-outside-the-event-loop issue,...
I don't think this is a disadvantage: The macosx backend just enforces a
cleaner coding style. The other backends are more forgi
Hi all,
At the time when the Mac OS X backend was first introduced, its performance was
significantly better than other backends, but this was due to the way its event
loop is organized. Nowadays the other backends use the same event loop
organization, and as far as I know currently there is no
Macbook.
Best,
-Michiel.
From: Michael Droettboom
To: Michiel de Hoon
Cc: Benjamin Root ; "matplotlib-devel@lists.sourceforge.net"
Sent: Wednesday, July 24, 2013 10:36 PM
Subject: Re: [matplotlib-devel] 1.3.0rc5 tagged
Thanks. I will address these issues before fina
I noticed that this release candidate will always skip the Mac OS X backend,
as the .check() method of BackendMacOSX in setupext.py returns None. Adding
return "darwin"
or some other string solves the issue.
Also, if I am not mistaken, the files under
lib/matplotlib/backends/Matplotlib.nib (as
-devel] Planning for 1.3.0
> To: "matplotlib development list"
> Date: Monday, April 15, 2013, 11:00 AM
> Hi Michiel,
>
> On 15.04.2013, at 6:03AM, Michiel de Hoon
> wrote:
>
> > --- On Sun, 4/14/13, Derek Homeier
> wrote:
> >> Of course if there are
nor comments that can
> probably be
> dealt with more efficiently in a PR.
>
> Mike
>
> On 04/12/2013 10:32 PM, Michiel de Hoon wrote:
> > Dear all,
> >
> > The animation code in matplotlib relies on timers to
> update the animated figures. Currently a n
Hi Derek,
--- On Sun, 4/14/13, Derek Homeier wrote:
> Of course if there are any other possible negative effects
> besides the window handling, I'd take your point.
Several bugs have been reported in the past that turned out to be due to Python
not being installed as a framework. For example, t
Hi Derek,
--- On Sun, 4/14/13, Derek Homeier wrote:
> The RuntimeError was enforced by the #ifdef
> WITH_NEXT_FRAMEWORK check that
> does not allow to use the backend at all, so I had to change
> this to a RuntimeWarning
> to be able to test the backend in the 1.3 branch.
This RuntimeError is th
ct: Re: [matplotlib-devel] Planning for 1.3.0
> To: "matplotlib development list"
> Date: Saturday, April 13, 2013, 9:03 AM
> Hi Michiel,
>
> On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:
>
> > The slow speed for long paths like the one in your
> example was
Dear all,
The animation code in matplotlib relies on timers to update the animated
figures. Currently a new timer is created by calling new_timer on a canvas, as
in
>>> f = pylab.figure()
>>> timer = f.canvas.new_timer()
This seems a bit of a wrinkle. For example, you may want to associate a t
Hi Derek,
The slow speed for long paths like the one in your example was due to a
limitation to Quartz itself. This was solved by breaking the path up into
subpaths of up to 100 points. But you mentioned that releases before 1.2 were
not slow (and I verified this with matplotlib 1.1.1), suggest
If we use autoconf for matplotlib, we may end up using a different compiler (or
compiler options) than what was used to compile Python itself. This can lead to
incompatibilities that will be very hard to figure out. As far as I understand,
using setup.py by default uses the same compiler and app
s in matplotlib make use of CXX, and would have to
be converted?
Best,
-Michiel.
--- On Fri, 11/30/12, Benjamin Root wrote:
From: Benjamin Root
Subject: Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
To: "Nathaniel Smith"
Cc: "Michiel de Hoon" ,
&quo
.
--- On Fri, 11/30/12, Chris Barker - NOAA Federal wrote:
> From: Chris Barker - NOAA Federal
> Subject: Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
> To: "Michael Droettboom"
> Cc: "Michiel de Hoon" ,
> "matplotlib-devel@lists.sourcefo
Hi,
The Mac OS X backend is entirely written in C (with some Objective-C elements
where necessary). AFAICT, this is the largest C/C++ code in matplotlib. This
backend was written from scratch without using Cython, SWIG, or Boost.Python.
From my experience, I would prefer to write such extension
Hi Eric,
I may be able to look at this over the weekend.
Best,
-Michiel.
--- On Sun, 9/2/12, Eric Firing wrote:
> From: Eric Firing
> Subject: backend_macosx linewidth bug
> To: "Michiel de Hoon"
> Cc: "matplotlib development list"
> Date: Sunday, Se
e from
> foreground color if present
> To: matplotlib-devel@lists.sourceforge.net
> Date: Friday, August 26, 2011, 10:20 PM
> On 08/26/2011 06:23 AM, Michiel de
> Hoon wrote:
> > Dear all,
> >
> > I am currently modifying the MacOSX backend to make
> its interactive/no
Dear all,
I am currently modifying the MacOSX backend to make its
interactive/non-interactive behavior consistent with the other backends in
matplotlib.
When I was testing the backend, I found a new bug that seems to be related to a
recent change in backend_bases.py:
https://github.com/matplot
OK, if there are no objections I will start making the appropriate changes to
the code and the documentation.
-- Michiel
On Sun Feb 27th, 2011 8:49 AM EST John Hunter wrote:
>On Sun, Feb 27, 2011 at 1:06 AM, Eric Firing wrote:
>
>> That's a good point. Until fairly recently, interactive behav
--- On Sat, 2/26/11, Eric Firing wrote:
> What about the non-interactive mode behavior--is it hard to
> make the MaxOSX backend behave like the others in that
> respect?
I agree that this should be done, but I just haven't found the time to look at
it (recently I have been looking at getting ani
> In any case it appears that with the exception of Tkinter, it may take a
> long time before interactive mpl backends can be used with py3k.
The MacOSX backend has already been ported to Py3k (at least the C part of it,
which is the largest and most difficult part of it), though I won't be able
Hi Hubert,
I just uploaded a fix for this bug to the matplotlib trunk svn repository (see
revision 8936). If you reinstall matplotlib from trunk, the bug should
disappear.
Best,
--Michiel.
--- On Thu, 1/27/11, Hubert Holin wrote:
> From: Hubert Holin
> Subject: [matplotlib-devel] MacOS X ba
Done.
Thanks,
--Michiel.
--- On Tue, 1/4/11, John Hunter wrote:
Michiel, can you review this and if it looks good contribute it to the 1.0.1
branch?
http://matplotlib.sourceforge.net/devel/coding_guide.html#version-control
Thanks,
JDH
--
If you use the MacOSX backend, you won't need pygtk, pycairo, pyqt, pygobject,
wx, tcl/tk, or anything they depend on, which was my main motivation for
writing this backend. Other than the fact that the MacOSX backend currently
does not support the non-interactive mode, it should work for you, d
--- On Wed, 11/17/10, Kynn Jones wrote:
>From a figure object:
figure.canvas.get_supported_filetypes()
returns a dictionary of supported file extensions, with mapping to more
detailed descriptions of each.
Yes,
but this solves the problem only for the non-GUI backends. It does not
w
--- On Sun, 10/24/10, Ryan May wrote:
> > One solution is to add an .animation attribute to the
> > Figure class, which is None by default (for non-animated
> > drawing).
> I'm not completely wild about it, because it just feels
> wrong to put something specific to animation inside figure.
OK I s
OK, thanks. Then it makes sense to implement blitting for the Mac OS X backend
as well.
Unfortunately I have hit one snag:
Drawing in Mac OS X / Quartz should be done from inside the event loop. You
cannot take a graphics context and just start drawing to it; the graphics
context won't be prope
Hello,
Recently I tried to get animations to work for the Mac OS X backend with the
new timer framework by implementing a TimerMac class that inherits from
backend_bases.TimerBase. This seems to work fine; the code is uploaded to SVN
if you'd like to try it.
I am not sure what to do about blit
--- On Sun, 10/10/10, Eric Firing wrote:
> Do you know anything about how Enthought packages their
> python and mpl for the Mac? Would it be as a framework?
Sorry, no idea. I haven't used the Enthought packages.
> If you think there is something that really should be fixed
> for the Mac to pre
The problem described in that bug report sounds similar to what happens if
Python was not installed as a framework. The Mac OS X backend checks for that
automatically, but the other backends do not as far as I know. If this is
indeed the problem, we should consider checking this when importing m
--- On Wed, 9/1/10, Brian Granger wrote:
> > So right now you're in a loop in which you let qt4 (or
> wx) watch the file descriptors qt4 needs, then zeromq the
> file descriptors that zeromq needs, and so on?
>
> ZMQ sockets are not really sockets in that they do not have
> a file descriptor inte
> 1. Our networking event loop that is based on zeromq/pyzmq
> 2. A single GUI event loop from wx, qt4, etc.
>
> We do this by triggering an iteration of our networking
> event loop on a periodic GUI timer.
So right now you're in a loop in which you let qt4 (or wx) watch the file
descriptors qt4
ct: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets
> and ipython
> To: "Michiel de Hoon"
> Cc: matplotlib-devel@lists.sourceforge.net, "IPython Development list"
> , enthought-...@enthought.com, "Evan Patterson"
>
> Date: Sunday, A
I implemented an event loop in the MacOSX backend and the PyOS_ImportHook event
loop in PyGTK, so I've been interested in this topic.
If I understand guisupport.py correctly, IPython runs the backend-specific
event loop. Have you considered to implement an event loop in IPython and to
run that
To avoid having to import MacOS, I've implemented the MacOS.WMAvailable()
function in src/_macosx.m. The updated version of backend_macosx.py doesn't
import MacOS; see revision 8625 in trunk.
--Michiel.
--- On Tue, 8/10/10, Derek Homeier wrote:
> From: Derek Homeier
> Subject: [matplotlib-de
--- On Thu, 7/22/10, John Hunter wrote:
> We could handle this on the agg side with a property,
> or require all canvases to supply get renderer.
>
Do we actually need a renderer in each of the backends? At least when I was
writing the Mac OS X backend, it was not clear to me what functionality
--- On Wed, 7/21/10, Tony S Yu wrote:
> I get something similar with TkAgg (unfortunately, I get an
> AttributeError with the macosx backend).
This is the AttributeError:
Traceback (most recent call last):
File "Desktop/tight_layout.py", line 142, in
tight_layout()
File "Desktop/tight_l
--- On Fri, 6/11/10, Eric Firing wrote:
> I agree that the difference in blocking behavior is still a
> problem. I think that what we should do for now, *if* multiple
> calls to show work on the Mac (which I can't easily test), is
> change the documentation to correspond to the present situation,
show(block=True) and show(block=False) to behave the same way.
--Michiel.
--- On Sat, 6/12/10, Eric Firing wrote:
> From: Eric Firing
> Subject: Re: [matplotlib-devel] repeated calls to show() are now OK?
> To: "Michiel de Hoon"
> Cc: "John Hunter" , "matplotl
--- On Sat, 6/12/10, Eric Firing wrote:
> > With TkAgg on Mac OS X, the first call to show()
> > blocks, and returns when all figures are closed by the user.
> > However, subsequent calls to show() return immediately.
>
> This is anomalous, then; on linux, no call to show blocks
> with tkagg.
>
> I agree that the difference in blocking behavior is still a
> problem. I think that what we should do for now, *if* multiple
> calls to show work on the Mac (which I can't easily test), is
> change the documentation to correspond to the present situation,
> highlighting the real problem of differ
Eric, Tony, thanks for your replies. I'll look at SciPy then for this
functionality.
Thanks,
--Michiel.
--- On Sat, 4/24/10, Eric Firing wrote:
> From: Eric Firing
> Subject: Re: [matplotlib-devel] Lowess smoothing
> To: "Michiel de Hoon"
> Cc: matplotlib-devel@l
When testing the cairo backend on Mac OS X, I did experience crashes with long
path lengths even with the current version (1.8.8) of cairo / pycairo. So the
path length check is still needed. I put it back in.
--Michiel.
--- On Mon, 2/22/10, Michiel de Hoon wrote:
> From: Michiel de H
so we know how many
points will actually be drawn.
--Michiel.
--- On Mon, 2/22/10, Eric Firing wrote:
> From: Eric Firing
> Subject: Re: [matplotlib-devel] Path length in the cairo backend
> To: "Michiel de Hoon"
> Cc: matplotlib-devel@lists.sourceforge.net
> Date: Mond
Dear all,
The draw_path method in backend_cairo.py starts with a check for the number of
vertices in the path, and raises an error if the path contains more than 18980
vertices:
def draw_path(self, gc, path, transform, rgbFace=None):
if len(path.vertices) > 18980:
rai
Do you get the segmentation fault also with other backends (e.g. Tkagg) or only
with the MacOSX backend?
--Michiel.
--- On Sun, 11/29/09, Matthew Brett wrote:
> From: Matthew Brett
> Subject: Re: [matplotlib-devel] Segmentation fault from fresh OSX snow
> leopard build
> To: matplotlib-devel
Eric Firing wrote:
> From: Eric Firing
> Subject: Re: [matplotlib-devel] Circular references in Figure
> To: "Michiel de Hoon"
> Cc: matplotlib-devel@lists.sourceforge.net
> Date: Sunday, November 8, 2009, 1:43 AM
> Michiel de Hoon wrote:
> > Hi everybody,
>
Hi everybody,
I was looking at this bug about a memory leak:
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
While this bug is now essentially fixed, I noticed that the Figure class
contains some circular references that prevent it from being cleaned up by th
According to this page from Apple:
http://developer.apple.com/releasenotes/OpenSource/PerlExtensionsRelNotes/index.html
you can use
env ARCHFLAGS='-arch i386' python setup.py build
I have tried this for 64-bits Python (using '-arch x86_64') and it seems to
work fine.
--Michiel.
--- On Wed, 8
> Is one of these two locations preferable for the
> default?
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
is preferable.
The location depends on whether the user has a framework Python or a normal
static Python installed. For GUI programs, a framework Python
Hi everybody,
Should the set_alpha method of a graphics context accept a string (instead of a
number) as an argument? Currently, some backends (agg, ps, pdf) accept strings
such as "0.2", whereas others (svg, cairo, Mac OS X) do not. Usually that is
not a problem, since in almost all cases set
ger wrote:
> From: Brian Granger
> Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based
> prototype of PyOS_InputHook for wx 2.8 and 2.9
> To: "Michiel de Hoon"
> Cc: "Robert Kern" , enthought-...@enthought.com,
> "matplotlib deve
The chunkiness probably comes from the fact that inputhook_wx is called
repeatedly. This is different from how PyOS_InputHook is being used in Tkinter,
PyGTK, and the Mac OS X backend.
Schematically, this is how the Tkinter/PyGTK/MacOSX event loops work:
1) PyOS_InputHook is called when Python
Hi everybody,
I believe a bug was introduced in revision 7002 of backend_cairo.py.
This code, in two places, now calls RendererCairo.convert_path with two
arguments (ctx and tpath), whereas RendererCairo.convert_path expects three
arguments. In one other place, RendererCairo.convert_path is cal
Recently I realized that there is a potential problem in both the Cairo and the
Mac OS X backend related to how graphics contexts are handled. I tried your
example and found that the Mac OS X backend shows the same incorrect result as
the Cairo backend, which makes me suspect that this bug is r
> I will have a look at the code for both PyGTK and OS X.
> Hopefully that will show me more of the best way of
> handling this.
The code in PyGTK is a bit easier to understand than the code for OS X. The OS
X code also includes stuff to handle SIGINTs (keyboard interrupts by ctrl-c),
which is
Hi Brian,
I wrote the code in PyGTK that uses PyOS_InputHook for interactivity, as well
as the Mac OS X native backend for matplotlib that uses PyOS_InputHook in
exactly the same way. PyQT and Tkinter also use PyOS_InputHook, though the code
is a bit kludgy on Windows. So I definitely agree tha
I am also finding the continuing increase in memory usage, but this also occurs
with other backends (I tried tkagg and pdf) and also without the call to
savefig. One possibility is a circular reference in the quiver function that
prevents data from being cleaned up.
--Michiel
--- On Mon, 1/19
I've written a patch that fixes this bug; see
https://sourceforge.net/tracker/?func=detail&atid=560722&aid=2508440&group_id=80706
--Michiel
--- On Mon, 1/12/09, Tony Yu wrote:
> From: Tony Yu
> Subject: [matplotlib-devel] Jagged plot in macosx backend
> To: "matplotlib development list"
> D
This is indeed a bug. In some places in the code, I was casting from double to
float (which is used by Mac OS X quartz internally) too soon. This created a
roundoff error, which shows up as the jagged plot. I am preparing a patch and
will submit it as soon as possible.
Thanks for reporting this
I've written a patch for the Mac OS X native backend to make use of the new
hatching support; see patch #2497785 at
https://sourceforge.net/tracker/index.php?func=detail&aid=2497785&group_id=80706&atid=560722
I tested this with the new hatch_demo.py in SVN trunk, and it seems to work
fine.
--M
> This seems like a reasonable change and I have added it to
> the trunk.
> It would be nice to get a canvas.draw_idle on the qt
> backend, so
> perhaps Darren you can add this to your list if you get
> some free
> time.
>
I have written such a function for the qt4 backend; see patch #2468809 at
> The interactive backends (wx, tk, gtk) all handle draw_idle
> in a way which delays the drawing until there are no
> more commands to run.
>
> By changing draw_if_interactive to use draw_idle instead of
> draw,
> wouldn't this automatically smooth over the performance
> issues without
> the user
> Could you post the script you are using to do the
> profiling?
This is the code that I was using
from pylab import *
import numpy
figure()
x=numpy.arange(20)
y=1+x**2
n = 4
for i in range(n*n):
subplot(n,n,i+1)
bar(x,y,log=True)
xlim(-5,25)
ylim(1,1e4)
> The call to subplot/
t as early as today in a bugfix release when some
> changes JJ and Michael are working on are ready, or the trunk, in
> which case it could be months.
> I'm in favor of branch, ...
Me too. :-).
--Michiel
>
> JDH
>
>
> On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoo
It appears that the 98.5.2 tarball is missing one file for the native Mac OS X
backend: src/_macosx.m is missing. The other file
(lib/matplotlib/backends/backend_macosx.py) is present.
--Michiel.
--- On Thu, 12/18/08, John Hunter wrote:
> From: John Hunter
> Subject: [matplotlib-devel] 98.5
5 66
--- On Tue, 10/28/08, Michiel de Hoon wrote:
> --- On Tue, 10/28/08, John Hunter
> wrote:
> > I haven't had a chance to look at the code yet,
> > but I suspect he hasn't implemented the
> > path collection draw method. If it's not
> > imp
--- On Tue, 10/28/08, John Hunter <[EMAIL PROTECTED]> wrote:
> I haven't had a chance to look at the code yet, but I
> suspect he
> hasn't implemented the path collection draw method. If
> it's not
> implemented, we fall back on drawing each path separately,
> which is a
> lot slower. scatter ulti
--- On Tue, 10/28/08, Christopher Barker <[EMAIL PROTECTED]> wrote:
> > 4) One drawback compared to the existing cocoa-agg
> >backend is that the latter allows easy integration
> >of matplotlib into a larger cocoa application,
> >whereas my backend only cares about matplotlib.
>
...
Hi everybody,
About two years ago, I wrote a backend for matplotlib on Mac OS X. This is a
native backend for Mac OS X, meaning that most of it is implemented in C
(Objective-C, to be precise) to fully make use of Apple's Quartz
graphics-rendering technology. I have been using this backend for
I think that this is a nice addition to the hexbin function. At first, I didn't
quite understand the documentation of the "C" functionality, but the new
hexbin_demo2.py example makes everything clear.
In theory, if reduce_C_function is len, then this gives the usual hexbin
result. It may be a g
75 matches
Mail list logo
