Re: [matplotlib-devel] Cairo backends and OpenGL use

[Chris Barker - NOAA Federal via Matplotlib-devel]

MPL does not have a backend that used “real” GPU rendering.

And it’s very hard to make one, due to the really low level nature of
OpenGL and similar APIs, and MPL’s rendering model.

You might try VisPy — it was designed for OpenGL from the start.


-CHB

Sent from my iPhone

On Jul 5, 2018, at 5:37 AM, Francesco Faccenda 
wrote:

Dear all,



I am writing to you because of an issue regarding the use of OpenGL in
cairo backends from matplotlib. As I set a cairo backend with the
instruction matplotlib.Use(“WXCairo”), there is evidence that the graphic
computation is not being carried out by the graphic card.

Since the significative amount of plotted data, the chart are heavy and
slow when the user is interacting with them, so a graphic acceleration
would be really appreciated.



As a side note, I am embedding matplotlib canvas on wxPython stages, that’s
why I choose WXCairo as backend, at first. However, setting other backends
(GTKCario, TKCairo, Qt4Cairo, Qt5Cairo etc) while still using wx, still
provides a working code without any errors, even if the graphic card is
still not exploited.

Is this an actual malfunction or am I missing something? What should I do
to run matplotlib graphic computation on a graphic card? Thank you in
advance.



Best regards,

Francesco Faccenda

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Make matplotlib running on GPU/CUDA

[Chris Barker]

On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda  wrote:

> I have to admit I already stumbled on VisPy while doing my research on the
> web. Still, I've got a lot of code already working with *matplotlib*.
> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
> to provide the users usefool tools, like lines picking, tooltips, lines
> copy/paste, square selectors for multiple selections, context menu and so
> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
> the beginning few lines were managed and noone complained, now that big
> amout of data has to be displayed, the non-GPU core of the library is
> starting to show its limits.
>
> Since matplotlib is a reference library for this kind of  applications, I
> thought it deserved an update in this direction.
>

Well, As I understand it, VisPY made some effort to be compatible with the
MPL API -- but that is going to depend on how much you use the lower-level
parts f the API -- things like the transform, etc. to take advantage of GPU
rendering, all the transforms, etc needs to be pushed to the GPU, so the
architecture (and API) needs to be quite different.


> If anyone is willing to do so, I'm available to discuss possible solutions
> and also provide any help I can give.
>

As Ben pointed out, and I was trying to make clear -- it really isn't a
matter of "just" writing an OpenGL backend -- there really needs to be a
major restructuring.

And VisPy is pretty much that project. Whether it is feature complete,
robust and maintained enough for your use-cases, I have no idea, but even
if not -- you'll probably be better off contributing to that effort than
starting all over with trying to make an GPU_based OPenGL back-end.

However -- maybe there is another option:

Taking full advantage of GPUs does require a full restructuring, but maybe
there are other ways to get better performance -- for instance, optimizing
the transform code, etc:

Using the GPU with PyCuda or [what the heck is the name of the more general
GPU-using lib??]

using numba

Maybe there is still room for Cython, etc

In short, profiling MPL carefully, to see where the performance bottlenecks
are:

With modern hardware, actually rendering stuff is no longer the slow part
of visualization. Rather, it's pushing data to the renderer, transforming
data etc.

This is why to take advantage of the GPU, you need to do the
transformations, etc on the GPU -- which the MPL architecture doesn't make
easy by dropping in a new back-end.

Which is why VisPy built a new architecture from the bottom up.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Make matplotlib running on GPU/CUDA

[Chris Barker]

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda 
wrote:

> But there’s a good news, I have a nice GPU available (an NVIDIA Tesla
> K40c), so I’d like to know if there is a way to make matplotlib run on it,
> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like  matplotlib API, built on OpenGL.

Unfortunately, it doesn't look like it's been updated in a while -- from
teh docs. But the gitHub project is active:

https://github.com/vispy/vispy

So maybe it's only the docs that haven't been updated!

But probably  a much better option than trying to shoehorn GPU rendering
into MPL.

The problem is that while MPL was designed to be "backend" independent --
so it is "easy" to plug in an alternative renderer, the rendering model is
not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Kivy backend

[Chris Barker - NOAA Federal]

On Mar 13, 2015, at 12:50 PM, Cyrille Rossant cyrille.ross...@gmail.com wrote:

 Exactly. Note that pushing data on the GPU is not that slow:

No -- and something has to be pushed to the video card at some point anyway.

But my experience is that if you need to push the data to the CPU,
that pretty much overwhelms the advantages you get by rendering on the
GPU.

And OpenGL only supports simple primitives -- so it's substantially
more a pain to do something as sole as render a filled polygon, let
alone a spline.

And yes, back In the day, it was faster to render on the video card,
but CPUs have gotten a lot faster, and memory busses not so much.

But whatever, I think we all agree that pushing the transformations to
the GPU is the big win.

-CHB

 in one
 second, you can send hundreds of millions of points on a modern GPU.
 However it would be a bit slow to send large amounts of data at every
 frame.

 GPU-based transformations are extremely fast, and you have full
 control on how they're implemented; in the end, it's just arbitrary C
 code that runs on the GPU on a per-vertex or per-pixel basis.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Kivy backend

[Chris Barker]

On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root ben.r...@ou.edu wrote:

  Probably what I am most interested in from OpenGL is its transforms stack.


OpenGL can't do anything with transforms that you couldn't do in python (or
C, or Cython). What it can do is push the transform computations to the
GPU(s) -- making for monstrously faster performance.

This is the problem with the current MPL architecture. It does all the
transforming outside of the back-ends, and assumes that the backends can
only render in 2-d pixel coordinates.

If we can re-factor to push the transforms to the back-end, most of them
could use the same generic code, but you'd have the option of the back-end
providing the transforms, which would buy you a LOT with Open GL, and could
maybe by you some with, say, wxAgg, as you could put the transforms in
C/C++ perhaps more efficiently.

Note that with OPenGL in general, its the transforming that buys you
performance -- when you push brand new data to be rendered, it takes a lot
of time to push that data to the video card, so drawing the first time
doesn't buy you much. But if you need to re-render that same data in a
different view, say zooming in or out, etc, then GL can fly -- if that
transformation can be done on the GPU.

As far as I understand it, that's what vispy is doing.

-CHB








 While matplotlib's transforms stack is fantastic, it is inherently limited
 to 2D operations. Upgrading the transforms stack in some way would be huge
 thing to me.

 On Fri, Mar 13, 2015 at 1:08 PM, Nicolas P. Rougier 
 nicolas.roug...@inria.fr wrote:


 It might be difficult to stick to matplotlib architecture and still
 benefit from OpenGL speed.
 There are a lot of GL techniques that speed up things a lot but are are
 not really compatible.

 For example, isolines, quiver plots, image interpolations and most
 transformations can be handled directly by the GPU
 (see http://glumpy.github.io/gallery.html)

 But we'll try to use matplotlib public api such that things will be
 mostly transparent for the user

 Nicolas

  On 13 Mar 2015, at 17:33, Benjamin Root ben.r...@ou.edu wrote:
 
  +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
 stuff to it! Does vispy have any plans to eventually bring that into
 mainline matplotlib, or does it break too much with the standard set of
 backends to make sense in matplotlib (or maybe it is too much of a
 maintenance/packaging burden?)
 
  Ben Root
 
  On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant 
 cyrille.ross...@gmail.com wrote:
  Kivy is all built on OpenGL, so it would probably be pretty
 straightforward to generate teh image with AGG, then dump it to the screen
 as an OpenGL texture. But it would be a bit sad to not take advantage of
 OpenGL at all in that process. (and getting AGG to work with Kivy may be
 less than trivial...)
 
  Note that vector graphics in OpenGL is a serious pain, but maybe Kivy
 has some stuff to help?
 
  Also, the MPL back-end structure wasn't designed to push much of the
 transforming, etc to the back -end, which is too bad, as that's what OpenGL
 does well.
 
  But I'd still take a look at the work done to make a real OpenGL
 back-end -- not sure how far that got, but worth a look.
 
  Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe
 not! form teh vispy docs:
 
  Vispy now ships a very basic and experimental OpenGL backend for
 matplotlib.
 
 
  Yes, and we plan to work on this backend in the next few months. We
 might have a couple of GSoC students working partly on the OpenGL MPL
 backend and possibly on Kivy integration.
 
 
 
 --
  Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
  by Intel and developed in partnership with Slashdot Media, is your hub
 for all
  things parallel software development, from weekly thought leadership
 blogs to
  news, videos, case studies, tutorials and more. Take a look and join the
  conversation now. http://goparallel.sourceforge.net/
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 
 
 
 --
  Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
  by Intel and developed in partnership with Slashdot Media, is your hub
 for all
  things parallel software development, from weekly thought leadership
 blogs to
  news, videos, case studies, tutorials and more. Take a look and join the
  conversation now.
 http://goparallel.sourceforge.net/___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR 

Re: [matplotlib-devel] Kivy backend

[Chris Barker]

On Sat, Mar 7, 2015 at 4:17 PM, Thomas Caswell tcasw...@gmail.com wrote:

 Thank your for your interest, mpl on touch devices sounds super cool!


Indeed!


 The easiest course is probably to develop a backend modeled after the
 {qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
 of choice.  In those cases we rely on Agg to handle the mpl specific
 drawing tasks and then embed the resulting bitmap into the GUI.


Kivy is all built on OpenGL, so it would probably be pretty straightforward
to generate teh image with AGG, then dump it to the screen as an OpenGL
texture. But it would be a bit sad to not take advantage of OpenGL at all
in that process. (and getting AGG to work with Kivy may be less than
trivial...)

Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has
some stuff to help?

Also, the MPL back-end structure wasn't designed to push much of the
transforming, etc to the back -end, which is too bad, as that's what OpenGL
does well.

But I'd still take a look at the work done to make a real OpenGL back-end
-- not sure how far that got, but worth a look.

Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
form teh vispy docs:

Vispy now ships a very basic and experimental OpenGL backend for
matplotlib.

HTH,
  -Chris







 A majority of the work in the gui backends deals window/widget creation
 and the plumbing required to convert interaction events from the GUI into
 the internal events mpl uses.

 Tom

 On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi rastogiach...@gmail.com
 wrote:

 Hello , I am a novice gsoc aspirant and I want to write a backend for
 kivy, I read some of the other conversations on the mailing list and I know
 about the template you guys provide but I am having trouble getting
 started, can you please help me get up-to speed. I would be great help if
 you could tell me what all I need to know of matplotlib  to write a good
 backend.
 Thank You
 Achyut Rastogi
 
 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib and Numfocus Fiscal Sponsorship Agreement (FSA)

[Chris Barker]

+1 -- sounds great!



On Tue, Jan 20, 2015 at 7:48 AM, Michael Droettboom md...@stsci.edu wrote:









 * Matplotlib is a widely used, well regarded, and powerful visualization
 library that has dominated the Python visualization stack for over a
 decade. However, to maintain that position, matplotlib must continue to
 evolve. Complementary or alternative libraries are appearing at an
 increasing rate, including browser-based plotting and GPU acceleration. To
 maintain its leadership position for the next decade, Matplotlib must
 interface with these alternatives while simultaneously expanding its
 capabilities and becoming easier to use and learn. Matplotlib’s large
 existing user base (greater than 50,000) means that new developments need
 to be carefully balanced with maintaining existing interfaces.  With the
 large user and code base comes a significant maintenance and user-support
 burden.  These responsibilities currently account for a majority of the
 core-developer time spent on matplotlib and has resulted in both the code
 base and community being in a healthier state than ever before. Even 6
 years ago there was no automated testing to speak of and the number of
 contributors continues to soar on github. However, this effort is, for the
 most part, done on a volunteer basis in the nights and weekends of the core
 developers.  To go beyond this maintenance level—to make step-change
 improvements for the benefit of matplotlib’s users—will require funding for
 full-time developers. Inspired and encouraged by the example of IPython, we
 would like to begin the process of fundraising. Managing funding on the
 needed scale is a complex and time-consuming process.  Thankfully,
 NumFOCUS, a 501(c)3 charity organisation co-founded by John Hunter, offers
 a fiscal sponsorship agreement to minimize the administrative and legal
 burden on open source projects. We would like to enlist NumFOCUS as our
 agents in all legal and financial matters, including banking, accepting
 donations as a non-profit, payroll, and access to legal counsel.  As part
 of the agreement, NumFOCUS would charge a percentage of all funds raised to
 cover their costs.  The full text of the agreement is attached. To comply
 with the legal and accounting requirements of a non-profit, matplotlib
 needs to form an administrative body to interact with NumFOCUS and direct
 the disbursement of any funds.  The proposed initial members of the body,
 are myself (Mike Droettboom), Eric Firing, Phil Elson, and Thomas Caswell,
 with Thomas acting as the point of contact with NumFOCUS. In practice,
 signing an FSA will have very little impact on the matplotlib project
 itself - it will still be BSD-licensed and community-driven as it has
 always been, and the only motivation for doing this is to give us an
 opportunity to apply for funding to do more work on matplotlib. We'd like
 to canvas the community's opinion on the matter, but to put a concrete
 timeline on the discussion, we would like to propose signing an FSA with
 NumFOCUS in 3 weeks (Feb 10th 2015) unless there is a major community
 discomfort with us doing so. Cheers, Michael Droettboom *

 --
 Michael Droettboom
 Science Software Branch
 Space Telescope Science Institute
 http://www.droettboom.com



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Date overhaul?

[Chris Barker]

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro s...@pobox.com wrote:

 I'm real naive about this stuff, but I have always wondered why
 matplotlib didn't just use datetime objects, or at least use
 timezone-aware datetime objects as an interchange format to get the
 timezone stuff right.


Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone
handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation   _may_ provide a similar hook in
the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly--e.g. from the pytz docs:

Unfortunately using the tzinfo argument of the standard datetime
constructors ‘’does not work’’ with pytz for many timezones.

So my suggestion is that MPL punts, and stick with leaving time zone
handling up to the user, I.e only use datetimes that are timezone naive.
What this means is that MPL would always a assume all datetimes interacting
with each other are in the same time zone (including same DST status).

Anyway, I'm being a bit lazy here, so I may be wrong, but I think the issue
at hand is that MPL currently uses a float array to store and manipulate
datetimes, and the thought is that it may be better to use numpy datetime64
arrays -- that would give us more consistent precision, and less code to
convert to/from various datetime formats.
I'm a bit on the fence about whether it's time to do it, as datetime64 does
have issues with the locale timezone, but as any implementation would want
to work with not-just-the-latest numpy anyway, it may make sense to start
now.

-Chris






-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Better defaults all around?

[Chris Barker]

On Wed, Nov 26, 2014 at 1:30 AM, Todd toddr...@gmail.com wrote:

 About this, I am not expert so forgive me if this is nonsensical.
 However, it would seem to me that these requirements are basically the same
 as the requirements for the new default colormap that prompted this whole
 discussion.  So, rather than create two inconsistent set of colors that
 accomplish similar goals, might it be better to instead use the default
 colormap for the line colors?  You could pick N equally-spaced colors
 from the colormap and use those as the line colors.


I'm no expert either, but while similar principles about colorblind
compatibility, etc apply, you want to sue a different scheme to represent a
continuous range of colors and a set of distinct colors that aren't
intended to be ranked.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] subtle design difference with Wx backend from others

[Chris Barker]

On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing efir...@hawaii.edu wrote:

 On 2014/11/23, 12:18 PM, Benjamin Root wrote:
  Reading through the backend_wx.py code, I noticed a small deviation from
  the other interactive backends. All other
  new_figure_manager_given_figure() separately creates a canvas and
  manager object (which, in turn, creates the window object) and hooks
  them all up. The manager would handle all window responsibilities such
  as creation/destruction and sizing. However, for the WX backend, this
  function just creates a FigureFrameWx object, which is the window
  widget. This object also becomes responsible for creating the canvas and
  the manager.
 
  This setup seems a bit backwards to me, but I am not entirely sure. It
  is definitely different. Does anybody know if it is merely a remnant of
  older designs (I think WX was the first backend)? What are the
  limitations of this approach, if any? Is there any interest in
  normalizing this backend design with the others (or vice versa)?

 In general, making the backends as similar as possible (and factoring
 out as much as possible) is good; but actually messing around with these
 things can be time consuming, painful, and hazardous.  It's hard to test
 with all the different platforms and versions.


Last I looked, and I doubt much has changed, the wx back-end required a
fair bit of love -- there was a lot of extra refresh() calls being made in
various places, most of which were unnecessary most of the time  -- i.e. a
bunch of extra refreshes. I've been hoping for literally years to find the
time to go in an clean that up, but not yet

So -- if someone can dedicate some time to clean up the wx back-end, then
it wold make sense to look into normalizing this, too. But I agree with
Eric, this is likely to be a significant job --  wouldn't tough unless
your'e ready to commit to some real work.

If it ain't broke.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] subtle design difference with Wx backend from others

[Chris Barker]

On Mon, Nov 24, 2014 at 9:41 AM, Benjamin Root ben.r...@ou.edu wrote:

 It is odd you mentioned the extra refreshes. I have to double-check my
 book examples, but I think I found that I needed to add some extra
 draw_idle() calls when using native wx widgets.


I haven't messed with widgets within MPL at all -- so I'm no help there.


 This does raise another point. As a development policy, how should we
 treat the backends? Should we be free to change it up so long as it works
 well with Matplotlib, or should we be cautious and recognize that there are
 users who go down beyond the canvas layer?


I've toyed with using the guts of MPL as a generic
for-something-other-than-plotting AGG renderer. But I think it's fair to
not support that kind of use-case with guarantees of backwards
compatibility.

I do think a just-agg-drawing lib would be  a nice think to have. So some
day, it may make sense to spilt it our out of MPL, and then we'd need to
worry about preserving the API, but while it's built into MPL, I wouldn't
worry about it.

-CHB







 Ben Root

 On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker chris.bar...@noaa.gov
 wrote:

 On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing efir...@hawaii.edu wrote:

 On 2014/11/23, 12:18 PM, Benjamin Root wrote:
  Reading through the backend_wx.py code, I noticed a small deviation
 from
  the other interactive backends. All other
  new_figure_manager_given_figure() separately creates a canvas and
  manager object (which, in turn, creates the window object) and hooks
  them all up. The manager would handle all window responsibilities such
  as creation/destruction and sizing. However, for the WX backend, this
  function just creates a FigureFrameWx object, which is the window
  widget. This object also becomes responsible for creating the canvas
 and
  the manager.
 
  This setup seems a bit backwards to me, but I am not entirely sure. It
  is definitely different. Does anybody know if it is merely a remnant of
  older designs (I think WX was the first backend)? What are the
  limitations of this approach, if any? Is there any interest in
  normalizing this backend design with the others (or vice versa)?

 In general, making the backends as similar as possible (and factoring
 out as much as possible) is good; but actually messing around with these
 things can be time consuming, painful, and hazardous.  It's hard to test
 with all the different platforms and versions.


 Last I looked, and I doubt much has changed, the wx back-end required a
 fair bit of love -- there was a lot of extra refresh() calls being made in
 various places, most of which were unnecessary most of the time  -- i.e. a
 bunch of extra refreshes. I've been hoping for literally years to find the
 time to go in an clean that up, but not yet

 So -- if someone can dedicate some time to clean up the wx back-end, then
 it wold make sense to look into normalizing this, too. But I agree with
 Eric, this is likely to be a significant job --  wouldn't tough unless
 your'e ready to commit to some real work.

 If it ain't broke.

 -Chris

 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR(206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115   (206) 526-6317   main reception

 chris.bar...@noaa.gov


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend

[Chris Barker]

On Tue, Nov 18, 2014 at 9:55 AM, Phil Elson pelson@gmail.com wrote:

 Isn't the XKCD stuff baked into the Agg backend. Is it even possible to
 produce XKCD svg or PDFs?


I wouldn't be surprised -- that's some pretty fancy stuff!

To the OP -- maybe you can use the cocoaagg back-end...

-CHB





 On 18 November 2014 17:01, Jens Nielsen jenshniel...@gmail.com wrote:

 I can reproduce it with the following traceback. Can you please open a
 bug report on Github for this issue?

 ```
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/site-packages/matplotlib/artist.py,
 line 59, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
   File /usr/local/lib/python2.7/site-packages/matplotlib/figure.py,
 line 1079, in draw
 func(*args)
   File /usr/local/lib/python2.7/site-packages/matplotlib/artist.py,
 line 59, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
   File /usr/local/lib/python2.7/site-packages/matplotlib/axes/_base.py,
 line 2092, in draw
 a.draw(renderer)
   File /usr/local/lib/python2.7/site-packages/matplotlib/artist.py,
 line 59, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
   File /usr/local/lib/python2.7/site-packages/matplotlib/lines.py, line
 712, in draw
 drawFunc(renderer, gc, tpath, affine.frozen())
   File /usr/local/lib/python2.7/site-packages/matplotlib/lines.py, line
 1067, in _draw_lines
 self._lineFunc(renderer, gc, path, trans)
   File /usr/local/lib/python2.7/site-packages/matplotlib/lines.py, line
 1107, in _draw_solid
 renderer.draw_path(gc, path, trans)
   File
 /usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py, line
 115, in draw_path
 rgbFace)
   File
 /usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py, line
 217, in draw_path
 renderer.draw_path(gc, tpath, affine, rgbFace)
   File
 /usr/local/lib/python2.7/site-packages/matplotlib/backends/backend_macosx.py,
 line 58, in draw_path
 gc.draw_path(path, transform, linewidth, rgbFace)
 AttributeError: GraphicsContextBase instance has no attribute 'draw_path'
 ```

 best
 Jens

 On Tue, Nov 18, 2014 at 4:12 PM, Mark Bakker mark...@gmail.com wrote:

 Sorry, forgot to mention that: 1.4.0

 On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root ben.r...@ou.edu wrote:

 Which version of matplotlib are you using?

 On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker mark...@gmail.com
 wrote:

 Hello list,

 I don't seem to get xkcd to work in the MacOSX backend. When I try to
 make a plot I get a nice white figure with nothing on it. Here's what I 
 did:

 import matplotlib.pyplot as plt
 %matplotlib # responds with Using matplotlib backend: MacOSX
 plt.plot([1,2,3])  # gives white figure with nothing on it

 When I do a kernel restart and specify the qt backend it works fine
 (so I have a workaround), but I presume it should work, right?

 Thanks,

 Mark



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and
 Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration 
 more
 Get technology previously reserved for billion-dollar corporations,
 FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports 

Re: [matplotlib-devel] google summer of code student

[Chris Barker]

On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell tcasw...@gmail.com wrote:

 We should be a mentoring organization for next summer.


well, maybe. A few years ago Google shifted to preferring fewer, larger,
mentoring organizations. So python projects have tended to be handled under
the PSF-sponsored organization.

Or we could go half-way, and have a numfocus one..


 we need to have a list of viable projects for a

summer student.  I suspect that these will have to have a balance
 between importance (to justify doing it) and shiny-ness (to get
 students to _want_ to do it).


It's a good idea to develop this list regardless of the sponsoring
organization structure.

 -Chris
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Purpose of doc/conda-recipes ?

[Chris Barker]

On Thu, Sep 11, 2014 at 1:07 PM, Sandro Tosi mo...@debian.org wrote:

 Hello,
 I've noticed in 1.4.0 the presence of doc/conda-recipes dir; from what
 I got from the doc it's a build system for Anaconda Continuum systems.


yes conda is that -- but it's also open-source and can be used outside of
Anaconda. I think it makes a lot of sense to have a conda recipe in with
the package source.

May I ask what is the purpose of this directory? if it's for building,
 why is it in the doc subtree?


I'm going to guess because it isn't (or wasn't) and official way to build
MPL. but I think it should probably go in the main source dir, alongside
setup.py -- conda is being pretty widely used these days.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Anaconda Support] OSX: why not make python invoke the framework?

[Chris Barker]

On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer aaron.meu...@continuum.io
wrote:

 The only potential issue I can think of for making python=pythonw is
 that pythonw is a shell script:


I agree -- that could create issues (though will mostly work, I suppose)

But somehow the python.org build has managed to make a pythonw that IS a
proper executable:

ORRW-M-1275474:bin chris.barker$ pwd
/Library/Frameworks/Python.framework/Versions/2.7/bin

ORRW-M-1275474:bin chris.barker$ ls -l pythonw
lrwxr-xr-x  1 root  wheel  8 Jul 16  2013 pythonw - pythonw2

ORRW-M-1275474:bin chris.barker$ ls -l pythonw2
lrwxr-xr-x  1 root  wheel  10 Jul 16  2013 pythonw2 - pythonw2.7

ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7
-rwxr-xr-x  1 chris.barker  admin  9180 May 13  2013 pythonw2.7

ORRW-M-1275474:bin chris.barker$ file  pythonw2.7
pythonw2.7: Mach-O executable i386

(yes, ti works for 64 bit too -- this just happens to be what I have)

It would be nice if Anaconda would do it the same way.

-Chris







 #!/bin/bash
 export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python
 /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@

 This is needed because otherwise Python thinks its sys.prefix is
 ../../ from the executable, i.e.,
 /Users/aaronmeurer/anaconda/python.app/Contents/MacOS

 $~/anaconda/python.app/Contents/MacOS/python
 Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03)
 [GCC 4.2.1 (Apple Inc. build 5577)] on darwin
 Type help, copyright, credits or license for more information.
  import sys
  sys.prefix
 '/Users/aaronmeurer/anaconda/python.app/Contents'

 I'm not sure what kinds of issues this would cause having python be a
 shell script rather than a Mach-O 64-bit x86_64 executable (or a
 symlink to a Mach-O 64-bit x86_64 executable).

 I suppose you could do this (replace 3.4 with 2.7 if you use Python 2):

 $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig
 $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4

 and see if anything breaks (or if you don't want to risk breaking your
 main Python install, do it in a separate conda environment).

 Aaron Meurer

 On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier
 de...@astro.physik.uni-goettingen.de wrote:
  On 14 Aug 2014, at 11:40 pm, Chris Barker chris.bar...@noaa.gov wrote:
 
  On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing efiring.oc...@gmail.com
 wrote:
   but as far as I can see, on OSX, there is no *advantage* to
 non-framework python.  Is this correct?
 
  Suggestion for anaconda:
  make bin/python a link to ../python.app/Contents/MacOS/python
 
  NOTE: the python.org python build has been doing this (or something
 like it) for years and many versions -- I had gotten pretty used to it and
 was pretty annoyed when I discovered Anaconda keeps anon-framework binary
 as the default.
 
  It was annoying enough that I had to explicitly call pythonw (or alter
 the #! line) for my wxPython scripts, but with ipython it's even worse --
 how would I start up ipython with a framework build?
 
  NOTE: if the Anaconda folks really think there is a real downside to
 using the framework executable for the default python, maybe the ipython
 start up script could use pythonw ?
 
  Eric - have you tried recent MPL with the python.org builds to confirm
 the issue? I'm a bit surprised that it would even semi-work -- when I try
 wxPython with the regular executable, I get an error message and it wont
 run at all.
 
  Just to make sure I understand - this is about whether the MPL macosx
 backend would run with non-framework
  Python at all? It certainly should not, as _macosx.m has been enforcing
 an error in this case for some versions.
  That put aside, when I disable the error at the end of _macosx.m I found
 the OSX backend to still work as it used
  to under OS X 10.9 with the Fink Python installation (which is not built
 as a framework, and unfortunately unlikely
  to change in foreseeable time). I.e. the only obvious problem is the
 lack of control by the window manager.
  Overall I still find it to perform better than any of the alternative
 backends. But having switched to PyQT4 as the
  default backend due to the above Fink troubles, I did notice some
 oddities under Mavericks. I have no idea if they
  are related to the problems Eric had originally reported, but they are
 clearly Mavericks-specific:
 
  When using MPL with ipython --pylab and the Quartz version of PyQT4, the
 interpreter seems to be slow down
  extremely after running for a little while. Weirdly this is not
 connected to any graphics display and in fact happens
  even without any plotting window opened, i.e. the ipython shell just
 randomly becomes completely unresponsive
  and hangs for several seconds on simple tasks like typing or navigating
 through history. The plotting itself actually
  does not appear to perform any worse than it used to under Mountain Lion.
  None of this seems to occur with the X11 variant of PyQT4.
  When

Re: [matplotlib-devel] [Anaconda Support] OSX: why not make python invoke the framework?

[Chris Barker]

On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing efiring.oc...@gmail.com
wrote:

  but as far as I can see, on OSX, there is no *advantage* to non-framework
 python.  Is this correct?

 Suggestion for anaconda:
 make bin/python a link to ../python.app/Contents/MacOS/python


NOTE: the python.org python build has been doing this (or something like
it) for years and many versions -- I had gotten pretty used to it and was
pretty annoyed when I discovered Anaconda keeps anon-framework binary as
the default.

It was annoying enough that I had to explicitly call pythonw (or alter the
#! line) for my wxPython scripts, but with ipython it's even worse -- how
would I start up ipython with a framework build?

NOTE: if the Anaconda folks really think there is a real downside to using
the framework executable for the default python, maybe the ipython start up
script could use pythonw ?

Eric - have you tried recent MPL with the python.org builds to confirm the
issue? I'm a bit surprised that it would even semi-work -- when I try
wxPython with the regular executable, I get an error message and it wont
run at all.



  (On 2.7, I think this would also make wxpython applications work, but I
 haven't checked recently.)


yup -- it should -- does for me anyway.

If there is some reason why this default to a framework is not a good idea,
 and/or cannot be implemented very soon in Anaconda, then I think we need to
 immediately remove macosx as a default in matplotlib.  A situation where a
 new Anaconda user fires up ipython and tries to plot, and it fails, is
 intolerable.


for what it's worth, I get odd os-x errors trying to se default MPL with
Anaconda as well -- haven't tried pythonw for that yet. (kludged it by
using the Agg back end only)


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Please Build the doc as HtmlHelp

[Chris Barker]

On Wed, Jul 30, 2014 at 11:20 AM, Gary Setter garyset...@yahoo.com wrote:

  Thank you for all the responds concerning Html Help. If someone would
 build using *class *sphinx.builders.htmlhelp.HTMLHelpBuilder  and upload
 the outputs were I can get them,


It would probably be easier to clone the repo, install sphinx, and do that
step yourself...

But thanks for offering, this would be nice for some folks.

-Chris





  I have a HTML Help workshop installed on my desktop. I would gladly
 setup the project and build the dot chm file. I'll send the results were
 ever you wish.
 Best regards,
 Gary Setter



 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris Barker]

Hi Russell,


 Makes we
  think we can drop 32 bit support, too. Maybe the newest 2.7 py.org
 binaries
  could be 64 bit only. It would simplify things a bit.

 I hope you will not drop 32-bit support yet.. I still use it to
 distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk
 8.5 have a nasty crashing bug that I have not found a workaround for,
 and old enough versions that don't have the bug need to run in 32-bit
 mode on Mavericks.


Darn. I guess it's not uncommon that even folks with a 64 bit machine may
need a lib or something that is 32 bit only -- so maybe good to keep it.
But it really is a pain -- and this example is supposed to be part of
Python's stdlib!

On Tue, Jun 3, 2014 at 1:44 PM, Matthew Brett matthew.br...@gmail.com
 wrote:

Do you need 32 bit support for the wheels or just for the MacPython
 binaries?   It's getting harder to build 32 / 64 bit universal
 binaries these days...


Exactly -- will an Intel  Universal Python pick up a 64 bit-only wheel?

That would be OK for most folks, I guess, though I'd really prefer it if
things were more clear -- you have a 32/64 bit python, you install wheels
and it works fine for you, so distribute via py2app, then it crashed when
run in 32 bit mode...

Oh well.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris Barker]

On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett matthew.br...@gmail.com
wrote:

 I want to rename the matplotlib wheel OSX wheel files on pypi so they
 will also install into homebrew, macports and system python.


+1



 matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl


what is this going to do on OS-X 10.7 and 10.8  systems running homebrew or
macports pythons? It seems this list could get pretty long!

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris Barker]

On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett matthew.br...@gmail.com
wrote:

  what is this going to do on OS-X 10.7 and 10.8  systems running homebrew
 or
  macports pythons? It seems this list could get pretty long!

Yes, it could, but this list:

 so we would have to add all those if we wanted to support them...



 https://www.adium.im/sparkle/?year=2014week=22graph=bar#osVersion


very interesting stats! I wonder how representative those are? Makes we
think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries
could be 64 bit only. It would simplify things a bit.


 suggests that 10.9 is the majority, and that 10.8 and 10.7 are only
 about 14 percent combined.  I guess a better case could be made for
 10.6 (still 16 percent), but I wonder how many 10.6 hold-outs are
 updating their homebrew / macports numpies regularly.


not many -- it can be a really a pain to do so -- macports and homebrew
really expect you to have a recent compiler, which I think is difficult or
impossible to install on 10.6...

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] unused variables

[Chris Barker]

On Thu, Mar 6, 2014 at 1:23 PM, Skip Montanaro s...@pobox.com wrote:

 Despite our wish that it wasn't so, it is likely that there is far
 more undocumented than documented code out in the wild, or behind
 firewalls where we can't see it.


Well, then you're hosed anyway -- relying on the name of an unused variable
using a call for your docs is, shall we say not very robust.

In my experience, there's no
 real need to be intentionally obscure by not giving a variable a
 meaningful, whether or not you intend/expect to use it. Besides, open
 source code can serve as a living example of good coding practices.
 Might as well do our best in that regard.


then use unused_meaningful_name

it looks like pylint, anyway, will accept that.

Or is the goal here to come to a consensus for MPL style?

If so, I'm +1 on _, and -0 on unused_meaningful_name

-Chris






 Just sayin'...

 Skip


 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to
 Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works.
 Faster operations. Version large binaries.  Built-in WAN optimization and
 the
 freedom to use Git, Perforce or both. Make the move to Perforce.

 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Chris Barker]

On Fri, Oct 25, 2013 at 3:32 PM, Todd toddr...@gmail.com wrote:

 I think one thing that contributes a lot to the API issues is the
 inconsistency between pyplot API and the OO API.  There isn't any reason
 the APIs need to be so different.


indeed.

I hadn't even realized how different they were.


 So the idea would be to have essentially all of the pyplot functions just
 be wrappers for methods from other classes, using the same name and same
 call signature (minus self).  All of the actual functionality would be
 implemented in the methods, the pyplot functions should not have any logic
 or tests.


+ inf

However, doing this with full backward compatibility could be a real
challenge...

This will make it easy to transition between the two, learning to use the
 OO interface would just involve learning what object the pyplot function is
 targeting (this should be in the pyplot function docstring).


That would help, though a namespace without any non-OO stuff would be still
be good, and, of course, docs and tutorials.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Chris Barker]

On Fri, Oct 25, 2013 at 6:34 AM, Benjamin Root ben.r...@ou.edu wrote:

 It doesn't feel weird. It feels generalized.


or both ;-)

It is the same way to add any number of plots, regardless if it is just
 one, or twenty. If you don't want to do it that way, you can just simply do:

 fig = plt.figure()
 ax = fig.gca()  # get current axes automatically creates an axes if one


rally ugly -- the whole point here is to get away from the concept of a
current anything -- I'm actually surprised that that's a figure method at
all...

 It does:

http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot
 This is *the* function that does axes creation for a figure, whether it is
 one, or many.



 subplots() is a recent addition.


And a nice one -- I've been wanting that for years! (and I
first discovered it in your tutorial, Ben!) The trick has always been that
plot() actually creates (If not re-using) three objects you might want to
work with: figure, axes, and line objects, so an oo interface that lets you
do that with one call is tricky -- I think this is a nice compromise.

We are in the process of updating our documentation. But add_subplot() is
 not going away because it works just fine, and it is very familiar to users
 of Matlab and Octave.


I've lost track a bit if there is support for a new OO-only API
(namespace), in which case, maybe some of this could be cleaned up as well.

I'd kind of like to see a fig.subplots() that has the same API as
plt.subplots(), for symmetry's sake, and because add_subplot() has a kind
of crufty API. Except it wouldn't return the figure instance (though it
could).

-Chris















 In principle I think the current API violates the There should be one--
 and preferably only one --obvious way to do it rule here, and elsewhere
 :-)


 I feel the way forward should be to create a cleaner API and map the
 current one through a compatibility layer to that.


 This has already been done. We have the GridSpec API that everything else
 maps to, for compatibility. But most people still like add_subplot() and
 subplots() for some odd reason... I think the primary issue is one of
 documentation, and we are currently in the process of upgrading that. We
 always welcome contributions to that effort!

 Cheers!
 Ben Root


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Chris Barker]

On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom md...@stsci.edu wrote:
 Here are the notes with action items from the meeting:

thanks for posting that. I see:

pylab - should it stay or should it go?

Comment from the peanut gallery:

Go.

But beyond that, matplotlib.pyplot is a big mess of both the
matlab-style state-machine current figure, current axis stuff, and
what you need to do (at least reasonably on the command line) OO
interface.

This makes it really hard to teach to newbies -- I just did this last
night, and made a point to use tutorials that emphasize the OO
interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
sure others that helped put the materials together that I stole
from...). However, there were still a number of examples in there that
just called plot() or whatever, and even if there were not, the
namespace is really cluttered with stuff!

Anyone like the idea of an matplotlib.ooplot namespace that would have
just what you need to use the oo style?

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] OS-X binaries?

[Chris Barker]

On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen ro...@uw.edu wrote:
 The last ones I got from you worked very well: just a few test failures
 and the current one seems to be doing about the same.

worked well for me too (something odd with wx back end re-rendering,
but I doubt that's a Mac build issue...)

I tok a quick look at your waf scripts and I couldn't tell how you are
handling the external compiled dependencies (png, zlib, freetype) --
are these statically linked in?

It'll be good to see these posted on the MPL download site.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] OS-X binaries?

[Chris Barker - NOAA Federal]

Are there recent binaries for OS-X anywhere? There don't seem to be
any for recent releases on the MPL download page.

I know we had a discussion about this a whole back, but don't remember
the outcome. But I hope we'll continue to put them up-- macports and
friends really aren't the best solutions for everyone.

Chris

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib user guide

[Chris Barker]

On Fri, Oct 18, 2013 at 11:56 AM, Benjamin Root ben.r...@ou.edu wrote:

 FWIW, I think my Anatomy of Matplotlib tutorial I gave at SciPy 2013
 struck a balance between pyplot and the OO interface.

Grat, I'll take a look.

Does the ipynb linked from the tutorial site have most of the
presentation material?

As it turns out, I need to give an intro to matplotlib class this week
-- I've been looking for some good materials to use -- why re-invent
the wheel?

I'll be sure to give you any feedback I have.

Hmmm.. this may be a time to put together a project of materials
designed to teach matplotlib in a classroom setting -- a little
different than a tutorial designed to be done on one's own.

There is a bunch of stuff scattered among scipy tutorials, bootcamp
lectures, etc, but having a central place to develop materials would
be nice.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Directories for C/C++ extensions

[Chris Barker]

 To expand slightly, with the current situation the onus is on us to ensure
 that mpl builds OK and passes all of our tests with and without each of the
 external libraries.

If you only have internal libs, then there is less to do -- it only
need to work with the version you bundle. And making sure it works
with any-old-version-that-may-not-exist-yet is a pretty formidable
challenge!

 Linux distro packagers will choose to set up qhull as a
 required dependency for their mpl package, and once they have done this can
 simply delete our directory containing the qhull source code in their mpl
 source package,

If they are going to insist on doing this, then, yes you should
certainly do it this way.

 we can all be confident that it will work correctly.

only if you've  tested against the version (maybe patched) of the
external lib they are using...

 If we always used our internal version then distro packagers would have to
 change our setup scripts to build using the external libraries.  This would
 be more time-consuming and error prone leading to less timely mpl distro
 releases.  We need to make their job as easy as possible.

it's easiest for them if they don't try to pull out an included
dependency -- but maybe you're right that that REALLY want to do that!

The needs of the distro packagers, which are primarily security and
 stability, are sometimes at odds with the needs of scientific software,
 where the premium is on reproducibility.  The output of matplotlib depends
 on the versions of some of its dependencies, not the version of matplotlib
 alone, and that's problematic for some...

exactly -- if we know exactly which version of a lib is in use, we
know that it works the way we expect in the use cases we expect to use
it in.

But I'm not maintaining this code, so have at it in the way that makes
sense to you.

NOTE: it would be a different story if this were a netwroking protocol
lib, or something where security patches would be critical. Maybe I'm
naive, but this doesn't seem likely in this case.

-Chris





-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib user guide

[Chris Barker]

On Fri, Oct 4, 2013 at 1:40 PM, Russell E. Owen ro...@uw.edu wrote:
 Introducing Plotting with Matplotlib

 Pyplot tutorial
 Controlling line properties
 Working with multiple figures and axes
 Working with text
 Interactive navigation
 Navigation Keyboard Shortcuts
 Working with text
 Text introduction
 Basic text commands
 Text properties and layout
 Writing mathematical expressions
 Text rendering With LaTeX
 Annotating text
 ...

 - Would you be willing to include a section on using the class API? (I'm
 assuming the above is all based on using pyplot?).

+inf

Even better, dump pyplot and use primarily the OO API. Asside from
folks that dont want to change anything when moving from Matlab, we
should all be using teh primarily OO API.

is it really that hard to type:

ax.plot()

rather than

plot() ?

And when you move away from interactive use (and we all should fi your
typing more than 4-5 lines of code) teh OO interface is a much better
way to go.

(I know, iPython notebooks allow you do do a LOT with esentially an
interactive interpreter, but still.)

Anyway, I've always thought it was a real shame that most of the
tutorials on MPL out there get people started on what I'm convinced is
the wrong foot.

- just my opinionated $0.02 worth...

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Directories for C/C++ extensions

[Chris Barker]

Ian,

 I am working on a PR to replace the use of matplotlib.delaunay with the
 Qhull library.

nice! -- ( though I sure wish Qhull did constrained delaunay...)

 Installation will be similar to the existing packages LibAgg
 and CXX in that if the system already has a sufficiently recent version of
 Qhull installed then matplotlib will use that, otherwise it will build the
 required library from the source code shipped with matplotlib.

Why bother, why not just always build the internal version?

(for that matter, same with agg)

Wouldn't it be a lot easier and more robust to be sure that everyone
is running the exact same code?

What are the odds that folks are using qhull for something else, and
even more to the point, what are the odds that the duplication of this
lib would matter one wit?

This isn't like LAPACK, where folks have a compellling reason to run a
particular version.

-- just my thoughts on how to keep things simpler.


-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] I have a Mac!

[Chris Barker - NOAA Federal]

On Fri, Aug 23, 2013 at 11:21 AM, Russell Owen ro...@uw.edu wrote:
 Here are my old instructions (I deleted them when I started using Apple's 
 libraries, but the wayback machine saves the day):

Thanks Russell -- this is helpful. A few comments:

 • If you plan to redistribute matplotlib, delete (or temporarily 
 move) the dynamic library so matplotlib statically links to libpng:
 % sudo rm /usr/local/lib/libpng*.dylib

I've found that passing --disable-shared works to prevent the dylibs
from being built at all. At least with libpng.

 • To check if a library is universal, run file on it, e.g.:
 % file /usr/local/lib/libpng*.a

this doesn't work for me on *.a files -- though it does on dylibs

 • Before building, you may wish to modify 
 include/freetype/configure/ftoption.h to enable hinting:
 • uncomment: #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER
 • perhaps comment out: #define 
 TT_CONFIG_OPTION_UNPATENTED_HINTING

handy to know.

Thanks,

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] I have a Mac!

[Chris Barker - NOAA Federal]

On Fri, Aug 16, 2013 at 3:41 PM, Hubert Holin hubert.ho...@free.fr wrote:
 Building for various architectures than one is on, on the 
 Mac, is something I regretfully bought into (Apple in the beginning told us 
 to go for it) but latter found out to be a useless hassle (Apple silently 
 removing PPC64 dev tools anybody? Urgh!)

 Bon courage

merci.

and I've felt your frustration, but it is setting down -- I know I
finally got rid of my old Mac G5 (nice machine to the end...), and I
think we can simply stick with Intel32+64 bit now, so not as bad.

And I do think there a real benefit to being about to provide
newbie-friendly option that just works on the Mac.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] I have a Mac!

[Chris Barker - NOAA Federal]

On Fri, Aug 16, 2013 at 7:32 AM, Michael Droettboom md...@stsci.edu wrote:
 We actually discussed this very issue yesterday in our Google hangout about
 continuous integration.  We're probably going to need to script a full setup
 from a clean Mac + XCode to a working matplotlib development environment in
 order to make that happen,

Just a note -- this did NOT just work the other day for me -- it
found the freetype libs that OS-X has in the X11 build, but didn't
like them at compile time. I haven't debugged it yet, sorry.

But the real trick here is what you want to build: which OS-X versions
do you want to support? which architectures? which Python Build(s)?

What I've been planning on doing is setting up a gitHub (or something)
project for building the various dependencies that various python
packages need -- there are a few that are broadly used: libpng,
libfreetype (used by MPL, PIL, wxPython, ???). The idea is that if you
wanted to build MPL (or PIL, or ???) you'd grab the
MacPyton_Dependencies project, build it, then go from there.

Anyone want to help? It just feels like we are all repeating
each-others work a LOT here!

NOTE: the big issues come up if you want to build binaries that are
re-distributable (as a package, or with py2app, or???). In this case,
you need binaries that can run on perhaps older machines than the one
you're building on, or a different architecture. Building to run on
the machine it's built-on is a lot easier. (particularly with macport
or homebrew)

-CHB








 and obviously that will be shared with the world.
 Things are even more complex on Windows, and I'd like to do that there, too.
 So stay tuned.

 Mike


 On 08/16/2013 10:02 AM, Paul Hobson wrote:

 Mike,

 That's great news. Is there any chance we can look forward to official
 instructions for setting up a Mac to develop matplotlib?

 I gave up a long time ago and started piecing to together my meager PRs in a
 linux VM.
 -paul


 On Fri, Aug 16, 2013 at 6:52 AM, Michael Droettboom md...@stsci.edu wrote:

 Thanks to the gracious donation from Hans Petter Langtangen and the
 Center for Biomedical Computing at Simula (http://home.simula.no/~hpl),
 I now have a new Mac Mini sitting at my desk.  This should allow me to
 keep on top of changes that affect the Mac builds and to better track
 down Mac-only issues.

 Stay tuned over the next few weeks and months as we will most likely be
 using some more of these funds to pay for hosted continuous integration
 services (as discussed yesterday in our MEP19 Google Hangout).

 Cheers,
 Mike




 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.

 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Calling to those embedding matplotlib in applications

[Chris Barker - NOAA Federal]

On Mon, Aug 12, 2013 at 7:01 AM, Michael Droettboom md...@stsci.edu wrote:
  I propose to fix this by turning on interactive only when
 running at an interactive console.

I embed MPL more than other uses, and this sounds like a fine solution to me/

Thanks,

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Calling to those embedding matplotlib in applications

[Chris Barker - NOAA Federal]

On Mon, Aug 12, 2013 at 11:16 AM, Michael Droettboom md...@stsci.edu wrote:
 Would you mind testing the very simple patch in the PR [1] and confirm
 that it has no negative consequences for you?

 [1] http://github.com/matplotlib/matplotlib/pull/2286

Hmm -- I'm not set up to build it right now -- but I'll see what I can do.

-Chris



 Mike

 On 08/12/2013 01:55 PM, Chris Barker - NOAA Federal wrote:
 On Mon, Aug 12, 2013 at 7:01 AM, Michael Droettboom md...@stsci.edu wrote:
   I propose to fix this by turning on interactive only when
 running at an interactive console.
 I embed MPL more than other uses, and this sounds like a fine solution to me/

 Thanks,

 -Chris




 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Setuptools and release candidate testing

[Chris Barker - NOAA Federal]

On Jul 24, 2013, at 7:23 AM, Michael Droettboom md...@stsci.edu wrote:


Part of this is due to the change to setuptools/distribute,


 Even though I was the one who spearheaded the move
to setuptools, I'm wondering whether we shouldn't examine backtracking
on some of this for the 1.4.x release.


I don't think so--in this case the timing was particularly bad, but the
core developers are pretty commited to setup tools/pip as the way of the
future, so these things will settle down.

And just like MPL has issues because many of us wait for final to test (
guilty as charged...) the distribution tools need to be tested by complex
packages like MPL in order to get robust and stable.

-CHB



The second issue is more one of process.  When I make a release
candidate, I announce it here, and Cc all of the packagers of the major
Linux distributions, as well as Christoph and Russell who put together
packages for Windows and Mac respectively.  Part of that delegation is
because I don't have installations of all of those platforms, and part
is to spread some of the workload.  And most of the time it works really
well -- a big thanks to everyone involved. However, this cycle there
have been a small number of critical bugs discovered in the fifth
release candidate that existed in the first release candidate, which
doesn't give me a lot of confidence that final won't have critical bugs
either.  I think some of this will be ameliorated over time as we build
out a more effective continuous integration infrastructure (see MEP19:
we could really use some help on this one), but some of it may have to
do with users being unwilling to test a release until it has the word
final attached. How can we get more ordinary users (who may have even
more unusual environments) involved?  I also suspect some of it has to
do with the timing in the summer which hits in the middle of vacations
and conference travel for many.  We can certainly avoid the summer
months next time.  But I don't think it's just about building more time
into the schedule.  Let me know if I'm doing something boneheaded ;)

Mike



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP14: Improve text handling

[Chris Barker - NOAA Federal]

On Thu, May 30, 2013 at 11:29 PM, Nicolas Rougier
nicolas.roug...@inria.fr wrote:

 I'm also concerned about the overhead of
 ctypes, given that there are already so many required optimizations in
 the matplotlib freetype wrapper to make it fast enough.  But I'm willing
 to hold judgement on that until some measurements have been made.


 I would never have thought ctypes would be a problem for speed/optimization 
 and I never benchmarked the freetype-py.

Well, I see it this way -- for high performing Python code, you often
need to vectorize operations one way or another. i.e. if you need to
do a given operation on a bunch  of numbers, objects, whatever, you
need to be able to pass the collection in to lower-level code, so you
dont have all the overhead of python funciton calls, dynamic typing,
etc, inside your loop.

Many (most) C libraries are not designed this way. So when writing
python wrappers, you need to loop though a sequence in python, and
call the underlying c function for each item. With ctypes, you write
that code inPython, with cython, it's easy to write that code in
cython, which gets compiled down to C -- you can get major performance
benefits from this.

And Cython is almost at easy to write as Python.

How this applied to freetype, I don't know.

 2) It's not Numpy-aware.  For example, it loads image buffers into
 regular Python lists.  This really should use Numpy for speed.

you can do this with ctypes, and would work fine for image buffers, by
many not as well as Cython for say, a large sequence of characters...

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ANN: matplotlib-1.3.0rc1

[Chris Barker - NOAA Federal]

On Wed, May 29, 2013 at 5:54 PM, Michael Droettboom md...@stsci.edu wrote:

 It looks like the ability to include pytz and other dependencies in
 binary distributions has been removed?

 It's really just that the matplotlib source no longer includes them.
 Binaries can be built however we want them to be.  Not knowing how the .dmg
 is put together, is it possible to add pytz, dateutil, pyparsing and six to
 the dmg during its creation?

I agree -- adding them to the binary package is the way to go here --
it's  packaging issue, not a development or building issue.

I can't imagine it would be hard to write a little script that
includes them all in one mpkg.

 Right -- and we're not using pip (because we can't) to handle our C/C++
 dependencies, many of which we continue to ship with matplotlib.

Should the code that's shipped with MPL be build-able with PIP? But
the harder issue is third-party dependencies that we expect the system
to provide: libpng, libfreetype, 

On the building side, I'd really like to see more support for this --
the Linux package managers handle it OK on LInux, but there is no good
system for Windows or OS-X.

I'm taking a look at gattai:

http://sourceforge.net/projects/gattai/

Mostly for the Mac, but it does support Windows and linux as well.

I'm not looking at Windows right now, as Christoph's repository gives
me all I need -- which makes me think:

Christoph, do you have a build system for all those that might be a
good basis for a multi-platform solution?

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP14: Improve text handling

[Chris Barker - NOAA Federal]

On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom md...@stsci.edu wrote:
 I've drafted a MEP with a plan to improve some of the text and font handling
 in matplotlib.

 I'd love any and all feedback.

nice writ-up and thanks for workign on this.

One idea (alternative?) would be to put more effort into the
mathtext renderer. TeX itself, of course does an outstanding job of
laying out text, paragraphs, etc. I'm assuming that the core stuff is
already in mathtext, so adding better support for regular old non-math
text would be a less-than-huge deal. And we still wouldn't need the
full how-to-split-pages and all that code for MPL.

Not sure about properly handling unicode issues, though modern TeX
does support unicode.

With a fully-function mathtex, it could be the default (only?) text
layout system for MPL, simplifying things quite a bit.

... just a thought.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ANN: matplotlib-1.3.0rc1

[Chris Barker - NOAA Federal]

On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen ro...@uw.edu wrote:

 I guess we could serve the associated packages (pytz, dateutil and six),
 or if they can be installed by pip, ask users to install those. But
 users using binary installers may not even have pip available, so it's a
 big initial hurdle.

If the binary installers are available (and easy to find), not such a
big deal -- this is teh case with Christoph's repository for Windows,
for instance.

Russell, have you been following the thread I started on the pythonmac
list? We really need a way to deal better with binaries on the Mac,
including dependency handling.

Note that supposedly the wheel format is coming (soon?), and after
that support for binary wheels by pip.

Of course, none of that helps right now...

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Chris Barker - NOAA Federal]

On Sat, Dec 1, 2012 at 6:44 AM, Michiel de Hoon

  Since the Python/C glue code is modified only very rarely, there may not be 
 a  need for regenerating the Python/C glue code by developers or users from a 
 Cython source code.

True.

 In addition, it is much easier to maintain the Python/C glue code than to 
 write it from scratch. Once you have the Python/C glue code, it's relatively 
 straightforward to modify it by looking at the existing Python/C glue code.

not so true -- getting reference counting right, etc is difficult -- I
suppose once the glue code is robust, and all you are changing is a
bit of API to the C, maybe


 This argues against making the Cython source code a part of the matplotlib 
 codebase.

huh? are you suggesting that we use Cython to generate the glue, then
hand-maintain that glue? I think that is a really, rally bad idea --
generated code is ugly and hard to maintain, it is not designed to be
human-readable, and we wouldn't get the advantages of bug-fixes
further development in Cython.

So -- if you use Cython, you want to keep using, and theat means the
Cython source IS the source. I agree that it's a good idea to ship the
generated code as well, so that no one that is not touching the Cython
has to generate. Other than the slight mess from generated files
showing up in diffs, etc, this really works just fine.

Any reason MPL couldn't continue with EXACTLY the same approach now
used with C_XX -- it generates code as well, yes?

Michael Droettboom wrote:

 For the PNG extension specifically, it was creating callbacks that can
 be called from C and the setjmp magic that libpng requires.  I think
 it's possible to do it, but I was surprised at how non-obvious those
 pieces of Cython were.  I was really hoping by creating this experiment
 that a Cython expert would step up and show the way ;)

Did you not get the support you expected from the cython list? Anyway,
there's no reason you can't keep stuff in C that's easier in C (or did
C_XX make this easy?). I think making basic callbacks is actually
pretty straightforward, but In don't know about the setjmp magic (I
have no idea hat that means!).

 The Agg backend has more C++-specific challenges, particularly
 instantiating very complex template expressions --

I'm guessing you'd do the complex template stuff in C++ -- and let
Cython see a more traditional static API.

 but some of that complexity could be reduced by using Numpy arrays in place 
 of the
 image buffer types that each of them contain

OR Cython arrays and/or memoryviews -- this is indeed a real strength of Cython.


 The Cython version isn't that much shorter than the C++ version.

I think some things make sense to keep in C++, though I do see a fair
bit of calls (in the C++) to the  python API -- I'm surprised there
isn't much code advantage, but anyway, the goal is more robust/easier
to maintain, which may correlate with code-size, but not completely.

 These declarations aren't exact matches to what one would find in the header 
 file(s) because Cython doesn't support exact-width data types etc.

It does support the C99 fixed-width integer types:

from libc.stdint cimport int16_t, int32_t,

Or are you talking about something else?

 I'm not sure why some of the Python/C API calls I needed were not defined in 
 Cython's include wrappers.

I suspect that's an oversight -- for the most part, stuff has been
added as it's needed.

One other note -- from a quick glance at your Cython code, it looks
like you did almost everything is Cython-that-will-compile-to-pure-C
-- i.e. a lot of calls to the CPython API. But the whole point of
Cython is that it makes those calls for you. So you can do type
checking, and switching on types, and calling np.asarray(), etc, etc,
etc, in Python, without calling the CPython api yourself. I know
nothing of the PNG API, and am pretty week on the CPython API (and C
for that matter), but I it's likely that the Cython code you've
written could be much simplified.


 Once things compiled, due to my own mistake, calling the function segfaulted. 
  Debugging
 that segfault in gdb required, again, wading through the generated code.  
 Using gdb on
 hand-written code is *much* nicer.

for sure -- there is a plug-in/add-on/something for using gdb on
Cython code -- I haven't used it but I imagine it would help.

Ian Thomas wrote:   
 I have never used Cython, but to me the code looks like an inelegant 
 combination of
 Python,C/C++ and some Cython-specific stuff.

well, yes, it is that!

 I can see the advantage of this approach for small sections of code, but I 
 have strong  reservations about using it for complicated modules that have 
 extensive use of
 templated code and/or Standard Template Library collections (mpl has examples 
 of
 both of these).

So far, I've found that Cython is good for:
 - The simple stuff -- basic loops through numpy arrays, etc.
 - wrapping/calling more complex C or C++
-- essentially handling the 

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Chris Barker - NOAA Federal]

On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom md...@stsci.edu wrote:

 but some of that complexity could be reduced by using Numpy arrays in place 
 of the
 image buffer types that each of them contain
 OR Cython arrays and/or memoryviews -- this is indeed a real strength of 
 Cython.

 Sure, but when we return to Python, they should be Numpy arrays which
 have more methods etc. -- or am I missing something?

Cython makes it really easy to switch between ndarrays and
memoryviews, etc -- it's a question of what you want to work with in
your code, so you have write a function that takes numpy arrays and
returns numpy arrays, but uses a memoryview internally (and passes to
C code that way). But I'm not an expert on this, I'mve found that I'm
either doing simplestuff where using numpy arrays directly works fine,
or passing the pointer to the data array off to C:

def a_function_to_call_C( cnp.ndarray[double, ndim=2, mode=c ] in_array ):

calls the_c_function, altering the array in-place

 cdef int m, n
 m = in_array.size[0]
 m = in_array.size[1]
 the_c_function( in_array[0], m, n )

 It does support the C99 fixed-width integer types:
 from libc.stdint cimport int16_t, int32_t,

 The problem is that Cython can't actually read the C header,

yeah, this is a pity. There has been some work on auto-generating
Cython from C headers, though nothing mature.  For my work, I've been
considering writing some simple pyd-generating code, just to make sure
my data types are inline with the C++ as it may change.

 so there
 are types in libpng, for example, that we don't actually know the size
 of.  They are different on different platforms.  In C, you just include
 the header.  In Cython, I'd have to determine the size of the types in a
 pre-compilation step, or manually determine their sizes and hard code
 them for the platforms we care about.

yeah -- this is a tricky problem, however, I think you can follow what
you'd do in C -- i.e. presumable the header define their own data
types: png_short or whatever. The actually definition is filled in by
the pre-processor. So I wonder if you can declare those types  in
Cython, then have it write C code that uses those types, and it all
gets cleared up at compile time -- maybe. The key is that when you
declare stuff in Cython, that declaration is used to determine how to
write the C code, I don't think the declarations themselves are
translated.

 It would at least make this a more fair comparison to have the Cython
 code as Cythonic as possible.  However, I couldn't find any ways around
 using these particular APIs -- other than the Numpy stuff which probably
 does have a more elegant solution in the form of Cython arrays and
 memory views.

yup -- that's what I noticed right away -- Im note sure it there is
easier handling of file handles.

 True.  We do have two categories of stuff using PyCXX in matplotlib:
 things that (primarily) wrap third-party C/C++ libraries, and things
 that are actually doing algorithmic heavy lifting.  It's quite possible
 we don't want the same solution for all.

And I'm not sure the wrappers all need to be written the same way, either.

-Chris
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Chris Barker - NOAA Federal]

On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith n...@pobox.com wrote:
 For the file handle, I would just write

   cdef FILE *fp = fdopen(file_obj.fileno(), w)

 and be done with it. This will work with any version of Python etc.

yeah, that makes sense -- though what if you want to be able to
read_to/write_from a file that is already open, and in the middle of
the file somewhere -- would that work?

I just posted a question to the Cython list, and indeed, it looks like
there is no easy answer to the file issue.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Chris Barker - NOAA Federal]

On Mon, Dec 3, 2012 at 12:24 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:

 but some of that complexity could be reduced by using Numpy arrays in place

 It would at least make this a more fair comparison to have the Cython
 code as Cythonic as possible.  However, I couldn't find any ways around
 using these particular APIs -- other than the Numpy stuff which probably
 does have a more elegant solution in the form of Cython arrays and
 memory views.

OK -- so I poked at it, and this is my (very untested) version of
write_png (I left out the py3 stuff, though it does look like it may
be required for file handling...

Letting Cython unpack the numpy array is the real win. Maybe having it
this simple won't work for MPL, but this is what my code tends to look
like.


def write_png(cnp.ndarray[cnp.uint32, ndim=2, mode=c ] buff not None,
  file_obj,
  double dpi=0.0):

cdef png_uint_32 width  = buff.size[0]
cdef png_uint_32 height = buff.size[1]

if PyFile_CheckExact(file_obj):
cdef FILE *fp = fdopen(file_obj.fileno(), w)
fp = PyFile_AsFile(file_obj)
write_png_c(buff[0,0], width, height, fp,
NULL, NULL, NULL, dpi)
return
else:
raise TypeError(write_png only works with real PyFileObject)


NOTE: that could be:

cnp.ndarray[cnp.uint8, ndim=3, mode=c ]

I'm not sure how MPL stores image buffers.

or you could accept any object, then call:

np.view()

-Chris



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Chris Barker - NOAA Federal]

On Mon, Dec 3, 2012 at 4:16 PM, Nathaniel Smith n...@pobox.com wrote:

 Yeah, this is a general problem with the Python file API, trying to
 hook it up to stdio is not at all an easy thing. A better version of
 this code would skip that altogether like:

 cdef void write_to_pyfile(png_structp s, png_bytep data, png_size_t count):
 fobj = objectpng_get_io_ptr(s)
 pydata = PyString_FromStringAndSize(data, count)
 fobj.write(pydata)

Good point -- not at all Cython-specific, but do you need libpng (or
whatever) to write to the file? can you just get a buffer with the
encoded data and write it on the Python side? Particularly if the user
wants to pass in an open file object. This might be a better API for
folks that might want stream an image right through a web app, too.

As a lot of Python APIs take either a file name or a file-like object,
perhaps it would make sense to push that distinction down to the
Cython level:
  -- if it's a filename, open it with raw C
  -- if it's a file-like object, have libpng write to a buffer (bytes
object) , and pass that to the file-like object in Python

anyway, not really a Cython issue, but that second object sure would
be easy on Cython

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Chris Barker - NOAA Federal]

On Fri, Nov 30, 2012 at 6:06 AM, Michael Droettboom md...@stsci.edu wrote:

 If you read between the lines of what I was saying, that is basically
 where I fall as well.  There seems to be a lot of desire to use Cython
 to make the code more accessible,

I'll add a beat to that drum -- I'm a big Cython fan.

 however, and I'm willing to consider
 it if it can be shown to be superior to the raw C/API for this task --

I think there is NO QUESTION that Cython is superior to the C/API --
why would you want to deal with the reference counting, etc yourself?
Cython can handle the boiler plate code for you very cleanly an
elegantly.

Something to keep in mind about Cython:

It can be used in multiple ways:

1) Add static typing to what is essentially Python code to get better
performance -- this may be what you mean by the more accesible part.
A great use, but maybe, maybe, maybe not best for the core bits of
MPL.

2) Calling C/C++ code -- Cython is s great way to call C/C++ code --
it can handle the packing and unpacking of python types, reference
counting, etc. for you, so much like using the C API, but a lot less
tricky boiler plate code to write.

(2) is the use case that I'm arguing is NO QUESTION a better option
than the C API.

Compared to SWIG, SIP (and I assume C_XX), the downside is that there
is no auto-generation of wrappers (at least nothing mature). However,
for the MPL case, we're not trying to wrap a large existing library,
but rather particular code that is often written for MPL specifically,
so hand-writing the Cython is a fine option.

So why not Ctypes, or??? I think the real strength of Cython in
wrapping C code is that you can write a thick wrapper in an
almost_python language. So if you want to vectorize a C function, for
instance, you can write that bit in Cython very easily (and Cython's
built-in understanding of numpy array is very helpful here). When you
use ctypes, you need to write that in pure Python -- easy enough, but
probably not very performant.

With SWIG, etc, you end up writing a fair bi tof C (or SWIG) code to
handle the thicker bits of the wrapper -- so you're dealing with the
raw CPython API, and , well, C. Cython really is an easier option.

I've found that for stuf that is less than very small (i.e. one or two
loops through an array), writing the core code in native C or C++ can
be easier, you know for sure you're not accidentally making expensive
Python calls, etc. but using Cython to call it is still very helpful.

 I'm not sure it is -- I always seem to end up with things that are more
 lines of code with more obscure workarounds than just coding in C directly.

Exactly -- but I don't think that applies to the CPython-API bits, but
rather the core code -- so keep that in C.

In summary, I guess what I think is the power of Cython is the
flexibility in where you draw the line between Python, Cython, and C
-- you can pass pure Python through Cython, or you can do almost
nothing with it but call a C function, and eveything in between.

 From my experience, I would prefer to write such extensions in C directly 
 rather
 than relying on Cython, SWIG, or Boost.Python, because those approaches would
 lead to another dependency (for developers at least),

The dependency is pretty easy to deal with compared to the many others in MPL.

 and requires developers to
 learn how to code in them. Which may not be very hard, but we may as well 
 avoid  that if possible.

Here's where I disagree -- if we go pure C and C-API developers need
to know the Python C-API -- that is actually a pretty big deal, and
hard to get right. Knowing enough Cython to call some C code is a
smaller lift for sure.

Anyway, I saw give it a shot -- I suspect you'll like it.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)

[Chris Barker]

On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas ianthoma...@gmail.com wrote:

 I think the code used to determine which triangle contains a certain point
 should be factored out into its own TriFinder class,

+1 -- this is a generally useful feature. In fact, it would be nice if
a lot of this were in a pacakge that deals with triangular meshes,
apart from MPL altogether (a scikit maybe?)

 I have a C++ TriFinder class
 that I could modify to work within matplotlib, and it is O(log N) so should
 be faster than your version for typical use cases.

What algorithm does this use? Is the code open source and/or availabel
for other projects?

I'm working on a package for working with unstructured grids in
general, and also have a use for what triangle is this point in code
for other purposes -- and I havne't found a fast, robust code for this
yet.

 particularly as only a few days ago I committed to writing a triangular grid
 interpolator for quad grids

what is a triangular interpolator for quad grids? sounds useful, too.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] PyGTK vs PyGObject

[Chris Barker]

On Oct 5, 2012, at 12:25 PM, Michael Droettboom md...@stsci.edu wrote:

 On 10/05/2012 02:53 PM, Chris Barker wrote:
 The upcoming pycairo version
 supports using image buffers (which can be Numpy arrays), but that's not
 helpful for drawing lines etc.


Thx-I did see some add-on code for using numpy arrays with pycairo once.

Maybe I'll look for that, and/or work on add-on code myself.

-Chris

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] PyGTK vs PyGObject

[Chris Barker]

On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom md...@stsci.edu wrote:

 We do use pycairo.  It certainly would get around the issue, but duplicate a
 lot of effort that pycairo already handles for us.

A bit OT -- but have you added, and or does pyCairo have, numpy-array awareness?

i.e. is there an efficient way to pass a lo tof coordinate parie,s etc
to pyCairo?

Just wondering, 'cause I'm trying to decide on a rendering lib to use
for another project.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Chris Barker]

On Wed, Oct 3, 2012 at 10:36 PM, Erik Bray erik.m.b...@gmail.com wrote:
 So as you wrote in the MEP, Numpy will simply have to be installed
 separately, I think, if the C++ modules require the Numpy headers.

Which is totally fine -- MPL requires a bunch of non-python
dependencies (OK, a few) anyway, so no matter how you slice it, you
need to get some stuf set up before you can build MPL.

Ideally, no on e needs to build MPL that would have trouble with this
requirement -- that's what binaries (and nifty linux .deb / .rpm ) are
for.

I personally prefer that dependencies are well documented, but not
necessarily auto-installed -- the auto stuff is just not reliable
enough.

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Chris Barker]

On Wed, Oct 3, 2012 at 2:08 PM, Christoph Gohlke cgoh...@uci.edu wrote:

A bunch of great stuff:

+1 all around

Another use-case is py2exe, py2app, and friends -- at the moment, you
pretty much have to include the whole dang MPL package to get things
to work. Cleaning up some of these dependencies could improve that.

-Chris


 On 10/3/2012 9:20 AM, Michael Droettboom wrote:
 I invite comments for a new MEP about improving the situation with
 respect to our bundling of third-party Python dependencies.

 In particular, I'd love feedback from the various stakeholders -- those
 producing binary installers and packages for the various platforms.

 https://github.com/matplotlib/matplotlib/wiki/MEP11

 Mike

 Hi,

 could dateutil, pytz, and pyparsing be made optional dependencies? I
 just tried, all of my own scripts do work without them being installed
 (one line needed to be removed in axes.py
 https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes.py#L19).
 Only about 10 of matplotlib's examples fail (after some additional
 changes).

 Frankly, I would remove/unbundle all 3rd party Python packages from
 matplotlib and declare them as dependencies for pip and easy_install,
 and of course in the documentation.

 I think that matplotlib, the library, should not attempt to work around
 Python's distribution/packaging limitations. Please do not use
 post-install or run-time scripts to detect and install missing
 dependencies.

 Concerning end user experience, the scipy-stack project seems like a
 better place to address this.

 Optionally, for Windows users that won't touch pip or easy_install (like
 me), matplotlib could provide separate downloads of installers for
 dateutil, pytz, pyparsing, and six. They are trivial to create.

 It is also easy to create EGGs or MSIs for matplotlib, which are
 occasionally requested.

 Also consider a separate package for the matplotlib tests, which would
 include 35 MB of baseline images that are of little use to end users.

 Christoph

 --
 Don't let slow site performance ruin your business. Deploy New Relic APM
 Deploy New Relic app performance management and know exactly
 what is happening inside your Ruby, Python, PHP, Java, and .NET app
 Try New Relic at no cost today and get our sweet Data Nerd shirt too!
 http://p.sf.net/sfu/newrelic-dev2dev
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] wxMPL patch

[Chris Barker]

On Tue, Sep 4, 2012 at 8:33 PM, Matt Newville
newvi...@cars.uchicago.edu wrote:

 Sorry for the delay I also haven't done anything about this... yet?   I
 might be more gung-ho to fold this into my wxmplot, which is fairly similar,
 but not exactly 1-to-1,  and has some name overlaps with wxmpl.   To be
 clear, I'm willing to refactor wxmplot to better accommodate  most of  the
 wxmpl interface,

Sounds like a great idea.

 What interfaces are you actually using from wxmpl?  I guess put another way:
 what do we want for a wx interface to matplotlib that's higher level than
 the standard backend.The PlotPanel and PlotFrames look close enough to
 merge.

Those are what I use -- actually, only the PlotPanel -- I generally
want to customize the Frame.


   The wxmpl StripCharter seems a little different from what I do with
 wxmplot, but perhaps that and the Channel class are easy enough to emulate.

Those are kind of higher-level stuff that's more suited to wxmplot, I
think -- as I don't use them, I don't care if you break the API -- but
that's just me.

 For how / where to host it, I don't much care.  Github and pypi seem easy
 enough.

I think it would be great to put it in the mpl repo as an mpl_toolkit
-- which means github, yes?


Thanks for taking this on!

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] wxMPL patch

[Chris Barker]

On Thu, Aug 30, 2012 at 9:22 PM, Carlo Segre se...@iit.edu wrote:
 Hi Chris:
 On Tue, May 1, 2012 at 9:31 AM, Benjamin Root

 AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect
 it
 would fit best as a mpl_toolkit.


 yes -- I figured that was most likely.

 Just a followup.  Has wxmpl been pulled into the toolkit source yet?

 Carlo

I haven't done anything, nor have I heard that anyone else has.

Care to take it on?

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] wxMPL patch

[Chris Barker]

Hi folks,

It seems Ken McIvor has more or less disappeared. However, his wxMPL
code is still useful and there are a few of us that are interested in
maintaining it.

What would be the procedure for getting it into a more official
location -- like maybe a matplotlib toolkit? Or even mixed right in
with the code (i.e. import matplotlib.wxmpl)?

It's one file -- there really isn't that much to it, but it's nice to have.

http://agni.phys.iit.edu/~kmcivor/wxmpl/

(the license looks BSD-ish to me)

Thanks,
   -Chris





On Mon, Apr 30, 2012 at 11:16 AM, Chris Barker chris.bar...@noaa.gov wrote:
 Hi Folks,

 I can't seem to find Ken McIvor -- Ken are you here?

 Anyway, here's a tiny patch of wxMPL to make it work with wxPython 2.9
 -- the only change is here, around line 1126:

       ## the following changed according to Robin Dunn's advice for 2.9
       ##    -- but it probably wasn't working right before!
        #topwin.Connect(wx.ID_ANY, self.GetId(), wx.wxEVT_ACTIVATE,
 self.OnActivate)
        topwin.Connect(self.GetId(), wx.ID_ANY, wx.wxEVT_ACTIVATE,
 self.OnActivate)

 This change works fine with wxPython2.8, also.

 Attached is the whole file.

 -Chris



 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR            (206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115       (206) 526-6317   main reception

 chris.bar...@noaa.gov



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] wxMPL patch

[Chris Barker]

On Tue, May 1, 2012 at 9:23 AM, Thomas Kluyver tho...@kluyver.me.uk wrote:
 On 1 May 2012 17:04, Chris Barker chris.bar...@noaa.gov wrote:
 (the license looks BSD-ish to me)

 At a glance, I think it's the X11 license, aka MIT license.


Would there be a problem bringing it in to MPL in that case?

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] wxMPL patch

[Chris Barker]

On Tue, May 1, 2012 at 9:31 AM, Benjamin Root

 AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect it
 would fit best as a mpl_toolkit.

yes -- I figured that was most likely.

 P.S. - Of course, you do realize that you are essentially making yourself
 the de facto maintainer of it, right?

Well, me or Matt or Carlo -- we'll fight over that among ourselves.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] jsxgraph or flot backend (or interactive viewer for svg backend?)

[Chris Barker]

On 12/5/11 9:49 PM, Jason Grout wrote:
 Has anyone ever worked on a backend that generates javascript code for
 one of the javascript plotters out there (like jsxgraph or flot)?
 Alternatively, I suppose we could generate an svg or html5 plot and then
 accompany it with the javascript code to trace the function, etc.

Someone has worked on a html5 back-end, It was jsut discussed a bit on 
the thread Using the Agg renderer by itself

Here's a cut and paste:

On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
 
  Ben is referring to mplh5canvas, available at
  http://code.google.com/p/mplh5canvas/. The main advantage of this
  approach is interactive zooming of plots within the browser. If this is
  not important to you, it will probably be faster to generate static PNGs
  or SVGs.
 
  The HTML5 backend should be easy to try out, as it is a pure Python
  package with no onerous dependencies.
 

-Chris







-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Using the Agg renderer by itself

[Chris Barker]

On 11/23/11 10:13 AM, Friedrich Romstedt wrote:
 2011/11/23 Chris.Barkerchris.bar...@noaa.gov:
 I've got some drawing to do (for a web app). I don't need all the MPL
 machinery, but I do need a high quality, fast, renderer.

 http://www.effbot.org/zone/aggdraw-index.htm

I've been wondering about that -- it doesn't look terribly maintained -- 
no updates for a long time, and I'm concerned about performance 99 if 
you are drawing something simple, but with lot's of points, all that 
conversion from numpy types to python type to C types is going to be an 
issue.

 http://www.effbot.org/imagingbook/imagedraw.htm

this is definitely slow for what I'm doing.

Thanks,
   -Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Chris Barker]

 As an additional note, if you are having difficulty compiling for 
 MacOS X, why not just ask for help with that?

yup -- there are some issues with which Tk is used by tkInter, but wx 
should be easy -- how have you tried to install?

-Chris


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Contouring unstructured triangular grids

[Chris Barker]

Ian Thomas wrote:
 On 15 April, Ian Thomas wrote:
 I've attached the patch for the new triangular grid functionality.
 
 As nobody has commented on the patch I submitted to add triangular
 grid functions, I can only assume that nobody has looked at it.

I have NO time to look at it, but I think it's great think to add.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] wx.AlphaPixelData() is failing on windows server 2003

[Chris Barker]

Michael Droettboom wrote:
 Is this bug related to matplotlib?  (i.e. does it happen only when 
 matplotlib is imported?)

It looks like you've done a pure-wx test, so it is a wx issue.

  If not, you may have more luck on the wxpython 
 mailing list.

yup, that's the place for it -- I suspect that windows server 2003 is 
old enough that it may not have the newer alpha-supporting drawing stuff 
-- that may be a dll that you could add, though.

You'll get a better answer on the wxpython-users list.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Can we retire numerix?

[Chris Barker]

Hi all,

I just ran into an issue with py2exe -- my app failed because various 
numpy sub-packages weren't included. However, I wasn't using them. But 
it failed because numerix imports them, and they weren't included 
because it imports them with __import__

Anyway, I can work around this, but it made me wonder: is it time to 
retire numerix? We all should be using numpy anyway.

note that the docstring is out of date, too:


1. The value of numerix in matplotlibrc: either Numeric or numarray

2. If none of the above is done, the default array package is Numeric.
Because the matplotlibrc always provides *some* value for numerix
(it has it's own system of default values), this default is most
likely never used.

To summarize: the  commandline is examined first, the  rc file second,
and the default array package is Numeric.


-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] wx back-end bugs/issues

[Chris Barker]

Hi all,

I usually use MPL embedded in wx, so I haven't noticed these before but 
with the pylab window:


1) A couple icons seem to be missing. See screenshot enclosed.

2) The save button doesn't work, as I get a cannot return std::string 
from a Unicode object error. This is with a unicode build of wxPython. 
I've had this same problem with my code. This issue is that the savefig 
code can't handle unicode (regular old fopen, I think). Here are two 
solutions:


1) use:

filename.encode('ASCII', 'replace')

on the string before using it, so that you'll get an odd name with 
non-ascii charactors but at least it will work.


2) Use:
F.savefig(open(path, w), dpi=dpi)

Python's open allows unicode filenames, and I was told that recent 
versions of MPL can take a file, rather than just aname, without an 
unacceptable performance hit, though in my code, without the latest MPL, 
I get an invalid PNG.


thanks,
-Chris






--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
inline: MPL_wx.png-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mpl1 + chaco

[Chris Barker]

Peter Wang wrote:
 Ah! and some good math implementation -- What does Chaco do for  
 that?

 We've also had this discussion internally a bit.  It usually  
 concludes with us wishing that someone would just port jsmath to  
 Python, or implement Knuth's TeX layout rules in Python. :)

It looks like jsmath uses the TeX layout rules, so those are the same 
thing. If you can do it in JS, you sure should be able to do it in Python!

  Currently Chaco2 doesn't have a math markup mechanism, but it was
 fairly trivial for me to port mpl's mathtext to Chaco1.  I didn't  
 bother moving that to Chaco2 because I really wanted to figure out a  
 way to do real TeX layout that would still fit into the interactive  
 model.

That would be nice. I agree, the Math-as-bitmap approach really isn't 
the way to go, but it does work OK in the meantime!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] mpl1 + chaco

[Chris Barker]

Peter Wang wrote:
 On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
 OK. I have to ask -- why aren't we all just using Chaco? 

 Most of ETS is being developed, tested, and run on Windows, Mac, and  
 Linux every day.

Ah, great to know -- that was decidedly not the case the last time I 
took a good look at Chaco.

  Long ago we factored out Chaco's  
 underlying drawing layer into a package called Kiva.

That was there from the beginning if I recall, which is great.

   Kiva's PS, PDF, SVG, and GL backends
 could all use a little love, but they were functioning at one point  
 in time.

Sorry to play devil's advocate here, but the question remains -- MPL 
developers (John, primarily, I suppose):

Why not dump MPL1, and work on a nice pylab-like front end to Chaco, 
while giving the love to the Kiva PS, PDF, SVG back-ends (and add GTK 
-- if it's not there)?

Most users, like me, just want something that does the job for us. I 
know I'm  going to take a look at Chaco again.

Add the skills of the MPL team to Chaco, and it could really shine!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mpl1 + chaco

[Chris Barker]

Darren Dale wrote:
 I need to create plots for qt4 projects at my lab, and I 
 have grown really accustomed to the quality of mpl's eps

So we need QT and EPS.

 output when usetex  is enabled.

Ah! and some good math implementation -- What does Chaco do for that? I 
know I took part in  a discussion about it on a Chaco list a few years 
back -- at  the time I argued that you're never going to do as well  at TeX.

These aren't deal-breakers so far -- it sounds like Kiva has at least 
rudimentary QT support -- and I imagine a MPL usetex-like approach could 
be applied to Chaco too (though I'd rather see the DVI parsed and 
rendered by Kiva...)

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel